Cloud computing : ce qu'il faut savoir avant de migrer

On m'a posé la question trois fois en un mois, à chaque fois par un dirigeant différent, et à chaque fois avec la même nuance de panique dans la voix : « On nous dit qu'il faut y aller, mais concrètement, on commence par quoi ? » La troisième fois, j'ai arrêté de répondre au téléphone et j'ai ouvert un document. Voici ce qui en est sorti.

Parce que le problème n'est jamais technique. Le problème, c'est que la migration vers le cloud est vendue comme une évidence alors qu'il s'agit d'un arbitrage économique et juridique, avec des gagnants et des perdants très identifiables. Après avoir accompagné des équipes sur ce sujet, vu des budgets exploser et des projets se planter proprement, je peux vous dire une chose : la plupart des entreprises qui migrent le font pour de mauvaises raisons, et celles qui réussissent ne sont pas celles qui avaient le meilleur plan technique.

Le cloud computing n'est pas un objectif. C'est un mode d'exploitation. Et comme tout mode d'exploitation, il a un coût, une courbe d'apprentissage et des cas où il ne faut surtout pas l'utiliser.

Faut-il migrer vers le cloud ? La grille de décision qu'on aurait dû me donner

J'ai longtemps cru que la question était « quel fournisseur choisir ». C'est faux. La première question est « quelles applications ont réellement intérêt à bouger ».

