Votre contrat d'hébergement infogéré arrive à son terme, et quelqu'un a proposé de passer sur AWS. La décision paraît technique. En pratique, une migration cloud échoue rarement sur le choix d'un type de serveur : elle déraille sur une intégration oubliée, un cache qui trompe l'équipe ou une question restée sans réponse, « qui applique les correctifs maintenant ? ».
Je pilote des projets techniques, je ne fais pas d'infogérance, et je préfère le dire tout de suite. Cet article décrit le travail du pilote de projet, pas celui de l'hébergeur : ce que je prépare, dans quel ordre, et ce que je refuse de laisser flou avant la bascule.
01Ce que change vraiment une migration cloud
Chez un infogéreur, beaucoup de choses sont faites pour vous sans être écrites nulle part : les mises à jour du système, les sauvegardes, la surveillance de nuit. En passant sur AWS, une partie de ce travail change de mains. AWS le décrit dans son modèle de responsabilité partagée : il gère l'infrastructure et la sécurité physique, et le client reste responsable du système d'exploitation invité, de ses correctifs, des applications et de la configuration du pare-feu (AWS, modèle de responsabilité partagée).
La CNIL dit la même chose avec d'autres mots. Elle range parmi les erreurs le fait de présumer que la sécurité incombe au seul fournisseur, de migrer sans repérer les données trop sensibles pour le cloud, ou de garder ses sauvegardes dans le même centre de données (CNIL, sécurité du cloud).
Le contrat change aussi. Le règlement européen sur les données oblige les fournisseurs cloud à faciliter le changement de fournisseur, et supprime les frais de changement, y compris les frais de sortie des données, à compter du 12 janvier 2027 ; d'ici là, ils peuvent encore être facturés (Commission européenne, le règlement sur les données expliqué). Je ne suis pas juriste, mais je pose la question à chaque fois : combien coûtera la sortie, chez l'ancien et plus tard chez le nouveau ?
02Faire l'inventaire avant de parler d'architecture
La première réunion d'une migration cloud dérive souvent vers les services AWS à utiliser. Je la ramène à une liste plus banale. Tant qu'elle n'existe pas, toute discussion d'architecture repose sur des suppositions.
Les cinq colonnes de mon inventaire
- L'application ou le service (site, back-office, API, tâches planifiées, boîte mail d'envoi).
- Ce dont il dépend : base de données, stockage de fichiers, ERP, CRM, paiement, nom de domaine et DNS.
- Les données qu'il porte, leur sensibilité et l'endroit où elles doivent rester.
- Qui s'en occupe aujourd'hui, côté infogéreur et côté interne.
- Ce qu'on en fait : on le déplace, on le garde, on le remplace ou on l'arrête.
La troisième colonne évite des surprises. Sur une intégration entre deux outils, j'ai appris en mission qu'un mélange de centimètres et de millimètres pouvait déformer tout un rendu. Depuis, je cherche quelle donnée fait référence et où c'est écrit. Une migration est le bon moment pour le noter, parce que les flux vont être rebranchés un par un.
Cet inventaire devient la base de la spécification de la migration. Je la versionne, comme je l'ai fait sur une spécification d'intégration ERP et site marchand qui bougeait presque à chaque réunion : tout le monde parle du même document, avec un numéro de version en tête.
03Choisir une stratégie par application, pas une pour tout
AWS décrit sept stratégies de migration, les « 7 R » : retirer, garder, réhéberger tel quel, relocaliser, racheter (passer à un logiciel en service), replateformer avec quelques ajustements, ou refondre l'architecture (AWS Prescriptive Guidance, migration strategies). La même page déconseille la refonte pendant une grande migration et recommande de moderniser une fois la bascule faite.
Je retiens surtout l'idée d'une décision par ligne d'inventaire. Un back-office que trois personnes utilisent peut rester où il est. Un vieux site de campagne peut être arrêté. Le site principal peut être déplacé presque tel quel. Remplir la cinquième colonne de l'inventaire avec ces mots oblige chacun à se prononcer.
Dans une conférence de re:Invent, Jake Burns, de l'équipe Executives in Residence d'AWS, met en garde contre le fait de mélanger migration et modernisation : on multiplie une complexité par une autre (AWS Events, accélérer une migration à grande échelle). Il raconte aussi qu'il s'était donné 12 mois pour sa propre migration, qu'elle en a pris 17, et qu'avec 17 mois de délai il pense qu'elle en aurait pris 24.
C'est l'avis d'un dirigeant d'AWS, donc d'un vendeur de cloud, mais je le rejoins sur l'échéance. J'ai commencé dans la production audiovisuelle, où la date de diffusion ne bouge pas, et je sais ce qu'une date fixe oblige à trancher.
Une limite tout de même : un réhébergement tel quel ne rend pas le site plus rapide ni moins cher par magie. Si le site a des problèmes, ils déménagent avec lui. C'est pour cette raison que je fais un audit technique avant de déplacer quoi que ce soit, pour savoir ce que l'on emporte.
04Écrire qui fait quoi après la bascule
C'est la partie que je refuse de laisser floue. Après la migration, quelqu'un doit appliquer les correctifs, surveiller, restaurer une sauvegarde à trois heures du matin et renouveler les certificats. Si personne n'a son nom en face de ces lignes, le premier incident le dira à votre place.
Je fais un tableau simple, une ligne par tâche, avec trois colonnes : AWS, le prestataire d'exploitation s'il y en a un, l'équipe interne. Le modèle de responsabilité partagée donne la première colonne. La CNIL demande de formaliser cette répartition dans un contrat (CNIL, sécurité du cloud), et je fais relire le tableau par ceux qui signeront.
Confier l'exploitation à un prestataire après la migration est un choix sain. Jake Burns défend une autre voie dans la même conférence : il juge plus facile d'apprendre le cloud à ses propres équipes que d'apprendre l'organisation à des personnes extérieures. Les deux se défendent. Ce qui ne se défend pas, c'est l'absence de choix. Je présente ce tableau en comité de pilotage, pour qu'une décision soit prise et écrite.
05Répéter la bascule et vérifier comme un visiteur
Pour un site dont les adresses ne changent pas, Google décrit une marche à suivre que j'applique telle quelle (Google Search Central, modifier l'hébergement). On copie le site sur la nouvelle infrastructure, on le teste sur un nom d'hôte temporaire bloqué à l'indexation, on vérifie que le pare-feu laisse passer Googlebot, et on baisse la durée de cache des enregistrements DNS au moins une semaine avant.
Le jour venu, on retire les blocages d'indexation, on change le DNS, puis on surveille les journaux des deux serveurs. L'ancien hébergement ne s'éteint que lorsque son trafic est tombé à zéro.
Ma liste du jour de bascule
- Une répétition complète, quelques jours avant, sur l'environnement de test.
- Une courte fenêtre de gel des écritures pour la dernière copie des données.
- Une comparaison de comptages et de quelques enregistrements témoins, ancien contre nouveau.
- Un retour arrière écrit : qui décide de revenir, avant quelle heure, et comment.
- Une vérification en navigation privée sur l'adresse publique, formulaire envoyé, commande test passée.
Ce dernier point vient d'une erreur que j'ai vue en mission : un site qui semblait normal à l'équipe connectée était cassé pour les visiteurs, à cause d'un cache. Depuis, je vérifie comme un visiteur, et pas avec la session de l'équipe. Je reprends une règle de ma machine de contenu : une vérification qui n'a pas eu lieu compte comme un échec, jamais comme un succès par défaut. Ma checklist de recette et de mise en production détaille le reste.
Google prévient aussi qu'une baisse temporaire de l'exploration est normale juste après le changement d'hébergement, puis qu'elle remonte dans les jours suivants. Je le dis à l'équipe marketing avant la bascule, pour éviter une alerte inutile le lendemain.
06Par où commencer si votre contrat se termine
Si l'échéance de votre infogérance approche, voici ce que je ferais lundi :
- Relire le contrat actuel : préavis, réversibilité, frais de sortie, format de restitution des données.
- Lancer l'inventaire en cinq colonnes avec la personne qui connaît le mieux le système, même s'il reste incomplet.
- Fixer une date de bascule réaliste mais proche, et la tenir.
- Remplir le tableau « qui fait quoi » avant de choisir le moindre service AWS.
Rien de tout cela ne demande de compétence cloud avancée, seulement de l'ordre et des décisions écrites. Si vous voulez quelqu'un pour piloter cette migration à vos côtés, la page services dit comment je travaille, et le portfolio montre le genre de projets que je mène ; on peut en parler.