Le verrouillage n'est jamais forcé — il est consenti par ignorance des lois physiques et économiques de l'infrastructure.

La lithographie ultraviolette extrême (EUV) est la seule technologie permettant de produire des puces sous 7 nanomètres. Une seule entreprise néerlandaise est le fabricant mondial unique de machines EUV — une machine coûte environ 150 à 200 millions d'euros et pèse 180 tonnes ; aucune alternative n'existe, ni en Chine, ni en Russie, ni ailleurs en Europe. En aval, un seul fondeur taïwanais produit environ 90% des puces avancées mondiales, sur une île exposée à une tension géopolitique structurelle documentée. Conséquence concrète : toute organisation, quel que soit son bare-metal possédé, dépend en dernier ressort de cette chaîne de fabrication pour son prochain achat de matériel.

Depuis 2008, chaque processeur d'un des deux grands fabricants x86 intègre un sous-système de gestion — un processeur secondaire gravé dans la puce principale, avec son propre firmware propriétaire et son propre système d'exploitation, fonctionnant indépendamment du système principal et même lorsque le serveur est éteint, tant qu'il reste alimenté. Le second grand fabricant dispose d'un équivalent. Une organisation qui pense s'être affranchie du cloud en achetant du bare-metal résout une dépendance logicielle pour tomber dans une dépendance matérielle plus profonde.

Faire s'exécuter en temps réel un modèle d'intelligence artificielle frontal pour des milliers d'utilisateurs simultanés, à latence sub-seconde, exige un cluster de processeurs graphiques dédiés, pas une carte isolée. Un accélérateur de dernière génération, en configuration de huit unités ou plus, coûte de l'ordre de 30 000 à 40 000 dollars pièce ; un système à huit accélérateurs s'échelonne entre 300 000 et 350 000 dollars. Chaque carte consomme environ 1 000 watts, imposant un refroidissement liquide hors de portée d'une organisation standard. Le prix de l'inférence facturé au client (un modèle frontal récent facturé au double du tarif de son prédécesseur lancé six semaines plus tôt) ne couvre pas le coût réel de l'infrastructure sous-jacente — il finance un déficit structurel adossé au pari que seuls les détenteurs du capital silicium le plus récent pourront in fine rentabiliser l'inférence à grande échelle.

Une norme comptable internationale entrée en vigueur en janvier 2019¹ impose de reconnaître au bilan la quasi-totalité des contrats de location sous forme d'un actif de droit d'utilisation et d'une dette locative correspondante — mettant fin à la pratique antérieure de location hors bilan. Un serveur physique loué sur plusieurs années tombe sous cette norme et alourdit visiblement le bilan et l'endettement apparent de l'entreprise ; le contrat de service cloud, structuré comme une consommation de service continue plutôt que comme une location d'actif identifiable, y échappe structurellement. Cette différence de traitement pousse mécaniquement les organisations vers la consommation cloud instantanée plutôt que vers l'engagement d'actif visible au bilan — non par choix technique, mais par optimisation comptable.

William Stanley Jevons observait en 1865¹ que l'amélioration de l'efficacité des machines à vapeur en Angleterre n'avait pas réduit la consommation totale de charbon du pays — elle l'avait augmentée, en rendant l'usage de la vapeur assez abordable pour multiplier ses applications. Transposé au calcul : une amélioration de l'efficacité peut augmenter la consommation totale, pas la réduire.

Sous infrastructure à capacité fixe, une régression algorithmique sature la machine dès que la charge dépasse la capacité disponible, déclenchant des signaux techniques durs et immédiats qui contraignent l'équipe à traiter la cause algorithmique dans l'urgence. Sous auto-scaling, la panne technique dure se transforme en dérive budgétaire lente : le signal d'alarme est anesthésié, pas supprimé.

Les principaux fournisseurs cloud proposent des instruments contractuels réduisant le coût unitaire du calcul en échange d'un engagement de durée — un type d'instance précis pendant un à trois ans, en échange d'une réduction pouvant atteindre l'ordre de 70% par rapport au tarif à la demande. Dans sa structure : un engagement de capital ; dans sa forme comptable : une facture.

Aucun de ces mécanismes ne relève d'une décision malveillante isolée : le duopole de fabrication, le verrou firmware, la barrière du cluster d'inférence et la mutation comptable sont chacun des faits structurels, documentés indépendamment. Leur empilement produit une dépendance qu'aucun des mécanismes pris seul n'expliquerait.

