Un DSI qui a passé cinq ans à évangéliser la transformation DevOps de son organisation — à fusionner les équipes, à supprimer les "silos", à célébrer la vélocité des déploiements en production — ne peut pas reculer sans admettre publiquement qu'il s'est trompé. Ce n'est pas de la lâcheté. C'est le Sunk Cost Fallacy documenté par Kahneman (2011) et Thaler (1980) : la tendance à continuer un engagement non pas parce qu'il est rationnel, mais parce qu'on a déjà trop investi pour rebrousser chemin.

L'investissement est double ici. Financier d'abord — les migrations, les formations, les certifications. Mais surtout public — les posts LinkedIn, les conférences, les cas d'usage internes, la réputation professionnelle construite sur cette transformation. Reculer, c'est effacer cinq ans de posture professionnelle devant ses pairs et son DG. La peur de perdre la face est plus forte que la rationalité économique. C'est ce verrou-là qui bloque la sortie cloud avant même qu'on ait ouvert un rack.

La décision de fusionner les équipes infra et dev en 2019 était correcte avec les informations de 2019. Le mouvement DevOps avait des arguments réels — casser les silos de livraison, réduire les délais de mise en production, responsabiliser les équipes sur la qualité du code en production. Ces arguments restent partiellement vrais.

Ce qui a changé, c'est la documentation. Le CLOUD Act clarifié. Les egress fees mesurés. Le risque géopolitique TSMC identifié. L'absence de Capacity Planning chiffrée dans les factures. La perte des compétences de couches basses mesurable dans les offres d'emploi (−34% postes Linux). La décision de 2026 est différente parce que les informations sont différentes — pas parce que le décideur était incompétent en 2019.

Réviser sa position à la lumière de nouvelles données n'est pas une capitulation. C'est la définition même de la bonne gestion. C'est ce que le corpus Opération Dindon fournit : les nouvelles données. Le reste est une décision d'ingénieur.

Le mouvement DevOps, né à la fin des années 2000, a répondu à un problème documenté et réel : les équipes de développement et les équipes d'opérations travaillaient dans des silos étanches. Le développeur livrait un artefact "par-dessus le mur". L'équipe ops l'installait sans comprendre ce qu'elle installait. Les délais de mise en production se comptaient en semaines, parfois en mois. Les incidents de production étaient des crises diplomatiques autant que techniques.

Le DevOps a résolu ça. L'intégration continue, la livraison continue, l'infrastructure as code, les tests automatisés, la responsabilité partagée sur la qualité en production — ce sont des contributions réelles qui ont amélioré la qualité logicielle et réduit les délais de livraison. Cette étude ne conteste pas ces acquis.

Ce que le mouvement DevOps n'avait pas anticipé : en cassant les silos de livraison, il a aussi cassé les silos de compétence. La fusion organisationnelle des équipes a progressivement entraîné la fusion des rôles, puis la fusion des responsabilités décisionnelles. Le développeur "full-stack" est devenu le développeur "full-infra" — pas par compétence acquise, mais par glissement de périmètre.

Résultat documentable : un développeur qui déploie sur Lambda sans comprendre ce qui tourne en dessous n'est pas un DevOps — c'est quelqu'un à qui on a donné une télécommande sans lui montrer la télévision. Il peut changer de chaîne. Il ne peut pas réparer le poste. Et quand le poste est en panne — c'est-à-dire quand le lock-in est installé — il ne le voit pas arriver.

La perte est double. Le développeur perd la conscience des couches basses. L'organisation perd l'ingénieur infrastructure comme garde-fou des décisions irréversibles. Personne ne fait plus de Capacity Planning. Personne ne lit les CGV avant de choisir un service managé. Personne ne demande "ce composant peut-il tourner hors AWS sans réécriture ?" — parce que plus personne n'a les compétences pour comprendre la réponse.

