Livre blanc — Transformation cloud : feuille de route pour les grands groupes

Livre blanc · Avril 2026

Transformation cloud : feuille de route pour les grands groupes

Migrer moins, transformer mieux, payer juste

« La question n'est plus faut-il aller au cloud, la plupart des groupes y sont à moitié, et c'est précisément ce milieu de gué qui coûte le plus cher. Ce livre est écrit pour en sortir : dans un sens ou dans l'autre, mais par décision. »

4 destins

5 phases

6 dérives

Pour chaque application du parc : replatformer, racheter, refondre ou laisser, avec la grille de tri

La feuille de route par vagues, des fondations au run, chaque phase avec son seuil de sortie

Celles qui coûtent des millions aux programmes de groupe, le signal qui les trahit, le geste qui les corrige

Pour les comités exécutifs, DSI groupe et directions financières, avec cinq arbitrages instruits, une doctrine cloud à copier, les cinq nombres du comité et un auto-diagnostic.

Sommaire

Avant-propos 03 Les cinq arbitrages que votre comité doit trancher 04 Trois lectures de ce document 06 1 Le milieu de gué Pourquoi les programmes de groupe s'enlisent · Où part l'argent cloud · Trois profils de groupe 07 2 Quatre destins pour chaque application La grille de tri du parc · Le legacy et le mainframe · Souveraineté et données réglementées 11 3 La feuille de route en cinq phases Fondations · Vague probante · Industrialisation · FinOps dès le premier jour · Le run cloud, chaque phase avec son seuil de sortie 15

4 Six dérives à des millions La migration horlogère · La facture sans pilote · La tour de contrôle sans pouvoir · Les compétences louées à vie · Le multi-cloud de principe · L'application zombie migrée 20 5 Équipes, fournisseurs, gouvernance L'équipe plateforme · Reconvertir plutôt que remplacer · Tenir tête aux hyperscalers et intégrateurs · La doctrine cloud à copier 24 6 L'année 1 du programme La frise T1-T4 · Les cinq nombres du comité exécutif 28 Passer à l'exécution 30 Annexe, Auto-diagnostic en vingt questions 31

Le parti pris

Le cloud n'est ni une destination ni une religion : c'est un modèle d'exploitation, qui ne rend que ce qu'on transforme. Migrer un parc tel quel, c'est déménager sa dette technique dans un immeuble plus cher, ce document trie d'abord, migre ensuite, et compte tout du long.

Avant-propos

Troisième année du programme « Move to Cloud » d'un groupe industriel : 30 % du parc migré, le double du budget consommé, et une réunion de crise dont l'ordre du jour tient en une ligne, la facture mensuelle du fournisseur cloud vient de dépasser le coût de l'ancien datacenter, qui tourne toujours, puisqu'il reste 70 % du parc à migrer. Personne n'a démérité : les équipes ont migré ce qui se migrait bien, l'intégrateur a tenu ses jalons, l'hyperscaler a livré ses crédits. C'est le programme lui-même qui était mal posé : on a acheté un déménagement, on avait besoin d'une transformation.

Ce scénario, nous le retrouvons, avec des variantes, dans la plupart des grands groupes que nous rencontrons : ni au départ, ni à l'arrivée, mais au milieu du gué, là où l'on paie deux infrastructures, deux modèles d'exploitation et deux jeux de compétences. Ce document est écrit pour en sortir. Sa conviction : la réussite d'une transformation cloud se joue avant la première migration, dans le tri du parc, le modèle d'équipe et la discipline financière, et se mesure en valeur transformée, jamais en nombre de serveurs déplacés.

Un mot sur notre place : nous concevons, déployons et exploitons des plateformes pour nos clients, dans le cloud quand c'est le bon choix, ailleurs quand ce ne l'est pas, nous ne revendons ni capacité ni licences des hyperscalers. Cela nous laisse libres d'écrire ce qui suit : que certaines applications n'ont rien à faire dans le cloud, que la réversibilité se négocie avant la signature, et que la facture se pilote comme un compte d'exploitation, pas comme une fatalité de fin de mois.

