Un investissement de 180 000€ sur 5 ans passe en revue du conseil d'administration. Une dépense mensuelle de 3 000€ passe sous le radar. C'est exactement la même chose financièrement — mais pas politiquement. Le cloud a transformé des décisions d'investissement en abonnements récurrents. Le résultat : des organisations qui dépensent 10 fois plus qu'elles ne le feraient en CapEx, sans jamais construire d'actif, sans jamais que ce chiffre soit agrégé et présenté comme une décision stratégique.

En France, le budget IT des grandes entreprises consacré au cloud est passé de 18% en 2019 à 41% en 2023. Le budget consacré aux équipes techniques internes a baissé de 22% sur la même période. La novlangue "OpEx" a rendu ces deux tendances invisibles l'une à l'autre.

"Vous ne payez que ce que vous consommez" est vrai au sens de la facturation à la seconde. Il est faux au sens économique : vous consommez ad vitam æternam, vous ne construisez jamais d'actif, et la valeur accumulée de vos paiements enrichit le fournisseur sans jamais vous appartenir. Sur 5 ans, "pay-as-you-go" produit 180 000€ de dépenses pour une instance GCP — et 0€ d'actif. Le même budget en CapEx produit un serveur, une compétence interne, et une valeur résiduelle.

"La plateforme scale automatiquement" a rendu superflue la question "qui gère la capacité ?" La réponse implicite était "personne — la plateforme le fait". En réalité, la scalabilité automatique à la hausse est réelle. La réduction des coûts à la baisse est bloquée par les commits noncancellable. Et la "plateforme" qui scale automatiquement a quand même besoin d'ingénieurs pour la configurer, la monitorer, et résoudre les incidents. Mais ces ingénieurs ont été supprimés parce que "la plateforme scale".

"Cloud-native" a créé une hiérarchie de compétences : celles qui sont "native" (propriétaires, récentes, certifiées par le fournisseur) et celles qui ne le sont pas (neutres, profondes, non certifiables par un hyperscaler). Un administrateur Linux avec 15 ans d'expérience n'est "pas cloud-native". Un junior certifié AWS Solutions Architect depuis 6 mois l'est.

En France, le nombre d'offres d'emploi pour "administrateur systèmes Linux" a baissé de 34% entre 2019 et 2023. Le nombre d'offres pour "Cloud Engineer AWS/GCP/Azure" a augmenté de 187% sur la même période. Le marché a appliqué la hiérarchie de la novlangue. Et le salaire moyen d'un DevOps certifié AWS est supérieur de 23% à celui d'un SRE bare-metal équivalent en expérience — la certification propriétaire vaut plus que la compétence neutre.

"DevOps" dans sa version cloud a fusionné deux rôles en en supprimant un. Le développeur a absorbé les opérations — mais pas les opérations bare-metal, les opérations cloud. Le "DevOps cloud" sait déployer sur EKS, configurer un pipeline GitHub Actions, et monitorer avec CloudWatch. Il ne sait pas ce qu'il y a sous EKS. Il ne peut pas en sortir seul. La fusion "DevOps" n'a pas créé des ingénieurs plus complets — elle a créé des ingénieurs plus dépendants du fournisseur.