Terraform, CloudFormation, Pulumi — vingt lignes de HCL ou de YAML pour instancier un cluster Kubernetes managé (EKS), une base DynamoDB, une file SQS, un réseau VPC complet. Pour un développeur, ce script ressemble à du code. Il a une syntaxe, des variables, des boucles, des modules réutilisables. Il vit dans Git, il est révisé en Pull Request, il est testé dans une pipeline CI/CD.

C'est exactement ça, le problème. L'IaC a transformé la physique de l'infrastructure en syntaxe applicative. En écrivant resource "aws_dynamodb_table" "users", le développeur a l'impression de déclarer une structure de données — pas de signer un engagement contractuel propriétaire, pas de créer un lock-in logiciel de dix ans, pas d'exclure tout futur déploiement sur une autre infrastructure sans réécriture complète.

Le code a dissous la conscience du fer. Derrière les vingt lignes HCL, il y a un datacenter en Virginie, des puces gravées par TSMC, un contrat soumis au droit californien, et des egress fees qui attendront patiemment que les données s'accumulent.

Un bug dans le code applicatif : git revert · rollback en minutes · l'état précédent est accessible dans l'historique Git.

Une erreur dans un script IaC qui instancie un service managé propriétaire : les données sont dedans · l'architecture applicative dépend de ce service · le "git revert" du Terraform ne rapatrie pas les données · la dette technique est contractuellement verrouillée.

Ces deux erreurs ont la même forme syntaxique — une ligne de code. Elles n'ont pas la même nature de risque. L'IaC a rendu cette différence invisible. C'est pourquoi l'ingénieur infrastructure doit être présent dans la revue des scripts IaC — pas pour dire non, mais pour nommer ce que le code représente physiquement et contractuellement.

Le merge DevOps n'a pas seulement été poussé par de bonnes intentions managériales. Il a été activement théorisé, marketé et financé par les hyperscalers sous les bannières du Serverless (AWS Lambda, 2014) et du NoOps — "Développez, on s'occupe du reste." Ces promesses ont un destinataire précis : le développeur. Leur objectif déclaré : supprimer la friction infrastructure. Leur effet réel : neutraliser l'ingénieur infrastructure comme opposant interne à la capture cloud.

Un ingénieur infrastructure qui comprend le fer est le principal obstacle à la vente de services cloud managés. Il pose des questions gênantes : Qu'est-ce qui tourne en dessous ? Où sont les données ? Que dit le contrat sur les egress ? Peut-on migrer ? Le supprimer organisationnellement — en fusionnant son rôle sous celui du développeur, en le faisant "évoluer" vers des certifications AWS, en renommant son métier "cloud engineer" — résout le problème commercial du côté hyperscaler.

2006-2010 : le mouvement DevOps émerge pour casser les silos de livraison. Objectif légitime.

2012-2015 : AWS, Google et Microsoft adoptent et amplifient le discours DevOps dans leurs conférences et certifications. Ils y ajoutent la couche "cloud-native" — l'idée que le vrai DevOps se fait sur le cloud. Les certifications hyperscalers remplacent progressivement les certifications infra neutres (Linux Foundation, Red Hat).

2014-2018 : Lambda (AWS), Cloud Functions (Google), Azure Functions. Le Serverless est présenté comme l'étape suivante du DevOps — plus besoin de gérer des serveurs. L'ingénieur infrastructure devient progressivement superflu dans cette narration.

2018-2024 : les organisations fusionnent massivement leurs équipes infra et dev sous des "tribes" DevOps. Le Capacity Planning disparaît. Les compétences de couches basses disparaissent. Le marché du travail Linux s'effondre (−34%). La capture est complète.

La chronologie n'est pas une théorie du complot — c'est une observation de marché. Les hyperscalers ont suivi une logique commerciale rationnelle. Les organisations ont suivi une logique managériale de bonne foi. Le résultat est documenté dans 64 études du corpus Opération Dindon.

L'ingénieur infrastructure avait une fonction invisible mais critique : le Capacity Planning. Avant de déployer un service, il estimait la charge, dimensionnait les ressources, prévoyait les pics, calculait le coût mensuel à l'échelle. Cette fonction n'était pas glamour — elle ne générait pas de démos impressionnantes en CODIR. Mais elle était le garde-fou financier de l'architecture.