L'usage prévu. Les chapitres se tiennent seuls ; la page 6 propose trois lectures selon votre rôle. Pressé ? Les cinq arbitrages (p. 4-5), la feuille de route (ch. 3) et l'année 1 (ch. 6) forment l'essentiel. Et si une seule chose doit survivre à cette lecture : le tri en quatre destins du chapitre 2, c'est lui qui sépare les programmes qui aboutissent de ceux qui s'enlisent.

Bonne lecture, et que votre prochaine réunion cloud parle de valeur transformée, pas de serveurs déplacés.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

pour l'équipe Clarendis, avril 2026

Les cinq arbitrages que votre comité doit trancher

Une transformation cloud de groupe n'est pas une décision, c'est cinq, souvent prises par défaut, donc mal. Les voici instruites : les deux voies, notre position, et le chapitre qui l'outille.

1 · Tout migrer, ou trier d'abord ?

ch. 2

Le « 100 % cloud en trois ans » fait de belles annonces et de mauvais programmes : il condamne à migrer tel quel, donc à payer la dette technique au tarif cloud. Notre position : trier le parc en quatre destins avant tout engagement de volume , une part du parc gagne à rester où elle est, et le dire tôt libère le budget pour ce qui se transforme vraiment.

2 · La vitesse du déménageur, ou celle du transformateur ?

ch. 1, 3

Le lift-and-shift intégral va vite, puis coûte cher pour toujours : machines surdimensionnées, licences reconduites, aucune élasticité. La refonte intégrale transforme tout, et ne finit jamais. Notre position : replatformer par défaut, refondre ce qui différencie, déménager tel quel seulement ce qui va s'éteindre. La vitesse se mesure en valeur transformée par trimestre.

3 · Un hyperscaler, ou plusieurs ?

ch. 4, 5

Le multi-cloud « de principe » double les compétences à bâtir, les socles à sécuriser et les négociations à mener, pour une réversibilité le plus souvent théorique. Notre position : un fournisseur principal choisi âprement, une réversibilité réelle (infrastructure décrite en code, données exportables, coûts de sortie chiffrés au contrat), et un second cloud seulement là où une exigence précise l'impose , réglementaire, souveraineté, ou service introuvable ailleurs.

4 · Acheter les compétences, ou les bâtir ?

ch. 5

Tout externaliser va vite la première année, puis le groupe découvre qu'il ne sait plus exploiter son propre système, et que chaque évolution passe par un bon de commande. Notre position : l'intégrateur pour accélérer, jamais pour posséder, une équipe plateforme interne dès le premier jour, la reconversion des équipes infrastructure comme chantier à part entière, et un contrat de transfert de compétences daté, avec des jalons qu'on facture s'ils sont manqués.

5 · La facture en fin de course, ou le coût dans chaque décision ?

ch. 3, 6

Dans l'ancien monde, le coût se décidait tous les cinq ans, à l'achat des machines ; dans le cloud, il se décide tous les jours, à chaque architecture et chaque environnement laissé allumé. Attendre la facture pour s'en soucier, c'est piloter dans le rétroviseur. Notre position : le FinOps n'est pas une équipe de contrôle ajoutée à la fin, c'est le coût rendu visible à celui qui le crée, dès la première vague : chaque dépense taguée et attribuée, chaque équipe devant son propre compteur.

Ce que ce document laisse de côté, et pourquoi

Le comparatif des hyperscalers (leurs services convergent, vos critères, implantations, conformité, tarification négociée, sont propres à votre dossier), le catalogue des outils (il périme en dix-huit mois), et le débat idéologique cloud contre datacenter (la bonne réponse est un portefeuille, pas un camp). Ce qui reste est ce qui ne périme pas : le tri, l'ordre des phases, la discipline des coûts, le modèle d'équipe.

