78 minutes d'erreur, cinq jours de panne : ce que CrowdStrike et Delta enseignent sur la reprise

L'erreur a duré 78 minutes et venait d'une autre entreprise. La reprise a duré d'un à cinq jours, et celle-là appartenait à chacun. Le 19 juillet 2024, la même défaillance a frappé plusieurs compagnies aériennes des États-Unis. Le lundi suivant, la plupart fonctionnaient presque normalement. Delta Air Lines a annulé près de 7 000 vols en cinq jours.

Pourquoi la même défaillance a-t-elle coûté un week-end aux unes et cinq jours à une autre ? La question reste ouverte, et Delta et CrowdStrike se la disputent devant les tribunaux. Delta affirme qu'elle dépendait plus que quiconque de la technologie touchée ; CrowdStrike, que ce sont la réponse et l'infrastructure de Delta elle-même qui ont allongé la reprise. Cet article ne tranche pas ce litige. Ce que le cas enseigne en revanche à toute entreprise, quel que soit le vainqueur, c'est que le temps qu'elle met à revenir se décide en bonne partie avant la panne, par ce qu'elle a laissé préparé.

Voici l'histoire documentée, heure par heure, avec ce que dit chaque partie : Delta et CrowdStrike, qui se sont poursuivies mutuellement, et Microsoft, qui a répondu par lettre. À la fin, ce qu'elle enseigne à toute entreprise qui dépend de ses systèmes, c'est-à-dire aujourd'hui presque toutes.

Jeudi, 22 h 09 à Mexico

CrowdStrike vend un logiciel de sécurité appelé Falcon. Son capteur s'installe sur les ordinateurs et les serveurs que l'entreprise cliente veut protéger et surveille ce qui se passe à l'intérieur du système d'exploitation pour détecter les attaques. Pour reconnaître de nouvelles techniques, il reçoit fréquemment de petites mises à jour de contenu : elles ne modifient pas le logiciel, elles lui apprennent seulement quoi chercher.

Le vendredi 19 juillet 2024, à 04 h 09 en temps universel (UTC), CrowdStrike a publié l'une de ces mises à jour pour les postes sous Windows [1]. Sur la côte est des États-Unis, il était 0 h 09 [8]. À Mexico, 22 h 09 le jeudi.

La mise à jour apportait deux nouveaux modèles pour surveiller la manière dont les programmes communiquent entre eux à l'intérieur de Windows. L'un d'eux demandait de vérifier une donnée que personne n'avait vérifiée auparavant. L'analyse des causes profondes que CrowdStrike a publiée le 6 août l'explique ainsi : ce type de modèle, créé en février 2024, définissait 21 champs d'entrée, mais le code qui l'exécutait ne lui en transmettait que 20 [2]. Pendant des mois, rien ne s'est produit, car les tests et les modèles précédents utilisaient un joker dans le champ 21 : « n'importe quelle valeur convient ». Celui du 19 juillet a été le premier à comparer réellement ce champ [2].

Le logiciel a tenté de lire la 21e donnée en dehors de la mémoire réservée aux 20 qu'il recevait, et Windows s'est arrêté [1][2]. L'outil qui devait valider le contenu avant son envoi avait sa propre erreur et l'a laissé passer [1]. La suite, des millions de personnes l'ont vue : l'écran bleu.

À 05 h 27 UTC, 78 minutes plus tard, CrowdStrike a retiré la mise à jour [1]. Les postes qui se sont connectés ensuite ne l'ont plus reçue. Mais ceux qui l'avaient reçue ne pouvaient pas télécharger la version corrigée, car ils plantaient avant d'avoir fini de démarrer.

Vendredi : 8,5 millions d'écrans bleus

Le lendemain, Microsoft a estimé l'ampleur : 8,5 millions d'appareils sous Windows, « moins d'un pour cent de toutes les machines Windows » [3]. C'était peu en pourcentage et énorme en conséquences. Microsoft l'a expliqué ainsi : l'impact économique et social reflétait le fait que CrowdStrike est utilisé par des entreprises qui exploitent de nombreux services critiques [3]. Les compagnies aériennes en faisaient partie.