Sur un portefeuille applicatif classique d'entreprise de taille moyenne, on retrouve à peu près la même répartition : une poignée d'applications qui tirent un bénéfice immédiat du cloud (pic de charge saisonnier, besoin d'élasticité, dépendance à des services managés), une majorité qui vivent très bien là où elles sont, et quelques-unes qui ne devraient jamais quitter le sol — soit pour des raisons de latence, soit pour des raisons réglementaires, soit parce que personne dans l'équipe ne sait plus comment elles fonctionnent.

Cette dernière catégorie est la plus dangereuse. Et c'est celle dont on parle le moins.

Les quatre critères qui comptent vraiment

Avant de décider quoi que ce soit, posez ces quatre questions sur chaque application, une par une, sans tricher :

1. La charge est-elle variable ou plate ? Si votre serveur tourne à 15 % de capacité toute l'année, le cloud vous facturera ce que vous consommez, mais vous continuerez de payer pour des réservations mal dimensionnées. Un pic saisonnier de trois semaines est un excellent candidat. Un service interne utilisé de 9 h à 17 h par 40 personnes l'est beaucoup moins.
2. Qui sait la maintenir ? Une application écrite par un prestataire disparu, sans documentation ni tests, migrera techniquement. Elle ne survivra pas à sa première panne en production dans un environnement que personne ne maîtrise.
3. Y a-t-il une contrainte de localisation des données ? Données de santé, données RH, données de paie, certaines données financières. Le sujet n'est pas technique, il est juridique, et il se tranche avec votre juriste, pas avec votre architecte.
4. Quel est le coût réel de sortie ? Pas le coût d'entrée. Le coût de sortie. Récupérer plusieurs téraoctets depuis un fournisseur public se facture, et cette facture est souvent découverte au pire moment.

Un dirigeant avec qui j'ai travaillé avait rempli cette grille pour 34 applications. Résultat : 6 étaient de bonnes candidates, 24 pouvaient attendre indéfiniment, et 4 posaient un problème réglementaire qu'il n'avait pas anticipé. Il a migré les 6. Deux ans plus tard, sa facture d'infrastructure avait baissé de 18 % — pas les 60 % qu'on lui avait promis, mais une baisse réelle, sans drame et sans réécriture massive.

Migrer 6 applications sur 34, c'est une réussite. Migrer 34 sur 34 en catastrophe, c'est un échec qui mettra trois ans à se voir.

Les coûts réels d'une migration cloud (et les trois pièges de facturation)

Ce que personne ne vous dit à la signature : la première année de cloud coûte presque toujours plus cher que l'année précédente sur site.

Pourquoi ? Parce que pendant la transition, vous payez deux fois. Les machines sur site tournent encore, le temps que tout soit validé. Les environnements cloud sont montés en parallèle, souvent en surdimensionné « pour être tranquilles ». Et les licences logicielles, elles, restent dues.

Sur un projet que j'ai suivi, le budget prévisionnel annonçait une économie de 30 % dès la première année. La réalité : +22 % la première année, équilibre atteint au bout de dix-huit mois, économie réelle à partir de la troisième année. Le projet était bon. Le chiffrage était faux.

Piège n° 1 : les frais de sortie de données

Le trafic entrant est presque toujours gratuit chez les grands fournisseurs. Le trafic sortant, lui, se facture. Si votre architecture fait régulièrement circuler des données entre régions ou vers l'extérieur, ces frais peuvent représenter une part significative de votre facture mensuelle. Et ils grimpent en flèche le jour où vous voulez partir.

Piège n° 2 : le surprovisionnement silencieux

Le réflexe naturel d'une équipe qui migre est de dimensionner large. Une base de données prévue pour un pic théorique, des instances dimensionnées pour le double du besoin réel, des environnements de test qui tournent 24 heures sur 24 alors qu'ils ne servent que quatre heures par semaine. Rien de tout ça ne se voit sur un schéma d'architecture. Tout se voit sur la facture.

Piège n° 3 : les licences oubliées

Certains éditeurs facturent leurs licences différemment selon qu'elles tournent sur votre matériel ou sur celui d'un tiers. Ce n'est pas systématique, mais quand ça arrive, le surcoût n'est pas anecdotique — j'ai vu des configurations où la licence coûtait plus cher que l'infrastructure qu'elle faisait tourner.

Poste de coût	Visible au chiffrage initial	Se révèle quand
Abonnement infrastructure	Oui	Dès le premier mois
Double fonctionnement transitoire	Rarement	Mois 2 à 8
Frais de sortie de données	Presque jamais	À la première migration interne, ou au départ du fournisseur
Licences logicielles adaptées	Parfois	Au premier renouvellement de contrat
Formation des équipes	Presque jamais	Mois 3 à 12, en continu
Refonte des sauvegardes et de la supervision	Non	Mois 1 à 4

Additionnez. Le chiffrage initial, dans la quasi-totalité des cas que j'ai vus, ne couvrait que la première ligne.

RGPD, souveraineté et localisation des données : le sujet qu'on repousse trop longtemps

Il y a une conversation que les équipes techniques évitent et que les directions repoussent : où sont physiquement vos données, et qui peut y accéder légalement.

Ce n'est pas un détail administratif. C'est un critère de choix de fournisseur, au même titre que le prix ou la performance.

Ce qui doit être vérifié avant de signer

• La région d'hébergement réelle, pas celle annoncée commercialement. Un fournisseur peut répliquer vos données dans une autre zone pour des raisons de redondance, sans que ce soit explicite dans la documentation que vous lisez.
• Les clauses contractuelles encadrant l'accès aux données par des autorités tierces. Ce point est déterminant si vos données ont une sensibilité juridique particulière.
• La réversibilité contractuelle : format d'export, délai de restitution, engagement sur l'effacement après départ.
• Le sous-traitant en cascade : qui, chez votre fournisseur, héberge réellement l'infrastructure sous-jacente.

Une entreprise avec laquelle j'ai travaillé avait migré l'intégralité de ses données RH vers une région européenne. Propre. Sauf que le service de supervision associé, lui, remontait ses journaux d'accès vers une région hors UE. Détecté lors d'un audit interne, sept mois après la migration. Personne n'était de mauvaise foi — simplement, personne n'avait regardé le schéma complet.

La conformité ne se rattrape pas après coup. Elle se conçoit avant.

Lock-in fournisseur : comment éviter de vous enfermer sans le voir

« On pourra toujours partir. » C'est la phrase que j'entends dans chaque réunion de lancement. Elle est vraie sur le papier et fausse en pratique. Pas parce qu'il serait impossible de changer de fournisseur, mais parce que le coût de ce changement augmente à chaque service propriétaire que vous adoptez.

Une base de données relationnelle standard se déplace avec un peu d'huile de coude. Une base de données managée avec une API propriétaire, un système de files de messages maison et une couche de fonctions serverless liée à un fournisseur précis, ça ne se déplace pas : ça se réécrit.

Ma règle, que j'applique systématiquement : je choisis mes services managés à l'envers. Je regarde d'abord combien coûte la sortie, et seulement ensuite à quel point le service me simplifie la vie.

Ce n'est pas une position dogmatique. Certains services propriétaires sont tellement supérieurs à l'alternative portable que le surcoût de sortie est un prix juste. Mais c'est une décision qui doit être prise sciemment, pas par défaut parce que c'était plus simple un vendredi après-midi.

La question à se poser à chaque service adopté

Si je devais reproduire ce service chez un autre fournisseur en trois mois, qu'est-ce que ça me coûterait en temps d'ingénierie ? Si la réponse dépasse deux mois de travail, vous venez d'ajouter un point de non-retour. Comptez-les. Un projet avec douze points de non-retour n'est plus un projet cloud : c'est une dépendance.

Un plan de migration qui tient debout (et les signaux d'alarme)

Les migrations qui se passent mal partagent souvent le même profil : un périmètre flou, pas de critère de succès mesurable, et aucune procédure de retour arrière.

La méthode qui a le mieux fonctionné sur les projets que j'ai vus tient en cinq temps, et elle a un mérite : elle est ennuyeuse.

1. Inventaire applicatif complet, avec pour chaque application son propriétaire fonctionnel, ses dépendances techniques et son niveau de criticité. C'est long, personne n'aime le faire, et c'est la seule étape qui évite de découvrir une dépendance cachée en pleine bascule.
2. Un pilote sur une application non critique, avec un critère de succès chiffré avant de commencer. Pas « ça marche mieux », un chiffre : temps de réponse, coût mensuel, taux d'erreur.
3. Bascule progressive, application par application, avec une période de double fonctionnement assumée et budgétée.
4. Extinction effective des ressources sur site correspondantes. C'est l'étape que tout le monde saute. Une machine virtuelle oubliée qui tourne encore « au cas où », et votre économie annoncée disparaît.
5. Revue à six mois, avec la facture réelle posée à côté du chiffrage initial. Pas pour se flageller, pour corriger le modèle économique des vagues suivantes.

Quand faut-il arrêter le projet ?

Trois signaux doivent vous alerter. Le premier : la facture réelle dépasse le prévisionnel de plus de 40 % sur deux mois consécutifs sans explication identifiée. Le deuxième : les incidents de production augmentent après la migration, pas avant. Le troisième, le plus grave : plus personne dans l'équipe ne sait expliquer comment fonctionne l'application migrée.

Ce dernier point mérite qu'on s'y arrête. Il arrive quand la migration a été traitée comme un déménagement, alors qu'il s'agit d'une reconstruction. On déplace des cartons, on ne se demande pas ce qu'il y a dedans, et six mois plus tard on découvre qu'une pièce essentielle a été perdue en route.

Une migration cloud réussie n'est pas une migration terminée. C'est une migration que votre équipe peut expliquer de bout en bout, panne comprise, à trois heures du matin.

Si vous ne pouvez pas en dire autant, le problème n'est pas le fournisseur. Le problème, c'est que vous avez déménagé sans faire l'inventaire.