La question qui départage tout le reste :pour cette application, qu'est-ce que le cloud change pour le client ou pour le compte de résultat, et comment le verrons-nous dans un an ? Une application qui a une réponse est un chantier de transformation ; une application qui n'en a pas est un déménagement, et un déménagement peut attendre, ou ne jamais partir.

Trois lectures de ce document

Selon la chaise que vous occupez au comité, le même document ne se lit pas dans le même ordre, ni avec la même question en tête.

Comité exécutif

Les cinq arbitrages (p. 4-5) → ch. 1 → ch. 6. Le milieu de gué vous dira où votre programme se situe et ce qu'il coûte à rester là ; l'année 1 vous donnera les cinq nombres à exiger chaque trimestre.

35 minutes, la question : où va l'argent ?

Dès cette semaine : demandez le coût mensuel total cloud + datacenters, et sa trajectoire sur douze mois. Si personne ne peut le donner en une réunion, l'arbitrage 5 est votre urgence.

DSI groupe

Ch. 2 → ch. 3 → ch. 5. Le tri en quatre destins est votre outil de cadrage ; les cinq phases, votre plan de programme ; le chapitre équipes, votre dossier RH et achats, c'est lui qui décide si le groupe saura exploiter ce qu'il construit.

Lecture intégrale, la question : dans quel ordre ?

Dès cette semaine : sur vos dix applications les plus coûteuses, posez la question des quatre destins. Le résultat surprend toujours, et structure tout le reste.

Direction financière