Le correctif existait depuis l'aube. Le difficile était de l'appliquer. Les instructions de Microsoft demandaient, poste par poste, de démarrer en mode sans échec depuis l'écran de récupération, d'entrer dans le dossier de CrowdStrike, de supprimer les fichiers C-00000291*.sys et de redémarrer [4]. Et un détail a transformé les minutes en heures : sur les postes dont le disque était chiffré avec BitLocker, l'outil de chiffrement de Windows, ce démarrage pouvait exiger la clé de récupération [4][5]. Une clé longue, différente pour chaque poste, que quelqu'un devait avoir conservée dans un endroit accessible alors que tout le reste était à l'arrêt.

Autrement dit, sur de nombreux postes, la réparation exigeait que quelqu'un se trouve devant la machine. Microsoft a publié ensuite un outil sur clé USB pour automatiser une partie du correctif, mais il fallait, là aussi, le brancher poste par poste [4]. Delta allait soutenir dans sa plainte que, dans son cas, les postes « ont dû être corrigés manuellement un à la fois et ne pouvaient pas être réparés à distance » [9]. Son directeur général, Ed Bastian, a déclaré à CNBC que la compagnie avait dû redémarrer à la main 40 000 serveurs [10].

CrowdStrike a fait état d'une reprise rapide dans sa base de clients : plus de 97 % des capteurs Windows étaient de nouveau en ligne le 24 juillet et environ 99 % le 29 juillet, par rapport à la semaine précédente [5][2]. Les chiffres globaux semblaient bons. Mais la moyenne cachait celui qui ne se relevait pas.

Samedi et dimanche : les unes se relèvent, une autre non

Les compagnies aériennes vivent d'un casse-tête qui se reconstitue chaque jour : quel avion va sur quelle ligne, quel pilote et quel équipage montent à bord de chaque vol, et si chaque personne respecte les heures de repos qu'exige la loi. Si le système qui assemble ce casse-tête s'arrête, les avions peuvent être prêts et pourtant ne pas décoller, car personne ne sait avec certitude qui se trouve où.

Plusieurs compagnies touchées ont annulé des vols le vendredi. Ce qui compte, c'est ce qui s'est passé ensuite. Selon le décompte de l'agence AP du lundi 22 juillet, United, la deuxième plus touchée, avait annulé près de 1 500 vols depuis le vendredi, mais ce lundi, en milieu de matinée, elle n'en comptait que 17. American, Spirit, Frontier et Allegiant étaient presque revenues à la normale. Southwest et Alaska, qui n'utilisent pas CrowdStrike, ont eu peu d'annulations [11].

Delta, en revanche, cumulait plus de 5 500 vols annulés depuis le vendredi, et le lundi elle en a annulé au moins 700 de plus. Ce jour-là, Delta et ses compagnies régionales représentaient près des deux tiers de toutes les annulations du monde, « y compris presque toutes celles des États-Unis » [11].

Lundi : le système qui n'arrivait pas à rattraper son retard

Qu'est-ce qui faisait défaut, si les ordinateurs étaient déjà en cours de réparation ? Delta l'a expliqué ces jours-là avec ses propres mots.

Bastian a écrit à ses clients que l'un de ses outils de suivi des équipages avait été touché et ne pouvait pas traiter l'énorme volume de changements provoqué par la panne. Les avions étaient pleins en plein été, à plus de 90 % d'occupation, « limitant nos capacités de réacheminement » [11]. À ses employés, il a dit qu'il fallait « encore quelques jours » pour que « le pire soit clairement derrière nous » [11].

Le directeur des systèmes d'information de Delta, Rahul Samant, a été plus précis. Selon AP, il a déclaré que les deux applications les plus difficiles à relancer avaient été celle qui gère le trafic à l'aéroport d'Atlanta, son principal centre d'opérations, et celle qui affecte les pilotes et le personnel de cabine aux vols. Cette dernière tournait déjà, « mais nous avons du retard à rattraper » ; et, selon AP, Samant a déclaré que de nouveaux problèmes continuaient d'apparaître [11].

C'est là le cœur du cas. Les ordinateurs peuvent se réparer un par un. Mais un système qui coordonne des milliers de personnes ne revient pas à la normale du seul fait d'être rallumé : il doit absorber tous les changements accumulés pendant son arrêt, et chaque vol annulé génère de nouveaux changements. C'est une file d'attente qui s'allonge pendant qu'on essaie de la vider.

Mardi : le régulateur arrive

