Les dépenses cloud dépassent les budgets prévus de 17 %, 84 % des organisations déclarent peiner à les maîtriser, et 21 % des charges migrées ont déjà été rapatriées vers des environnements internes. Ces trois chiffres, issus de la même enquête, décrivent une seule et même erreur de départ : on a chiffré une migration, alors que ce qu’on achetait était une exploitation.
Voxalia a un peu plus d’un an, et ce sujet revient dans presque toutes les discussions d’infrastructure, généralement au moment où la facture de la deuxième année arrive.
Les chiffres, et ce qu’ils disent vraiment
Le State of the Cloud Report publié par Flexera le 19 mars 2025, auprès de plus de 750 professionnels et dirigeants techniques, donne des repères solides parce qu’ils sont reconduits d’année en année.
84 % des organisations citent la maîtrise des dépenses cloud comme leur premier défi. Les budgets sont dépassés de 17 % en moyenne, et la dépense est attendue en hausse de 28 % sur l’année à venir. Un tiers des organisations dépensent plus de douze millions de dollars par an en cloud public.
Le chiffre le plus intéressant est ailleurs, et il est rarement cité : 21 % des charges de travail migrées ont été rapatriées vers des environnements internes. Ce n’est pas anecdotique, ce n’est pas non plus un rejet du cloud, puisque la dépense continue de croître fortement. C’est le signe qu’une part significative des décisions de migration a été prise sur des hypothèses qui ne se sont pas vérifiées.
Notons enfin que 87 % des organisations citent l’efficacité et l’économie comme leur premier indicateur, et ce pour la sixième année consécutive. Le cloud est donc jugé, année après année, sur une promesse d’économie que ces mêmes chiffres montrent difficile à tenir.
Premier coût oublié : la double exploitation
Une migration ne bascule pas d’un coup. Elle se fait par vagues, et pendant ces vagues, l’entreprise paie deux infrastructures.
L’ancienne d’abord, parce que l’amortissement du matériel court, que les contrats d’hébergement ont des durées et des préavis, et surtout parce qu’il reste toujours quelque chose : un système que personne n’ose déplacer, une dépendance découverte en route, une application dont le fournisseur ne suit pas. La nouvelle ensuite, dès la première charge migrée.
Cette période de recouvrement est presque toujours sous-estimée dans le calendrier, et comme elle est calculée à partir du calendrier, elle est mécaniquement sous-estimée dans le budget. Un décalage de six mois sur une migration de deux ans représente un quart de coût supplémentaire sur ce poste, sans qu’aucune erreur technique n’ait été commise.
Le remède n’est pas budgétaire, il est méthodologique : traiter la sortie de l’ancien socle comme un projet à part entière, avec son responsable et sa date, plutôt que comme la conséquence automatique de l’arrivée sur le nouveau.
Deuxième coût oublié : le modèle de facturation, pas le prix
C’est le plus mal compris, et c’est celui qui produit les mauvaises surprises de la deuxième année.
Une infrastructure interne a un coût largement fixe : le matériel est acheté, l’utiliser davantage ne coûte rien de plus. Une infrastructure cloud a un coût largement variable, indexé sur l’usage. Le passage de l’un à l’autre ne change pas seulement le montant, il change la nature de la dépense.
Trois conséquences pratiques, dans l’ordre où elles se manifestent.
Les habitudes acquises en environnement interne coûtent désormais de l’argent. Un environnement de test laissé allumé le week-end, une machine surdimensionnée par précaution, une sauvegarde conservée indéfiniment : tout cela était gratuit et devient une ligne de facture.
Les transferts de données sortants se facturent, et ils sont rarement modélisés dans le business case initial parce que personne ne sait les estimer avant d’être en production.
Enfin, la dépense devient corrélée au succès. Une application qui marche mieux que prévu coûte plus cher, ce qui est logique et parfaitement déstabilisant pour un budget annuel construit sur une hypothèse d’usage.
Reprendre la main sur ce poste est possible, et c’est l’objet de la démarche FinOps, que 59 % des organisations interrogées par Flexera déclarent renforcer. Mais elle se met en place après coup, sur une facture qu’on subit déjà.
Troisième coût oublié : les compétences et la charge d’exploitation
Le troisième poste est humain, et c’est celui que les entreprises anticipent le moins bien.
Le discours de vente d’une migration met en avant la réduction de la charge d’exploitation : plus de serveurs à changer, plus de salle à climatiser. C’est vrai. Ce que ce discours ne dit pas, c’est que la charge ne disparaît pas, elle change de nature et de niveau d’exigence.
Administrer un environnement cloud demande des compétences différentes de celles qui administraient les serveurs : réseau logiciel, gestion fine des identités et des droits, automatisation de l’infrastructure, surveillance de la dépense. Ces compétences sont rares et chères, et l’entreprise se retrouve dans une situation inconfortable : les personnes dont elle disposait ne sont plus tout à fait celles dont elle a besoin, et celles dont elle a besoin sont les plus courtisées du marché.
Deux réponses coexistent, et aucune n’est gratuite. Former les équipes en place coûte du temps et suppose de l’accepter dans le calendrier. Recruter coûte de l’argent et un délai. La troisième voie, qui consiste à confier l’exploitation à un tiers, mérite d’être examinée avec les yeux ouverts, parce qu’elle déplace le problème vers la connaissance de votre système par ce tiers, avec les conséquences que nous avons décrites à propos de la réversibilité.
Le rapatriement n’est pas un échec du cloud, c’est un échec de calcul
Ces 21 % de charges rapatriées méritent d’être lus à côté d’un autre chiffre, parce que les deux racontent la même histoire dans deux domaines différents.
L’enquête mondiale publiée par Deloitte en 2024, auprès de plus de 500 dirigeants, mesurait que 70 % des organisations avaient réinternalisé de façon sélective une partie de ce qu’elles avaient externalisé au cours des cinq années précédentes, alors même que 80 % prévoyaient de maintenir ou d’augmenter leurs dépenses d’externalisation. C’est exactement la structure qu’on observe ici : un mouvement de fond qui continue, et une part significative d’allers-retours coûteux à l’intérieur de ce mouvement.
Dans les deux cas, la cause est la même, et nous l’avons développée à propos du coût du retour arrière après une externalisation : le business case s’arrête avant la partie coûteuse. Il compare un coût actuel connu à un coût futur estimé, sans chiffrer la transition, la période de double fonctionnement, ni le retour éventuel.
La conséquence pratique est directe pour une migration cloud. Un dossier sérieux devrait contenir, dès le départ, une estimation de ce que coûterait le rapatriement d’une charge donnée : quelles dépendances au fournisseur ont été créées, quel volume de données devrait être ressorti et à quel prix, quelles compétences seraient nécessaires. Non pas parce qu’on prévoit de revenir, mais parce que cette estimation est le meilleur révélateur du degré d’enfermement que la décision crée. Une charge dont la sortie est impensable n’est pas migrée, elle est cédée.
Ce qui distingue une migration réussie d’une migration subie
Une observation de terrain, qui n’a rien d’original mais que les chiffres soutiennent.
Les migrations qui tiennent leur promesse sont celles où l’on a changé quelque chose. Reprendre une application telle quelle pour la poser sur une machine louée revient à louer au prix fort ce qu’on possédait, sans obtenir aucune des propriétés qui justifiaient le déplacement : élasticité, disponibilité, vitesse de mise à disposition. C’est cette configuration qui produit l’essentiel des rapatriements.
À l’inverse, une migration qui s’accompagne d’un travail sur l’application elle-même, sur son dimensionnement, sur ses sauvegardes, sur son automatisation, obtient un service meilleur et une facture maîtrisable. Le coût de ce travail est réel, et il devrait figurer dans le business case au lieu d’être présenté comme une amélioration ultérieure.
Le test à se poser avant de démarrer est donc simple, et il relève du cadrage du besoin bien plus que de la technique : que gagne-t-on qu’on ne pouvait pas obtenir avant ? Si la seule réponse est « on n’aura plus de serveurs à gérer », le calcul est fragile, parce que c’est exactement la promesse que les 21 % de rapatriements viennent contredire.
Ce que nous en tirons
Nous refusons les missions de migration formulées comme un simple déplacement, et nous le disons avant de chiffrer.
Notre position tient en trois exigences. Chiffrer la sortie de l’ancien socle en même temps que l’arrivée sur le nouveau, avec une date et un responsable. Modéliser la facture d’exploitation à douze et vingt-quatre mois, hypothèses écrites, plutôt que de raisonner sur le coût du projet. Et poser dès le départ la question des compétences, en disant honnêtement ce que l’entreprise devra savoir faire après notre départ.
Ce dernier point est celui qui nous coûte le plus d’affaires, parce qu’il revient à réduire notre propre périmètre futur. Nous préférons cette conversation à celle qui arrive dix-huit mois plus tard, quand la facture a doublé et que plus personne en interne ne sait pourquoi.
Vous pouvez lire qui nous sommes et d’où nous venons et ce que nous faisons en infrastructure avant de nous accorder le moindre crédit.
Questions fréquentes
Pourquoi les migrations cloud dépassent-elles leur budget ?
Trois postes échappent presque toujours au chiffrage initial. La double exploitation, puisque l’ancienne infrastructure continue d’être payée pendant toute la durée de la bascule, et que cette durée est habituellement sous-estimée. Le changement de modèle de facturation, une dépense fixe devenant variable et indexée sur l’usage, ce qui rend payantes des habitudes qui étaient gratuites en interne. Et la charge d’exploitation, qui ne disparaît pas mais change de nature et demande des compétences différentes, rares et chères. Selon le State of the Cloud Report de Flexera publié en mars 2025, les budgets cloud sont dépassés de 17 % et 84 % des organisations citent la maîtrise des dépenses comme leur premier défi.
Le rapatriement de charges depuis le cloud est-il fréquent ?
Il l’est plus qu’on ne le dit. Le State of the Cloud Report de Flexera publié le 19 mars 2025, auprès de plus de 750 professionnels et dirigeants techniques, mesure que 21 % des charges de travail migrées ont été rapatriées vers des environnements internes. Ce chiffre ne traduit pas un rejet du cloud, puisque la dépense reste attendue en hausse de 28 % sur l’année à venir. Il indique qu’une part significative des décisions de migration reposait sur des hypothèses de coût ou de performance qui ne se sont pas vérifiées.
Faut-il migrer une application telle quelle ou la retravailler ?
Déplacer une application sans la modifier revient le plus souvent à louer au prix fort ce que l’on possédait, sans obtenir les propriétés qui justifiaient le déplacement : élasticité, disponibilité, rapidité de mise à disposition. C’est la configuration qui produit l’essentiel des rapatriements observés. Un travail sur le dimensionnement, les sauvegardes et l’automatisation a un coût réel, qui devrait figurer dans le business case initial plutôt qu’être présenté comme une amélioration ultérieure. Le test préalable tient en une question : que gagne-t-on qu’on ne pouvait pas obtenir avant ?
Sources
- Flexera, 2025 State of the Cloud Report, publié le 19 mars 2025, plus de 750 professionnels et dirigeants techniques (communiqué) : 84 % des organisations en difficulté sur la maîtrise des dépenses cloud, budgets dépassés de 17 %, dépense attendue en hausse de 28 %, 21 % des charges migrées rapatriées vers des environnements internes, 59 % renforçant leurs équipes FinOps, 87 % citant l’efficacité et l’économie comme premier indicateur pour la sixième année consécutive.
- Deloitte, Global Outsourcing Survey 2024, 2024, plus de 500 dirigeants (70 % ayant réinternalisé de façon sélective sur cinq ans, 80 % prévoyant de maintenir ou d’augmenter leurs dépenses d’externalisation).