Ch. 1.2 (où part l'argent) → ch. 3.4 (FinOps) → ch. 4 (les dérives). Vous y trouverez les trois postes de gaspillage type, le modèle d'attribution des coûts aux équipes, et les six dérives dont quatre se lisent directement dans la facture.

30 minutes, la question : qui pilote le coût ?

Dès cette semaine : demandez quelle part de la dépense cloud est taguée et attribuée à une équipe nommée. Sous 80 %, personne ne pilote, on constate.

Votre programme est déjà enlisé

Ch. 1 (situer l'enlisement) → ch. 4 (nommer la dérive) → ch. 2 (retrier ce qui reste). Reprendre un programme ne veut pas dire repartir de zéro : c'est retrier le reste-à-faire avec la grille des quatre destins, et souvent en retirer un tiers.

Le chemin de reprise

Chapitre 1

Le milieu de gué

1

Pourquoi les programmes cloud de grands groupes s'enlisent au tiers du chemin, où part réellement l'argent, et trois profils de groupe pour situer le vôtre avant de reprendre la marche.

1.1 Pourquoi ça s'enlise : la mécanique du gué

Les programmes cloud de groupe suivent presque tous la même courbe. Première année : euphorie, les applications faciles migrent vite, les crédits du fournisseur adoucissent la facture, les jalons sont verts. Deuxième année : le rythme casse, restent les applications qui parlent au mainframe, celles dont l'éditeur n'existe plus, celles que personne n'ose toucher. Troisième année : le gué, deux infrastructures payées en parallèle, deux modèles d'exploitation, des équipes écartelées entre l'ancien qu'il faut maintenir et le nouveau qu'il faut apprendre. C'est le moment où les comités demandent « où en est-on ? » et où la réponse honnête est : au plus cher.

La cause n'est presque jamais technique. Elle tient dans l'ordre des décisions : on a fixé une cible de volume (« 80 % du parc en 2027 ») avant de trier le parc, choisi l'intégrateur avant le modèle d'équipe, signé l'engagement de consommation avant de savoir consommer. Chaque décision prise dans le désordre se paie au milieu du gué , c'est là que ce chapitre commence, parce que c'est là que la plupart de nos lecteurs se trouvent.

Le renversement de ce livre : la sortie du gué n'est pas d'accélérer la migration, c'est de réduire le reste-à-migrer. Retirer du périmètre ce qui n'a rien à y faire (ch. 2) raccourcit le pont plus vite que n'importe quel renfort d'intégrateur.

1

Chapitre 1 · Le milieu de gué

1.2 Où part l'argent cloud : les trois fuites que toute facture cache

La facture cloud d'un groupe au milieu du gué contient presque toujours un quart à un tiers de dépense évitable, non par négociation, mais par hygiène. Trois fuites dominent, et chacune se mesure en quelques jours avec les outils du fournisseur lui-même :

Part typique de la dépense évitable (groupe au milieu du gué, reconstitution sur nos dossiers)

Surdimensionnement hérité (machines copiées telles quelles)

~12 %

Environnements oubliés (tests, démos, projets finis)

~8 %

Licences et options reconduites sans examen

~6 %

Ordres de grandeur constatés sur nos dossiers de reprise, votre répartition différera, rarement le total. La mesure exacte est l'exercice de la phase 4 (ch. 3).

Ces fuites partagent une origine : dans le cloud, la dépense n'a plus de garde-fou physique. Au datacenter, la machine commandée en trop se voyait, il fallait la recevoir, la brancher, lui trouver une baie. Dans le cloud, elle se crée en trois clics, ne dérange personne, et facture pour toujours. Le garde-fou doit donc être reconstruit ailleurs : dans le tag obligatoire, le budget par équipe, l'extinction automatique des environnements, toute la discipline de la phase 4.

L'argument à double tranchant : ce quart évitable est la meilleure nouvelle du dossier, c'est un autofinancement du programme qui dort dans la facture. Mais il ne se récupère qu'une fois : le récupérer sans installer la discipline qui l'empêche de revenir, c'est écoper sans boucher.

1

Chapitre 1 · Le milieu de gué

1.3 Ce que le cloud change vraiment, et ce qu'il ne change pas

Le discours commercial promet l'agilité, l'innovation et l'économie ; le terrain livre autre chose, de précieux, mais à condition de le nommer exactement. Ce que le cloud change vraiment : le délai (un environnement en minutes au lieu de semaines, c'est le gain le plus sous-exploité, et le premier des cinq nombres du ch. 6), l'élasticité (payer la pointe seulement quand elle a lieu, décisive pour les charges saisonnières, indifférente pour les charges plates), les services managés (bases, files, IA : des années d'ingénierie louées à l'heure), et la visibilité du coût (chaque euro attribuable à une équipe et un usage, si on installe la discipline pour le lire).

Ce qu'il ne change pas : une application mal conçue reste mal conçue, plus chère, même, car ses défauts facturent à l'heure ; une organisation en silos reste en silos, le cloud lui donne juste des silos plus modernes ; une dette de sécurité reste une dette, exposée plus vite, car tout est à un DNS du réseau public. D'où la règle qui structure le chapitre 2 : le cloud amplifie ce qu'on y apporte. On n'y envoie donc que ce qu'on a décidé de transformer, ou ce qui est déjà sain.

Là où le cloud gagne presque toujours

Là où il faut poser le crayon et calculer

Les charges variables ou saisonnières, les nouveaux produits numériques, l'analytique et l'IA, la reprise après sinistre, tout ce qui vit en SaaS standard, et les environnements de développement, premiers bénéficiaires du délai en minutes.

Les charges plates et lourdes qui tournent 24/7 (le calcul au fil de l'eau se paie plus cher que la machine amortie), les données massives qui sortent souvent (les frais de sortie s'accumulent), le legacy stable qui s'éteindra dans trois ans, et tout ce que la réglementation assigne à un territoire.

Le mot que ce document n'emploiera plus : « migration ». Un programme de groupe réussi contient des migrations, des rachats de SaaS, des refontes, des extinctions et des maintiens assumés, le mot juste est portefeuille, et il se gère comme tel : par arbitrages datés, pas par slogan.