Le mardi 23 juillet, le ministère des Transports des États-Unis (DOT) a ouvert une enquête sur Delta. Selon AP, le ministère a indiqué l'avoir ouverte après avoir constaté les perturbations généralisées et persistantes des vols de Delta « et des signalements de défaillances préoccupantes du service client » [12]. Le secrétaire aux Transports, Pete Buttigieg, s'était déjà entretenu avec Bastian et a déclaré que son ministère avait reçu « des centaines de plaintes » [11].

Le mercredi 24, à 7 h 45, Bastian a publié une nouvelle lettre aux clients : les annulations et les retards du mardi avaient baissé de 50 % par rapport au lundi ; il prévoyait des annulations minimes le mercredi et un jeudi normal. Il a offert des miles et des bons de voyage « comme nouveau geste d'excuse » [13].

Le 31 juillet, Bastian a déclaré à CNBC qu'au cours des sept jours précédents Delta avait enregistré moins de 100 annulations sur plus de 30 000 vols [10]. L'exploitation était revenue. Le coût commençait à peine à se chiffrer.

L'addition

Dans son rapport à l'autorité boursière du 8 août, Delta a avancé les chiffres : environ 7 000 annulations en cinq jours [6]. Un impact direct sur le chiffre d'affaires de 380 millions de dollars, principalement dû aux remboursements et aux indemnisations en espèces et en miles, et 170 millions de dépenses supplémentaires, principalement des remboursements de frais aux clients et des coûts d'équipage. En contrepartie, pour les vols qui n'ont pas volé, elle a dépensé environ 50 millions de moins en carburant [6]. Au net, environ 500 millions de dollars.

« Une perturbation opérationnelle de cette durée et de cette ampleur est inacceptable, et nos clients et nos employés méritent mieux », a déclaré Bastian dans ce même rapport [6]. Les personnes touchées ont été plus d'un million selon la plainte de Delta [9] ; 1,3 million selon Reuters [7].

Trois versions de la même panne

À partir d'ici, l'histoire devient litige. Il convient de la lire pour ce qu'elle est : trois parties avec des avocats, chacune racontant sa version, mais un seul procès, à deux parties. Delta et CrowdStrike se sont poursuivies mutuellement le même jour, chacune devant un tribunal différent. Microsoft a répondu par lettre, et ne figure pas comme partie dans ces plaintes. Ce qui suit est tiré de leurs propres lettres et plaintes.

La version de Delta. Le 29 juillet, son avocat, David Boies, a adressé à CrowdStrike une lettre dans laquelle il lui faisait des reproches sur l'incident et la menaçait de poursuites [14]. Deux jours plus tard, le 31 juillet, Bastian a déclaré à CNBC : « Vous ne pouvez pas arriver dans une exploitation vitale, 24 h sur 24 et 7 jours sur 7, et nous dire que nous avons un bug » [10]. Il a expliqué pourquoi Delta avait davantage souffert : « Nous sommes, de loin, les plus gros utilisateurs des deux [Microsoft et CrowdStrike] dans le secteur, et c'est donc nous qui avons été frappés le plus durement en matière de capacité de reprise » [10]. Quelques mois plus tard, dans sa plainte, déposée le 25 octobre 2024 devant le tribunal d'État du comté de Fulton, en Géorgie, Delta soutient qu'elle n'avait pas activé les mises à jour automatiques et que la mise à jour lui est parvenue malgré tout, et que « si CrowdStrike avait testé la Mise à jour défectueuse ne serait-ce que sur un seul ordinateur avant de la déployer, l'ordinateur serait tombé en panne » [9]. Elle réclame plus de 500 millions de dollars pour intrusion informatique, rupture de contrat et négligence grave, entre autres chefs [9].

La version de CrowdStrike. Son avocat, Michael Carlinsky, a répondu à cette lettre le 4 août. Selon sa lettre, quelques heures après l'incident, CrowdStrike a proposé son aide à Delta ; son directeur général a proposé du personnel sur site à celui de Delta et « n'a pas reçu de réponse » ; lors du suivi, on lui a dit que « les ressources sur site n'étaient pas nécessaires » [14]. Il a demandé que Delta explique « pourquoi les concurrents de Delta, face à des difficultés similaires, ont tous rétabli leurs opérations beaucoup plus vite », et a averti que sa responsabilité est « plafonnée par contrat à un montant à un seul chiffre, en millions » [14]. Dans sa propre plainte, déposée le même 25 octobre devant le tribunal fédéral, CrowdStrike soutient que d'autres grandes compagnies aériennes ont retrouvé un fonctionnement presque normal le 20 juillet, et que c'est « la propre réponse et l'infrastructure informatique de Delta » qui ont allongé sa reprise [8].

