On ne patche pas un poids : anatomie d'une vulnérabilité LLM

Une faille sans ligne coupable

En novembre 2025, le Google Threat Intelligence Group a publié une observation troublante. Un acteur malveillant a exploité une vulnérabilité zero-day dont l'exploit semble avoir été façonné avec l'aide d'un modèle de langage. Rien d'exceptionnel jusque-là — sauf un détail.

La faille n'était pas un débordement de tampon. Ce n'était pas une entrée non validée ni une erreur d'allocation mémoire. Google la décrit comme une faille logique sémantique dans un mécanisme d'authentification à deux facteurs. Autrement dit : un raisonnement défaillant, pas un octet corrompu.

Cette nuance change tout quand la cible n'est plus un code, mais un LLM. Une vulnérabilité zero-day LLM n'a souvent aucune ligne coupable à isoler. Elle vit ailleurs — et cet ailleurs résiste au geste réflexe de l'ingénieur : le patch.

Le bug déterministe et la dérive comportementale

Dans le logiciel classique, une vulnérabilité est un fait localisable. Un pointeur mal géré, une requête SQL non échappée, une condition de course. On la trouve, on l'écrit noir sur blanc, on la referme. Le correctif est net : avant, la porte était ouverte ; après, elle est close.

Ce déterminisme est la promesse tacite de tout CVE. On suppose qu'à chaque faiblesse correspond un endroit précis dans le code, et donc un correctif précis. La sécurité informatique s'est construite sur ce contrat implicite : localiser, isoler, corriger.

Un grand modèle de langage brise ce contrat. Sa « faiblesse » ne réside dans aucune instruction. Elle est distribuée dans des centaines de milliards de poids — ces nombres appris pendant l'entraînement, qui encodent le comportement statistique du modèle. Personne n'a jamais inspecté la zone de l'espace latent d'où sort une réponse dangereuse.

Quand un attaquant contourne un garde-fou par une reformulation habile, il n'exploite pas un bug : il exploite une propriété émergente du modèle, apprise et non programmée. Le blog a déjà exploré cette bascule à travers l'injection de prompt et la figure du confused deputy, où l'on ne force jamais un LLM, on le persuade. Ici, le problème est encore plus radical : il n'y a pas de porte à fermer, seulement un comportement à infléchir.

Or on ne patche pas un poids. Le « correctif » devient du fine-tuning, du filtrage en garde, du ré-alignement — jamais une fermeture franche. On ne colmate pas une fuite : on rééduque une tendance. Et une tendance rééduquée peut ressurgir sous une autre forme.

Ce que l'immunologie sait déjà

Pour comprendre pourquoi le paradigme du patch échoue, il faut sortir de l'informatique et entrer dans le vivant. Le corps humain dispose de deux régimes de défense, et leur différence éclaire exactement notre problème.

Le premier est l'immunité innée. Barrières fixes, déterministes, présentes dès la naissance : la peau, les muqueuses, les cellules qui reconnaissent des motifs moléculaires universels de pathogènes. C'est rapide, c'est stéréotypé, c'est câblé. L'exact équivalent du pare-feu, de la validation d'entrée, de la liste blanche.

Le second est l'immunité adaptative. Les lymphocytes B et T apprennent à reconnaître des menaces jamais rencontrées, gardent une mémoire de ce qu'ils ont combattu, et affinent leur réponse au fil des expositions. Une revue récente publiée dans Frontiers in Immunology rappelle d'ailleurs que l'immunité innée ne fait pas que réagir la première : elle régule et oriente en amont l'immunité adaptative, via la présentation d'antigènes et la polarisation des réponses. Les deux régimes ne sont pas cloisonnés ; le premier programme le second.

La sécurité d'un LLM relève inévitablement du second régime. On ne peut pas dresser la liste exhaustive des attaques possibles, car l'espace des reformulations est infini. On ne peut qu'apprendre au système à reconnaître des motifs d'attaque — ce qui recrée, trait pour trait, les faiblesses du vivant.

