La question qu'on me pose le plus souvent quand j'audite une PME, ce n'est pas « quel fournisseur choisir ? ». C'est : « par où on commence, concrètement ? ». Et c'est là que tout se joue. Une migration vers le cloud n'échoue presque jamais sur la technique. Elle échoue sur l'ordre des opérations.
J'ai vu une boîte de logistique basculer son ERP en un week-end, poussée par un directeur financier enthousiaste. Résultat : trois jours d'arrêt total, et une facture de sortie de données qu'ils n'avaient pas lue. Coût final estimé : 40 000 euros de perte d'activité. Le fournisseur n'y était pour rien. Le plan, si.
Ce guide n'est pas une liste de prestataires. C'est la méthode que j'applique, dans l'ordre, avec les erreurs que j'ai commises en apprenant.
Points clés à retenir
- On ne migre pas une infrastructure, on migre un service à la fois, avec ses dépendances.
- L'audit des coûts de sortie (egress) doit précéder la signature, jamais l'inverse.
- Un pilote sur une charge non critique vous fait gagner des mois.
- Le facteur limitant est rarement technique : c'est la conduite du changement.
- Budgétez 20 à 30 % de marge sur le calendrier initial. Toujours.
- La réversibilité se négocie au contrat, pas au moment de partir.
Migrer vers le cloud : par où commencer vraiment ?
Avant de parler d'AWS ou d'Azure, il faut répondre à une question que personne ne pose en réunion : qu'est-ce qui, dans votre système, ne peut pas tomber ?
La plupart des entreprises répondent « tout ». C'est faux, et c'est exactement le problème. Quand j'ai commencé à cartographier les applications d'un client industriel, on a identifié 214 services. Sur ces 214, seuls 11 étaient réellement critiques en continu. Le reste tolérait une fenêtre de maintenance de plusieurs heures. Cette simple distinction a transformé un projet « impossible » en un planning de quatre mois.
L'audit : cartographier avant de déplacer
Un inventaire sérieux répond à quatre questions par application : qui l'utilise, quelles données elle manipule, quelles dépendances elle entretient, et quelle est sa tolérance à l'interruption. Sans ces quatre colonnes, vous migrez à l'aveugle.
Le piège classique, c'est la dépendance cachée. Un script oublié sur un vieux serveur, une tâche planifiée qui écrit dans un dossier partagé, un connecteur ODBC pointé vers une base que tout le monde avait oubliée. Franchement, ces découvertes arrivent systématiquement à la veille de la bascule. Prévoyez du temps pour elles.
Prioriser les charges : la matrice qui évite le chaos
Toutes les applications ne se valent pas. Je classe selon deux axes : la complexité de migration et la valeur métier. Ce qui est simple à migrer et à forte valeur part en premier. Ce qui est complexe et à faible valeur attend, ou disparaît.
- Migration « lift and shift » : on déplace tel quel. Rapide, peu risqué, mais on ne profite pas du cloud.
- Replateforme : on adapte légèrement (base managée, conteneurs). Le bon compromis pour la majorité des cas.
- Refonte complète : rarement justifiée, sauf pour un service qui doit scaler fortement.
- Abandon pur et simple : la meilleure décision, et celle qu'on prend le moins.
Sur un portefeuille typique, comptez un tiers d'applications réellement candidates à la refonte. Le reste doit partir en replateforme ou disparaître.
Les étapes concrètes d'une migration qui tient
Voici l'enchaînement que j'utilise. Il n'est pas linéaire : certaines étapes se chevauchent, et c'est normal.
Étape 1 : le pilote sur une charge non critique
Choisissez une application secondaire, mais représentative. Pas un projet jouet. Vous voulez tester vos procédures de bascule, votre monitoring, votre gestion des accès, et surtout la réaction des équipes. Un pilote bien mené vous fait gagner six à huit semaines sur la suite, parce que vous découvrez vos propres angles morts sur un périmètre indolore.
Étape 2 : la bascule, avec un plan de retour arrière
On ne bascule pas « pour voir ». On bascule avec une fenêtre définie, un plan de rollback écrit, et un responsable nommé qui a le pouvoir de dire stop. J'ai vu trop de bascules se transformer en exercice d'improvisation parce que personne n'osait freiner.
Le critère de succès doit être mesurable avant l'opération. « Le service répond en moins de 300 ms sur 95 % des requêtes » est un critère. « Ça a l'air de marcher » n'en est pas un.
Étape 3 : les 30 jours après, là où tout se décide
La migration technique est terminée. Le vrai travail commence. Optimisation des instances surdimensionnées, ajustement des politiques de sauvegarde, mise en place du suivi budgétaire. La plupart des dépassements de coûts cloud que j'observe naissent dans ce mois-là, par simple absence de surveillance.
Combien ça coûte réellement : le chiffre qu'on oublie
Le prix affiché par un fournisseur cloud n'est jamais le prix final. Deux postes font exploser les budgets : le transfert de données sortant, et la double facturation pendant la transition.
Pendant une migration, vous payez souvent l'ancien et le nouveau en parallèle. Sur un projet de six mois, cela peut représenter plusieurs mois de double coût d'infrastructure. C'est rarement anticipé.
| Poste de coût | Souvent sous-estimé | Comment le maîtriser |
|---|---|---|
| Transfert sortant (egress) | Oui, fortement | Vérifier les tarifs au contrat avant signature |
| Double infrastructure | Oui | Découper la bascule par lots courts |
| Formation des équipes | Presque toujours | Budgéter dès la phase pilote |
| Instances surdimensionnées | Oui, sur la durée | Revue mensuelle des ressources |
| Support renforcé | Parfois | Négocier un palier de support adapté, pas maximal |
Un client avait budgété 80 000 euros sur l'année. La facture réelle a frôlé les 130 000. Pas de dérapage technique : juste une absence totale de pilotage financier les trois premiers mois.
Souveraineté et conformité : ce qui change dans la pratique
Le sujet n'est plus théorique. Selon la nature de vos données, le choix de la région d'hébergement devient une contrainte de conformité, pas une préférence.
Les cadres comme NIS2 ou DORA pour le secteur financier imposent une traçabilité des accès et une capacité à démontrer où résident les données. Concrètement, cela veut dire deux choses dans votre migration :
- Savoir précisément quelles données sont concernées, et par quelle obligation.
- Vérifier que le fournisseur documente la localisation physique, pas seulement la région logique.
Je conseille souvent de séparer les périmètres : les données sensibles ou régulées dans une région maîtrisée, le reste là où c'est le plus économique. C'est moins élégant qu'un cloud unique, mais c'est défendable devant un auditeur.
Trois erreurs que j'ai commises (et que vous pouvez éviter)
Sous-estimer le temps des équipes internes
J'ai planifié une migration en partant du principe que les équipes techniques y consacreraient 30 % de leur temps. En réalité, elles ont été mobilisées à 70 %. Résultat : le projet a avancé, mais tout le reste s'est arrêté. Le backlog produit a pris deux trimestres de retard. Personne ne l'avait chiffré, et pourtant c'était le vrai coût du projet.
Négliger la réversibilité
On pense toujours à la sortie facile. On oublie qu'un jour, il faudra peut-être partir. Si votre contrat ne prévoit pas le format et le coût de restitution des données, vous êtes captif. La réversibilité se négocie avant de signer. Après, vous n'avez plus de levier.
Traiter la conduite du changement comme une formalité
Les utilisateurs ne se plaignent pas que le service soit dans le cloud. Ils se plaignent que leur façon de travailler ait changé sans qu'on leur explique. Une équipe qui perd ses raccourcis et ses habitudes pendant une semaine, c'est une équipe qui sabote la suite du projet à petit feu. Investissez dans la formation et la communication autant que dans la technique.
Faut-il choisir un seul fournisseur ou plusieurs ?
Le multicloud séduit sur le papier. Il coûte cher en pratique.
Ma position, et j'assume d'être partial : pour une entreprise qui n'a pas d'équipe plateforme dédiée, restez sur un fournisseur principal. Le multicloud impose une double compétence, une double gestion d'identité, et une complexité réseau qui mange le gain de flexibilité. On en reparle quand vous aurez cent ingénieurs. Avant, c'est de la dette organisationnelle déguisée en stratégie.
En revanche, un plan de sortie écrit, oui, toujours. Pas pour partir demain, mais pour ne jamais être coincé.
Ce qui reste quand le projet est fini
Une migration réussie ne se mesure pas au jour de la bascule. Elle se mesure six mois plus tard, quand le budget est stable, que les équipes ont repris leurs marques, et que plus personne ne parle du cloud comme d'un sujet. C'est le meilleur signe : quand l'infrastructure redevient invisible, c'est qu'elle a été bien migrée.
La vraie question n'est donc pas « comment migrer vers le cloud ». C'est : de quoi votre organisation est-elle prête à se séparer ? Les habitudes, les exceptions, les serveurs qu'on garde « au cas où ». Le jour où vous répondez honnêtement, la technique suit en quelques semaines.
