Pendant la Guerre froide, l’Union soviétique a mis au point un système appelé Perimeter, connu en Occident sous le nom de « Main Morte ». Conçu pour lancer l’intégralité de l’arsenal nucléaire russe de manière automatique si les capteurs détectaient une frappe nucléaire et que les communications avec la direction militaire étaient interrompues[s], ce système reposait sur une logique simple : si les humains ne peuvent pas réagir, laissons les machines décider. À l’époque, cette idée était terrifiante. Ce qui devrait nous terrifier aujourd’hui, c’est que nous intégrons quelque chose d’analogue dans les fondements mêmes de la civilisation moderne, sans que personne n’ait voté pour, et sans que la plupart des gens ne sachent même qu’il existe.
La fragilité de l’infrastructure IA n’est pas une préoccupation hypothétique. C’est un phénomène qui a déjà provoqué des défaillances coûtant des milliards de dollars, et les conditions qui l’engendrent ne font que s’accélérer. Les systèmes automatisés gèrent désormais les plateformes cloud, les réseaux et les services numériques qui soutiennent la banque, la santé, les transports et les gouvernements. Lorsqu’ils tombent en panne, c’est à une échelle et une vitesse que les opérateurs humains ne peuvent pas égaler.
Fragilité de l’infrastructure IA : ce qui s’est réellement passé
Le 19 juillet 2024, l’entreprise de cybersécurité CrowdStrike a déployé une mise à jour logicielle de routine pour son capteur Falcon. Un bug dans son système de test automatisé a laissé passer un fichier défectueux. En quatre-vingts minutes environ, près de 8,5 millions d’ordinateurs sous Windows dans le monde se sont retrouvés bloqués sur un écran bleu de la mort[s]. Les compagnies aériennes ont annulé des vols. Les hôpitaux ont perdu l’accès aux dossiers des patients. Les banques se sont figées. Les services d’urgence sont tombés en panne.
Les pertes financières pour les entreprises du Fortune 500 ont dépassé cinq milliards de dollars en dommages directs[s]. De nombreuses machines touchées ont nécessité une remédiation manuelle sur site — souvent un démarrage en mode sans échec ou en environnement de récupération Windows et la suppression du fichier défectueux du capteur CrowdStrike ; certains terminaux se sont rétablis après plusieurs redémarrages ou grâce à des outils de récupération automatisés.[s] Le déploiement automatisé a causé le problème ; une grande partie de la reprise a toutefois dépendu d’interventions manuelles.
Puis le scénario s’est reproduit, différemment. Le 20 octobre 2025, Amazon Web Services a subi une panne majeure lorsqu’une condition de concurrence dans le système automatisé de gestion DNS de DynamoDB a supprimé un enregistrement d’extrémité critique[s]. DynamoDB lui-même fonctionnait parfaitement, mais personne ne pouvait y accéder. La défaillance s’est propagée à de nombreux services AWS dépendants en plus de quinze heures, perturbant des millions d’utilisateurs dans le monde.[s] Les requêtes échouées ont généré des tentatives de réessai automatisées, créant une « tempête de réessais » qui a submergé l’infrastructure interne d’AWS, rendant la reprise encore plus difficile[s].
Il ne s’agissait ni d’attaques sophistiquées ni d’accidents improbables. Ces incidents étaient les conséquences prévisibles d’un type spécifique de fragilité des infrastructures automatisées — plans de contrôle cloud et chaînes de mise à jour des terminaux qui gèrent d’autres systèmes automatisés — avec des modes de défaillance qui se propagent plus vite que toute intervention humaine.
Pourquoi l’automatisation aggrave les choses, au lieu de les améliorer
L’attrait de la gestion automatisée des infrastructures est évident. Les machines ne se fatiguent pas, elles s’adaptent sans effort et réagissent en quelques millisecondes. Mais ces mêmes propriétés deviennent des handicaps lorsqu’un problème survient.
L’agence de notation Fitch a mis en garde après l’incident CrowdStrike : les points de défaillance uniques « risquent d’augmenter à mesure que les entreprises cherchent à consolider leurs infrastructures pour tirer parti des économies d’échelle et de l’expertise, ce qui entraîne une concentration du marché entre les mains d’un nombre réduit de fournisseurs »[s]. Privacy International a été plus directe : « La concentration du pouvoir entre les mains des géants technologiques crée une dépendance excessive à des points de défaillance uniques. La diversité renforce la résilience »[s].
Le problème ne réside pas dans le fait qu’un système automatisé soit peu fiable. Individuellement, ces systèmes fonctionnent bien la plupart du temps. Le vrai défi survient lorsqu’ils interagissent. Une défaillance dans un système piloté par l’IA peut se propager à d’autres, amplifiant l’impact bien au-delà de la faille initiale[s]. La panne d’AWS en a été l’illustration parfaite : un bug DNS est devenu une défaillance d’extrémité, puis un effondrement du plan de contrôle, pour finalement provoquer une interruption de service mondiale.
Le filet de sécurité humain qui n’existe pas
La réponse classique pour rassurer face aux systèmes automatisés est l’idée d’un « humain dans la boucle », c’est-à-dire qu’une personne supervise toujours le système et peut le désactiver. Les recherches montrent de plus en plus que cette idée relève du mythe rassurant.
Le Contrôleur européen de la protection des données a publié en 2025 une analyse détaillée concluant que « le simple fait d’intégrer un humain dans le processus de décision ne garantit pas nécessairement de meilleurs résultats ». Le rapport souligne que « inclure un humain ne suffit pas à empêcher les systèmes de produire des résultats erronés ou nuisibles »[s].
Le Centre pour la sécurité et les technologies émergentes de l’Université de Georgetown a étudié le biais d’automatisation – la tendance à faire confiance aux systèmes automatisés même lorsqu’ils se trompent – dans les domaines de l’aviation, de l’automobile et de la défense militaire. Leur conclusion : « l’humain dans la boucle ne peut pas prévenir tous les accidents ou erreurs », car ce biais opère à un niveau psychologique que la formation seule ne peut pas entièrement corriger[s].
Pire encore, les compétences nécessaires pour intervenir en cas de crise s’atrophient. La perte de compétences, ou « deskilling », est bien documentée en médecine, où les outils de diagnostic par IA dégradent déjà le jugement clinique des professionnels censés les superviser[s]. Ce phénomène se généralise : à mesure que l’IA prend en charge les tâches routinières des infrastructures, les ingénieurs qui supervisaient autrefois ces systèmes perdent les intuitions et l’expertise nécessaires pour intervenir lorsque l’automatisation tombe en panne.
Le vide réglementaire
D’ici la fin de l’année 2026, le nombre d’identités IA non humaines et autonomes devrait dépasser quarante-cinq milliards, soit plus de douze fois la main-d’œuvre humaine mondiale. Pourtant, seulement dix pour cent des organisations déclarent avoir une stratégie pour gérer ces systèmes autonomes[s]. Cet écart entre la vitesse de déploiement et la maturité des cadres de gouvernance est le terreau idéal pour la fragilité de l’infrastructure IA.
L’IA n’hérite pas seulement des risques existants. Elle en crée de nouveaux. Comme l’a souligné un chercheur en politiques d’infrastructure, l’IA « amplifie et aggrave » les risques traditionnels, « élargissant le rayon d’impact des défaillances systémiques » en introduisant « des risques liés aux interactions, aux données et aux attaques, à une vitesse et une échelle machiniques »[s].
Certaines juridictions commencent à agir. L’AB 316 de Californie, entrée en vigueur en janvier 2026, interdit aux défendeurs d’invoquer le fonctionnement autonome d’un système IA comme moyen de défense contre des réclamations en responsabilité[s]. L’AI Act du Colorado, applicable à partir de juin 2026, imposera des évaluations d’impact annuelles pour les systèmes IA à haut risque. Le règlement européen sur l’IA encadre désormais les modèles d’IA à usage général. Mais l’automatisation des infrastructures qui fait fonctionner Internet, le cloud et le réseau électrique ? Elle opère largement en dehors de ces cadres.
Ce qui doit changer
Les leçons tirées de CrowdStrike et d’AWS ne signifient pas que l’automatisation est mauvaise. Elles montrent que l’automatisation sans disjoncteurs, sans expertise humaine maintenue et sans réelle diversité parmi les fournisseurs d’infrastructures est une recette pour des défaillances en cascade, systémiques, capables de mettre à genoux des économies entières.
Trois principes sont essentiels. Premièrement, le déploiement échelonné : aucune mise à jour automatisée ne devrait toucher tous les systèmes simultanément. CrowdStrike s’est depuis engagé dans une approche progressive, déployant les mises à jour auprès d’un sous-ensemble de clients avant un déploiement plus large[s]. Cela devrait être une norme industrielle, et non une leçon apprise après une catastrophe. Deuxièmement, la diversité des infrastructures : lorsqu’une seule région cloud en panne peut paralyser des services dans soixante pays, c’est l’architecture elle-même qui est vulnérable. Troisièmement, la préservation des compétences humaines : les personnes censées prendre le relais des systèmes automatisés doivent s’entraîner régulièrement à le faire, et non se contenter de savoir que c’est théoriquement possible.
La fragilité de l’infrastructure IA n’est pas un risque futur. C’est une réalité actuelle. Chaque panne en cascade nous rappelle que nous avons construit des systèmes optimisés pour l’efficacité en conditions normales, mais d’une fragilité catastrophique en cas d’anomalie. La Main Morte avait été conçue pour un scénario que ses créateurs espéraient ne jamais voir se réaliser. Nous, nous l’intégrons dans les systèmes dont nous dépendons au quotidien.
En 1985, l’Union soviétique a activé Perimeter, un système de commandement nucléaire semi-autonome que les services de renseignement occidentaux ont surnommé la « Main Morte ». Ce système surveillait l’activité sismique, les niveaux de radiation, la pression atmosphérique et les liaisons de communication. S’il détectait des signatures compatibles avec une frappe nucléaire et ne parvenait pas à joindre la direction militaire, il pouvait transférer l’autorité de lancement à des officiers de service dans des bunkers renforcés, ou, dans certaines configurations, initier le lancement de manière autonome[s]. Ce système incarnait une philosophie précise : lorsque les enjeux sont existentiels, éliminer la latence humaine du processus décisionnel critique. Cette philosophie imprègne désormais notre gestion des infrastructures numériques, et elle engendre un schéma reconnaissable de fragilité de l’infrastructure IA.
La fragilité de l’infrastructure IA à travers le prisme de la théorie des accidents normaux
En 1984, le sociologue Charles Perrow a publié Normal Accidents, soutenant que les systèmes présentant deux propriétés – complexité interactive et couplage serré – produiront inévitablement des défaillances catastrophiques, quelles que soient les mesures de sécurité mises en place. Un système est « interactif complexe » lorsque ses composants interagissent de manière non linéaire et imprévisible. Il est « étroitement couplé » lorsque les défaillances se propagent plus vite que les opérateurs ne peuvent intervenir[s].
Les infrastructures modernes gérées par l’IA présentent ces deux propriétés à un degré extrême. Des chercheurs de Stanford et de l’Université Bocconi ont appliqué directement le cadre de Perrow aux systèmes d’IA et conclu que « dans le paradigme actuel, les accidents normaux de Perrow s’appliquent aux systèmes d’IA, et ce n’est qu’une question de temps avant qu’un tel accident ne se produise »[s]. Le mécanisme est simple : à mesure que les systèmes d’IA deviennent omniprésents, « différents algorithmes interagiront directement, créant des systèmes étroitement couplés dont la capacité à causer des dommages sera impossible à prédire »[s].
Une analyse complémentaire de l’Université de Louisville étend ce cadre, notant que « l’augmentation de la complexité et l’élargissement du rôle des composants IA dans un système réduisent sa compréhensibilité, ce qui accroît la probabilité d’accidents normaux »[s]. L’idée clé de cette recherche est que l’IA ne se contente pas d’ajouter des composants à des systèmes existants ; elle modifie fondamentalement la manière dont ces systèmes tombent en panne. Les défaillances traditionnelles sont linéaires et traçables. Les défaillances médiées par l’IA sont non linéaires et souvent incompréhensibles pour les opérateurs en temps réel.
Anatomie de deux défaillances en cascade
L’incident CrowdStrike du 19 juillet 2024 en est une illustration parfaite. Le capteur Falcon de CrowdStrike opère au niveau du noyau de Windows, avec un accès privilégié au cœur du système d’exploitation. Le fichier Channel 291, une mise à jour de configuration du capteur, a passé la validation automatisée en raison d’un bug dans le système de vérification de contenu. Ce fichier a déclenché une lecture mémoire hors limites dans le parseur du capteur Falcon, provoquant un plantage du noyau Windows[s]. Quatre-vingts minutes après son déploiement, environ 8,5 millions d’appareils étaient hors service. Leur rétablissement a nécessité une intervention manuelle sur chaque machine : accès physique, démarrage en mode sans échec, suppression du fichier défectueux.
Les pertes pour les entreprises du Fortune 500 ont dépassé cinq milliards de dollars en dommages directs, les secteurs de la santé et de la banque étant les plus touchés, avec respectivement 1,94 milliard et 1,15 milliard de dollars de pertes[s]. Fitch Ratings a noté que cet incident « met en lumière un risque croissant de points de défaillance uniques » et a averti que cette concentration « risque de s’accentuer à mesure que les entreprises cherchent à consolider leurs infrastructures »[s].
La panne d’AWS du 20 octobre 2025 a révélé un mode de défaillance différent, mais avec les mêmes dynamiques sous-jacentes. AWS utilise deux sous-systèmes automatisés pour la gestion DNS : un Planificateur DNS (qui surveille l’état des équilibreurs de charge et propose des modifications) et un Exécuteur DNS (qui applique les changements via Route 53). Une condition de concurrence latente entre des instances redondantes de l’Exécuteur a conduit une tâche de nettoyage à supprimer l’enregistrement DNS actif de l’extrémité DynamoDB US-EAST-1, le laissant sans adresse IP associée[s].
DynamoDB lui-même est resté sain en interne, mais son inaccessibilité DNS s’est propagée à travers le plan de contrôle d’AWS. Les vérifications d’état d’EC2, Lambda, CloudWatch et NLB dépendaient toutes de DynamoDB. Les kits de développement logiciel des clients, confrontés à des requêtes échouées, ont lancé des réessais automatisés, créant une tempête de réessais qui a submergé l’infrastructure interne des résolveurs. Les vérifications d’état des NLB ont commencé à rejeter les nouvelles instances EC2, ralentissant la reprise. La panne a persisté plus de quinze heures et a provoqué des interruptions de service en aval pour des centaines de fournisseurs de logiciels en tant que service, qui ont attribué leurs défaillances à AWS[s].
Ces deux incidents partagent un schéma caractéristique de la fragilité de l’infrastructure IA : des systèmes de gestion automatisés opérant à des vitesses dépassant la compréhension humaine, interagissant avec des dépendances étroitement couplées de manière à amplifier les défaillances plutôt qu’à les contenir.
Le biais d’automatisation et l’érosion de la capacité de contournement humain
La théorie des organisations à haute fiabilité (HRO) suggère que le problème des accidents normaux peut être atténué par des pratiques organisationnelles spécifiques : prise de décision décentralisée, culture de la sécurité forte, redondance et formation continue par simulation[s]. L’exigence critique est que les opérateurs humains conservent à la fois l’autorité et la compétence pour contourner les systèmes automatisés. Les tendances actuelles sapent ces deux aspects.
Le Centre pour la sécurité et les technologies émergentes de Georgetown a étudié le biais d’automatisation dans trois domaines (les incidents liés à l’Autopilot de Tesla, les incidents aéronautiques Boeing/Airbus et les systèmes de défense aérienne militaires) et a conclu que « l’humain dans la boucle ne peut pas prévenir tous les accidents ou erreurs ». Ce biais provoque « des erreurs de commission (agir sur la base de suggestions IA incorrectes) et des erreurs d’omission (ne pas agir parce que l’IA n’a pas déclenché d’action) »[s].
L’analyse 2025 du Contrôleur européen de la protection des données a identifié un problème plus fondamental dans la supervision humaine des systèmes automatisés : « les résultats du système encadrent les choix disponibles, orientant subtilement les utilisateurs vers des conclusions spécifiques ». Le CEPD a conclu que « le simple fait d’ajouter un humain dans le processus décisionnel ne garantit pas nécessairement de meilleurs résultats », car cette supervision est souvent mise en œuvre « comme une simple formalité procédurale ou un geste symbolique »[s].
Pire encore, la perte de compétences dégrade activement l’expertise humaine dont dépend cette supervision. Dans le domaine de la santé, où les outils de diagnostic par IA se multiplient, les chercheurs décrivent deux mécanismes distincts : la déqualification technique, soit l’érosion des capacités pratiques lorsque les systèmes prennent en charge l’exécution, et la déqualification cognitive, soit le transfert des processus mentaux essentiels, comme l’interprétation, la pensée critique et l’apprentissage itératif[s]. Ces mêmes dynamiques s’appliquent à l’ingénierie des infrastructures. Lorsque l’IA gère le DNS, l’équilibrage de charge, la mise à l’échelle et le déploiement, les ingénieurs qui supervisent théoriquement ces systèmes perdent l’intuition opérationnelle acquise par la pratique manuelle.
L’ampleur du déficit de gouvernance
Le décalage entre le déploiement de l’IA et sa gouvernance est quantifiable. D’ici la fin de l’année 2026, le nombre d’identités IA non humaines et autonomes devrait dépasser quarante-cinq milliards, soit plus de douze fois la main-d’œuvre humaine mondiale, tandis que seulement dix pour cent des organisations déclarent avoir une stratégie de gestion pour ces systèmes autonomes[s]. Les recherches montrent que « les défaillances en cascade se propagent plus vite que les réponses traditionnelles aux incidents ne peuvent les contenir », avec des environnements simulés révélant qu’un seul agent compromis peut corrompre quatre-vingt-sept pour cent des processus décisionnels en aval en quatre heures[s].
L’IA crée ce que les chercheurs en politiques appellent un « risque incrémental », soit de nouvelles couches de vulnérabilités qui n’existaient pas avant son déploiement. Il ne s’agit pas de remplacer les risques existants, mais de les aggraver : « L’IA les amplifie et les aggrave, élargissant le rayon d’impact des défaillances systémiques » en introduisant « des risques liés aux interactions, aux données et aux attaques, à une vitesse et une échelle machiniques »[s].
Les réponses réglementaires émergent, mais restent fragmentées. L’AB 316 de Californie écarte la défense de responsabilité « c’est l’IA qui l’a fait ». L’AI Act du Colorado impose des évaluations d’impact annuelles. Le règlement européen sur l’IA encadre les modèles à usage général. Le NIST a publié en décembre 2025 un projet de cadre de cybersécurité pour l’IA, bien que ses auteurs aient explicitement reconnu des lacunes concernant les systèmes d’IA agentiques, où plusieurs agents coordonnent et agissent de manière autonome[s]. Aucun de ces cadres ne traite spécifiquement des systèmes de gestion automatisée des infrastructures qui font fonctionner le cloud, acheminent le trafic Internet ou équilibrent les réseaux électriques.
Fragilité de l’infrastructure IA : remèdes structurels
Pour remédier à la fragilité de l’infrastructure IA, des changements au niveau architectural, et pas seulement réglementaire, sont nécessaires. Quatre interventions sont essentielles.
Déploiements canaris obligatoires. Aucune mise à jour automatisée ne devrait se propager à l’ensemble des clients simultanément. CrowdStrike s’est engagé à adopter une approche échelonnée pour le déploiement des mises à jour de contenu, en les testant d’abord auprès d’un sous-ensemble de clients avant un déploiement plus large[s]. Cela devrait être une exigence réglementaire pour tout logiciel opérant au niveau du noyau ou gérant des infrastructures critiques.
Exigences de diversité architecturale. La panne d’AWS a révélé que les stratégies de zones de disponibilité ne peuvent pas résoudre les dépendances aux services fondamentaux dont la défaillance se propage à l’ensemble du plan de contrôle[s]. L’analyse de Privacy International est juste : « Internet ne devrait pas être confiné à des chemins étroits et à des jardins clos »[s]. Les services critiques ont besoin d’une véritable redondance multi-fournisseurs, et pas seulement d’un déploiement multi-régions au sein d’un seul fournisseur.
Maintien de la compétence de contournement. En s’inspirant des principes des HRO, les organisations doivent investir dans ce que les formateurs en médecine appellent la « pratique délibérée », soit des exercices réguliers où les opérateurs humains gèrent les infrastructures sans assistance automatisée[s]. L’analogie avec l’aviation est précise : les pilotes continuent de piloter manuellement les approches malgré les capacités de l’autopilote, spécifiquement pour éviter l’atrophie des compétences.
Disjoncteurs automatisés avec limitation du rayon d’impact. La tempête de réessais qui a amplifié la panne d’AWS est un schéma de défaillance connu. Les systèmes automatisés doivent intégrer des disjoncteurs qui arrêtent les réessais en cascade et imposent une limitation du rayon d’impact. La réponse post-incident d’AWS, consistant à désactiver et réévaluer les systèmes d’automatisation responsables, est une bonne intuition appliquée après coup plutôt qu’en amont[s].
Le parallèle avec la Main Morte
La Main Morte soviétique avait été conçue pour éliminer le jugement humain d’un système où un retard de réponse signifiait l’anéantissement. Ses concepteurs comprenaient le compromis : rapidité et certitude de la réponse en échange du risque de catastrophe autonome. La fragilité de l’infrastructure IA moderne intègre ce même compromis dans des systèmes que nous utilisons quotidiennement, mais sans la même clarté sur ce à quoi nous renonçons.
Perimeter avait au moins une étape d’activation explicite ; un haut responsable devait l’enclencher en cas de crise. Nos systèmes de gestion automatisée des infrastructures sont toujours actifs, toujours en train de propager des changements, toujours étroitement couplés à des dépendances en aval. Lorsqu’ils tombent en panne, c’est à la vitesse du réseau. La question n’est pas de savoir si la prochaine défaillance en cascade se produira, mais si nous aurons construit les disjoncteurs, l’expertise humaine et la diversité architecturale nécessaires pour la contenir lorsqu’elle surviendra.
