Avant la généralisation du cloud public, la frontière entre les équipes d'exploitation (administrateurs systèmes, ingénieurs systèmes, ce que l'on nomme aujourd'hui SRE) et les équipes de développement était nette. Cette frontière n'était pas arbitraire : elle reposait sur une compétence physique réelle. L'équipe Ops connaissait les limites matérielles du datacenter — la puissance disponible par baie, la capacité thermique, les contraintes de câblage, les limites de stockage physique — et opposait un refus motivé à toute demande qui menaçait ces limites.

Une demande de provisionnement déraisonnable de la part d'une équipe Dev ou d'une agence web sous-traitante se heurtait à un feu rouge technique, posé par quelqu'un qui comprenait concrètement pourquoi la demande posait un risque. Ce refus créait une friction réelle, et cette friction était souvent vécue comme une frustration légitime par les équipes Dev, pressées par des délais commerciaux que l'Ops ne partageait pas toujours.

Il serait malhonnête de présenter cet ancien monde comme parfait. Les rigidités de l'Ops historique ont aussi produit de vraies inefficacités, des délais de livraison disproportionnés, et une culture parfois excessivement conservatrice. La frustration des équipes Dev face à ces délais n'était pas infondée. C'est cette frustration légitime qui a ouvert la porte à la promesse suivante : et si l'on pouvait supprimer la friction sans supprimer la fiabilité ?

La philosophie DevOps est née, à l'origine, d'une intention saine : rapprocher deux métiers qui communiquaient mal, réduire les délais de mise en production, et instaurer une responsabilité partagée sur le cycle de vie complet d'une application. Cette intention n'est pas en cause ici.

Ce qui s'est produit ensuite est une dérive structurelle plus qu'un complot orchestré. La généralisation du cloud public a permis de créer un profil hybride — connaissant les bases des outils utilisés par l'Ops (systèmes, middleware) et les bases du métier Dev (agilité, quelques langages) — sans que ce profil hybride hérite de la compétence physique profonde qui justifiait historiquement les hard limits. Le résultat n'est pas un pont entre deux métiers complets. C'est une dilution des deux : ni la profondeur Ops d'avant, ni la profondeur Dev complète, mais une compétence transversale qui suffit à opérer dans l'abstraction cloud sans jamais avoir besoin de comprendre ce qu'il y a dessous.

C'est ce point précis qui distingue ce diagnostic d'une simple nostalgie de l'ancien monde. Le problème n'est pas que les hard limits aient disparu parce que les gens sont devenus négligents. Le problème est que l'abstraction cloud a rendu le hard limit structurellement irréalisable, indépendamment de la bonne volonté individuelle de qui que ce soit.

Une commande comme un déploiement d'infrastructure produit un effet immédiat et visible : une ressource apparaît, un serveur démarre, une console affiche un statut vert. Ce schéma — action minimale, gratification quasi instantanée, sensation de contrôle — est documenté de longue date en psychologie comportementale sous le nom de renforcement intermittent ou immédiat, et il est étudié depuis des années dans la conception des interfaces numériques grand public : notifications, mécaniques de jeu, réseaux sociaux.

Ce document avance une thèse précise et limitée : ce même mécanisme de gratification immédiate s'applique à l'expérience de provisionnement cloud. Cliquer ou exécuter une commande et voir une ressource apparaître instantanément procure une sensation de pouvoir et de contrôle disproportionnée par rapport à l'effort réel engagé. Plus l'abstraction est totale, plus la gratification est rapide et plus le coût réel — financier, technique, physique — est invisible au moment de l'action.

L'effet net de ce mécanisme à l'échelle d'une entreprise est cumulatif : chaque petite gratification individuelle (un déploiement rapide, une ressource qui apparaît) renforce l'habitude collective de recourir à l'abstraction plutôt que d'évaluer le coût structurel. C'est un effet de design produit qui se traduit en comportement organisationnel — pas un jugement sur la volonté de qui que ce soit.