Le fork capture le code, mais l'émulation capture le geste : un fournisseur peut reproduire fidèlement le comportement observable d'une interface ouverte sans jamais reprendre une ligne de son code sous licence — ce qui la met hors de portée du droit d'auteur tout en produisant le même effet de dépendance à son implémentation propriétaire.

Qui possède les retours de la production ? Le fournisseur qui héberge l'exécution d'un projet open source observe, à distance et en continu, la manière dont il est réellement utilisé en conditions réelles — un signal que le mainteneur du projet, s'il n'héberge pas lui-même cette exécution, ne reçoit jamais dans la même proportion. Ce déséquilibre d'information oriente silencieusement la feuille de route du projet vers les usages du fournisseur qui les observe.

Ce déséquilibre d'observation n'est pas seulement technique : il est contractualisé. Les conditions d'utilisation des grands fournisseurs cloud distinguent explicitement la « donnée client » (protégée, usage restreint à la fourniture du service) de la « donnée de télémétrie » ou « donnée de service » — métriques de performance, journaux d'utilisation, schémas d'appel d'API — que le fournisseur se réserve le droit d'analyser librement pour améliorer et dimensionner sa propre infrastructure. Cette distinction contractuelle, présentée comme une clause technique anodine, est le socle juridique exact de l'asymétrie décrite plus haut : le fournisseur d'infrastructure capture légalement la visibilité sur l'usage réel de tout logiciel — propriétaire ou ouvert — qui s'exécute sur sa plateforme, à l'insu de l'éditeur du logiciel lui-même.

Un commit légitime en apparence — une amélioration de performance, une correction de bug — peut discrètement réorienter un projet ouvert vers un seul type de matériel ou une seule plateforme d'exécution, sans jamais violer la licence ni être identifiable comme une capture au moment où il est proposé. L'enracinement propriétaire qui en résulte se lit après coup, dans l'accumulation, pas dans un commit isolé.

Écrire une infrastructure « agnostique » revient à renoncer, par construction, à toute fonctionnalité avancée propre à un seul fournisseur — le dénominateur commun de ce que l'abstraction peut décrire diminue à mesure que le périmètre multi-cloud s'élargit. La loi de la variété requise (Ashby, 1956)¹ explique qu'un plan de contrôle unifié ne peut absorber une variété de comportements supérieure à la sienne ; l'isomorphisme institutionnel (DiMaggio & Powell, 1983)² explique pourquoi la direction persiste dans cette stratégie malgré l'échec technique documenté — le multi-cloud s'assimile alors à une prime d'option réelle rarement mise en regard de sa probabilité d'exercice.

Chaque environnement supplémentaire n'ajoute pas une variante, il ajoute un système parallèle complet : maintenir une posture multi-cloud opérationnelle ne consiste pas à écrire une seule définition d'infrastructure exécutable partout, malgré la promesse portée par les outils d'infrastructure-as-code — chaque fournisseur impose ses propres divergences d'implémentation, jusque dans le stockage persistant et l'équilibrage de charge. Même lorsqu'un même workload s'exécute sur deux fournisseurs distincts, la télémétrie d'infrastructure sous-jacente — état matériel du nœud, métriques de l'hyperviseur, journaux système bas niveau — n'est jamais exposée par une interface commune : l'agnosticisme s'arrête là où commence le débogage de la production.

Face au renoncement systématique et à la taxe de duplication, la réponse structurelle consiste à choisir un unique environnement d'exécution cible — un fournisseur cloud maîtrisé en profondeur plutôt que plusieurs maîtrisés en surface — et à l'exploiter pleinement plutôt que de payer indéfiniment le prix de l'agnosticisme.

Une infrastructure cloud se décompose en trois couches : la couche physique (silicium, datacenter — Livre I), la couche d'orchestration (hyperviseur, control plane, API de gestion), et la couche d'usage. La souveraineté juridique revendiquée par les offres de « cloud souverain » porte sur les deux couches périphériques, sans nécessairement porter sur la couche intermédiaire qui gouverne pourtant le fonctionnement réel. Grossman & Hart (1986)¹ établissent qu'un droit de propriété formel sur un actif ne confère de contrôle réel que dans la mesure où son détenteur peut décider des usages non spécifiés par contrat — ces « droits de contrôle résiduels ». Illustration documentée : une offre de cloud « souverain » où les mises à jour de la couche logicielle du grand fournisseur sous-jacent transitent par une zone de quarantaine où l'opérateur local peut auditer le code avant déploiement, mais où le monitoring et l'administration opérationnelle restent assurés par cet opérateur, sans que la conception de l'orchestrateur lui-même ne change de mains.

