Les Five Eyes avertissent que la résilience des infrastructures doit primer sur l’engouement pour l’IA
Les responsables cyber des Five Eyes ont publié une déclaration commune de six agences afin de faire évoluer le débat sur Google News, de l’engouement pour l’IA vers la résilience des infrastructures. Leur message était direct : l’IA de pointe accélérera les cybermenaces, mais l’achat de davantage d’outils d’IA ne corrigera pas des fondations de sécurité fragiles.
L’avertissement du 22 juin provenait d’agences de cybersécurité d’Australie, du Canada, de Nouvelle-Zélande, du Royaume-Uni et des États-Unis. Il remettait en cause une promesse familière du secteur selon laquelle des logiciels toujours plus performants compenseraient le vieillissement des systèmes, la lenteur des correctifs, les accès excessifs et les plans de reprise incomplets.
La déclaration ne rejetait pas la défense assistée par l’IA. Elle plaçait plutôt l’IA derrière une priorité plus exigeante : maintenir les opérations essentielles lorsque la prévention échoue. Cette position met les conseils d’administration, les opérateurs d’infrastructures, les éditeurs de logiciels et les agences gouvernementales sous pression pour démontrer que leurs systèmes peuvent résister aux perturbations.
Google News place l’avertissement des Five Eyes devant les dirigeants d’entreprise
Le changement central n’est pas une nouvelle capacité d’IA. C’est une demande coordonnée de résilience mesurable avant que les organisations n’ajoutent davantage d’automatisation.
La déclaration des Five Eyes réunissait les dirigeants de six agences. L’Australie était représentée par Stephanie Crowe de l’Australian Cyber Security Centre. Rajiv Gupta représentait le Canadian Centre for Cyber Security.
Catriona Robinson représentait le National Cyber Security Centre de Nouvelle-Zélande. Richard Horne représentait le National Cyber Security Centre du Royaume-Uni. David Imbordino de la National Security Agency et Nick Andersen de CISA ont signé pour les États-Unis.
Cette composition est importante, car l’avertissement franchit les frontières nationales et institutionnelles. Il reflète une évaluation commune d’agences responsables de la défense civile, du renseignement, de la réponse aux incidents et de la sécurité des infrastructures critiques.
Les agences ont déclaré que les modèles de pointe devraient transformer les capacités cyber offensives et défensives. Elles ont également résumé le calendrier attendu dans une formule saisissante : « Le calendrier ne se compte pas en années, mais en mois. »
Cette déclaration mérite d’être présentée avec prudence. Il s’agit d’une prévision gouvernementale, et non d’une preuve que des cyberattaques entièrement autonomes opèrent déjà sur des chaînes d’intrusion complètes.
L’avertissement reflète néanmoins des évolutions mesurables des capacités. Une analyse de mars du National Cyber Security Centre du Royaume-Uni indiquait que ses chercheurs avaient évalué sept modèles de pointe publiés avant mars 2026.
Le meilleur modèle a accompli près de six fois plus d’étapes d’attaque que le modèle le plus performant testé 18 mois auparavant. Certains modèles effectuaient encore des actions utiles lorsque le temps d’évaluation a expiré.
Ces résultats suggèrent que l’IA peut de plus en plus soutenir des activités cyber en plusieurs étapes. Ils n’établissent pas qu’un modèle puisse compromettre de manière indépendante n’importe quelle cible choisie, sans accès, préparation ou intervention humaine.
Cette distinction est importante. Une couverture alarmiste peut faire paraître l’IA comme un adversaire indépendant. Le danger le plus immédiat est souvent plus simple : l’IA aide les attaquants existants à rechercher des cibles, écrire du code, adapter des leurres et industrialiser les tâches répétitives.
L’avertissement cyber commun s’est donc concentré sur cinq actions bien connues. Les organisations devraient réduire leur surface d’attaque, appliquer les correctifs plus rapidement, traiter les systèmes hérités, renforcer les contrôles d’identité et s’entraîner à la réponse aux incidents.
Aucune de ces actions ne dépend d’un modèle non testé ni d’une plateforme de sécurité coûteuse. Chacune exige une connaissance des actifs, une responsabilité opérationnelle et une maintenance continue.
C’est pourquoi cette histoire concerne bien plus que les équipes de sécurité. Les agences ont explicitement présenté la cyberrésilience comme une responsabilité de direction liée à la continuité, à la confiance du marché et à la valeur à long terme.
Un conseil d’administration ne peut pas satisfaire à cette responsabilité en approuvant l’achat d’une solution de sécurité basée sur l’IA. Il doit se demander si les services essentiels continuent de fonctionner après le vol d’identifiants, la défaillance d’un fournisseur ou l’indisponibilité d’un système exposé.
La visibilité de l’avertissement dans Google News élargit son audience, mais l’agrégation peut réduire l’argument à un nouveau titre spectaculaire sur l’IA. Le message le plus important se trouve en dessous : les organisations restent responsables des faiblesses ordinaires, même lorsque les attaques gagnent une vitesse extraordinaire.
C’est là que se situe le conflit central de l’article. Les investissements dans l’IA sont visibles, commercialisables et faciles à annoncer. La maintenance des infrastructures est plus lente, moins séduisante et souvent plus difficile à financer.
Pourtant, l’infrastructure détermine si des attaquants assistés par l’IA trouvent une voie facile. Elle détermine aussi si les défenseurs peuvent contenir les dégâts lorsqu’une intrusion réussit.
L’IA réduit la fenêtre de décision des défenseurs
L’IA modifie le risque cyber en augmentant la vitesse et l’échelle, tandis que la fragilité des infrastructures détermine l’ampleur des dommages causés par cette accélération.
Les dirigeants des Five Eyes ont affirmé que l’IA raccourcit la période entre la découverte d’une vulnérabilité et son exploitation. Cela ne signifie pas que chaque faille nouvellement divulguée fera immédiatement l’objet d’attaques générées par l’IA.
Cela signifie que les défenseurs ne devraient plus compter sur de longs délais entre la divulgation publique, la préparation des attaquants et l’exploitation active. Un processus de correction conçu autour d’un délai confortable peut devenir un risque important.
Cette pression est particulièrement forte dans les environnements complexes. Les hôpitaux, les services publics, les fabricants, les agences gouvernementales et les fournisseurs de télécommunications exploitent souvent des systèmes qui ne peuvent pas être redémarrés à n’importe quel moment.
Les technologies opérationnelles, ou OT, contrôlent des processus physiques tels que le traitement de l’eau, la distribution d’électricité et la production industrielle. Leur mise à jour peut nécessiter des examens de sécurité, le soutien des fournisseurs, des interruptions planifiées et une coordination avec les opérateurs de première ligne.
Ces contraintes rendent l’injonction à « appliquer les correctifs plus rapidement » plus complexe qu’elle n’en a l’air. Une mise à jour précipitée peut interrompre un service essentiel, tandis qu’une mise à jour retardée peut laisser aux attaquants une voie connue.
La résilience offre une manière de résoudre ce conflit. Une organisation peut isoler un système vulnérable, restreindre ses communications, ajouter de la surveillance, préparer des procédures manuelles et planifier une mise à jour contrôlée.
Ces contrôles compensatoires ne suppriment pas la faille sous-jacente. Ils réduisent la probabilité qu’une faiblesse se transforme en urgence à l’échelle du système.
L’évaluation des cyberrisques des Five Eyes met également l’accent sur la réduction de la surface d’attaque. Une surface d’attaque comprend chaque compte, service, appareil, application et connexion accessibles qu’un adversaire peut cibler.
Les organisations accumulent fréquemment des systèmes exposés sans approbation délibérée. Des équipes ouvrent des services d’accès à distance pour un travail temporaire, conservent d’anciennes interfaces d’administration ou connectent des équipements conçus pour un usage isolé.
L’IA peut aider les attaquants à explorer cet environnement plus efficacement. Elle peut organiser la reconnaissance, comparer des versions logicielles à des faiblesses connues et générer des variantes de techniques d’intrusion courantes.
Cependant, elle ne peut pas exploiter une interface qui n’est pas accessible. Elle ne peut pas réutiliser un identifiant supprimé. Elle ne peut pas se déplacer librement dans un réseau qui applique une segmentation réelle.
C’est le fondement pratique de l’avertissement. Une architecture solide limite la valeur que les attaquants tirent d’outils plus rapides.
L’identité est un autre contrôle central. Les organisations se concentrent souvent sur la question de savoir si un compte utilise un mot de passe robuste, tout en négligeant l’étendue des accès détenus par ce compte.
L’authentification multifactorielle ajoute une deuxième étape de vérification. Le principe du moindre privilège limite les utilisateurs, services et agents logiciels aux accès minimaux nécessaires à leurs tâches.
Ces contrôles deviennent plus importants à mesure que les entreprises déploient une IA agentique. Un agent d’IA peut effectuer des actions dans plusieurs outils, au lieu de simplement générer du texte pour un utilisateur.
Un agent disposant d’identifiants étendus peut commettre des erreurs à la vitesse d’une machine. Un agent compromis peut également fournir à un attaquant un accès à des applications connectées, à des données stockées et à des flux de travail automatisés.
Les recommandations du Royaume-Uni sur l’utilisation prudente des agents préconisent des identifiants temporaires, un périmètre limité, une surveillance comportementale et une responsabilité humaine claire.
Elles proposent également un test pratique de préparation. Si une organisation ne peut pas comprendre, surveiller ou contenir les actions d’un agent, cet agent n’est pas prêt à être déployé.
Ce n’est pas un argument contre l’automatisation. C’est un argument en faveur d’une autonomie assortie de mécanismes de confinement.
La même règle s’applique à l’IA défensive. Un système qui modifie automatiquement les règles de pare-feu ou désactive des comptes peut stopper une attaque plus rapidement qu’une équipe humaine.
Il peut également interrompre des opérations légitimes si ses conclusions sont erronées. Les opérateurs d’infrastructures ont donc besoin de seuils d’approbation, de procédures de retour en arrière, de journaux d’audit et d’un moyen défini d’arrêter les actions automatisées.
La vitesse seule ne constitue pas la résilience. La résilience associe une détection rapide à des décisions maîtrisées et à des systèmes récupérables.
Le véritable arbitrage oppose les dépenses d’IA à la maintenance de sécurité
Les organisations font face à un compromis de ressources entre des projets d’IA visibles et le travail moins visible qui rend les services numériques fiables.
L’IA est devenue un aimant à budgets, car les dirigeants peuvent la relier à la croissance, à l’efficacité et au positionnement concurrentiel. La maintenance de sécurité intervient généralement dans la même conversation sous l’angle des coûts, de la conformité ou de la dette technique.
Cette différence crée des incitations biaisées. Un nouveau pilote d’IA peut produire une démonstration en quelques semaines. Le remplacement d’une infrastructure non prise en charge peut exiger des années d’approvisionnement, de migration, de tests et de refonte des processus.
La déclaration des Five Eyes s’oppose à ce déséquilibre. Elle décrit les systèmes non pris en charge comme des passifs stratégiques, et non comme de simples technologies anciennes en attente d’une future mise à niveau.
Les systèmes hérités créent plusieurs types de risques. Les fournisseurs peuvent ne plus publier de correctifs. La documentation peut être incomplète, et les employés qui comprennent des configurations inhabituelles peuvent avoir quitté l’organisation.
Les équipements plus anciens peuvent également dépendre d’applications qui ne fonctionnent pas sur des plateformes actuelles. Le remplacement d’un seul composant peut donc nécessiter de modifier toute une chaîne opérationnelle.
Cela explique pourquoi les organisations reportent la modernisation. Le risque de toucher à un système de production fragile paraît immédiat, tandis que le risque d’une future attaque semble incertain.
La reconnaissance assistée par l’IA modifie ce calcul. Les attaquants peuvent rechercher de la documentation publique, identifier des configurations courantes et multiplier plus rapidement les tests contre des cibles exposées.
La bonne réponse ne consiste pas à remplacer tous les anciens systèmes d’un coup. Les organisations ont besoin d’un inventaire priorisé qui relie les actifs aux services essentiels.
Un inventaire des actifs répertorie le matériel, les logiciels, les comptes, les dépendances et les connexions externes qui soutiennent les opérations. Une cartographie des services va plus loin en montrant quels composants doivent fonctionner ensemble pour produire un résultat.
Cette différence est importante lors d’un incident. Une liste peut indiquer aux intervenants qu’une base de données existe. Une cartographie des services peut montrer quelle fonction hospitalière, quel processus de paiement ou quel portail client s’arrête lorsque cette base de données tombe en panne.
L’accent mis par les agences sur la continuité des activités transforme la cartographie en préoccupation de direction. Les dirigeants doivent identifier les services dont l’interruption aurait des conséquences en matière de sécurité, de finances, de droit ou d’intérêt public.
Ils doivent ensuite déterminer combien de temps chaque service peut rester indisponible. Ils ont également besoin de priorités de restauration testées, de sauvegardes propres, de moyens de communication alternatifs et de procédures opérationnelles manuelles.
Ce travail est difficile à mettre en valeur. Il prend de la valeur lorsqu’un composant ordinaire tombe en panne ou qu’un attaquant désactive une dépendance critique.
Cette tension s’étend aux politiques publiques. Les gouvernements souhaitent que les entreprises adoptent l’IA pour des raisons économiques et de sécurité nationale. Ils dépendent également d’infrastructures exploitées par le secteur privé, dont les propriétaires disposent de ressources et d’incitations inégales.
Les grandes banques et les entreprises de télécommunications peuvent maintenir des équipes d’intervention spécialisées. Les hôpitaux ruraux, les réseaux municipaux d’approvisionnement en eau, les écoles et les petits fournisseurs de services publics ne peuvent souvent pas égaler cette capacité.
Une stratégie de résilience qui considère tous les opérateurs comme également capables laissera des lacunes prévisibles. Les outils d’IA ne suppriment pas les contraintes de personnel, d’approvisionnement et d’exploitation qui se cachent derrière ces lacunes.
Les États-Unis illustrent ce conflit. En juin, Nick Andersen, directeur par intérim de la CISA, a déclaré que les perturbations importantes des infrastructures critiques devaient être considérées comme une réalité attendue.
Ses propos reflétaient une évolution plus large : ne plus chercher à prévenir chaque incident, mais maintenir les opérations essentielles malgré les perturbations. C’est une exigence plus difficile à satisfaire que l’achat de contrôles préventifs.
Dans le même temps, la CISA continue de faire face à des questions concernant ses effectifs et ses relations avec les opérateurs d’infrastructures. Cybersecurity Dive a rapporté que la restructuration gouvernementale et les pertes de personnel avaient endommagé certains partenariats public-privé.
En juin, le Department of Homeland Security a proposé ANCHOR-CI comme cadre de remplacement pour la collaboration autour des infrastructures critiques. Ce cadre soutient des conseils sectoriels, intersectoriels, industriels et régionaux.
Sa conception reconnaît une réalité fondamentale : les systèmes d’énergie, de communications, de finance, de transport, de santé et d’eau dépendent les uns des autres. La résilience ne peut pas être mesurée au sein d’une seule organisation.
Un fournisseur de services publics peut rétablir son réseau tout en restant incapable d’opérer parce que les télécommunications sont indisponibles. Un hôpital peut maintenir ses générateurs, mais perdre l’accès à un fournisseur pharmaceutique ou à un système de patients hébergé dans le cloud.
La résilience des infrastructures d’IA exige donc plus que des modèles sécurisés. Elle nécessite une cartographie des dépendances, des exercices conjoints, un partage d’informations protégé et des plans de reprise tenant compte des défaillances en cascade.
Les coalitions privées peuvent aider. De grands opérateurs, dont JPMorgan Chase, Mastercard, AT&T et Berkshire Hathaway Energy, ont formé l’Alliance for Critical Infrastructure en février 2026.
Le groupe cherche à renforcer la coordination intersectorielle. Son existence signale également que les mécanismes gouvernementaux existants n’ont pas suivi le rythme des besoins opérationnels.
La coordination privée a ses limites. Les entreprises ne disposent pas des mêmes renseignements, de la même autorité juridique ni du même mandat national que les organismes publics.
Cela rend l’affrontement central plus complexe qu’une opposition entre gouvernement et industrie. Le véritable adversaire est une culture de financement qui récompense l’adoption visible tout en reportant la maintenance partagée.
L’avertissement des Five Eyes tente d’inverser cette priorité. L’IA peut soutenir ce travail, mais ne peut s’y substituer.
Ce que le message sur les infrastructures ne prouve pas
L’avertissement établit l’urgence, mais il ne prouve pas que l’IA a déjà transformé chaque étape des cyberattaques réelles.
Les agences gouvernementales publient souvent des recommandations avant que la capacité projetée la plus grave ne devienne courante. C’est une caractéristique de la préparation, mais les lecteurs devraient distinguer les éléments observés des évaluations prospectives.
Les dirigeants des Five Eyes ont déclaré que les modèles de pointe devraient dépasser les attentes actuelles du secteur. Ils n’ont pas publié de référence universelle démontrant que les modèles actuels peuvent exécuter des attaques complètes et autonomes contre des environnements de production bien défendus.
L’évaluation britannique fournit des preuves plus concrètes. Son modèle le plus performant a accompli près de six fois plus d’étapes d’attaque que le meilleur modèle testé 18 mois auparavant.
Toutefois, les performances de référence dépendent de la conception des tâches, de l’accès aux outils, des limites de temps, des environnements d’évaluation et des critères de réussite. Un cyberchamp d’essai contrôlé ne reproduit pas toutes les complications présentes dans un réseau opérationnel de services publics ou d’entreprise.
Les modèles peuvent aussi générer des commandes incorrectes, mal interpréter les réponses du système ou se retrouver piégés dans des boucles improductives. Les opérateurs humains fournissent encore les objectifs, le contexte, les accès et le jugement dans de nombreux usages avancés.
Cette incertitude ne devrait pas devenir un prétexte à l’inaction. Les équipes de sécurité se préparent régulièrement à des capacités plausibles avant que les attaquants ne les déploient à grande échelle.
Elle devrait influencer les choix d’investissement. Une prévision spectaculaire ne justifie pas l’abandon de contrôles efficaces au profit d’une automatisation expérimentale.
L’IA défensive introduit sa propre surface d’attaque. Les modèles peuvent ingérer des contenus non fiables, se connecter à des outils sensibles et agir sur la base d’entrées manipulées.
L’injection de prompt se produit lorsque des instructions hostiles dissimulées dans un contenu influencent le comportement d’un système d’IA. Un agent qui traite un e-mail, une page web, un document ou un ticket de support peut rencontrer ce type de contenu dans le cadre de son travail ordinaire.
Si cet agent possède des autorisations étendues, une défaillance au niveau du modèle peut devenir un incident d’infrastructure. Le principe du moindre privilège et l’isolation en limitent les conséquences.
La qualité des données constitue une autre contrainte. Les systèmes de sécurité basés sur l’IA dépendent des journaux, des inventaires, des alertes et des historiques.
Un modèle ne peut pas identifier de manière fiable un comportement anormal si les capteurs ne détectent pas une activité importante. Il ne peut pas prioriser un actif vulnérable si l’inventaire indique à tort que cet actif a été retiré.
C’est pourquoi l’analyse des modèles de pointe affirme que l’IA amplifiera à la fois les forces et les faiblesses. Une meilleure automatisation peut accélérer un programme mature, tandis que des données peu fiables peuvent automatiser la confusion.
Les défenseurs font également face à un problème de vérification. Un modèle peut produire une explication convaincante pour une conclusion erronée.
Les équipes de sécurité ont besoin de preuves reproductibles à l’appui des décisions à fort impact. Elles devraient conserver les événements sous-jacents, les commandes, les actifs affectés et les enregistrements d’accès qui étayent une recommandation automatisée.
L’examen humain reste important, mais placer simplement une personne à la fin de chaque workflow ne suffit pas. Les réviseurs ont besoin de temps, d’autorité, de contexte système et d’une norme claire pour rejeter une action automatisée.
La question sceptique n’est donc pas de savoir si l’IA aide les attaquants ou les défenseurs. Les preuves soutiennent déjà les deux usages.
La meilleure question est de savoir si les organisations peuvent gouverner l’IA sans ajouter de dépendances fragiles à des environnements déjà vulnérables.
Cette question interpelle également les fournisseurs. « Alimenté par l’IA » n’explique pas d’où un produit tire ses données, ce qu’il peut modifier, comment il échoue ou si les clients peuvent restaurer les configurations précédentes.
Les acheteurs devraient exiger des limites techniques. Ils doivent savoir de quels modèles et services un produit dépend, où les données circulent et ce qui se passe lorsqu’un fournisseur externe devient indisponible.
Ils devraient demander si les actions restent visibles et réversibles. Ils devraient également tester le comportement du produit lorsque ses entrées sont incomplètes, retardées, contradictoires ou intentionnellement hostiles.
Ces exigences peuvent ralentir le déploiement. Elles distinguent aussi une automatisation défensive utile du théâtre de l’IA.
Le cycle des titres de Google News continuera de mettre l’accent sur des modèles plus rapides et des capacités en expansion. Les équipes d’infrastructure doivent fonctionner selon un autre rythme.
Elles ont besoin de preuves reproductibles que les contrôles fonctionnent pendant un incident. L’annonce d’un modèle ne peut pas fournir cette assurance.
La résilience commence par le confinement et la reprise
La réponse la plus solide aux attaques plus rapides est un environnement qui limite les déplacements, préserve les fonctions critiques et restaure les services dans un ordre connu.
La prévention reste nécessaire. Les organisations devraient toujours fermer les services exposés, supprimer les logiciels non pris en charge, corriger les failles exploitables et bloquer les identifiants volés.
Le modèle de résilience part de l’hypothèse que certains contrôles préventifs échoueront. Il demande ensuite jusqu’où un attaquant peut se déplacer et quels services restent disponibles.
La segmentation réseau sépare les systèmes en zones contrôlées. Elle peut empêcher un ordinateur portable de bureau compromis de communiquer directement avec des contrôleurs industriels ou des bases de données sensibles.
La segmentation ne fonctionne que lorsque les organisations la testent. Des règles de pare-feu oubliées, des comptes de gestion partagés et des connexions fournisseurs peuvent rétablir discrètement les chemins qu’un schéma d’architecture prétend bloquer.
La segmentation des identités est tout aussi importante. Les comptes administratifs ne devraient pas être utilisés pour les e-mails, la navigation ou le travail documentaire de routine.
Les comptes de service nécessitent des autorisations strictement définies, des durées de vie d’identifiants courtes lorsque cela est possible, ainsi qu’une surveillance des comportements inhabituels. Les agents d’IA devraient respecter les mêmes restrictions.
Les sauvegardes restent un contrôle de reprise central, mais posséder des fichiers de sauvegarde ne signifie pas pouvoir restaurer un service. Les organisations doivent tester les restaurations dans des conditions réalistes.
Cela implique de confirmer que les sauvegardes sont isolées des identifiants de production. Cela exige également de mesurer le temps nécessaire à la restauration des données, à la reconstruction des systèmes, à la validation et à l’approbation opérationnelle.
Les objectifs de reprise devraient refléter les conséquences pour les services. Un tableau de bord d’analytique client peut rester hors ligne plus longtemps qu’un système de répartition d’urgence.
Les équipes doivent établir ces priorités avant une crise. Sinon, la partie prenante la plus bruyante ou le serveur le plus visible peut monopoliser une capacité de reprise limitée.
Les exercices de gestion d’incident mettent ces conflits en évidence. Un exercice sur table présente aux dirigeants une perturbation simulée et les oblige à prendre des décisions à l’aide des plans existants.
Les exercices de reprise technique vont plus loin. Les équipes reconstruisent les systèmes, renouvellent les identifiants, restaurent les données et vérifient si les applications dépendantes se reconnectent correctement.
Les agences des Five Eyes ont exhorté les dirigeants à s’assurer que les contrôles fonctionnent sous pression. Cette formulation fait passer la norme de l’intention documentée au comportement observé.
Une politique indiquant que les comptes critiques utilisent l’authentification multifacteur a une valeur limitée si les comptes d’urgence la contournent. Un plan d’intervention a une valeur limitée si les fournisseurs ne peuvent pas être contactés en dehors des heures ouvrées.
Cette approche peut également améliorer l’adoption de l’IA. Les organisations disposant de limites d’accès claires, d’inventaires fiables et de mécanismes de retour arrière testés peuvent introduire l’automatisation avec davantage de sécurité.
Elles peuvent limiter un agent à un environnement spécifique, observer ses actions et annuler les changements. Elles peuvent également évaluer s’il améliore le temps de réponse sans accroître le risque opérationnel.
L’initiative Cyber Shield du Royaume-Uni illustre cette double approche. Le programme vise à développer une cyberdéfense agentique à l’échelle nationale tout en continuant de privilégier le déploiement de correctifs, la réduction des systèmes hérités et des technologies sécurisées dès la conception.
Sa vision de la défense à la vitesse des machines reconnaît que le jugement humain reste nécessaire dans des environnements complexes. Elle indique également que des attaques entièrement autonomes n’ont pas encore été observées sur l’ensemble du cycle de vie d’une intrusion réelle.
Cette combinaison est plus utile que l’un ou l’autre extrême. Les gouvernements n’ont pas besoin d’écarter l’IA parce que l’autonomie reste incomplète.
Ils n’ont pas non plus besoin de traiter l’IA comme un substitut à l’ingénierie établie. La stratégie pratique consiste à automatiser là où la rapidité compte et à contenir l’automatisation là où les erreurs comptent.
Pour les développeurs, cela signifie construire des systèmes observables et réversibles. Les applications devraient enregistrer des événements de sécurité significatifs et exposer des informations sur leur état que les opérateurs peuvent interpréter.
Les logiciels devraient prendre en charge des paramètres sécurisés par défaut, des autorisations limitées, des mises à jour rapides et une reprise prévisible. Ces qualités aident tous les clients, y compris ceux qui ne disposent pas de grandes équipes de sécurité.
Pour les acheteurs d’entreprise, la question passe du volume de fonctionnalités au comportement du service. Le produit peut-il fonctionner pendant une panne du fournisseur ? Les administrateurs peuvent-ils exporter les données et configurations essentielles ?
Les équipes peuvent-elles identifier chaque dépendance externe ? Peuvent-elles révoquer les accès sans attendre le fournisseur ?
Pour les travailleurs du savoir, la résilience des infrastructures peut sembler lointaine jusqu’à ce qu’un service familier disparaisse. Échecs d’authentification, documents inaccessibles, perturbations des paiements et retards de communication transforment rapidement des faiblesses techniques en problèmes opérationnels.
De bonnes pratiques de gestion de l’information personnelle ne peuvent pas réparer un réseau d’entreprise. Elles peuvent réduire les perturbations individuelles.
Conserver les contacts essentiels, les décisions et le contexte de travail dans une base de connaissances personnelle consultable peut aider les travailleurs à préserver la continuité lorsque les canaux habituels deviennent fragmentés.
La leçon plus large reste organisationnelle. Les connaissances critiques, les accès et les procédures opérationnelles ne devraient pas dépendre d’une seule personne, d’un seul compte ou d’une seule plateforme indisponible.
La résilience consiste à identifier ces concentrations avant qu’un incident ne les révèle.
Trois signaux indiqueront si l’avertissement change les comportements
Le prochain test consistera à voir si les gouvernements et les opérateurs traduisent la déclaration des Five Eyes en contrôles financés, en reprise mesurée et en déploiement responsable de l’IA.
Le premier signal sera la publication de directives de mise en œuvre par les agences nationales de cybersécurité. La déclaration des Five Eyes établit des principes, mais les opérateurs ont besoin d’exigences sectorielles et de mesures utilisables.
La mise en œuvre par la CISA des directives fédérales sur la sécurité de l’IA est particulièrement importante. L’agence a évoqué la gestion des vulnérabilités, les outils défensifs assistés par IA et le soutien aux autorités étatiques et locales.
Il faudra observer si les nouvelles directives définissent des délais de correctifs, une couverture des actifs, des exigences en matière d’identité ou des tests de reprise. Des mesures concrètes renforceraient l’interprétation donnant la priorité aux infrastructures.
De larges encouragements sans délais, financement ni vérification l’affaibliraient. Les organisations savent déjà que les correctifs et la préparation aux incidents sont importants.
Le deuxième signal sera constitué par les preuves issues d’opérations cyber réelles impliquant l’IA. Les laboratoires gouvernementaux et les chercheurs indépendants devraient continuer à publier des évaluations distinguant l’assistance de l’autonomie.
Des rapports utiles montreront quelles étapes d’une attaque les modèles peuvent mener à bien, à quelle fréquence ils réussissent, quels outils ils nécessitent et où l’intervention humaine reste indispensable.
La même transparence devrait s’appliquer à la défense. Les agences et les fournisseurs devraient indiquer si l’IA réduit le temps d’enquête, améliore la priorisation des vulnérabilités ou contient les incidents sans générer un niveau inacceptable de faux positifs.
De meilleures preuves justifieraient une automatisation ciblée. Des affirmations vagues sur les capacités renforceraient les inquiétudes selon lesquelles les dépenses en IA dépassent les preuves opérationnelles.
Le troisième signal sera l’investissement dans la résilience chez les opérateurs d’infrastructures critiques. Les annonces comptent moins que les résultats éprouvés.
Les conseils d’administration devraient demander combien de services critiques disposent de cartographies de dépendances à jour, de plans de reprise testés, de sauvegardes isolées et de délais de restauration vérifiés. Ils devraient suivre les systèmes non pris en charge et les correctifs à haut risque en retard.
Les gouvernements doivent également répondre aux inégalités de capacité. Les petites entreprises de services publics et les prestataires de soins de santé ne peuvent pas satisfaire aux attentes nationales sans expertise accessible, financements et mécanismes fiables de partage d’informations.
Le cadre ANCHOR-CI proposé offre un test de coordination public-privé. Ses conseils régionaux et intersectoriels devraient produire des relations opérationnelles, et non simplement de nouvelles structures de réunion.
Le succès signifierait que les opérateurs partagent des informations sensibles sur les risques, s’exercent face à des perturbations en cascade et savent qui contacter en cas d’urgence. Une méfiance persistante ou une participation limitée affaiblirait le programme de résilience plus large.
Le cycle d’actualités de Google News passera rapidement au prochain modèle d’IA, à la prochaine démonstration de sécurité ou à la prochaine prévision spectaculaire. Le travail sur les infrastructures avance au rythme des inventaires, des fenêtres de maintenance, des décisions d’achat, des exercices et de vérifications répétées.
Ce rythme plus lent ne le rend pas moins urgent. Il explique pourquoi les dirigeants des Five Eyes ont choisi d’intervenir maintenant.
Les organisations devraient utiliser cet avertissement comme filtre de décision. Avant d’ajouter une nouvelle fonctionnalité de sécurité basée sur l’IA, les dirigeants devraient identifier le service essentiel qu’elle protège et la défaillance qu’elle réduit.
Ils devraient se demander ce qui se passe lorsque le modèle, le réseau, le fournisseur d’identité ou le service cloud devient indisponible. Ils devraient également exiger des preuves que la reprise fonctionne dans un délai acceptable.
La position des Five Eyes ne demande pas aux organisations de choisir entre l’IA et la cybersécurité. Elle leur demande de cesser de confondre l’adoption de l’IA avec les progrès en cybersécurité.
Cette distinction déterminera si des outils défensifs plus rapides renforcent les services essentiels ou se contentent de reposer sur des faiblesses non résolues.
Alors que le prochain titre de Google News promet une nouvelle avancée des capacités de l’IA, la question utile est moins glamour : votre organisation peut-elle subir un choc sérieux, le contenir et poursuivre ses activités les plus importantes ?



