This article is only available in French.
Il y a des failles qu'on oublie, et il y a Log4Shell. Dans les jours qui ont suivi sa publication, en décembre 2021, des milliers d'équipes ont passé leurs nuits sur une seule question : est-ce qu'on utilise Log4j, quelque part ? La plupart n'en savaient rien.
Cinq ans plus tard, l'IA est partout dans la sécurité : dans les outils d'audit, dans les centres opérationnels, et aussi du côté des attaquants. L'actualité offre même un point de comparaison. En octobre 2026, PHP2Shell, une faille critique du moteur PHP, a été découverte, documentée et sondée dans un paysage où l'IA pèse des deux côtés.
D'où l'expérience de pensée : si Log4Shell sortait aujourd'hui, qu'est-ce qui changerait ?
Une faille au ras du sol
Log4j est une bibliothèque Java qui sert à écrire des journaux. Sa faiblesse tenait à une fonctionnalité d'interprétation : certaines expressions insérées dans le texte à journaliser étaient évaluées au lieu d'être écrites telles quelles. Comme une application journalise presque tout ce qu'un utilisateur lui envoie (un en-tête, un identifiant, un message), il devenait possible de détourner ce comportement à distance.
Deux chiffres résument la gravité : un score de sévérité de 10 sur 10, et une exploitation de masse démarrée en quelques heures. La raison n'est pas la sophistication de la faille, mais l'inverse : elle était triviale. C'est précisément ce qui rend l'expérience de pensée intéressante.
Log4Shell n'avait pas besoin de l'IA. Ses défenseurs, si.
Côté attaque : l'IA n'aurait presque rien changé
C'est le constat contre-intuitif. On imagine volontiers que l'IA aurait rendu Log4Shell encore plus dévastatrice. En réalité, la faille était déjà au plus bas de l'échelle de difficulté. L'exploitation de masse, le cœur de la crise, ne demandait aucune expertise rare : des scans automatisés ont balayé Internet en quelques heures, et des traces d'exploitation antérieures à la publication ont été retrouvées après coup.
L'IA aurait pu gratter des marges : trier plus vite les cibles intéressantes, automatiser la suite de l'intrusion. Mais sur la partie qui a fait mal, elle n'avait rien à apporter. On ne rend pas plus facile ce qui est déjà trivial.
Côté défense : c'est là que tout aurait basculé
Le vrai goulot d'étranglement de 2021, ce n'était pas le correctif : une version corrigée était disponible dès la publication. Le problème, c'était de savoir où l'appliquer. Log4j était embarquée comme dépendance de dépendance, enfouie dans des archives Java imbriquées, dans des équipements fermés, dans des outils internes que plus personne ne maintenait. Et le correctif lui-même a dû être repris plusieurs fois.
Avec les outils de 2026, plusieurs étapes se seraient compressées :
- L'inventaire : des agents capables de parcourir dépôts, images de conteneurs et binaires pour répondre en heures, et non en semaines, à la question « où tourne Log4j ? ».
- Le correctif : des assistants qui ouvrent les demandes de mise à jour en série et font tourner les tests, exactement le travail répétitif que l'IA absorbe le mieux.
- La détection : le tri du déluge d'alertes dans les centres opérationnels.
La chronologie ci-dessous compare le déroulé réel de 2021 à un scénario 2026 plausible. Basculez d'un scénario à l'autre : la zone colorée est la fenêtre d'exposition, le temps pendant lequel l'attaquant a l'avantage.
- J-9Attaquants : Premières traces d'exploitation (1er décembre, retrouvées après coup)
- J0Défenseurs : Publication de la faille, version corrigée 2.15 disponible
- J0Attaquants : Scans de masse sur Internet en quelques heures
- J+3Défenseurs : Correctif jugé incomplet : version 2.16
- J+8Défenseurs : Nouvelle faille voisine : version 2.17
- J+18Défenseurs : Version 2.17.1, dernier correctif de la série
- J+24Défenseurs : Des serveurs vulnérables subsistent encore des mois plus tard
J0 = publication de la faille, le 10 décembre 2021. Le scénario 2021 reprend les dates publiques des correctifs ; le scénario 2026 est une projection illustrative, pas une mesure.
Le contrepoint PHP2Shell
Si l'histoire s'arrêtait là, la conclusion serait rassurante : l'IA profite surtout aux défenseurs. PHP2Shell vient nuancer ce tableau.
Ses deux failles (CVE-2026-109618 et CVE-2026-109619) touchent le moteur PHP lui-même, sur toutes les versions depuis la 5.4. Contrairement à Log4Shell, il ne s'agit pas d'une fonctionnalité détournée mais de corruption mémoire, une catégorie de bug longtemps réputée difficile à transformer en attaque fiable.
Les chercheurs qui ont analysé l'affaire l'affirment : l'IA a ramené à quelques jours un travail d'exploitation qui demandait auparavant des mois de spécialistes. Des catégories de bugs vieilles de dix ans redeviennent exploitables. La divulgation elle-même a déraillé : une tentative d'exploitation a été repérée par les leurres (honeypots) d'Amazon dès le 17 octobre, les identifiants des failles ont fuité le 20, et PHP a avancé ses correctifs au 21. Une troisième faille, publiée le 23 octobre, attendait encore son correctif à la fin du mois.
Mais il y a l'autre face. Ces mêmes failles ont été trouvées par des chercheurs du programme Patch the Planet d'OpenAI, puis indépendamment par l'équipe de Wiz, et signalées à PHP dès le mois d'août. L'IA a pesé dans la découverte autant que dans l'exploitation. Et à la fin octobre, aucune intrusion réussie n'avait été confirmée publiquement : la course n'était pas perdue d'avance.
Le comparateur ci-dessous met les deux affaires en vis-à-vis, phase par phase.
Choisissez une phase pour lire l'analyse. Appréciation éditoriale, pas une mesure.
Ce que ça change pour nous
Mettre les deux affaires côte à côte fait apparaître un déplacement. L'IA ne change pas tellement le risque d'être attaqué ; elle change quelles failles comptent.
Pour les failles « faciles » comme Log4Shell, la difficulté d'exploitation était déjà nulle : l'IA joue surtout pour les défenseurs, à condition qu'ils aient leurs outils en place avant la crise. Pour les failles « difficiles » comme PHP2Shell, la barrière technique qui nous protégeait de fait est en train de tomber, et le délai entre la sortie d'un correctif et son exploitation se raccourcit d'autant.
Trois leçons pratiques en découlent :
- L'inventaire n'est plus optionnel. On ne corrige pas ce qu'on ne sait pas faire tourner. Une nomenclature logicielle (SBOM) tenue à jour et interrogeable, c'est la différence entre des heures et des semaines.
- La « difficulté d'exploitation » ne vaut plus comme critère de tri. Une faille mémoire réputée complexe mérite désormais la même urgence qu'une faille triviale.
- Le temps de correction devient l'indicateur clé. Si l'attaquant gagne des mois sur l'exploit, le défenseur doit gagner des jours sur le déploiement. Automatiser le correctif, les tests et la mise en production : c'est là que l'IA défensive rapporte le plus.
En décembre 2021, on a manqué de visibilité. En 2026, on risque de manquer de temps. L'IA peut nous rendre la première ; c'est à nous de l'utiliser pour gagner le second.
Vos serveurs utilisent PHP ? Appliquez sans attendre les versions corrigées listées dans l'avis de php.net. Si vous voulez un regard extérieur sur vos applications, notre service Sécurité applicative peut vous accompagner.