Le jour où 8,5 millions d'ordinateurs sont morts — et ce que ça m'a appris pour bâtir des logiciels qui ne peuvent pas défaillir
J'étais assis dans le hall d'un hôtel à Hyderabad quand mon téléphone s'est mis à vibrer. Pas le flot habituel de notifications Slack — c'était un déluge. Toute la flotte de machines Windows d'un client était passée au bleu. Puis un autre client. Puis la nouvelle est tombée : des aéroports clouaient les avions au sol, des hôpitaux annulaient des opérations, des banques gelaient des transactions. Tout ça à cause d'une seule mise à jour de fichier de CrowdStrike, plus petite que la photo que vous prendriez de votre déjeuner.
19 juillet 2024. Le jour où environ 8,5 millions de systèmes Windows ont simultanément sombré dans l'écran bleu de la mort. Le jour qui allait finir par coûter à l'économie mondiale plus de 10 milliards de dollars de dommages. Et le jour où je suis devenu obsédé par une question qui m'empêche encore de dormir la nuit : Pourquoi construisons-nous les systèmes les plus critiques de l'histoire de l'humanité sur des fondations qu'un fichier de configuration peut anéantir ?
Je dirige Veriprajna, un cabinet de conseil en IA. Nous construisons ce que j'appelle des solutions « Deep AI » — des systèmes qui s'intègrent à l'infrastructure fondamentale, et non les minces surcouches ChatGPT qui dominent le marché aujourd'hui. Quand la panne CrowdStrike s'est produite, la moitié du secteur de l'IA a haussé les épaules. « Problème de sécurité », disaient-ils. « Pas notre domaine. » Mais j'ai vu quelque chose de différent. J'ai vu exactement la même fragilité architecturale qui gangrène chaque entreprise pressée de greffer de l'IA sur ses opérations sans comprendre ce qui se passe en dessous.
J'ai passé des mois après la panne à disséquer l'analyse des causes profondes, à suivre le litige de Delta Air Lines et à étudier les recherches émergentes sur la vérification formelle. Ce que j'ai découvert a changé la façon dont mon équipe construit tout. J'ai rédigé ici une analyse interactive complète de l'étude intégrale, mais cet essai raconte l'histoire derrière la recherche — les parties qui ne rentrent pas proprement dans un livre blanc.
Un fichier plus petit qu'un JPEG a mis à terre l'aviation mondiale
Voici ce qui s'est réellement passé, débarrassé du jargon.
La plateforme de sécurité Falcon de CrowdStrike s'exécute à l'intérieur du noyau Windows — la couche la plus profonde et la plus privilégiée du système d'exploitation. Voyez-la comme la salle des machines d'un navire. Si quelque chose tourne mal sur le pont, on peut le réparer. Si quelque chose tourne mal dans la salle des machines, le navire coule.
Pour détecter rapidement les nouvelles menaces, CrowdStrike a construit un système appelé « Rapid Response Content ». Au lieu de pousser des mises à jour logicielles complètes (lentes et exigeant des tests), ils poussent de petits fichiers de configuration — en gros des fiches d'instructions qui indiquent au moteur de sécurité quels motifs rechercher. C'est astucieux. C'est aussi, comme nous l'avons appris, effroyablement dangereux.
Ce matin-là, deux nouveaux jeux d'instructions ont été déployés pour détecter un type précis de communication interprocessus. Ces instructions faisaient référence à 21 paramètres d'entrée. Le problème ? Le moteur s'exécutant sur chaque point de terminaison — le code réel s'exécutant dans le noyau — n'en comprenait que 20 paramètres.
Le cloud disait « lis 21 champs ». Le noyau n'en connaissait que 20. Cette non-concordance a fait planter 8,5 millions d'ordinateurs.
Le validateur dans le cloud a approuvé la mise à jour parce que sa définition du gabarit incluait 21 champs. Il vérifiait par rapport à sa propre attente, et non par rapport à la réalité de ce que le point de terminaison pouvait gérer. Quand l'interpréteur au niveau du noyau a tenté d'accéder à ce 21e champ, il a lu au-delà de la limite de la mémoire allouée. Dans l'espace noyau, ce n'est pas une erreur récupérable. C'est un plantage instantané. Écran bleu. Redémarrage. Nouveau plantage. Redémarrage. Nouveau plantage. Une boucle de mort infinie.
Je me souviens d'avoir expliqué cela à un investisseur non technique lors d'un dîner quelques semaines plus tard. Il m'a regardé fixement et a dit : « Alors tu me dis que personne n'a testé si la chose qui recevait la mise à jour pouvait réellement traiter la mise à jour ? » J'ai hoché la tête. Il a posé sa fourchette. « Ce n'est pas un bogue logiciel. C'est de la négligence. »
Il n'avait pas tort. Et un juge de Géorgie allait, pour l'essentiel, lui donner raison.
Pourquoi 40 000 serveurs ont dû être réparés à la main
La partie de l'histoire qui ne reçoit pas assez d'attention, c'est la récupération — ou plutôt, l'impossibilité de la récupération à distance.
Voici l'ironie cruelle : l'agent CrowdStrike est la chose qui reçoit les commandes du cloud. « Annule cette mise à jour. » « Applique ce correctif. » Mais le plantage survenait si tôt dans la séquence de démarrage que l'agent ne s'initialisait jamais. Le logiciel censé recevoir le signal de secours était précisément ce qui provoquait la noyade.
Mon équipe a commencé à appeler cela le problème de l'« agent mort ». Chaque machine touchée était orpheline. Elle ne pouvait pas rappeler la base. Elle ne pouvait pas recevoir d'instructions. Le seul remède consistait à démarrer physiquement chaque machine en mode sans échec, à naviguer jusqu'à C:\Windows\System32\drivers\CrowdStrike\, et à supprimer manuellement le fichier défectueux.
Pour Delta Air Lines, cela signifiait toucher environ 40 000 serveurs et des milliers de postes de travail. À la main. Un par un.
J'ai déjà géré des opérations de récupération informatique par le passé, et la logistique d'une telle échelle est presque incompréhensible. Il faut un accès physique à des machines qui peuvent se trouver dans des salles de serveurs verrouillées, dans différentes villes. Il faut des techniciens qui savent démarrer en mode sans échec — ce qui, à l'ère du chiffrement BitLocker, exige souvent des clés de récupération stockées sur… d'autres serveurs qui ont eux aussi planté. C'est un empilement sans fin de tortues.
Les concurrents de Delta — American Airlines, United — se sont rétablis en un à trois jours. La perturbation de Delta a duré plus de cinq jours et a entraîné plus de 7 000 vols annulés et 550 millions de dollars de pertes. La différence ? Le système de suivi des équipages de Delta, le logiciel qui indique à la compagnie où se trouvent ses pilotes et ses agents de bord et quand ils sont disponibles, fonctionnait presque entièrement sous Windows. Quand ces serveurs sont morts, Delta n'a pas seulement perdu des ordinateurs. Elle a perdu la capacité de savoir où étaient ses propres employés.
Que se passe-t-il quand un bogue logiciel devient une « faute lourde » ?
C'est ici que l'histoire passe de la salle des serveurs à la salle d'audience, et là où, selon moi, les implications deviennent véritablement révolutionnaires pour le secteur.
Delta a poursuivi CrowdStrike. Cela seul n'a rien de surprenant — les entreprises poursuivent leurs fournisseurs après des défaillances majeures tout le temps. Ce qui est surprenant, c'est ce que le juge a autorisé à suivre son cours.
Historiquement, les éditeurs de logiciels ont été protégés par leurs contrats. Enfouie dans les conditions d'utilisation, on trouve toujours une clause de plafonnement de responsabilité — généralement limitée à ce que le client a payé pour l'abonnement. C'est un arrangement confortable. Vous vendez un logiciel qui opère au niveau le plus profond de l'infrastructure d'un client, et s'il détruit tout, votre exposition maximale se limite à douze mois de frais de licence.
En mai 2025, la juge Kelly Lee Ellerbe de la Fulton County Superior Court a refusé de rejeter les allégations de Delta pour faute lourde et — c'est celle qui m'a fait me redresser sur ma chaise — intrusion informatique.
L'argument de la faute lourde est simple : CrowdStrike a poussé la mise à jour vers l'ensemble des 8,5 millions de systèmes simultanément. Aucun déploiement échelonné. Aucun déploiement canari. Aucun « essayons d'abord ceci sur 1 % des machines pour voir ce qui se passe ». Les avocats de Delta ont soutenu que cela constituait un mépris conscient de risques connus. Le propre rapport post-incident de CrowdStrike a admis que le Content Validator présentait une erreur de logique et que le Content Interpreter n'avait pas de vérification des limites à l'exécution.
Mais l'allégation d'intrusion informatique est celle qui devrait terrifier tout éditeur SaaS qui lit ceci. Delta avait désactivé les mises à jour automatiques dans ses paramètres. CrowdStrike a poussé la mise à jour malgré tout, via le mécanisme de fichier de canal au niveau du noyau. La juge a statué que les obligations légales relatives à l'intrusion informatique sont indépendantes de l'accord d'abonnement — ce qui signifie que le plafond de responsabilité prévu au contrat ne s'applique pas.
Quand un fournisseur passe outre vos préférences explicites pour pousser du code dans votre noyau, le plafond de responsabilité du contrat peut ne pas le protéger. Voilà la nouvelle réalité juridique.
J'ai parlé à trois RSSI différents depuis cette décision, et chacun d'eux m'a dit la même chose : « Nous réécrivons nos accords fournisseurs. » L'ère de la confiance illimitée dans les mises à jour automatiques des fournisseurs de sécurité est révolue.
Le parallèle dérangeant avec le secteur de l'IA
Voici maintenant où je vais être franc, et où certains de mes pairs dans le domaine de l'IA n'aimeront pas ce que j'ai à dire.
Le secteur de l'IA se construit sur les mêmes fondations fragiles que CrowdStrike a mises au jour. Nous le faisons simplement plus vite et avec plus de battage.
Le marché est aujourd'hui dominé par ce que j'appelle les « surcouches de LLM » — de minces couches applicatives qui font des appels d'API à GPT-4 ou Claude, enveloppent la réponse dans une jolie interface et appellent cela un produit d'IA. J'ai vu des présentations d'entreprises dont toute l'architecture technique se résume littéralement à « nous envoyons une invite à OpenAI et affichons le résultat ». Elles sont valorisées à des dizaines de millions de dollars.
J'étais à une conférence l'an dernier où un fondateur présentait fièrement son « outil d'analyse de sécurité alimenté par l'IA ». J'ai posé une question toute simple : « Que se passe-t-il si OpenAI modifie son API, multiplie ses prix par 10 ou tombe en panne pendant six heures ? » Il m'a regardé comme si je lui avais demandé ce qui se passe si la gravité cesse de fonctionner. « Ça n'arrivera pas », a-t-il dit.
Ça arrivera. Ça arrive toujours. La panne CrowdStrike a prouvé que même les fournisseurs d'infrastructure les plus fiables, ceux sur lesquels vous avez misé toute votre exploitation, peuvent pousser un seul mauvais fichier et tout faire s'effondrer.
C'est pourquoi nous avons bâti Veriprajna autour de ce que j'appelle la « Deep AI » — et je tiens à être précis sur ce que j'entends par là, car le terme est employé à tort et à travers.
Une solution de Deep AI ne loue pas son intelligence auprès d'un unique fournisseur tiers. Elle utilise des architectures hybrides — petits modèles de langage spécialisés, modèles vision-langage, réseaux de neurones sur graphes — déployés sur l'infrastructure même du client lorsque le cas d'usage l'exige. Elle s'intègre au niveau système, et non au niveau de l'interface. Et surtout, elle utilise la vérification formelle pour fournir des garanties mathématiques sur son comportement, et non de simples estimations probabilistes.
La différence compte. Une surcouche de LLM vous donne un agent conversationnel qui a généralement raison. Un système de Deep AI vous donne un moteur qui est prouvablement correct pour la tâche précise qu'il est conçu pour accomplir.
Pourquoi je suis devenu obsédé par la vérification formelle
Je serai honnête : avant la panne CrowdStrike, je considérais la vérification formelle comme une curiosité universitaire. Un sujet sur lequel les chercheurs publiaient des articles et que personne n'utilisait en production. Le micronoyau seL4 — un noyau de système d'exploitation formellement vérifié — était impressionnant, mais semblait être une réussite isolée exigeant des années d'efforts de niveau doctorat.
Puis j'ai lu l'analyse des causes profondes de CrowdStrike pour la troisième fois, et quelque chose a fait tilt.
Toute la catastrophe se résumait à un écart sémantique. Le validateur cloud croyait que le gabarit avait 21 champs. L'interpréteur du point de terminaison croyait qu'il en avait 20. Deux composants du même système entretenaient des croyances contradictoires sur la réalité, et personne ne s'en est aperçu parce qu'il n'existait aucune spécification partagée et mathématiquement rigoureuse par rapport à laquelle les deux composants étaient vérifiés.
La vérification formelle élimine les écarts sémantiques. Elle utilise des preuves mathématiques pour garantir que le logiciel — l'implémentation réelle — satisfait toujours sa spécification. Pas « généralement ». Pas « dans nos tests ». Toujours. Si la preuve est validée, le logiciel ne peut pas violer sa spécification. Point.
Mon équipe a passé des semaines l'an dernier à expérimenter un cadre appelé VeCoGen, qui combine de grands modèles de langage avec des moteurs de vérification formelle pour générer automatiquement du code C vérifié. Le LLM propose des implémentations candidates, et un vérificateur de preuves confirme mathématiquement la correction avant tout déploiement. Si le code comporte un bogue — même subtil, comme une erreur d'un cran dans une limite de tableau — la preuve échoue et le code est rejeté.
Je me souviens de la première fois où nous l'avons fait fonctionner sur un exemple non trivial. Mon ingénieur en chef, qui s'était montré sceptique quant à toute l'entreprise, a regardé la sortie vérifiée et a dit : « Alors l'IA écrit le code et la preuve que le code est correct ? » Oui. Et le vérificateur de preuves est un système distinct et de confiance qui se moque de la confiance de l'IA — il ne se soucie que de la vérité mathématique.
Nous entrons dans une ère où le code généré par l'IA sera préféré au code écrit à la main — non pas parce que l'IA est plus intelligente, mais parce que l'IA peut générer la preuve mathématique en même temps que l'implémentation.
Martin Kleppmann a fait récemment cette prédiction, et je pense qu'il a tout à fait raison. Le « vérificateur de preuves » devient le gardien. Pas de preuve, pas de déploiement. C'est l'exact inverse du modèle CrowdStrike, où le validateur se contentait pour l'essentiel d'apposer un tampon sur les mises à jour en se fondant sur ses propres hypothèses.
Et si le système avait pu se soigner lui-même ?
Il y a un détail à propos du 19 juillet qui me hante. Le plantage s'est produit à l'échelle mondiale, sur l'ensemble des 8,5 millions de points de terminaison, parce qu'il n'existait aucun mécanisme automatisé pour détecter le motif de défaillance et interrompre le déploiement en temps réel.
Réfléchissez-y. Des millions de machines ont commencé à planter simultanément. Les signaux de télémétrie étaient là — lectures mémoire hors limites, paniques noyau immédiates, boucles de démarrage. Mais aucun système ne surveillait ces signaux d'une manière qui aurait pu déclencher un coupe-circuit automatique.
C'est le problème que la télémétrie pilotée par l'IA est conçue pour résoudre. La surveillance traditionnelle fonctionne selon des règles statiques : « Alerter si l'utilisation du processeur dépasse 90 %. » C'est comme régler un détecteur de fumée qui ne se déclenche que lorsque la maison est déjà en flammes. Ce dont vous avez besoin, c'est d'un système qui comprend à quoi ressemble le « normal » à un niveau granulaire et qui peut détecter les premières microsecondes d'écart.
Nous construisons ce que la communauté de recherche appelle l'analytique de télémétrie pilotée par l'IA, ou les cadres AITA. Ils utilisent l'apprentissage automatique non supervisé — forêts d'isolement, autoencodeurs, regroupement basé sur la densité — pour établir des références comportementales des composants du système. Les résultats de recherches récentes sont frappants : réduction de 35 % du temps moyen de détection des anomalies, réduction de 40 % des faux positifs, et une exactitude de détection des anomalies atteignant 97,5 % de précision avec 96,2 % de rappel.
Dans le scénario CrowdStrike, un système doté d'AITA aurait détecté la lecture hors limites comme un écart par rapport au comportement de référence dans les premières millisecondes de l'application de la mise à jour. Il aurait pu déclencher un coupe-circuit local — en isolant le pilote défectueux, en revenant à la dernière configuration réputée bonne — avant que le plantage ne se propage en cascade. Pas après que 8,5 millions de machines soient tombées. Avant que la deuxième machine ne tombe.
Nous ne parlons pas de science-fiction. Nous parlons de systèmes qui existent déjà dans la recherche et qui passent en production. La question n'est pas de savoir si les entreprises adopteront des architectures autoréparatrices. C'est de savoir si elles les adopteront avant ou après la prochaine cascade mondiale.
Comment construire concrètement pour cet avenir ?
Les gens me posent toujours une variante de : « D'accord, je suis convaincu que ça compte. Mais mon entreprise ne peut pas tout reconstruire de zéro. Par où commencer ? »
Question légitime. Voici où m'a mené ma réflexion après un an à travailler sur le sujet.
Premièrement, auditez ce qui s'exécute dans votre noyau. La plupart des entreprises n'ont aucune idée du nombre d'agents tiers opérant au Ring 0 — le niveau de privilège le plus profond. Chacun de ces agents est un risque potentiel de type CrowdStrike. Exigez que tout fournisseur opérant au niveau du noyau fournisse la preuve de procédures de déploiement échelonné, de versionnage de schéma entre ses validateurs cloud et ses interpréteurs de point de terminaison, et de tests de simulation de boucle de démarrage. S'il ne peut pas la fournir, voilà votre réponse sur la rigueur de son ingénierie.
Deuxièmement, cessez de traiter l'IA comme une couche d'interface. Si votre « stratégie IA » est un ensemble d'outils en surcouche de LLM qui dépendent tous des deux ou trois mêmes fournisseurs de modèles, vous avez un risque de concentration qui reflète le problème de dépendance à CrowdStrike. Commencez à construire ou à acquérir des modèles spécialisés qui s'exécutent sur votre infrastructure pour vos flux de travail les plus critiques. C'est ce que signifie la souveraineté de l'IA en pratique — non pas une idéologie, mais une résilience opérationnelle.
Troisièmement, faites de la vérification formelle une exigence d'approvisionnement, et non une aspiration de recherche. Les outils existent désormais. VeCoGen et des cadres similaires rendent possible la génération de code vérifié à grande échelle. Pour tout composant critique pour la sécurité — tout ce qui touche au noyau, traite des transactions financières ou prend des décisions médicales — exigez une preuve mathématique de correction, et non de simples pourcentages de couverture de tests.
J'ai eu une discussion animée avec un client potentiel sur ce dernier point. Il a dit : « Vous nous demandez de ralentir notre chaîne de déploiement. » J'ai répondu : « La chaîne de déploiement de CrowdStrike était très rapide. Elle a poussé une mise à jour défectueuse vers 8,5 millions de machines en quelques minutes. La vitesse n'était pas le problème. La vitesse sans vérification était le problème. »
Il a signé le contrat.
Le précédent qui change tout
Voici ce qui, selon moi, échappe à la plupart des gens de la tech au sujet de l'affaire Delta c. CrowdStrike.
La décision sur la faute lourde ne concerne pas seulement une compagnie aérienne et un fournisseur de sécurité. Elle établit une nouvelle norme de diligence pour les mises à jour logicielles automatisées. Quand un juge affirme que pousser du code non testé vers des millions de machines sans déploiement échelonné pourrait constituer une faute lourde, cela s'applique à chaque fournisseur qui fait la même chose. Quand un juge affirme que passer outre les préférences de mise à jour d'un client pour pousser du code au niveau du noyau pourrait constituer une intrusion informatique indépendamment du contrat, cela réécrit les règles pour chaque entreprise SaaS dotée de mécanismes de mise à jour automatique.
La « faute lourde » d'aujourd'hui deviendra l'attente de référence de demain. Déploiements échelonnés, vérification formelle, vérification des limites à l'exécution, télémétrie autoréparatrice — ce ne sont plus des avantages concurrentiels. Ce sont la norme minimale que les tribunaux et les régulateurs exigeront.
Et voici ce qui m'enthousiasme, tout en me terrifiant : le secteur de l'IA est sur le point d'affronter ce même moment de vérité. Aujourd'hui, la plupart des systèmes d'IA fonctionnent de manière probabiliste — ils ont « généralement raison », et quand ils ont tort, nous haussons les épaules et appelons cela une hallucination. Mais à mesure que l'IA s'enfonce plus profondément dans l'infrastructure critique — gestion des réseaux électriques, approbation de traitements médicaux, exécution de transactions financières — « généralement raison » aura le même poids juridique que « nous n'avons pas testé la mise à jour avant de la pousser vers 8,5 millions de machines ».
Le coût de 10 milliards de dollars de la panne CrowdStrike n'est pas le prix d'un bogue. C'est l'acompte d'une mise à niveau mondiale de la façon dont nous construisons et vérifions les logiciels.
Les entreprises qui le comprennent — celles qui investissent dès maintenant dans la Deep AI, la vérification formelle et les architectures souveraines — ne se contenteront pas d'éviter la prochaine catastrophe. Elles définiront la norme que tous les autres se démèneront pour atteindre une fois qu'elle sera arrivée.
Je sais de quel côté de cette ligne de partage je veux être. La question est de savoir si vous choisirez avant le prochain 19 juillet, ou après.
