IA contre IA : réduire à quelques heures le délai entre une faille et son correctif

Le 17 juillet 2026, WordPress a publié le correctif d’une faille critique de son cœur, baptisée wp2shell. Les premières attaques ont commencé le soir même (Wordfence). Quand l’attaquant va plus vite qu’un cycle de maintenance classique, tout se joue sur une question : qui arrive le premier.

Nous avions anticipé ce virage en refondant nos pipelines autour d’agents IA. Cet été nous a donné raison, et nous a rappelé une fois que la course ne se gagne jamais d’avance. Cet article décrit notre dispositif, l’incident qui l’a mis à l’épreuve et ses effets sur vos projets.

Début 2026 : un millefeuille d’actions et de vérifications

Nous avons engagé en janvier une refonte complète de nos pipelines de développement et de déploiement. Notre objectif : faire entrer l’IA dans la chaîne de production, sans jamais lui donner les clés sans contrôle.

Ce chantier a commencé par la migration de nos dépôts de GitLab vers GitHub. GitHub se connecte plus étroitement à Claude Code, l’agent de développement IA d’Anthropic, et à l’écosystème d’automatisation qui l’entoure.

La refonte visait un objectif précis : déployer des agents autonomes managés (managed agents). Ces agents IA s’exécutent à tout moment, sur un événement ou sur un horaire, la nuit comme le week-end. Chacun accomplit une tâche précise et en rend compte.

Notre chaîne alterne ainsi les couches d’action et les couches de contrôle jusqu’à la production. Aucune modification ne la traverse sans avoir été contrôlée.

Entre son développement et sa mise en production, une fonctionnalité passe devant huit IA vérificatrices. Chacune cherche un type de défaut précis :

1. Code review technique : qualité, lisibilité et maintenabilité du code.
2. Code review sécurité : failles, secrets exposés, dépendances à risque.
3. Code review performance : requêtes, temps de réponse, consommation de ressources.
4. Code review cas limites (« Et si… ? ») : scénarios imprévus, erreurs, entrées inattendues.
5. Conformité aux critères d’acceptation : la fonctionnalité fait-elle exactement ce qui a été demandé ?
6. Doc review : la documentation suit-elle le code ?
7. Release review : dernière vérification avant la mise en production.
8. Sanity check : contrôle automatique de l’application juste après chaque déploiement.

Été 2026 : les failles se multiplient et sont exploitées plus vite

Cet été, deux courbes ont grimpé en même temps : le nombre de failles découvertes sur les technologies web et la vitesse de leur exploitation.

Nous maintenons des applications en Symfony, React, Node et WordPress. Toutes sont concernées, mais WordPress et son écosystème de plugins sont particulièrement ciblés. WordPress est le CMS le plus répandu du web (W3Techs), donc le plus rentable à attaquer.

Plus de failles

Vulnérabilités WordPress (cœur, plugins et thèmes) recensées de juillet à septembre. Source : somme des rapports hebdomadaires Wordfence Intelligence, 13 semaines par an, chaque semaine rattachée au mois qui contient la majorité de ses jours (consulté le 27 octobre 2026).

Le rythme hebdomadaire a lui aussi changé d’échelle : en moyenne 172 vulnérabilités par semaine à l’été 2025, contre 282 à l’été 2026. La semaine du 28 septembre au 4 octobre 2026 en a compté 512 (Wordfence).

Des failles exploitées beaucoup plus vite

Le volume de failles compte moins que leur vitesse d’exploitation.

• ~5 heures : délai médian avant exploitation de masse pour les vulnérabilités WordPress les plus exploitées (Patchstack, 2026). Il se comptait encore en jours.
• ~90 minutes : en juillet 2026, une faille critique du cœur de WordPress a commencé à être exploitée une heure et demie après la publication du correctif.
• ×10 en moins de 24 heures : en septembre 2026, le trafic d’attaque visant une nouvelle faille critique a été multiplié par plus de dix en une journée.

Pour l’attaquant, la publication d’un correctif indique désormais exactement où frapper. Pour le défenseur, elle ouvre une fenêtre qui se compte en heures.

Retour d’expérience : la fois où l’attaquant est arrivé le premier

Cet été, une attaque a franchi notre vigilance pour la première fois.