L'asymétrie d'information principal-agent (Stiglitz)¹ se matérialise concrètement : interrogés publiquement sur la durée pendant laquelle un grand fournisseur cloud garantit la disponibilité de ses mises à jour logicielles à un opérateur local, les responsables techniques n'ont pas donné de réponse précise, renvoyant la question aux clauses confidentielles du contrat entre les deux sociétés — l'existence même d'un engagement de durée n'est pas publique. Teece (1986)² complète l'ancrage : un innovateur peut ne pas capter la valeur de son innovation lorsque des actifs complémentaires spécialisés restent détenus par un tiers ; ici, une clause de réversibilité restitue la donnée brute mais pas les actifs complémentaires nécessaires à son exploitation — API de gestion, configuration des services managés, automatisations construites autour.

Principe de réunification : fonder la couche d'orchestration sur un logiciel dont le code source est intégralement disponible, et le faire compiler par l'opérateur local lui-même à partir de ses propres chaînes de construction, plutôt que de recevoir un binaire livré et maintenu par un tiers — ce qui déplace le point d'exercice du contrôle résiduel de la distribution du binaire vers la compilation elle-même. Principe d'isolation : ne recevoir, en amont, que le code source publié, sans canal de distribution privilégié ni notification préalable d'un fournisseur unique — l'intégration d'une évolution devient un acte volontaire de l'opérateur local, à un rythme qu'il détermine.

Les trois mécanismes partagent une structure commune : chacun documente un niveau d'ouverture réelle et vérifiable (le code, le manifeste, la donnée) qui coexiste avec un niveau de contrôle qui, lui, reste fermé (l'usage observé, le comportement à l'exécution, l'orchestration). L'ouverture partielle n'est pas un mensonge — elle est l'alibi structurel qui rend le niveau fermé invisible.

Une masse de données accumulée exerce une attraction irrésistible sur le calcul et les services tiers qui la traitent (McCrory, 2010)¹ : plus une organisation stocke de données chez un fournisseur, plus il devient économiquement rationnel d'y exécuter aussi le calcul qui les traite, par simple évitement des coûts de transfert. Ces coûts sont eux-mêmes une barrière à la sortie délibérément irréversible (Klemperer, 1987)² : aux tarifs standard 2026, l'egress internet facturé par les grands fournisseurs s'échelonne de 0,08 à 0,12 dollar par gigaoctet selon le palier, et jusqu'à 0,23 dollar pour un transit intercontinental — soit, pour un pétaoctet exporté, un ordre de grandeur de 80 000 à plus de 200 000 dollars. Le temps de transfert renforce ce constat : à un débit soutenu de 10 Gbit/s, déplacer un pétaoctet demande de l'ordre de neuf jours de transfert continu — une limite physique théorique optimale, calculée sans dégradation ni interruption, donc un plancher.

Une identité IAM n'est pas un fichier que l'on exporte : c'est une relation vivante, valable uniquement à l'intérieur du graphe de confiance du fournisseur qui l'a émise. Un rôle, un profil d'instance, une identité managée n'ont de sens que dans l'annuaire et l'infrastructure de vérification du fournisseur d'origine — migrer une organisation ailleurs ne migre pas cette relation, elle doit être recréée de zéro. La matérialité empirique le confirme sur les trois grands fournisseurs : une clé protégée par les HSM d'un premier fournisseur (validation FIPS 140-2 Level 2¹) ne peut jamais être exportée en clair ; chez les deux autres grands fournisseurs, la clé est générée et utilisée exclusivement à l'intérieur de HSM certifiés FIPS 140-2 Level 3, avec la même garantie de non-extraction. W. Brian Arthur (1989)² établit qu'un choix technique initial, même mineur, peut se retrouver verrouillé par l'effet cumulatif de petits événements historiques renforcés par des rendements croissants, sans décision unique identifiable — le choix initial d'un fournisseur d'identité s'inscrit dans cette dynamique. Grossman & Hart (1986)³ complètent l'ancrage : le contrat peut énumérer des droits spécifiques (accès, portabilité des données brutes), mais le droit résiduel sur la chaîne d'attestation matérielle — quel HSM signe, quel hyperviseur atteste le démarrage d'une machine — revient par défaut à celui qui possède l'infrastructure.