Les dépenses CPF en certifications cloud ont triplé entre 2020 et 2023 — finançant massivement des certifications propriétaires AWS/GCP/Azure. Chaque certification AWS est un service AWS (documenté dans les CGV, soumis à l'accord CPA séparé). Elle est résiliable par AWS. Elle n'est pas transférable à GCP ou à un infogéreur souverain. L'"upskilling" cloud n'est pas de la montée en compétence — c'est un investissement public dans la dépendance privée à un acteur extraterritorial. Les fonds CPF, collectés sur les salaires français, financent la capture cognitive documentée dans le corpus.

"Transformation digitale" a transformé une question opérationnelle (comment améliorer nos systèmes ?) en question identitaire (sommes-nous une entreprise moderne ?). Une entreprise qui n'est pas "en transformation digitale" est rétrograde. Cette pression identitaire a court-circuité des analyses coût-bénéfice qui auraient dû être menées.

McKinsey (2022) : 70% des projets de "transformation digitale" échouent à atteindre leurs objectifs. Le coût moyen d'un projet de transformation digitale raté pour une grande entreprise européenne : 45 à 120 millions d'euros. Ces échecs ne sont pas principalement des échecs techniques — ce sont des échecs de cadrage. On a répondu à "est-on moderne ?" plutôt qu'à "est-ce que ça marche mieux ?"

Si la résilience est "by design" — dans l'architecture — pourquoi testerait-on ? Cette logique a produit des PCA documentés mais non testés. L'incident AWS us-east-1 de décembre 2021 a mis hors service des services "multi-AZ" parce que le plan de contrôle était centralisé. Le "design" et la réalité avaient divergé. Personne ne l'avait vu parce que personne ne testait — parce que c'était "by design".

Gartner (2023) : 35% des organisations qui ont migré massivement vers le cloud envisagent un rapatriement partiel pour raisons de coût et de résilience. Ce chiffre était de 8% en 2020. La "resilience by design" a produit des organisations qui découvrent les limites de leur résilience lors des incidents réels — pas lors des tests.

Si le "best" est défini par l'écosystème AWS, alors le "best" est toujours AWS. "Best of breed" signifie choisir le meilleur outil pour chaque besoin — mais quand tous les outils sont évalués dans le catalogue d'un seul fournisseur, "best of breed" devient "maximum de lock-in". La question "est-ce le meilleur outil parmi tous les outils disponibles ?" a été remplacée par "est-ce le meilleur outil dans ce catalogue ?" La novlangue a rétréci le périmètre de la comparaison sans que personne ne le remarque.

"Nos données sont dans le cloud global" sonne rassurant — moderne, distribué, résilient. "Nos données sont sur des serveurs en Virginie, en Irlande et à Singapour, sous juridiction américaine, soumis au CLOUD Act, avec une clause de non-divulgation légalement possible si les autorités américaines l'ordonnent" sonne différemment. C'est pourtant exactement la même chose. La novlangue "global infrastructure" a dissocié la question physique (où sont les serveurs ?) de la question juridique (quelle loi s'applique ?) pour rassurer sur la première en évitant la seconde.

"Vos données restent en Europe" est vrai au sens physique — les octets sont sur des disques en Irlande ou en Allemagne. Il est faux au sens juridictionnel — la Section 14.12 des CGV GCP stipule que le droit applicable est celui de l'État de Californie et que les tribunaux compétents sont ceux du comté de Santa Clara. "Data residency" a créé une illusion de souveraineté physique qui masque l'absence de souveraineté juridique. Les régulateurs européens ont mis des années à articuler cette distinction — pendant lesquelles des administrations publiques sensibles ont migré vers le cloud "en Europe" en croyant être protégées.

"AWS est conforme RGPD" signifie qu'AWS a mis en place des mécanismes pour aider ses clients à être conformes RGPD. Ça ne signifie pas que l'utilisation d'AWS est conforme RGPD — c'est une nuance que la novlangue "compliance" a effacée. La conformité est une propriété du système complet (infrastructure + usage + contrat + juridiction), pas du seul fournisseur. En désignant le fournisseur comme "compliant", la novlangue a déplacé la responsabilité de vérification vers le fournisseur — et supprimé l'incitation du client à vérifier lui-même.

Les hyperscalers achètent massivement des RECs — Renewable Energy Certificates. Un REC signifie que quelque part dans le réseau électrique, une quantité d'énergie équivalente à la consommation déclarée a été produite par une source renouvelable. Cela ne signifie pas que les serveurs qui hébergent vos données tournent à l'énergie verte. Cela signifie que la comptabilité carbone du fournisseur est équilibrée sur le papier.

Le datacenter AWS us-east-1 en Virginie consomme plusieurs gigawatts. Le réseau électrique de Virginie est alimenté à 30% par le charbon et le gaz naturel. Les RECs achetés par AWS ne changent pas ce mix électrique. Ils compensent comptablement une consommation réelle de fossiles. C'est de la comptabilité carbone créative — exactement comme l'OpEx est de la comptabilité financière créative.