Les programmes de certification du trio (AWS Certified Solutions Architect, Microsoft Azure Administrator, Google Cloud Professional) sont financés, conçus, délivrés et entretenus par les fournisseurs cloud eux-mêmes. Ce n'est pas une accusation : c'est une description factuelle de leur structure. Un ingénieur qui investit plusieurs mois et plusieurs centaines d'euros dans une certification AWS a, de fait, un capital professionnel investi dans l'écosystème AWS.

Ce mécanisme est documenté dans l'industrie sous le nom de capture par certification (vendor certification lock-in). Il ne nécessite aucune intention malveillante centralisée pour produire un effet net mesurable : un professionnel certifié a un biais rationnel et compréhensible à recommander, dans ses choix d'architecture futurs, l'écosystème dans lequel il a investi son temps et son argent. Ce biais n'est pas un défaut moral. C'est une conséquence logique de la structure d'incitation.

Cette thèse est distincte d'une accusation de complot. Elle ne prétend pas que le trio a inventé DevOps dans l'intention explicite de créer ce mécanisme. Elle affirme que, une fois la dynamique DevOps installée par le marché, le trio a structuré son offre de certification pour en tirer un bénéfice de fidélisation mesurable — ce qui est un comportement rationnel d'acteur économique, pas une anomalie.

Le modèle des six couches de verrouillage déjà établi dans ce corpus place la couche cognitive comme la plus profonde et la plus difficile à déverrouiller : ce n'est pas un verrou contractuel, ni un verrou technique, mais un verrou de référentiel mental. Une équipe formée et certifiée dans l'écosystème du trio développe, par construction, un référentiel de solutions par défaut centré sur cet écosystème.

Ce mécanisme explique un phénomène observable et fréquent : lorsqu'une direction d'entreprise déjà verrouillée dans le trio souhaite explorer un retour vers le bare metal ou un hébergeur local, les équipes techniques internes proposent souvent, de façon spontanée et non délibérée, des solutions qui restent dans le référentiel du trio — un service managé alternatif, une option de réduction de coût au sein du même écosystème, plutôt qu'une option de sortie réelle.

Cette reformulation est importante parce qu'elle change la nature de la réponse appropriée. Si le problème était une question de volonté individuelle (confort, peur), la réponse appropriée serait managériale ou disciplinaire. Si le problème est cognitif et structurel — un déficit de formation sur un référentiel alternatif — la réponse appropriée est pédagogique : élargir le référentiel disponible, pas sanctionner l'absence d'un référentiel qui n'a jamais été enseigné.

Ce qui suit n'est pas une proposition théorique inédite. C'est la restitution d'un programme de formation professionnelle réel, suivi en 2005 dans un centre de formation professionnelle destiné aux demandeurs d'emploi, sur une durée de six mois. Ce socle a permis, à l'époque, de former des techniciens capables de comprendre l'infrastructure du bit jusqu'au système d'exploitation, avant toute spécialisation ultérieure. Il a fait ses preuves comme point d'entrée dans le métier il y a vingt ans, et la thèse de ce document est qu'il reste pertinent aujourd'hui comme réponse structurelle au verrouillage cognitif décrit en section 5.

Trois mécanismes distincts ont été décrits dans ce document : un mécanisme comportemental où le design produit exploite une gratification immédiate documentée, un mécanisme économique où les certifications produisent une fidélisation structurelle sans intention malveillante centralisée, et un mécanisme cognitif où l'absence de référentiel alternatif empêche, par construction, la proposition spontanée de solutions hors du trio. Aucun des trois ne repose sur une accusation de mauvaise volonté individuelle.

Cette distinction a une conséquence pratique directe. Si le problème était la volonté, la réponse serait disciplinaire. Puisque le problème est structurel — design produit, incitation économique, déficit cognitif — la réponse appropriée est elle aussi structurelle : un programme de formation qui reconstruit le référentiel manquant.

Ce document ne prétend pas que ce programme de formation est une solution complète ou suffisante à lui seul. Il prétend que c'est un levier nécessaire, documenté par un précédent réel — un programme qui a déjà existé et déjà produit des résultats il y a vingt ans — et que ce levier répond précisément au mécanisme cognitif identifié en section 5, plutôt qu'à un mécanisme de volonté qui n'a jamais été la véritable cause du problème.