Le 19 juillet 2024, une panne informatique venue d’un composant obscur de sécurité a mis une bonne partie de la planète en pause. Vols retardés, hôpitaux ralentis, guichets bloqués, écrans bleus en série sur des milliers de postes Windows : en quelques heures, un simple fichier défectueux s’est transformé en incident mondial. Derrière ce bug lié au logiciel Falcon Sensor de CrowdStrike, on retrouve un mélange de mise à jour précipitée, dépendance massive à un même outil et procédures de secours parfois trop théoriques. L’épisode a remué autant les équipes techniques que les comités de direction, en montrant à quel point nos systèmes informatiques restent fragiles dès qu’un maillon critique se dérègle.
Ce qui frappe dans cette histoire, ce n’est pas seulement l’ampleur du dysfonctionnement, mais la façon dont il s’est propagé. Une mise à jour poussée vers des millions de machines Windows, un fichier corrompu, puis une boucle de redémarrage infernale qui rend les postes inutilisables sans intervention manuelle. Pendant que les équipes de CrowdStrike préparent un correctif, des aéroports repassent au papier-crayon, des entreprises déclenchent leurs plans de continuité et des admins système jonglent entre mode sans échec, scripts de réparation et hotline en surchauffe. À travers ce récit, l’objectif est de proposer une analyse claire de ce qui s’est vraiment passé ce jour-là, de ses causes techniques jusqu’aux conséquences économiques, tout en tirant des leçons très concrètes pour la sécurité informatique et la résilience des organisations.
- Date clé : le vendredi 19 juillet 2024, une mise à jour défectueuse de Falcon Sensor déclenche un incident mondial sur les postes Windows.
- Origine du problème : un fichier corrompu provoque une boucle de redémarrage, rendant de nombreux ordinateurs inutilisables sans intervention technique.
- Secteurs touchés : aéroports, compagnies aériennes, hôpitaux, services publics, grandes entreprises et prestataires IT.
- Impact financier : baisse d’environ 10 % de l’action CrowdStrike et perte estimée à 8,3 milliards de dollars de capitalisation en une journée.
- Portée technique : systèmes Windows affectés, tandis que macOS et Linux restent épargnés.
- Résolution : correctif diffusé vers 7h30, mais nécessité de réparer manuellement les postes déjà impactés.
- Enseignement principal : dépendance excessive à un seul outil de sécurité et manque de procédures de résolution automatisées pour les mises à jour critiques.
Panne informatique du 19 juillet 2024 : retour précis sur le déroulé de la journée
Pour comprendre ce qu’il s’est vraiment passé le 19 juillet 2024, il faut suivre la journée presque minute par minute. L’incident n’a pas débarqué comme un éclair bleu sur tous les écrans du monde en même temps, il s’est plutôt diffusé par vagues, au rythme des redémarrages Windows et des horaires de bureaux.
Tout commence vers 6h00, heure de Paris. CrowdStrike déploie une mise à jour de son agent Falcon Sensor, composant central de sa suite de sécurité informatique pour les terminaux. Sur le papier, rien d’exotique : une nouvelle version censée renforcer la détection des comportements suspects, comme les ransomwares ou les accès non autorisés. En réalité, un des fichiers livrés avec cette mise à jour est défectueux, et c’est lui qui va mettre le feu aux poudres.
À partir de ce moment, chaque machine Windows qui télécharge ce fichier et redémarre se retrouve piégée dans un scénario bien connu des admins : boucle de reboot. Le système démarre, charge les composants critiques, rencontre le fichier corrompu, tombe en erreur, redémarre… et ainsi de suite. Pour les utilisateurs, cela ressemble à une machine « possédée » qui refuse obstinément d’afficher le bureau.
Entre 6h et 7h, les premiers signaux faibles apparaissent dans les centres de support. Des tickets remontent depuis l’Asie et l’Europe, des captures d’écran d’erreurs Windows commencent à circuler sur les canaux internes. À ce stade, beaucoup d’équipes pensent encore à un bug local ou à un problème de patch Microsoft. Pourtant, les points communs se dessinent déjà : Windows, Falcon Sensor actif, même comportement de redémarrage infini.
À 7h27 environ, CrowdStrike identifie le coupable : un composant livré dans la dernière mise à jour. L’éditeur retire rapidement le fichier problématique, publie un correctif et remet en ligne une version précédente stable. À partir de 7h30, toutes les machines qui démarrent ou mettent à jour Falcon reçoivent le bon fichier et ne sont plus touchées par la panne informatique. Le feu est contenu, du moins pour les systèmes qui n’ont pas encore basculé dans la boucle d’erreur.
Le vrai souci, ce sont les postes déjà contaminés avant le correctif. Ceux-là ne peuvent plus booter correctement, donc impossible de télécharger quoi que ce soit. Ils se retrouvent coincés du mauvais côté de la barrière. Les équipes IT doivent alors intervenir en local, lancer Windows en mode sans échec, aller chercher le dossier C:ProgramDataCrowdStrike, supprimer les fichiers incriminés, redémarrer… fois plusieurs centaines ou milliers de machines dans certains groupes.
Pendant ce temps, l’effet domino se voit dans le monde réel. Dans les aéroports, des systèmes d’enregistrement chutent les uns après les autres, obligeant les compagnies à repasser au papier. Certains hôpitaux voient leurs postes administratifs ou de gestion bloqués, ce qui complique l’accueil et les flux de patients. Des guichets bancaires, des écrans d’information, des télévisions connectées en entreprise affichent soudainement des erreurs ou restent figés.
Un rythme se met en place dans la journée : diagnostic, tri des postes, priorisation des machines vitales, correction manuelle, réouverture progressive des services. Certaines entreprises relèvent la tête en fin de matinée, d’autres traînent des problèmes résiduels tout le week-end. Beaucoup découvrent à cette occasion que leurs plans théoriques de gestion de crise ne sont pas si simples à appliquer quand des milliers de PC partent en vrille simultanément.
Ce déroulé presque scénarisé montre à quel point un incident sur un composant de système informatique largement déployé peut enclencher une réaction en chaîne. Le 19 juillet n’a pas seulement été un bug de plus, mais une sorte de stress test grandeur nature pour les organisations connectées.
Une panne informatique mondiale sans cyberattaque derrière
Un point a vite posé question ce jour-là : s’agissait-il d’une attaque coordonnée ou d’un bug interne à un fournisseur ? Dans un contexte où les ransomwares et les offensives étatiques font régulièrement les gros titres, voir des millions de postes Windows devenir inutilisables d’un coup avait de quoi inquiéter.
Le PDG de CrowdStrike, George Kurtz, est intervenu très tôt dans les médias pour clarifier un élément essentiel : « il ne s’agit pas d’un incident de sécurité ni d’une cyberattaque ». Autrement dit, aucun acteur malveillant n’a pris le contrôle d’infrastructures, et aucune fuite de données n’a été détectée en lien direct avec cet incident. La source est purement logicielle, liée à une mauvaise mise à jour d’un composant pourtant chargé de protéger les machines.
Cette précision change beaucoup de choses dans l’analyse. On ne parle pas ici de faille exploitée par un attaquant, mais de risque lié au cycle de vie des mises à jour lui-même. Pour un responsable de sécurité informatique, ça renvoie à une question un peu inconfortable : comment vérifier qu’un agent de protection ne devient pas, par erreur, une source de panne massive ?
En pratique, la réponse classique s’appuie sur des environnements de préproduction, des canaux de diffusion graduels, des tests ciblés sur des parcs limités. Pourtant, l’épisode de juillet 2024 montre que même avec ces garde-fous, le risque zéro n’existe pas, surtout quand un outil se retrouve déployé à très grande échelle. La confiance aveugle dans les mises à jour « de sécurité » ne suffit plus, il faut une approche plus nuancée et mieux pilotée.
Ce jour-là, une partie du monde a donc découvert qu’un bug dans un antivirus moderne peut provoquer des dégâts concrets, comparables à ceux d’une attaque, sans qu’aucun pirate ne soit intervenu. Une réalité un peu dérangeante, mais qui force à repenser la façon dont on gère les outils présentés comme protecteurs.
Causes techniques de la panne CrowdStrike de juillet 2024 et rôle du système Windows
Sur le plan technique, la panne du 19 juillet 2024 repose sur un enchaînement assez simple, mais redoutable. Au cœur du problème, on retrouve un composant de Falcon Sensor, installé sur les postes Windows, qui doit analyser en continu les comportements suspects. Un fichier livrée dans la mise à jour publiée vers 6h00 contenait une erreur qui provoquait un plantage très tôt dans le processus de démarrage du système.
Quand Windows lancait les services, Falcon tentait de charger ce composant défectueux. L’erreur survenait avant même que l’environnement de bureau ne soit utilisable. Le système réagissait en redémarrant automatiquement, pensant corriger une anomalie temporaire. Le même scénario se répétait ensuite en boucle, créant ce fameux redémarrage infini.
Un point clé tient au périmètre des systèmes concernés. Les parcs macOS et Linux équipés de solutions CrowdStrike n’ont pas été impactés, ce qui indique bien un problème spécifique à l’agent Windows. Autrement dit, c’est le couple Falcon Sensor + Windows qui a déclenché le dysfonctionnement, pas le back-end de CrowdStrike ni l’infrastructure réseau globale.
| Aspect | Détail |
|---|---|
| Origine de la panne | Bug dans un fichier de mise à jour de Falcon Sensor |
| Systèmes affectés | Postes sous Microsoft Windows équipés de Falcon |
| Systèmes non affectés | macOS, distributions Linux et machines sans Falcon |
| Symptôme visible | Boucle de redémarrage, écran ne dépassant pas le chargement initial |
| Correctif | Retrait du fichier fautif et retour à une version stable de l’agent |
Les machines qui étaient éteintes au moment de la diffusion du correctif ont eu de la chance. Lorsqu’elles ont été allumées après 7h30, elles ont récupéré la bonne version du fichier et n’ont jamais vu la panne informatique. C’est une des raisons pour lesquelles certaines entreprises n’ont quasiment pas ressenti l’incident, simplement parce que leur journée de travail commençait plus tard, ou parce qu’une partie de leur parc était encore hors tension.
Là où la situation s’est compliquée, c’est pour les postes déjà touchés avant cette heure limite. Ceux-là devaient être réparés à la main, ou au moins via des outils d’administration à distance, en passant par des modes de démarrage avancés. La procédure standard recommandée reposait sur le mode sans échec Windows, accessible notamment par la touche F8 au boot, puis l’accès au dossier C:ProgramDataCrowdStrike pour supprimer les fichiers incriminés.
Une méthode alternative a circulé pour les organisations en difficulté avec le mode sans échec : enchaîner une quinzaine de redémarrages successifs pour forcer Windows à activer des outils de récupération, puis restaurer les paramètres système par défaut. Cette approche « bourrine » a dépanné certains environnements très verrouillés, mais elle reste loin d’être agréable à gérer à grande échelle.
Ce qui se cache derrière tout ça, c’est plus largement la tension entre deux exigences : réactivité sur les mises à jour de sécurité informatique et maîtrise des risques de régression. Dans un monde où les attaques progressent vite, retarder les patchs expose les systèmes. À l’inverse, pousser des mises à jour automatiques à des millions de machines sans filet suffisant, c’est accepter un risque industriel, comme celui qui a explosé ce vendredi de juillet 2024.
Une bonne partie des équipes IT en ont tiré une conclusion nette : il ne suffit plus de valider fonctionnellement une mise à jour, il faut aussi prévoir comment la désactiver ou la neutraliser rapidement sur le terrain. Sans cette capacité de retour arrière, la moindre erreur devient un casse-tête planétaire.
Conséquences concrètes de la panne informatique sur les entreprises et les services publics
Sur le papier, un redémarrage infini sur un poste Windows, c’est un bug pénible. Dans la vraie vie, quand des milliers de machines se mettent à boucler en même temps dans des aéroports, des banques ou des hôpitaux, on bascule dans une crise opérationnelle. L’impact du 19 juillet 2024 a surtout été visible à travers les lenteurs, les files d’attente et les procédures improvisées pour garder un minimum de service.
Dans le transport aérien, plusieurs compagnies ont signalé des retards importants. Air France-KLM, par exemple, a évoqué des problèmes sur certains systèmes d’enregistrement et d’embarquement. Le groupe a dû repasser temporairement par des procédures manuelles pour traiter les passagers, imprimer des listes, vérifier les identités à la main. Les aéroports gérés par ADP ont également connu des perturbations, notamment sur les écrans d’information voyageurs et certains postes de contrôle.
Le rail n’a pas été épargné, même si la SNCF a indiqué un impact plutôt limité. Quelques systèmes de billetterie ont décroché, créant des retards ponctuels au guichet, mais sans blocage massif des circulations. On retrouve là un effet positif d’architectures plus diversifiées et d’outils parfois moins homogènes que dans l’aérien.
En parallèle, des hôpitaux et cliniques ont vu des postes administratifs tomber en panne, ce qui complique la gestion des admissions, des dossiers patients non médicaux et de la facturation. La plupart des systèmes cliniques de coeur de métier étant souvent isolés ou basés sur d’autres solutions, on n’a pas assisté à un effondrement généralisé des soins, mais plutôt à un ralentissement visible et à un stress supplémentaire pour les équipes déjà sous pression.
Sur le plan financier, CrowdStrike a encaissé le choc en bourse. L’action a reculé d’environ 10 % en une seule séance, ce qui représente une perte d’environ 8,3 milliards de dollars de capitalisation. Au-delà de ce chiffre symbolique, de nombreux clients et partenaires ont réévalué leur relation avec l’éditeur, pas forcément pour le quitter, mais pour diversifier leurs dépendances critiques.
Il ne faut pas oublier les services plus discrets, mais très sensibles. Certains prestataires IT ont vu leur activité de dépannage informatique à distance exploser, avec des demandes en urgence pour débloquer des parcs entiers. D’autres ont été eux-mêmes touchés, incapables de se connecter à leurs outils habituels, ce qui a rallongé encore les délais de résolution.
Enfin, un secteur un peu particulier a été mis sous tension : l’écosystème des Jeux olympiques de Paris. Les services chargés des accréditations, de la logistique des uniformes ou de la sécurité ont dû composer avec des systèmes ralentis ou partiellement indisponibles. Ce contexte a servi de répétition générale, presque forcée, pour vérifier la robustesse des procédures de continuité à quelques jours de l’ouverture officielle.
En résumé, la même cause technique a engendré des effets très variés selon la maturité des organisations. Les structures qui disposaient de plans de continuité réalistes, testés et adaptés à leur parc se sont relevées beaucoup plus vite. Celles qui s’appuyaient sur un seul outil de sécurité et des procédures théoriques ont découvert dans la douleur ce que signifie une panne mondiale un vendredi matin.
Pour tous, cet épisode a rappelé une chose simple : un système informatique ne se juge pas seulement à sa performance en temps normal, mais à la façon dont il encaisse un choc inattendu.
Effets sur les utilisateurs finaux et sur la confiance numérique
Côté utilisateurs, la journée du 19 juillet a souvent pris la forme d’attentes interminables et de messages flous. Dans les terminaux, beaucoup ont simplement vu des files qui n’avançaient plus, sans toujours comprendre que derrière, des admins tentaient de sortir Windows de la boucle de reboot sur des centaines de postes.
En entreprise, des équipes entières se sont retrouvées sans PC opérationnel. Certains se sont rabattus sur leurs smartphones, d’autres ont improvisé des réunions papier, ou ont décidé de renvoyer les salariés chez eux le temps de rétablir les systèmes. La productivité a clairement été touchée, même si la plupart des structures ont rattrapé une partie du retard les jours suivants.
Un effet plus subtil s’est installé ensuite : la remise en cause de la confiance dans les mises à jour automatiques et dans les solutions de sécurité. Certains utilisateurs se sont demandé pourquoi un antivirus, censé protéger la machine, pouvait la rendre inutilisable du jour au lendemain. Pour les départements IT, il a fallu prendre le temps d’expliquer, de contextualiser, parfois de défendre des choix techniques auprès de directions un peu échaudées.
Cet aspect immatériel, la confiance, reste pourtant central. Sans mise à jour régulière, les systèmes deviennent vite des cibles faciles pour les attaques. Mais sans garde-fou sur ces mêmes mises à jour, on se retrouve exposé à des incidents globaux comme celui de juillet 2024. L’équilibre entre ces deux risques s’est retrouvé au cœur de nombreuses discussions internes après la crise.
Au final, la panne a agi comme un révélateur. Elle a montré que l’expérience utilisateur ne dépend pas seulement d’une jolie interface ou d’un bon débit fibre, mais de tout un empilement de briques techniques dont l’une peut parfois lâcher au plus mauvais moment.
Comment la panne a été résolue et quelles procédures ont été mises en place
Une fois le fichier fautif identifié et le correctif publié, la priorité s’est déplacée vers un objectif très opérationnel : sortir les machines coincées de la boucle de redémarrage. La résolution a pris la forme d’une série de procédures, plus ou moins industrialisées selon la taille des parcs à traiter.
La méthode la plus directe passait par le mode sans échec de Windows. L’idée : démarrer le système avec un minimum de services, sans lancer Falcon Sensor en pleine capacité, puis accéder au système de fichiers pour corriger le problème. Dans la pratique, les admins devaient, pour chaque machine concernée, forcer l’accès aux options avancées de démarrage, choisir le mode sans échec, puis se rendre dans le dossier C:ProgramDataCrowdStrike.
Une fois sur place, la recommandation consistait à supprimer les fichiers identifiés comme problématiques. La suppression achevée, un redémarrage classique permettait généralement de retrouver un système fonctionnel, qui pouvait ensuite recevoir une version corrigée de Falcon. Cette procédure, simple en apparence, devient une vraie course d’endurance lorsqu’on la répète sur des centaines de terminaux répartis sur plusieurs sites.
Pour les environnements où le mode sans échec restait difficile à atteindre, une autre approche a circulé : enchaîner environ 15 redémarrages d’affilée pour déclencher automatiquement les mécanismes de récupération de Windows. Une fois ces outils activés, certains admins ont pu restaurer des points de restauration système ou désactiver temporairement le service incriminé, avant de remettre l’agent à jour.
En parallèle, les postes qui n’avaient pas encore redémarré depuis la mise à jour initiale recevaient, eux, la version corrigée. Pour ces machines-là, aucun blocage n’apparaissait. De nombreuses entreprises ont d’ailleurs pris la décision de laisser certains PC éteints le temps de valider la situation, pour éviter de les contaminer à leur tour par un redémarrage malheureux.
L’ANSSI, côté français, a diffusé plusieurs recommandations claires. L’agence a notamment conseillé d’isoler du réseau les postes en cours de traitement, pour éviter des interactions imprévues, de sauvegarder les données sensibles avant toute manipulation risquée, et de documenter précisément chaque intervention. Ce dernier point peut sembler bureaucratique, mais il devient crucial lorsqu’il s’agit de comprendre a posteriori ce qui a été changé, sur quelles machines, et avec quel résultat.
On peut résumer les réponses possibles selon l’état des systèmes de la façon suivante :
| État du système | Procédure recommandée |
|---|---|
| Machine bloquée en boucle de redémarrage | Intervention manuelle en mode sans échec, suppression des fichiers Falcon défectueux, redémarrage et mise à jour |
| Machine éteinte pendant l’incident | Attendre le correctif, puis allumer pour recevoir la version stable et vérifier le comportement |
| Machine fonctionnelle avec Falcon actif | Vérifier la version de l’agent, appliquer les mises à jour préventives et contrôler les journaux |
Cette gestion différenciée montre bien que toutes les machines ne se trouvaient pas dans la même situation. Les admins ont dû faire du tri, hiérarchiser les postes critiques, parfois sacrifier temporairement des fonctions secondaires pour concentrer leurs efforts sur les systèmes vitaux.
Pour les organisations qui avaient déjà travaillé leurs plans de continuité, l’incident a servi de crash test. Certaines disposaient de procédures de bascule vers des outils alternatifs, de postes de secours ou de modes dégradés documentés. D’autres se sont aperçues qu’un plan stocké dans un classeur SharePoint ne suffit pas quand il faut expliquer à des dizaines d’équipes comment faire un démarrage en mode sans échec en urgence.
À ce stade, difficile de ne pas faire le lien avec les réflexions plus globales sur la continuité d’activité informatique. Un document de stratégie ne vaut que s’il est testé régulièrement et adapté aux outils réellement utilisés sur le terrain. La panne de juillet 2024 a rappelé que les procédures doivent être concrètes, réalistes et connues des équipes opérationnelles, pas uniquement des responsables.
En filigrane, l’épisode a également renforcé l’intérêt pour les formations orientées exploitation, maintenance et support. Les profils capables de diagnostiquer rapidement une boucle de démarrage, de manier le mode sans échec, de comprendre la logique d’un agent de sécurité ne sortent pas de nulle part. Des cursus centrés sur la maintenance système, comme ceux analysés dans certains retours d’expérience sur la formation en maintenance informatique, prennent ici tout leur sens.
Au final, la résolution de la panne informatique du 19 juillet n’a pas été magique. Elle a reposé sur des gestes techniques assez basiques, mais multipliés à une échelle inhabituelle. Ce genre de crise rappelle que les fondations du métier d’admin système restent indispensables, même dans un monde saturé d’outils « managés » et d’automatisation.
Leçons à tirer pour la sécurité informatique et la résilience des systèmes après l’incident de juillet 2024
Une fois les écrans redevenus verts et les boucles de redémarrage maîtrisées, reste la question qui fâche un peu : qu’est-ce qu’on fait de tout ça pour éviter la prochaine catastrophe du même genre ? L’incident de juillet 2024 a mis en lumière plusieurs faiblesses structurelles qui dépassent largement le cas CrowdStrike.
Première alerte, la dépendance excessive à un seul fournisseur pour une brique critique comme l’agent de sécurité. Beaucoup d’organisations se sont retrouvées à la merci du même bug, parce qu’elles avaient standardisé à l’extrême leur socle de protection. Cette standardisation apporte des gains de gestion, mais elle concentre aussi les risques. Diversifier les solutions, au moins sur des périmètres séparés, devient une approche plus prudente, même si elle complique un peu l’administration au quotidien.
Deuxième enseignement, le besoin d’une vraie gouvernance des mises à jour. Il ne s’agit pas de couper les updates automatiques, ce qui serait suicidaire face aux menaces actuelles, mais d’imposer des canaux de diffusion par vagues, des cohortes de tests et des mécanismes clairs de rollback. Envoyer une mise à jour de sécurité partout en même temps revient à déployer un changement majeur en production sans filet. L’épisode du 19 juillet montre que ce pari peut très mal tourner.
Troisième axe, l’importance d’une culture de la résilience. Un système informatique résilient ne se contente pas d’éviter les pannes, il se prépare à fonctionner en mode dégradé quand tout ne va pas bien. Savoir comment continuer à enregistrer des passagers à la main, comment imprimer des listes d’embarquement hors ligne, comment basculer une partie de la production sur des outils alternatifs, tout cela ne s’improvise pas le jour J.
Pour renforcer cette culture, certaines entreprises ont commencé à organiser des exercices de type « game day » autour de scénarios réalistes. Une mise à jour de sécurité qui tourne mal, une coupure longue d’un fournisseur cloud, une base de données corrompue : autant de cas concrets qui obligent les équipes à tester leurs réflexes, à ajuster leurs procédures, à repérer les angles morts. Ce genre de préparation, inspirée du monde de la sécurité et du SRE, devrait devenir aussi courant que les exercices d’évacuation incendie.
Enfin, l’épisode met sur la table la question de la transparence et du partage d’information. Pendant et après la crise, de nombreux échanges entre éditeurs, CERT, agences nationales et communautés techniques ont permis de comprendre vite le cœur du problème et de diffuser des méthodes de correction. Cette circulation rapide de l’information a limité la casse et accéléré la résolution. Freiner ces échanges par excès de communication contrôlée ou par peur de l’image nuirait à tout l’écosystème.
Pour les développeurs, les admins et les responsables techniques, la panne de juillet 2024 restera probablement comme un cas d’école. Elle coche beaucoup de cases : bug dans une mise à jour de sécurité, propagation mondiale, conséquences visibles dans la vie quotidienne, justification de revoir la façon dont on conçoit la résilience. De quoi alimenter longtemps les discussions dans les salles serveurs et les rétrospectives de projet.
Quelles sont les causes principales de la panne informatique du 19 juillet 2024 ?
La panne du 19 juillet 2024 vient d’une mise à jour défectueuse de Falcon Sensor, un composant de sécurité développé par CrowdStrike. Un fichier livré avec cette mise à jour a provoqué un plantage précoce dans le démarrage de Windows, créant une boucle de redémarrage sur de nombreux postes. Les systèmes macOS et Linux n’étaient pas concernés, car le problème visait spécifiquement l’agent Windows.
Quels types de systèmes informatiques ont été les plus touchés par l’incident ?
Les machines les plus touchées étaient les postes Windows sur lesquels Falcon Sensor était installé et mis à jour avant la diffusion du correctif. Les serveurs, les postes sous d’autres systèmes d’exploitation et les machines éteintes au moment de la mise à jour ont été beaucoup moins impactés, voire pas du tout.
Comment les entreprises ont-elles pu résoudre le dysfonctionnement sur leurs postes ?
La correction passait souvent par un démarrage en mode sans échec, l’accès au dossier C:ProgramDataCrowdStrike puis la suppression des fichiers défectueux avant un redémarrage classique. Dans certains cas, des redémarrages répétés ont été utilisés pour déclencher les outils de récupération de Windows. Les machines qui s’allumaient après 7h30 ont reçu la version corrigée de l’agent et n’ont pas subi la panne.
La panne était-elle liée à une cyberattaque ou à un problème de sécurité informatique externe ?
Non, tout indique qu’il ne s’agissait pas d’une cyberattaque. La direction de CrowdStrike a confirmé qu’aucune compromission ni intrusion malveillante n’avait été détecté en lien avec cet événement. L’origine est interne au logiciel, liée à un bug dans la mise à jour, ce qui en fait un incident de fiabilité plutôt qu’une attaque de sécurité.
Quelles sont les principales conséquences à long terme de cet incident pour les organisations ?
À long terme, l’incident pousse les organisations à revoir leur dépendance à un seul éditeur pour les outils de sécurité, à renforcer la gouvernance des mises à jour et à mieux préparer les plans de continuité d’activité. Beaucoup ont engagé des audits de leurs processus de déploiement, des tests de scénarios de crise et des formations supplémentaires pour leurs équipes techniques afin de limiter l’impact de futurs événements similaires.