La version de Microsoft. Delta avait annoncé qu'elle se retournerait aussi contre Microsoft [6], et Microsoft ne s'est pas tue. Son avocat, Mark Cheffo, a écrit le 6 août, selon CNBC et NBC News. La lettre affirme que Microsoft a proposé une aide gratuite chaque jour du 19 au 23 juillet et que Delta l'a déclinée ; qu'un employé de Delta a répondu le 22 juillet « Tout va bien… » ; que le directeur général de Microsoft, Satya Nadella, a écrit à Bastian le 24 juillet sans obtenir de réponse ; et que le système de suivi des équipages ne tournait ni sous Windows ni sur Azure, mais était pris en charge par « d'autres fournisseurs de technologie, comme IBM ». Elle conclut : « Delta, contrairement à ses concurrents, n'a apparemment pas modernisé son infrastructure informatique » [15].

La réplique de Delta. La compagnie a répondu que, depuis 2016, elle a investi « des milliards de dollars » dans ses systèmes [15]. Boies a écrit de nouveau le 8 août : « Il n'y a aucun fondement — aucun — pour suggérer que Delta était d'une quelconque manière responsable du logiciel défectueux » [16]. Selon le média spécialisé Skift, Delta soutient en outre que l'offre d'aide sur site est arrivée alors qu'elle avait déjà restauré la plupart de ses systèmes critiques [16].

Où en est l'affaire

Plus de deux ans après la panne, le litige entre Delta et CrowdStrike reste ouvert.

En mai 2025, la juge Kelly Lee Ellerbe, du tribunal du comté de Fulton, a rejeté les demandes de Delta pour déclaration mensongère intentionnelle et fraude par omission, mais a laissé se poursuivre celles pour négligence, y compris la théorie de la négligence grave, et celle pour intrusion informatique [17]. L'avocat de CrowdStrike a alors déclaré que le pire scénario pour son client serait un paiement « à un seul chiffre, en millions » [17]. Dans son rapport trimestriel à l'autorité boursière d'août 2026, CrowdStrike a indiqué que, dans la plainte de Delta devant le comté de Fulton, la phase de discovery se poursuivait, celle où les parties se demandent et s'échangent les preuves avant le procès [18]. Autrement dit, il n'y avait encore ni procès ni jugement.

Le régulateur, lui, a clos sa partie. Selon Reuters, qui a repris un article de Politico, le DOT a clos l'enquête sans amende. La décision a été prise en novembre de l'année précédente et rendue publique en juin 2026. Un porte-parole a déclaré que l'examen avait établi que les passagers de Delta avaient reçu « des remboursements rapides, une assistance adéquate pour les bagages » et une aide appropriée pour les passagers en situation de handicap [7].

Qui doit payer combien, un tribunal le décidera. Cet article ne prend pas parti sur ce point. Ce que nous pouvons faire, en revanche, c'est regarder ce qui n'est pas contesté et nous demander ce que cela enseigne.

Ce que ce cas enseigne

1. L'erreur venait d'un autre ; la reprise était la sienne

Aucune des trois versions ne conteste l'essentiel : la défaillance a été introduite par un fournisseur, et elle a atteint de nombreuses entreprises en même temps. Ce qui a varié, c'est le temps que chacune a mis à revenir. CrowdStrike peut répondre de son erreur devant un tribunal. Mais les jours qu'a duré l'interruption, ce sont les passagers et la compagnie elle-même qui les ont payés, et ce temps, personne ne le rend. Delta réclame 500 millions ; CrowdStrike affirme que son contrat limite ce qu'elle paierait à moins de dix. Quel que soit le résultat, le contrat avec le fournisseur ne remplace pas la capacité de se relever.

La question pour un comité n'est pas « et si notre fournisseur tombait en panne ? ». C'est : quand il tombera en panne, combien de temps nous faudra-t-il, à nous ?

2. On ne répare pas ce qu'on n'a pas inventorié