Une vulnérabilité publique (CVE, Common Vulnerabilities and Exposures) venait d’être publiée sur un composant utilisé par l’un de nos clients. Quelques heures plus tard, un attaquant l’exploitait sur son site, juste avant le déploiement de notre correctif.

L’incident est resté sans gravité : aucune fuite de données, aucun impact durable sur le service. L’objectif de l’attaquant illustre pourtant l’époque. Il cherchait des clés d’API et des jetons d’accès pour faire du LLMjacking : utiliser les comptes d’IA de ses victimes pour financer de nouvelles campagnes d’attaque avec leurs crédits.

L’IA démultiplie désormais la capacité des attaquants. Elle les aide à trouver les failles et à écrire les exploits, puis se nourrit de ressources volées pour attaquer encore. Pour tenir, la défense doit aligner des agents IA plus rapides que ceux d’en face.

Notre réponse : deux systèmes, une seule chaîne de déploiement

Depuis l’incident, nous avons réduit nos cycles de correctifs au strict minimum. Le dispositif repose sur deux systèmes complémentaires. Le premier part de la production, le second du développement, et tous deux rejoignent la même chaîne de déploiement contrôlée.

Côté production : surveiller ce qui tourne réellement

• Correctifs système automatisés : des scripts appliquent plusieurs fois par jour les mises à jour de sécurité du système et des paquets serveur. Le code applicatif n’est jamais modifié par ce biais.
• Agents autonomes sur la SBOM : des agents contrôlent en continu notre SBOM de production (Software Bill of Materials, l’inventaire exhaustif des composants et versions effectivement déployés).
• Scanner de CVE : il interroge régulièrement les bases de vulnérabilités publiques, les croise avec la SBOM et signale aussitôt toute dépendance à risque.

Côté développement : corriger à la source

1. Détection : des bots de type Dependabot signalent chaque mise à jour disponible.
2. Tri : une IA fusionne les mises à jour triviales sur la branche de développement. Pour les autres, le lead développeur du projet est notifié et tranche.
3. Campagnes : les alertes du scanner de CVE alimentent des campagnes de mise à jour groupées, qui traitent les besoins en masse.
4. Priorisation : une CVE de sévérité haute ou critique fait basculer la campagne en hotfix prioritaire. Il passe en tête de file et part en production dès que la chaîne de contrôles l’a validé.

Une seule chaîne de déploiement, contrôlée à chaque étape

Chaque correctif applicatif suit le même chemin, qu’il vienne de la production ou du développement : développement, testing, préproduction, production. À chaque environnement, le pipeline d’agents IA exécute des contrôles de sécurité et de qualité différents. Les étapes restent toutes en place et s’enchaînent sans temps mort.

Ce que cela change pour vous

Une faille non corrigée devient exploitable en quelques heures, et une maintenance mensuelle laisse donc votre site exposé pendant des semaines. Votre site, votre marque et vos données dépendent désormais d’un indicateur : le temps écoulé entre la publication d’un correctif et son déploiement.

Face à des attaques outillées par l’IA, seule une défense elle-même automatisée tient la cadence. Notre dispositif vous apporte quatre garanties :

• Visibilité continue : une SBOM de production tenue à jour et confrontée chaque jour aux bases de CVE.
• Traçabilité : chaque correctif suit le cycle développement, testing, préproduction, production, avec des contrôles automatisés de sécurité et de qualité à chaque étape.
• Escalade par sévérité : fusion automatique des mises à jour triviales, arbitrage du lead développeur pour les autres, hotfix prioritaire pour les CVE hautes et critiques.
• Périmètre maîtrisé pour l’IA : nos agents n’accèdent jamais aux données de production. Nos équipes s’y connectent par authentification unique (SSO) et réseau privé virtuel (VPN). Les secrets sont stockés dans Vault et les mots de passe chiffrés dans Passbolt.

Ce dispositif s’intègre à nos contrats de maintenance applicative. Pour évaluer l’état de vos propres applications, notre checklist d’audit de sécurité donne un premier point de repère. Si vous exploitez un parc WordPress, notre retour sur la reprise de TMA WordPress d’une ETI détaille la méthode.

Une course qui se joue en continu

L’IA accélère la course entre attaquants et défenseurs, des deux côtés. Elle se gagne désormais avec des agents IA spécialisés qui détectent, corrigent et se contrôlent les uns les autres en continu.

Vous voulez savoir où en sont vos applications face à cette nouvelle vitesse d’attaque ? Parlons-en.