Le temps que l'ingénieur ait connaissance d'un incident et veuille en diagnostiquer la cause racine, les journaux non externalisés, l'état mémoire et le contexte précis de l'erreur ont souvent déjà été détruits par le redémarrage automatique de l'orchestrateur. En accomplissant parfaitement sa fonction de résilience, l'orchestrateur incinère simultanément la scène de l'incident. Un glissement distinct s'ajoute à cette destruction : un ingénieur qui exécute un runbook — de plus en plus généré par des assistants d'intelligence artificielle — sans en comprendre chaque étape ne développe jamais la capacité à réagir face à un incident qui ne correspond à aucune procédure existante, c'est-à-dire face à tout incident réellement nouveau.

Les trois mécanismes convergent sur un même point : la réglementation et les architectures ouvertes peuvent rendre portable ce qui se compte et se fichier — les octets, les définitions de rôle — sans jamais atteindre ce qui ne se compte pas — l'écosystème attiré par la masse, la relation de confiance derrière l'identité, l'instinct derrière le diagnostic.

Un modèle d'intelligence artificielle frontal, servi sous API par un fournisseur unique, impose un double compromis que son marketing dissimule derrière la taille annoncée de sa fenêtre de contexte. Le premier est le débit simultané : un cluster d'inférence privé, dimensionné pour une seule organisation, sert nécessairement moins d'utilisateurs en parallèle qu'un service mutualisé sur des milliers de clients, à coût unitaire équivalent — l'élasticité apparente du service centralisé masque cette asymétrie de charge. Le second est la fraîcheur des poids : un modèle exécuté localement reste figé entre deux campagnes de ré-entraînement, tandis que le service propriétaire est mis à jour en continu par son fournisseur. L'alibi de la fenêtre de contexte géante — plusieurs millions de jetons annoncés par certains fournisseurs en 2026 — ne résout ni l'un ni l'autre : le piège n'est jamais la taille de la mémoire volatile, c'est la dépendance structurelle au cerveau centralisé qui la porte.

Les normes recommandées pour les datacenters imposent une température de fonctionnement entre 18 et 27°C à l'entrée du matériel — l'allée froide où travaille le technicien est souvent plus froide encore. Le niveau sonore y dépasse fréquemment 85 décibels, seuil au-delà duquel la réglementation impose une protection auditive. Un environnement conçu pour le matériel, pas pour un corps donné, filtre silencieusement qui peut y travailler longtemps sans inconfort disproportionné.

Plusieurs études indépendantes sur le secteur technologique documentent des taux de harcèlement plus élevés dans les rôles techniques profonds que dans les rôles administratifs. Sur une équipe ne comptant qu'une seule femme, ce profil porte une charge cognitive supplémentaire — voir sa performance perçue comme représentative de tout un groupe — quantifiable par la théorie du jeton unique (Kanter, 1977)¹, absente pour le profil majoritaire de la même équipe.

La matière (Livre I), le droit et le logiciel (Livre II), l'information (Livre III) et l'humain (Livre IV) documentent chacun un mécanisme de capture qui ne se lit jamais dans sa propre couche : le silicium capture au niveau du firmware, la licence capture au niveau de l'exécution observée, la donnée capture au niveau de ce qu'elle attire, et la cognition capture au niveau du modèle qui la simule. Aucune de ces captures n'est imposée par la force — chacune est consentie par ignorance des lois physiques, économiques et organisationnelles qui la rendent possible.

Cette fonte finale a suivi une méthode fixe, répétée à chaque chapitre : Claude rédige, en s'appuyant exclusivement sur les textes sources et sur une vérification indépendante de chaque fait avancé. Gemini audite ensuite sans concession, cherchant délibérément la faille plutôt que la confirmation — citations à vérifier mot pour mot, angles morts à débusquer, incohérences à signaler. Amine arbitre en dernier ressort : il tranche les désaccords entre la Production et l'Auditeur, corrige la trajectoire quand les deux se trompent ensemble, et décide seul de ce qui reste ou disparaît. Aucun chapitre de ce traité n'a été scellé sans passer par ces trois filtres, dans cet ordre, autant de fois que nécessaire.