Edition 13

Deux réalités coexistent, et il faut les tenir ensemble. Première réalité : l'avertissement est réel et fondé. Les attaques pilotées par l'IA arrivent, elles frapperont les infrastructures critiques, et une réponse public-privé coordonnée est effectivement la bonne réponse. Après l'été que nous venons de vivre, voir une industrie qui a passé deux ans à minimiser le problème le dire enfin clairement, c'est un progrès. Deuxième réalité : lisez la liste des signataires avec lucidité. Les entreprises qui construisent les modèles les plus offensifs sont les mêmes qui vous vendent la défense, et cette lettre fait aussi office d'annonce de lancement coordonnée pour Daybreak, Mythos et Perception.

Retenez le signal, mais gardez le portefeuille fermé un moment. L'alerte systémique ne vous oblige pas à acheter la nouvelle plateforme de défense IA de qui que ce soit, et elle ne remplace certainement pas les fondamentaux que je continue de marteler. La bonne réponse à « les attaques IA arrivent » n'est pas un beau produit IA neuf vissé sur des fondations branlantes : c'est finir le travail de fond ennuyeux, le même qui aurait stoppé la plupart des incidents de cet été. Achetez les outils défensifs s'ils méritent leur place. Ne laissez pas une lettre ouverte opportunément bien calée décider à votre place.

Voilà l'argument central de la sécurité à l'ère de l'IA résumé en un projet de week-end, et il vaut plus que la lettre de coalition évoquée plus haut. Non pas parce que c'est sophistiqué, mais précisément parce que c'est trivial. Un gars, légèrement irrité par son moniteur, a pointé un outil IA commercial sur le firmware fermé d'appareils courants et les a tous compromis. La barrière qui protégeait jadis le matériel obscur, à savoir que la rétro-ingénierie était un travail lent, spécialisé et coûteux, est exactement la barrière que l'IA vient d'effacer. C'est la vraie histoire de cette époque : pas une magie nouvelle, mais l'effondrement du coût de la compétence.

Pour votre modèle de menace, deux enseignements. Premier enseignement : chaque périphérique est un petit ordinateur connecté, à peine protégé, et votre inventaire des actifs n'inclut presque certainement pas la webcam, le moniteur ou les appareils de salle de réunion qui peuvent être reflashés pour persister sous le système d'exploitation. Deuxième enseignement : c'est pourquoi les invites d'autorisation du navigateur comptent. WebUSB, WebHID et WebBluetooth permettent à un site malveillant d'atteindre ce matériel si un utilisateur clique sur « Autoriser ». Si vos programmes de sécurité de la chaîne d'approvisionnement et d'endpoint s'arrêtent aux laptops et aux serveurs, ils s'arrêtent trop tôt.

Arrêtez-vous sur les 86 %, car c'est le chiffre qui devrait réorganiser vos priorités. La plupart des organisations ne voient pas ce que leurs collaborateurs envoient à l'IA, ce qui signifie que la plupart des politiques de gouvernance IA sont des documents décrivant une réalité que personne ne mesure réellement. C'est le problème de l'IA fantôme et de l'IA douteuse évoqué il y a quelques semaines, désormais étayé par de la télémétrie : interdire les outils ne fonctionne pas, cela ne fait que pousser les usages vers des comptes personnels où vous n'avez aucune visibilité. La seule chose qui fonctionne, c'est un canal sanctionné et supervisé, plus simple à utiliser que le canal fantôme.

Mais ne passez pas à côté de ce qui est genuinement nouveau, car c'est là que vivront les incidents de l'année prochaine. Le centre de gravité s'est déplacé des employés qui collent du texte dans un chatbot vers des agents directement connectés à vos systèmes via MCP, et Netskope observe ce trafic quadrupler. C'est un risque différent : non plus ce qu'un humain tape, mais ce qu'un agent autonome est autorisé à atteindre. Un quadruplement du tissu connectif entre vos données et des modèles externes, c'est un quadruplement du rayon de souffle. Si votre gouvernance IA suppose encore que le risque est un copier-coller dans ChatGPT, vous gouvernez le problème de l'année dernière.

Des prospects m'ont soulevé ce point la semaine dernière, alors soyons directs sur pourquoi le cadrage habituel est erroné. Le quantique ne se range pas correctement dans la case « problème futur », et la raison n'est pas le calendrier matériel, que personne ne peut fixer avec précision. C'est le principe « moissonne maintenant, déchiffre plus tard ». Au moment où vos données chiffrées sont capturées, le compteur démarre, et le déchiffrement intervient simplement plus tard. La vraie question n'est donc pas « quand le quantique arrivera-t-il », mais « combien de temps mes données doivent-elles rester secrètes, et est-ce plus long que le temps nécessaire pour casser le chiffrement qui les protège ». Pour la plupart des données réglementées, contrats, dossiers de santé, secrets commerciaux, la réponse est déjà oui. Ce qui signifie qu'elles sont déjà exposées.

Et cela amplifie tout le reste dans cette newsletter. Chaque violation que j'ai couverte où « seulement des données chiffrées » ont été dérobées constitue un dépôt dans le coffre-fort de quelqu'un, en attente. Un chiffrement déjà faible, un TLS mal configuré, des tailles de clés obsolètes, des schémas maison, n'a pas besoin d'un ordinateur quantique pour être préoccupant aujourd'hui : il mérite d'être préoccupant maintenant, et un ordinateur quantique plus tard ne fera qu'aggraver les choses. Le premier mouvement n'est pas la panique ni le tout-remplacement : c'est un inventaire cryptographique. Sachez où vous utilisez la cryptographie, quels algorithmes, quelles tailles de clés, dans quels systèmes, y compris ceux qu'exploitent vos fournisseurs. Vous ne pouvez pas migrer ce que vous ne voyez pas, et l'UE veut cet inventaire terminé d'ici la fin de cette année. C'est un projet 2026 déguisé en projet 2032.

C'est l'équilibre sur lequel je veux que vous réfléchissiez réellement, car les deux extrêmes sont vendus comme des bonnes pratiques et les deux sont des pièges. La fragmentation est réelle : cinquante outils déconnectés, cinq tableaux de bord et trois équipes travaillant selon trois calendriers différents, voilà comment un incident contenu devient une violation de 276 jours. La consolidation est donc une bonne hygiène, c'est indéniable. Mais poussée trop loin, vous arrivez exactement là où DORA et NIS2 vous interdisent d'être : le risque de concentration, l'ensemble de votre posture de sécurité reposant sur un seul fournisseur qui devient alors un point de défaillance unique et une cible de choix. DORA le nomme explicitement : la dépendance excessive à un prestataire TIC tiers critique est un risque que vous devez gérer, non une efficience à maximiser.

La réponse n'est donc pas un slogan : c'est un jugement, et c'est le vôtre à défendre. Consolidez pour l'intégration et la visibilité, les deux choses que la fragmentation détruit, mais maintenez une indépendance délibérée aux points où la mauvaise journée d'un seul fournisseur vous emporterait avec lui. Cartographiez vos dépendances critiques, demandez-vous lesquels de vos fournisseurs vous ne pourriez genuinement pas vous permettre de perdre, et assurez-vous que la réponse n'est ni « tous » ni « un seul ». C'est le vrai travail derrière la stratégie fournisseur, et c'est exactement le muscle que NIS2 et DORA cherchent à développer. Ni « un seul interlocuteur » ni « le meilleur de chaque catégorie pour tout » n'est une stratégie. L'équilibre, oui.