Ce que la direction RSE a validé : "En migrant vers AWS, nous réduisons notre empreinte carbone grâce à la mutualisation des ressources." Ce qu'elle a en réalité fait : délocaliser la consommation énergétique vers des datacenters américains alimentés partiellement aux fossiles, avec une compensation carbone virtuelle achetée sur un marché de certificats.

Une architecture Serverless mal conçue (Lambda qui se réveille à froid à chaque requête, containers qui tournent en attente, jobs de monitoring qui interrogent des APIs toutes les 30 secondes) consomme du compute en continu — et donc de l'énergie en continu. Cette inefficacité est invisible dans la console cloud : elle apparaît comme une ligne de coût, pas comme une empreinte carbone. L'architecte bare-metal qui dimensionne son serveur une fois l'optimise pour durer 5 ans. L'architecture serverless peut consommer 10 fois plus de cycles CPU pour la même charge utile — et la direction RSE ne le saura jamais parce que personne ne mesure le kWh par requête.

Le mécanisme est structurel et n'implique pas de malveillance individuelle :

Étape 1 : le cabinet de conseil recommande une stratégie "cloud-first" basée sur les analyses du marché (Gartner, IDC) qu'il cite abondamment. Il facture l'étude de cadrage : 150 000 à 500 000€ selon la taille de l'organisation.

Étape 2 : l'hyperscaler certifie le cabinet comme "partenaire de niveau supérieur" (AWS Premier Partner, Google Cloud Partner, Microsoft Gold Partner). Cette certification requiert un nombre minimum de certifications cloud dans les équipes du cabinet — finançant ainsi les certifications propriétaires documentées dans la Section 2.

Étape 3 : le cabinet conduit la migration. Il facture des jours-hommes d'intégration. La complexité est son alliée — plus l'architecture est complexe, plus la migration dure, plus les jours-hommes s'accumulent.

Étape 4 : la migration produit des écarts par rapport aux estimations. Le cabinet facture des jours-hommes de remédiation. Puis de formation. Puis d'optimisation (FinOps). La relation est structurellement perpétuelle.

Ce que la boucle produit : le cabinet n'a pas d'intérêt financier à recommander le bare-metal ou l'infogéreur local — il n'y a pas de "partenariat" avec ces acteurs, pas de certification, pas de jours-hommes de migration complexe. Le conseil est structurellement orienté vers la complexité.

"Cloud-first" est le terme qui transforme une option en obligation. Une politique "cloud-first" signifie que tout nouveau projet doit d'abord évaluer une solution cloud avant toute autre option. En pratique, elle signifie que les options bare-metal, infogérance locale, ou cloud souverain sont examinées après le cloud hyperscaler — et avec un niveau de scepticisme inverse. Ce renversement de la charge de la preuve a été installé dans les politiques IT de centaines d'organisations européennes par des slides de cabinets de conseil.

Un serveur acheté 15 000€ est inscrit au bilan de l'entreprise comme un actif immobilisé. Il est amorti sur 3 à 5 ans selon le plan comptable. Chaque année, une dotation aux amortissements (3 000 à 5 000€/an) est comptabilisée en charge — réduisant le résultat imposable. Au taux d'IS français de 25%, cette dotation génère une économie fiscale de 750 à 1 250€/an.

Sur 5 ans, un serveur à 15 000€ génère entre 3 750 et 6 250€ d'économie fiscale cumulée. Le coût net réel du serveur n'est pas 15 000€ — c'est 15 000€ moins l'économie fiscale = environ 8 750 à 11 250€.

La VM GCP à 3 000€/mois génère 36 000€ de charges déductibles par an — mais sans créer d'actif. Les charges sont déductibles dans les deux cas. La différence : le bare-metal crée un actif qui apparaît dans les fonds propres, augmente la valeur comptable de l'entreprise, peut être mis en garantie d'un emprunt, peut être revendu, et peut être présenté à un investisseur comme un signe de solidité patrimoniale.

