Votre nouveau logiciel métier est presque prêt. La question de son hébergement arrive pourtant avec plusieurs réponses incompatibles : le prestataire recommande son cloud, la DSI veut conserver les accès et les utilisateurs doivent retrouver leurs dossiers sans changement de réseau. Choisir une machine ne résout pas encore ces contraintes.
Le bon choix sépare trois décisions : où l’application fonctionne, quels services elle utilise et qui en assure l’exploitation. Un serveur dédié peut être loué chez un hébergeur ; une machine virtuelle peut appartenir au SI interne ou à un cloud. La DSI reste un interlocuteur responsable, quelle que soit la localisation retenue.
Le bon arbitrage consiste à vérifier les dépendances et la capacité de reprise avant de comparer les offres d’infrastructure. Le risque est de déplacer les incidents dans un nouvel environnement, avec davantage de reprises manuelles et personne pour les diagnostiquer. Une solution simple, maîtrisée et restaurable peut mieux servir les métiers qu’une plateforme plus élaborée dont personne ne possède les procédures.
Dans une refonte de logiciel sur mesure, Dawap peut préparer une exploitation hébergée ou une livraison dans votre infrastructure. Le cadrage doit rendre explicites les responsabilités, les accès et les critères de réception, avec votre DSI et les intervenants concernés.
Dans quels cas faut-il revoir l’hébergement pendant la refonte ?
Un logiciel interne peut rester au même endroit si son environnement est maintenu, ses dépendances accessibles et son exploitation documentée. Le remplacement de son code n’impose pas automatiquement une migration cloud. À l’inverse, une application bien reconstruite restera fragile si elle dépend d’une machine hors support ou d’un unique compte administrateur.
Reprenez le choix lorsqu’un accès distant devient nécessaire, que les volumes évoluent, que l’ancien système doit cohabiter avec le nouveau ou que l’exploitant change. La décision doit aussi intégrer les périodes sensibles : clôture, commandes, préparation logistique ou traitements réglementaires. La fenêtre acceptable dépend de ces usages, pas du vocabulaire commercial de l’hébergeur.
Pour un simple changement d’infrastructure sans modification fonctionnelle, bornez le projet en conséquence. Mélanger nouvelles règles métier, migration des données et nouvelle plateforme dans une seule bascule multiplie les causes possibles d’un incident. Séparer ces transformations peut faciliter leur validation, lorsque leurs dépendances le permettent.
Cloud, VPS, serveur dédié et on-premise : comparer les bonnes dimensions
| Option | Intérêt possible | Point à vérifier |
|---|---|---|
| Serveur virtuel ou VPS hébergé | Environnement relativement simple pour une charge connue. | Qui met à jour le système, surveille l’espace disque et rétablit le service ? |
| Serveur dédié hébergé | Ressources réservées et configuration maîtrisée. | Quelles procédures couvrent une panne matérielle et la reconstruction sur une autre machine ? |
| Cloud avec services managés | Recours possible à une base, un stockage ou des composants exploités par le fournisseur. | Quelles tâches restent à l’équipe et quelle dépendance créent les services retenus ? |
| Infrastructure du client | Insertion dans les réseaux, outils et règles d’exploitation existants. | La capacité disponible, les délais d’accès et les compétences correspondent-ils au logiciel cible ? |
| Architecture hybride | Certains composants restent internes, d’autres sont hébergés ailleurs. | Comment l’application se comporte-t-elle lorsque la liaison ou un service distant devient indisponible ? |
Ces options ne constituent pas une échelle de qualité. Une architecture hybride ajoute des frontières à exploiter ; elle ne devient pas préférable par son seul nom. Un service managé réduit certaines tâches, mais ne prend pas automatiquement en charge les droits applicatifs, les règles métier ou la réception des données restaurées.
Le modèle de responsabilité partagée d’AWS illustre cette répartition : les tâches du client varient avec les services utilisés. Il faut lire les responsabilités du fournisseur réellement retenu, sans transposer mécaniquement celles d’une autre offre.
Trois profils pour éprouver le choix avant de signer
Un outil interne dont les dépendances restent dans le réseau du client
Cas fictif : une application de suivi de dossiers lit un ERP interne, dépose des documents sur un stockage partagé et utilise l’annuaire de l’entreprise. Les utilisateurs travaillent déjà dans un environnement administré par la DSI. Une cible interne peut limiter les nouvelles frontières, si les ressources, la sauvegarde et le support y sont disponibles.
Si la DSI ne peut pas fournir un environnement maintenu ou une personne pour recevoir les alertes, alors cette proximité réseau ne suffit plus. Comparez une exploitation déléguée dans le SI et une cible externe avec des échanges limités et contrôlés. La décision doit conserver un responsable du service complet, même lorsque plusieurs intervenants administrent ses composants.
Un portail externe qui échange avec un logiciel de gestion
Un portail professionnel doit être accessible aux clients, alors que les traitements de gestion restent internes. La première question porte sur les échanges nécessaires : lecture du catalogue, consultation des documents, création d’une demande ou confirmation d’une commande. Toutes ces opérations n’exigent pas forcément une connexion directe à chaque interaction utilisateur.
Un composant d’échange peut isoler certaines dépendances, mais il ajoute sa propre exploitation et un délai de propagation à accepter. Si le métier exige une confirmation immédiate de l’ERP, alors ce délai doit être pris en compte avant de proposer une copie locale des données. Une interface rapide qui affiche un état périmé peut déplacer la charge vers le support.
Une application dont la charge varie fortement pendant certains événements
Une campagne commerciale, une clôture ou une collecte périodique peut concentrer les opérations. Évaluez les ressources nécessaires au parcours et à ses dépendances : base de données, stockage, file de traitements et API tierces. Augmenter le nombre de serveurs web ne résout pas automatiquement une limite du système qui reçoit les écritures.
En réalité, la capacité à limiter temporairement un traitement ou à organiser une file peut être plus utile qu’une montée en charge automatique. Le métier doit accepter l’attente et voir l’état des opérations. L’équipe mesure ensuite le comportement sur un scénario représentatif, sans dimensionner toute l’architecture à partir d’un pic supposé ou d’un test sans ses dépendances.
Partir des dépendances au SI, pas du prix de la machine
Retrouver les échanges qui font fonctionner une journée métier
Inventoriez les API ERP et CRM, l’annuaire, le SSO, les fichiers échangés, les courriels, les tâches planifiées et les postes qui utilisent l’application. Pour chaque flux, identifiez le sens, l’authentification, la fréquence, les erreurs possibles et son propriétaire. Un export nocturne peut être plus critique pour la facturation qu’un écran fréquemment consulté.
Le signal faible est souvent un traitement connu d’un seul utilisateur : un dossier partagé monté sur un poste, une autorisation par adresse IP ou une commande lancée à la main. Le déplacement du logiciel peut interrompre ce chemin sans modifier son interface. Les entretiens métier doivent donc compléter l’inventaire technique.
Éprouver le trajet depuis l’environnement cible
Une API joignable depuis le réseau interne ne l’est pas nécessairement depuis le futur hébergement. Vérifiez résolution de noms, routage, certificats, identité et accès aux environnements de test. La réussite d’un appel authentifié doit être rapprochée du résultat métier obtenu, avec un périmètre et des données autorisés.
La checklist de déploiement dans le SI du client organise cette réception. Elle permet de traiter un accès manquant avant que la refonte dépende de lui pour sa première mise en production.
Nommer l’exploitant de chaque composant
« Hébergé chez nous » doit se traduire en tâches. Qui surveille l’application ? Qui reçoit une alerte ? Qui renouvelle un certificat ? Qui décide d’un correctif de sécurité ? Qui peut restaurer les données si l’interlocuteur habituel est absent ? Une adresse de support ne répond pas seule à ces questions.
- La direction métier fixe les conséquences acceptables d’une interruption et valide les parcours prioritaires.
- La DSI définit les conditions d’accès, les interfaces avec le SI et les exigences d’exploitation internes.
- L’équipe applicative maintient le logiciel, ses dépendances et ses procédures dans le périmètre convenu.
- L’hébergeur couvre les ressources et opérations définies par son offre, avec des exclusions à vérifier.
Pour les tâches partagées, nommez un responsable de décision et un exécutant. Une restauration peut mobiliser l’hébergeur pour les ressources, Dawap pour la compatibilité applicative et le métier pour la réception. Sans ordre d’intervention, chacun peut attendre que l’autre commence.
Comparer le coût complet et la capacité à faire évoluer
La facture de calcul et de stockage n’est qu’une partie du coût. Ajoutez les environnements de recette, sauvegardes, journaux, supervision, transferts, mises à jour, astreintes éventuelles et exercices de reprise. Une solution moins chère à louer peut demander davantage de travail récurrent à une équipe déjà occupée.
Comparez ensuite les changements prévisibles : volume de documents, nombre d’utilisateurs, horaires d’accès et nouveaux systèmes à connecter. Il ne s’agit pas de construire pour une croissance imaginaire. Il faut identifier ce qui pourra être augmenté simplement et ce qui nécessitera une nouvelle intervention ou une interruption.
Le second signal discret est une infrastructure provisionnée dans le compte personnel d’un intervenant ou sous un abonnement dont le client ne connaît pas les conditions. La maîtrise des contrats, comptes et moyens de paiement doit être organisée dès le cadrage, avec les accès nécessaires au modèle d’exploitation convenu.
Présenter une comparaison dont les exclusions restent visibles
Demandez la même description pour chaque option : ressources, environnements, stockage, protection des copies, interventions prévues et conditions de sortie. Un total n’est comparable que si les tâches absentes sont aussi recensées. Le temps de coordination avec la DSI, les exercices de restauration et les mises à jour ne deviennent pas gratuits parce qu’ils ne figurent pas sur la facture du serveur.
La comparaison doit distinguer coût de mise en place et coût récurrent. Pour chaque évolution probable, indiquez la personne qui estime, la dépendance qui peut bloquer et le délai d’intervention à prévoir. Ces informations rendent le budget discutable sans publier de prix standard qui ne correspondrait ni aux contraintes du SI ni au niveau de service réellement acheté.
Matrice de décision : retenir, différer ou écarter une cible
| Constat du cadrage | Décision proposée | Preuve à obtenir |
|---|---|---|
| Interfaces accessibles, exploitant désigné, reprise exercée. | Retenir l’option dans la comparaison finale. | Dossier de réception et coût complet du périmètre. |
| Chemin réseau ou identité encore non disponible. | Différer l’engagement de bascule. | Parcours exécuté depuis la cible avec les autorisations prévues. |
| Service managé dont la sortie reste inconnue. | Qualifier la dépendance avant de le rendre indispensable. | Export, reconstruction et assistance au transfert décrits. |
| Aucune personne ne reçoit les alertes ou ne peut restaurer. | Écarter la cible tant que l’exploitation reste sans responsable. | Responsabilités acceptées et exercice de reprise attribué. |
Cette matrice organise une décision de projet ; elle ne certifie pas une infrastructure. Conservez les entrées examinées, les sorties attendues et les réserves avec leur responsable. Une option peut revenir dans la comparaison lorsqu’une preuve manquante devient disponible. À l’inverse, un accès validé peut devoir être revu si l’application ou les politiques du SI changent.
Pour instruire une option, remettez à l’exploitant les entrées utiles : inventaire des dépendances, besoins d’accès et parcours de référence. Il renvoie les sorties du contrôle depuis la cible, les responsabilités acceptées et les réserves. Le dossier conserve les résultats, le contrat de service examiné et le repli proposé. Une cible ne devient admissible que lorsque les obstacles au parcours prioritaire ont reçu une réponse vérifiable.
Organiser le passage entre ancien et nouvel hébergement
Décrire l’ordre des interventions et le périmètre d’arrêt
Le plan de transition indique quand les écritures sont arrêtées ou redirigées, comment les derniers écarts sont repris et qui contrôle la cible. Les dépendances comprennent DNS, certificats, traitements planifiés, accès aux fichiers et systèmes partenaires. Chaque intervention doit produire une trace permettant de savoir quel état est actif.
Les entrées de la bascule comprennent le dernier état repris, les accès reçus et les dépendances disponibles. La journalisation relie ces éléments aux sorties attendues : cible active, traitements contrôlés et réserves attribuées. Prévoyez les contrôles de supervision immédiatement après ouverture. Un changement de domaine ou de cible peut laisser un ancien traitement fonctionner en parallèle. Le dossier doit expliquer comment l’équipe vérifie qu’un seul chemin réalise les effets qui ne doivent pas être dupliqués.
Préparer un repli dont les conséquences sont comprises
Le repli peut conserver l’ancien hébergement pour certains usages, remettre une version compatible ou interrompre temporairement une fonctionnalité. Il doit préciser ce que deviennent les nouvelles données et les opérations déjà transmises. La décision appartient à l’autorité prévue, avec les conséquences métier décrites avant l’intervention.
La suppression de l’ancien environnement vient après les vérifications convenues et la conservation des éléments nécessaires. À différer : l’arrêt d’un système dont un batch ou un partenaire dépend encore. À refuser : une bascule qui ne permet pas d’identifier qui écrit les données, où se trouvent les copies et quelle équipe peut agir sur un incident.
Préparer sauvegarde, restauration et sortie de l’hébergement
Une sauvegarde disponible chez le fournisseur ne prouve pas que le logiciel pourra redémarrer avec ses pièces jointes, ses configurations et une version compatible. Demandez quels éléments sont sauvegardés, comment les copies sont protégées et comment une restauration isolée est testée.
Le guide sauvegarde et restauration après une refonte fournit une fiche d’exercice. Les objectifs de perte de données et de délai de reprise se définissent avec les métiers ; ils ne découlent pas du seul choix cloud ou serveur dédié. Le plan de reprise de l’application métier relie ces objectifs aux dépendances et aux services à rouvrir.
La réversibilité se prépare aussi : export des données, récupération des documents, configuration, droits, dépendances propriétaires et assistance au transfert. Il faut connaître le coût et les étapes d’une sortie avant de dépendre d’un service difficile à remplacer. Le dossier de réversibilité applicative aide à formaliser ce passage de relais.
Identifier ce qui dépend d’un service propre au fournisseur
Une base, une file ou un stockage managé peut simplifier l’exploitation tout en créant des opérations de sortie spécifiques. Décrivez les données exportables, les formats, les fonctions utilisées et le composant qui devra éventuellement les remplacer. Le code source de l’application ne contient pas nécessairement les ressources nécessaires à son redémarrage ailleurs.
Demandez une preuve proportionnée sur une partie représentative : extraction lisible, récupération des objets et reconstruction du paramétrage nécessaire. Si la sortie exige une transformation, alors celle-ci doit être connue avec ses limites. Cette vérification ne conduit pas à refuser tous les services managés ; elle permet de choisir leurs bénéfices en comprenant la dépendance et la charge de transfert associées.
Cas fictif : un portail B2B relié à un ERP interne
Une PME veut remplacer un portail vieillissant. Son ERP reste dans le réseau interne, tandis que les clients professionnels commandent à distance. La DSI possède un hébergement existant ; le prestataire propose également une exploitation externe. Aucun de ces éléments ne tranche encore la décision.
La première étape teste les échanges catalogue, tarifs par compte et commandes depuis les deux environnements candidats. Si un accès ERP externe n’est pas disponible dans les conditions requises, l’équipe étudie un composant d’échange maîtrisé ou conserve le portail dans l’infrastructure interne. Elle ne transforme pas cette restriction en ouverture générale du réseau.
Le choix final s’appuie sur le parcours complet, l’exploitant désigné et une restauration réceptionnée. Cet exemple est illustratif : il ne décrit ni un déploiement client ni un engagement de service de Dawap. Il montre pourquoi la comparaison doit couvrir le SI et les utilisateurs avant les caractéristiques de la machine.
Erreurs fréquentes dans le choix de l’hébergement
Confondre redondance et sauvegarde
Un composant répliqué peut reproduire une suppression ou une donnée corrompue. Vérifiez séparément la continuité lors d’une panne et la possibilité de retrouver un état antérieur exploitable. Les deux répondent à des incidents différents et demandent des vérifications propres.
Décider sans l’équipe qui recevra le logiciel
Une architecture peut fonctionner pendant les démonstrations et rester inexploitable par son destinataire. Refusez une mise en production si les accès, les procédures ou les responsabilités indispensables ne sont pas disponibles. Différez les optimisations secondaires, mais pas les conditions minimales pour intervenir en cas d’incident.
Plan d’action : faire valider une décision d’hébergement
- Décrire les utilisateurs, horaires critiques, données et dépendances du logiciel cible.
- Faire comparer deux options réellement exploitables, avec les mêmes besoins de recette et de reprise.
- Répartir les tâches entre DSI, prestataire applicatif et hébergeur, y compris les exclusions.
- Tester les flux les plus contraignants depuis l’environnement envisagé.
- Faire réceptionner le déploiement et une restauration avant la bascule définitive.
- Conserver la décision, les accès et les procédures dans un dossier transmissible.
Le cadrage de la refonte et de son exploitation permet d’arbitrer ces éléments avant de figer la cible. Le logiciel peut alors être conçu pour son environnement réel, avec des fonctionnalités adaptées aux métiers et des intégrations contrôlées.
Conclusion : choisir un hébergement que votre organisation sait exploiter
Le lieu d’hébergement ne remplace ni la connaissance du SI, ni la répartition des responsabilités. Commencez par les parcours et les dépendances, puis sélectionnez les ressources adaptées à la charge et aux compétences disponibles.
La preuve attendue est concrète : un logiciel accessible dans les conditions prévues, des interfaces réceptionnées et une capacité de reprise exercée. Une solution plus simple peut être préférable si elle permet de tenir ces conditions durablement.
Le modèle de cahier des charges de refonte permet de réunir ces décisions avec le périmètre fonctionnel. Il évite de traiter l’exploitation comme une annexe découverte à la fin du projet.
Dawap vous accompagne pour refondre votre logiciel sur mesure et préparer son hébergement, dans votre SI ou dans une solution hébergée, avec une répartition explicite des tâches et une réception adaptée à vos équipes.