Pour réparer à la main, un par un, les 40 000 serveurs que, selon Bastian, Delta a dû redémarrer [9][10], il faut d'abord savoir lesquels, où ils se trouvent, qui peut accéder à chacun et dans quel ordre il convient de les relancer. Et, pour ceux dont le disque est chiffré, où se trouve la clé de chacun [4][5]. Si ces clés vivent dans un système qui est lui aussi tombé, la reprise s'arrête avant d'avoir commencé.

Un inventaire utile en situation d'urgence n'est pas une feuille avec des noms de serveurs. Il dit ce que fait chaque poste, de quoi il dépend, qui s'en occupe, comment y accéder quand le réseau ou l'annuaire des utilisateurs ne répond pas, et ce qui se relance en premier. Il s'écrit à froid et se conserve là où il peut être consulté alors que tout le reste est éteint.

3. Ce qui se rétablit en dernier, ce ne sont pas les ordinateurs

Le cas le montre clairement : les ordinateurs de Delta ont été réparés au fur et à mesure, et pourtant elle a continué d'annuler des vols. Selon Delta elle-même, le système qui affecte les équipages devait absorber une montagne de changements accumulés [11]. Dans sa version, le goulet d'étranglement a été un système métier, non une machine.

C'est pourquoi un plan de reprise ne s'arrête pas à « le serveur démarre ». Il doit dire quels systèmes métier reviennent en premier, combien de temps il leur faut pour rattraper ce qui s'est accumulé, ce que l'on fait à la main entre-temps et qui décide quelles opérations sont suspendues pour que la file cesse de s'allonger.

4. Une procédure jamais répétée est une hypothèse

Dans la lettre du 4 août, CrowdStrike a demandé à Delta de conserver, entre autres, ses plans de sauvegarde, de reprise et de continuité, « et tout test connexe de ces plans » [14]. Nous ne savons pas ce que Delta avait écrit ni ce qu'elle avait répété ; c'est précisément ce que le procès peut révéler. Mais la question de l'avocat est la bonne pour toute entreprise : avoir le plan ne suffit pas ; ce qui compte, c'est quand il a été testé pour la dernière fois et combien de temps cela a pris.

Un exercice révèle ce que le papier ne dit pas : la clé de récupération que personne ne trouve, l'accès qui dépend du système même qui est tombé, l'étape qu'une seule personne sait accomplir.

5. Une équipe qui connaît déjà la procédure

Réparer des milliers de postes à la main exige beaucoup de mains qui savent exactement quoi faire, avec des instructions claires et sans improviser. En situation d'urgence, chaque personne qui doit apprendre la procédure le jour même est du temps perdu. Les équipes qui se rétablissent vite ne sont pas nécessairement les plus grandes, mais celles qui savent déjà qui fait quoi.

6. Décidez à l'avance qui entre pour aider

CrowdStrike et Microsoft affirment avoir proposé leur aide et que Delta l'a déclinée ; Delta affirme que l'aide est arrivée trop tard [14][15][16]. Au-delà de savoir qui a raison, l'épisode laisse une leçon pratique : en pleine crise, accepter une aide extérieure implique de donner des accès, d'expliquer l'environnement et de coordonner des personnes nouvelles, et cela coûte du temps. Cette décision gagne à être prise avant : qui peut entrer, avec quels accès, qui coordonne et quand elle se déclenche.

Cinq questions pour votre prochain comité

1. Si demain un fournisseur rend inutilisable la moitié de nos ordinateurs, combien de temps nous faut-il pour revenir ? Le savons-nous parce que nous l'avons mesuré, ou parce que nous le supposons ?
2. Avons-nous un inventaire qui serve quand tout est éteint ? Quels postes, de quoi ils dépendent, comment y accéder et dans quel ordre les relancer.
3. Où sont les clés de récupération des disques chiffrés, et peut-on les consulter si l'annuaire des utilisateurs est tombé ?
4. Quel système métier serait notre « système des équipages » ? Celui qui, même une fois les machines revenues, met des jours à rattraper son retard.
5. Quand avons-nous répété la reprise pour la dernière fois, qui y a participé et qu'est-ce qui a échoué ?

Si deux réponses ou plus sont « je ne sais pas », le risque n'est pas chez le fournisseur : il est dans ce qui reste à préparer.

Par où commencer cette semaine