Une entreprise qui migre 100% de son infrastructure vers le cloud opère une destruction silencieuse de son bilan : les actifs immobilisés disparaissent, remplacés par des charges récurrentes. En comptabilité analytique, cette entreprise est devenue structurellement plus légère — mais aussi plus fragile. Elle n'a plus d'actifs productifs propres. Si le fournisseur augmente ses prix, elle n'a aucun levier de négociation patrimonial. Si elle veut se faire racheter, l'acquéreur ne trouvera pas d'infrastructure au bilan — seulement des contrats d'abonnement et des commits noncancellable.

"Le cloud vide la trésorerie sans créer de valeur patrimoniale" n'est pas une métaphore. C'est une réalité comptable.

Le 7 décembre 2021, AWS us-east-1 subit un incident majeur affectant de nombreux services — Kinesis, Lambda, API Gateway, AppSync, EventBridge, et d'autres. Des milliers d'équipes SRE à travers le monde reçoivent simultanément des alertes en cascade sur leurs propres services. La cause racine : une anomalie dans le plan de contrôle interne AWS.

Ce que le SRE pouvait faire : regarder ses dashboards, voir que tout tombait simultanément, lire la page de statut AWS ("We are investigating"), et attendre. Il n'avait accès à aucun log AWS interne, aucune métrique du plan de contrôle, aucun runbook AWS. La boîte noire était fermée. Le SRE était en première ligne du stress organisationnel — son téléphone sonnait, son manager lui demandait une ETA de rétablissement — mais il n'avait aucun levier technique sur la cause.

Ce que cela révèle : "Zero-ops" signifie aussi zéro visibilité sur la cause racine des incidents. Le SRE cloud-native est un expert en conséquences — il voit les effets, il ne peut pas diagnostiquer les causes quand elles sont dans l'infrastructure du fournisseur.

Un SRE bare-metal face à un incident à 3h du matin a accès à tout : les logs kernel, les métriques hardware, les traces réseau, les appels système. Il peut aller jusqu'au niveau physique si nécessaire. Son diagnostic peut descendre jusqu'à "le disque NVMe du slot 3 a un taux d'erreurs élevé depuis 48h" ou "la carte réseau du serveur 7 perd des paquets sur le VLAN de production".

Un SRE cloud-native face au même incident a accès à ses propres métriques applicatives — et s'arrête à la surface de l'API du fournisseur. Il ne peut pas voir ce qui se passe sous Lambda. Il ne peut pas diagnostiquer une dégradation de DynamoDB. Il ne peut pas tracer une requête au-delà des logs CloudWatch. La couche inférieure est opaque par design. Et cette opacité est présentée comme un avantage ("managed service — vous n'avez pas à vous en occuper") jusqu'au moment où ça tombe — et où vous n'avez toujours pas à vous en occuper parce que vous ne pouvez pas.

"Digital transformation" crée l'urgence identitaire → "Cloud-native" valide la direction → "OpEx" rend la dépense invisible → "Pay-as-you-go" normalise ne rien posséder → "Upskilling" finance les certifications propriétaires → "Cloud-native" dévalue les compétences neutres → "Zero-ops" justifie la suppression des ingénieurs → "Data residency" rassure sur la souveraineté → "Compliance" déresponsabilise le client → "Resilience by design" supprime l'incitation à tester → "Partenariat stratégique" lock-in l'organisation → "Optimisation RH" supprime les derniers ingénieurs qui pourraient sortir.

Chaque terme renforce le suivant. La sortie devient de plus en plus difficile à chaque étape. Ce n'est pas un complot — c'est un écosystème. Et les écosystèmes n'ont pas besoin de complot pour être efficaces.

Opération Dindon a documenté la capture cognitive, la boucle infrationnelle, la perte de souveraineté, l'amputation du savoir technique. Cette étude démontre que ces phénomènes sont mesurables : −34% de postes Linux, ×3 de dépenses CPF en certifications propriétaires, 70% d'échec des transformations digitales, 35% de cloud repatriation envisagé. La novlangue n'est pas la cause unique — elle est le vecteur. Elle a rendu possibles des décisions qui auraient été impossibles si elles avaient été nommées correctement.