D'abord l'auto-immunité. Un système immunitaire trop zélé attaque les tissus sains : c'est la maladie auto-immune. Un garde-fou trop agressif refuse des requêtes légitimes : ce sont les faux positifs, le sur-blocage, le modèle qui refuse de traduire un texte médical parce qu'il croit y voir une menace.

Ensuite l'échappement par mutation. Les virus survivent en variant leurs antigènes de surface — la variation antigénique de la grippe force à refaire le vaccin chaque année. Un attaquant fait exactement cela : il paraphrase son exploit jusqu'à ce que la formulation ne déclenche plus le motif appris. Le garde ne reconnaît plus l'ennemi qu'il connaissait sous un autre visage.

Enfin la fenêtre d'exposition. Entre le moment où une nouvelle attaque apparaît et le moment où le système la « mémorise » via un ré-entraînement, il existe un délai d'immunodéficience. C'est là, dans cet intervalle, que vit toute vulnérabilité zero-day LLM : dans le temps que met la défense adaptative à apprendre.

Ce que cela impose au dirigeant

Sur mes propres déploiements d'agents, j'ai cessé depuis longtemps de poser la question « est-ce patché ? ». C'est la mauvaise question — celle du logiciel figé. La bonne est : quelle est la stratégie de défense en profondeur ? Le vivant ne compte jamais sur une seule barrière, et une revue systématique du paysage défensif des IA agentiques confirme la même intuition : on superpose des contrôles runtime plutôt que d'espérer un correctif unique.

Je m'appuie sur quatre gestes, tous empruntés à la logique immunitaire.

Le premier : une couche de garde indépendante du modèle, en entrée comme en sortie. Un second système — souvent un modèle plus petit, parfois de simples règles — inspecte les flux sans partager les poids du modèle principal. Comme l'immunité innée, elle est stéréotypée mais rapide, et surtout elle ne peut pas être persuadée par le même argument qui a séduit le modèle.

Le deuxième : le principe de moindre privilège appliqué aux outils exposés à l'agent. Un agent qui ne peut appeler que trois fonctions, sans accès direct à la base de production, limite radicalement le rayon d'explosion. La leçon rejoint celle du data poisoning, où la vulnérabilité vit dans les données plutôt que dans le code : quand on ne peut pas garantir la propreté de la source, on cloisonne l'aval.

Le troisième : le monitoring comportemental, détection d'anomalie plutôt que signature figée. On ne cherche pas la chaîne de caractères de l'attaque connue — elle mutera. On surveille les écarts de comportement : un agent qui appelle soudain un outil qu'il n'utilise jamais, un volume de requêtes anormal, une dérive du taux de refus. C'est la mémoire immunitaire au travail.

Le quatrième, le plus inconfortable : accepter un taux de faux positifs. Un système sans aucun refus abusif est un système sans garde. Comme l'immunité, la sécurité LLM impose un arbitrage permanent entre tolérance et vigilance. Refuser cet arbitrage, c'est choisir soit l'auto-immunité paralysante, soit la porte grande ouverte.

Cultiver, pas colmater

Ces réflexes ne relèvent pas d'un produit qu'on achète une fois, mais d'une posture qu'on entretient — le genre de cadrage que nous construisons en immersion chez dac.consulting avant de brancher le moindre agent sur une donnée sensible.

La métaphore immunitaire porte une dernière vérité, moins flatteuse. Aucun organisme n'est jamais « guéri » de la possibilité d'être infecté. Il maintient une vigilance coûteuse, permanente, jamais définitive. Sécuriser un LLM obéit à la même loi : ce n'est pas colmater une brèche, c'est cultiver une immunité vivante, avec ses rechutes et ses angles morts.

Et parfois, la réponse la plus honnête à une vulnérabilité zero-day LLM n'est pas un garde-fou de plus. C'est de reconnaître qu'un modèle probabiliste, aussi bien surveillé soit-il, n'a rien à faire au contact d'une donnée critique. Le meilleur système immunitaire reste celui qui n'a jamais eu à combattre l'infection qu'on lui a épargnée.