Quand l'ingénieur infrastructure a été fusionné sous la coupe du développeur, cette fonction a disparu. Le cloud engineer — souvent un développeur reconverti avec une certification AWS Solutions Architect — ne prévoit plus la capacité. Il la consomme à l'aveugle. Lambda scale automatiquement — c'est la promesse. Ce que la promesse ne dit pas : Lambda scale aussi la facture, de manière non linéaire, sans alerte par défaut.

Un développeur déploie une fonction Lambda qui interroge DynamoDB avec un accès séquentiel au lieu d'un accès par batch. La fonction est déclenchée 10 millions de fois par jour. Coût estimé par le développeur : "Lambda est presque gratuit au Free Tier." Coût réel à l'échelle : la combinaison des invocations Lambda + les lectures DynamoDB + le transfert de données peut représenter plusieurs milliers d'euros par mois selon l'architecture exacte.

Un ingénieur infrastructure aurait estimé ce coût avant le déploiement. Le capacity planning est la traduction de l'architecture logicielle en coûts réels — avant qu'ils ne soient facturés. Sans cette compétence dans l'équipe, le DAF découvre les coûts en fin de mois. Pas avant.

Le DAF est le seul décideur qui ressent physiquement les conséquences du merge infra/dev — sous forme de factures cloud en croissance non linéaire, de coûts de sortie imprévus, de TCO jamais calculé. Il est aussi le plus facile à convaincre avec des données : montrer la courbe de la facture cloud sur 36 mois, superposer la disparition progressive de l'équipe infra dédiée, et laisser la corrélation parler.

La reconstruction de la frontière infra/dev n'est pas seulement une décision technique ou organisationnelle — c'est une décision financière. L'ingénieur infrastructure est un garde-fou du DAF. Sa disparition a un coût. Ce coût est mesurable, documenté, et croissant.

Recréer une frontière étanche entre infra et dev sans protocole réactive immédiatement la guerre légendaire "Devs vs Ops" : le ticket JIRA qui dort trois semaines, l'équipe infra qui dit non par réflexe, l'équipe dev qui contourne par frustration. Cette guerre a existé. Elle a produit le mouvement DevOps. Il ne s'agit pas de revenir à 2005.

La frontière à reconstruire n'est pas un mur. C'est une interface — une API organisationnelle qui permet aux deux métiers de collaborer sans se dissoudre l'un dans l'autre.

L'Internal Developer Platform (IDP) souverain est la réponse opérationnelle. L'ingénieur infrastructure ne dit plus "non" — il fournit. Il conçoit et met à disposition des développeurs des briques d'infrastructure abstraites, mais agnostiques et réversibles : une brique base de données qui peut tourner sur PostgreSQL bare-metal ou sur un cloud, une brique file de messages qui peut être RabbitMQ ou SQS selon le contexte, une brique authentification qui n'est pas verrouillée sur Cognito.

La règle de la brique souveraine : chaque composant fourni par la plateforme interne doit pouvoir répondre "oui" à la question "peut-il tourner hors AWS sans réécriture ?" Si la réponse est non, le choix est délibéré, documenté, et assumé par les deux parties — pas subi par défaut parce que "c'était simple à deployer".

L'IDP résout le problème organisationnel. Il ne résout pas le problème épistémologique : un développeur qui utilise une brique IDP sans comprendre ce qu'il y a en dessous reste incapable de reconnaître un lock-in architectural quand il en crée un.

La solution n'est pas de former chaque développeur à gérer un cluster Kubernetes. C'est de lui montrer une fois, physiquement, ce que resource "aws_dynamodb_table" déclenche en dessous — comme le professeur qui sort une parabole pour que l'étudiant comprenne sin/cos. Pas pour en faire un ingénieur infrastructure. Pour qu'il sache lire une facture cloud, reconnaître un inode, comprendre pourquoi un script IaC n'est pas un git revert.