La question revient à chaque audit : « on bascule tout ce week-end, ça devrait passer, non ? » J'ai entendu cette phrase onze fois en cinq ans. Neuf fois, le lundi matin ressemblait à un champ de bataille. Pas parce que le cloud est mauvais. Parce que migrer n'est pas déménager des serveurs, c'est redessiner une architecture, et personne ne vous le dit assez brutalement.
Je vais être direct : la plupart des échecs que j'ai vécus ou observés ne viennent pas de la technique. Ils viennent de décisions prises trop vite, par des gens pressés de cocher la case « cloud » sur une slide de comité de direction. Voici les erreurs à éviter lors de la migration vers le cloud — celles que j'ai commises, celles que j'ai vues cramer des budgets, et comment les contourner.
Points clés à retenir
- Un inventaire applicatif incomplet est la première cause de dérapage : chaque dépendance oubliée se paie en heures d'astreinte.
- Le lift-and-shift sans réévaluation des coûts fait exploser la facture : j'ai vu un budget mensuel tripler en six semaines.
- La sécurité se prépare avant la bascule, jamais après. Les clés IAM oubliées traînent des mois.
- Une migration se pilote par vagues, pas en big bang. Les gros week-ends uniques échouent plus souvent qu'ils ne réussissent.
- Le vrai indicateur de succès n'est pas « c'est migré », c'est « ça coûte moins cher et ça tient la charge ».
Les erreurs à éviter lors de la migration vers le cloud : ce que j'ai appris à la dure
Mon pire souvenir remonte à un projet chez un éditeur de logiciel de paie. Équipe de douze personnes, trois environnements, une promesse de bascule en un mois. On a mis quatre mois et demi. Le coupable : un service interne qui appelait une base de données legacy par un chemin réseau codé en dur dans une variable d'environnement que personne n'avait documentée. On l'a découvert à 2 h du matin, en production.
Ce genre de surprise n'a rien d'exceptionnel. Roughly a third des projets que j'ai suivis ont dérapé sur un composant "qu'on avait oublié". Toujours mineur sur le papier. Jamais mineur dans les faits.
Erreur n°1 : sauter l'audit d'inventaire
Vous ne pouvez pas migrer ce que vous ne connaissez pas. Et la plupart des organisations connaissent environ 70 % de leur parc applicatif. Les 30 % restants sont ceux qui font mal : scripts de cron, jobs de batch lancés par un ancien stagiaire, intégrations bricolées entre deux outils SaaS.
Ce que je fais désormais systématiquement :
- Un inventaire exhaustif des applications, avec propriétaire, criticité et dépendances entrantes et sortantes.
- Une cartographie des flux réseau, y compris ceux qui passent par des VPN d'ancienne génération.
- Un test de coupure sur un environnement de préproduction, en débranchant pour voir ce qui tombe. Radical, mais diablement efficace.
Cette phase prend du temps. Elle vous en fera gagner dix fois plus ensuite.
Erreur n°2 : croire que le lift-and-shift est neutre financièrement
Le lift-and-shift a une réputation de simplicité. On prend l'existant, on le pose chez un hyperscaler, on change les DNS. Techniquement, ça marche. Financièrement, c'est un piège.
Pourquoi ? Parce qu'une machine virtuelle mal dimensionnée dans votre datacenter coûte le prix que vous avez négocié. La même machine mal dimensionnée dans le cloud coûte ce que vous consommez, à la seconde. Un service qui tournait sur un serveur surdimensionné pendant cinq ans sans que personne ne s'en aperçoive devient une ligne de facture qui grimpe chaque jour.
Sur un projet de refonte pour une PME industrielle, le premier mois de facture cloud a été 2,7 fois supérieur à l'estimation initiale. On a mis six semaines à comprendre d'où venait l'écart : trois instances de calcul tournaient en permanence pour alimenter un tableau de bord que deux personnes consultaient le mardi matin.
Mon conseil : traitez la migration comme une occasion de redimensionner, pas de transposer. C'est le moment de regarder chaque charge de travail et de se demander si elle a encore sa place telle quelle. Spoiler : souvent, non.
Erreur n°3 : repousser la sécurité à la phase 2
« On sécurise après, une fois que ça tourne. » J'ai dit ça une fois. Une seule. Un bucket de stockage laissé en accès public pendant onze jours. On l'a détecté parce qu'un client curieux a trouvé un PDF interne via une recherche. Aucune fuite massive, mais la frayeur a coûté plus cher en crédibilité qu'en euros.
Les erreurs de sécurité classiques en migration :
- Des rôles IAM créés en urgence avec des permissions larges, jamais resserrés.
- Des clés d'API stockées dans le code plutôt que dans un coffre-fort dédié.
- Le chiffrement au repos activé partout, mais pas en transit entre deux services internes.
- Des journaux d'audit activés trop tard : vous ne saurez pas qui a fait quoi pendant les deux premières semaines.
La sécurité n'est pas une couche qu'on ajoute. Elle se décide au moment où l'on dessine l'architecture cible, sinon elle coûte le double et protège la moitié.
Quelle stratégie adopter concrètement ?
Il existe plusieurs approches, et choisir la mauvaise fait plus de dégâts qu'une exécution imparfaite. Voici mon tableau de lecture, basé sur ce que j'ai vu marcher — et échouer.
| Approche | Quand c'est pertinent | Piège principal |
|---|---|---|
| Lift-and-shift | Applications stables, deadline serrée, peu de temps pour refactorer | Les coûts d'exploitation grimpent silencieusement |
| Replatform | Besoin de gagner en agilité sans tout réécrire | Nécessite une équipe avec des compétences nouvelles |
| Refonte complète | Applications critiques, ambitions produit fortes | Délais longs, risque d'abandon à mi-parcours |
| Migration par vagues | Portefeuille applicatif large et hétérogène | Nécessite de la coordination entre équipes |
Ce que je recommande dans 80 % des cas : par vagues, en commençant par une application non critique. Vous apprenez sur du petit, vous industrialisez, puis vous attaquez les gros morceaux. C'est moins glorieux qu'un big bang. C'est aussi beaucoup moins risqué.
Combien de temps prend une migration cloud ?
Deux mois pour une petite application bien isolée. Entre six et dix-huit mois pour un système d'information de taille moyenne. Ce qui allonge toujours le calendrier n'est pas la technique : c'est l'alignement des équipes, la validation des parties prenantes, et les ajustements métier découverts en cours de route. Prévoir 30 % de marge sur le planning n'est pas du pessimisme, c'est de l'arithmétique honnête.
Qui doit piloter le projet ?
Une personne dédiée à plein temps, avec autorité pour trancher. Pas un comité. Pas un chef de projet qui gère trois autres dossiers en parallèle. J'ai vu deux migrations réussies sur un modèle où le responsable technique avait un mandat clair pour dire non à un service métier qui demandait une exception. C'est ce mandat qui fait la différence entre un projet qui avance et un projet qui s'enlise.
Ce que personne ne vous dira à la fin
Une fois la bascule terminée, il reste un travail que la plupart des équipes sous-estiment : l'optimisation continue. Les six premiers mois après migration sont ceux où l'on découvre les mauvaises surprises de dimensionnement, les réservations d'instances mal calibrées, les services qui pourraient passer en serverless et coûter cinq fois moins.
J'ai gardé une règle simple : pendant trois mois après chaque bascule, un point hebdomadaire sur la facture et les alertes de performance. Pas glamour. Mais c'est ce qui a permis de ramener une facture cloud initialement à 6 000 € par mois autour de 3 800 € — sans rien dégrader.
La migration vers le cloud n'est pas une ligne d'arrivée. C'est un point de départ, et le pilotage commence vraiment après la bascule. Ceux qui l'oublient paient deux fois : une fois pour migrer, une fois pour corriger. Ceux qui l'intègrent dans leurs habitudes finissent par oublier qu'ils ont un jour eu un datacenter. C'est probablement le meilleur signe que ça s'est bien passé.