Nul besoin d'un grand projet. Choisissez un système critique, celui dont l'arrêt d'une journée vous ferait le plus mal, et demandez à votre équipe trois choses par écrit : la liste des postes dont il dépend, les étapes pour le relancer à partir de zéro si plus rien ne fonctionne, et le nom de la personne qui les exécute. Demandez-lui ensuite de les suivre dans un environnement de test, chronomètre en main. Le temps que cela prend, et ce qui manque sur le papier, constituent votre point de départ.

Ce que fait Hábil : comment nous pouvons vous aider

Hábil n'a participé ni à l'incident de CrowdStrike ni à la reprise de Delta. Ce qui suit est ce que nous faisons, en général, pour deux moments : le jour de la panne et les mois qui la précèdent.

Quand quelque chose de critique tombe, notre Équipe SWAT intervient avec méthode : d'abord elle contient les dégâts et stabilise ce qui est tombé, ensuite elle établit ce qui s'est passé et depuis quand, corrige la cause de fond et rétablit l'exploitation par étapes, pour ne pas créer un autre problème. À la fin, elle vous remet une mémoire technique avec les preuves : ce qui a été trouvé, ce qui a été fait, comment cela a été vérifié et ce qui reste de votre côté. Nous travaillons avec votre équipe, non à sa place, dans le cloud ou dans votre centre de données.

Et avant l'urgence, avec le Provisionnement d'infrastructure, nous vous aidons à mettre en place une base solide et documentée, pour que, le jour où quelque chose tombe en panne, votre équipe sache quoi relancer en premier et comment.

La première conversation est sans frais : elle a pour objectif de situer le système dont la perte vous ferait le plus mal, ce dont vous disposez aujourd'hui pour le relancer et ce qui vous manque. Écrivez-nous sur WhatsApp.

Questions fréquentes

S'agissait-il d'une cyberattaque ?

Non. Delta, CrowdStrike et Microsoft la traitent comme une mise à jour défectueuse. L'analyse de CrowdStrike décrit une erreur de programmation et de validation dans son propre contenu, non une intrusion [1][2].

Pourquoi ne l'a-t-on pas réparée à distance, si l'erreur a été corrigée en 78 minutes ?

Parce que les postes touchés plantaient avant d'avoir fini de démarrer et n'arrivaient pas à télécharger le correctif. Sur beaucoup d'entre eux, la réparation exigeait d'être devant la machine : démarrer en mode sans échec, supprimer un fichier et, sur les disques chiffrés, saisir une clé de récupération [4][5]. Delta soutient que, dans son cas, il n'y avait aucun moyen de le faire à distance [9].

Pourquoi Delta a-t-elle mis plus de temps que d'autres compagnies ?

C'est précisément ce qui est contesté. Delta affirme qu'elle dépendait plus que quiconque de la technologie touchée et que son système d'équipages n'a pas pu absorber le volume de changements [10][11]. CrowdStrike et Microsoft attribuent la lenteur à l'infrastructure et à la réponse de Delta [8][15]. Un tribunal tranchera.

Mon entreprise est-elle à risque si elle n'utilise pas CrowdStrike ?

Toute entreprise qui reçoit des mises à jour automatiques d'un fournisseur, qu'il s'agisse de sécurité, du système d'exploitation ou d'une application, dépend du bon déroulement de cette mise à jour. La question utile n'est pas de savoir quel fournisseur vous utilisez, mais combien de temps vous mettriez à vous rétablir si une mise à jour échouait.

Le contrat avec le fournisseur ne me protège-t-il pas ?

Il peut vous donner un droit de réclamer, mais il ne vous rend pas l'exploitation. Dans ce cas, CrowdStrike soutient que sa responsabilité est limitée par contrat à un montant à un seul chiffre en millions de dollars, face aux plus de 500 millions que réclame Delta [9][14].

Que convient-il de préparer en premier ?

Un inventaire d'un système critique consultable quand tout est éteint, une procédure de reprise écrite et répétée chronomètre en main, et les noms des personnes qui l'exécutent.

Les citations sont traduites de l'anglais (traduction propre). Les versions de Delta, de CrowdStrike et de Microsoft sont ce que chaque partie affirme dans ses lettres et ses plaintes, non des faits prouvés. État de la procédure selon le dernier rapport trimestriel de CrowdStrike (août 2026), consulté le 21 octobre 2026.