Un audit de sécurité se termine d'ordinaire par un PDF : une trentaine de pages, des notes de gravité, une liste de recommandations, une date. On le classe, on l'oublie, et la release suivante rend l'essentiel obsolète. Cloudflare a rendu public, en octobre 2026, le skill qui a servi de point de départ à son harnais de chasse aux vulnérabilités — et ce dépôt ne produit pas un document, mais un état.
Le dépôt est sous licence MIT, s'installe via la CLI de skills et s'active sur une phrase du type « security audit this codebase ». Derrière la simplicité de l'entrée, l'architecture est celle d'un petit système d'exploitation d'audit : des agents isolés, des fichiers de vérité, des validateurs, et une règle qui tient tout le reste — l'agent qui vérifie un constat n'est jamais celui qui l'a trouvé.
Six phases, trois verdicts, deux validateurs
Le déroulé publié compte six phases : reconnaissance (architecture, frontières de confiance, surfaces d'entrée), chasse guidée par la couverture, validation des candidats, sortie structurée, vérification indépendante des enregistrements, rapport. La reconnaissance écrit deux artefacts — une cartographie et surtout un registre de couverture, coverage-ledger.json, qui liste ce qui doit être testé. Chaque unité du registre part chez un chasseur distinct, et des « critiques de couverture » cherchent les trous.
Vient ensuite le tri. Les constats atterrissent dans un findings.json validé par un schéma, avec trois verdicts : confirmed (trace source complète, résultat observé borné), needs_validation (fait précis non résolu, et aucune sévérité) et rejected (candidat réfuté). Deux validateurs Node sans dépendance contrôlent la forme à chaque mise à jour du registre comme à chaque remplacement de constat. Détail révélateur : le billet de blog décrit sept phases, le dépôt en publie six. L'objet bouge encore.
Un constat « needs_validation » n'a pas de gravité. Le doute n'est pas noté : il est localisé.
Du document à l'état
Ce que change le format n'est pas la beauté du JSON. C'est qu'un fichier se diff, se rejoue et se cumule. Le dépôt l'assume : plusieurs passes sur le même code sont additives ; les registres précédents servent à cibler les manques, à revalider la source modifiée et à ne pas traiter du travail périmé comme du travail couvert. Un audit cesse d'être un événement pour devenir une suite d'états datés.
Conséquence directe pour une équipe web : le livrable peut s'accrocher à la chaîne de release. À chaque déploiement, on sait ce qui a été testé, ce qui a changé de statut, ce qui reste en suspens. Le point le plus utile n'est pas la liste des failles trouvées, c'est la liste de ce qui n'a pas été testé — elle existe enfin noir sur blanc au lieu d'être implicite.
Le piège : une démo n'est pas un audit
La tentation est de croire qu'il suffit d'installer le skill et de laisser tourner. Les prérequis refroidissent vite : un agent de code avec un modèle capable d'utiliser des outils et de lancer des sous-agents en parallèle, Node pour les validateurs, et surtout un bac à sable imposé par le système, sans réseau externe, environnement nettoyé, limites de ressources. Sans ce bac à sable, les pistes restent en needs_validation au lieu d'être exécutées. Autrement dit, l'outil le plus intéressant du lot est celui qui empêche de faire n'importe quoi.
Cloudflare fournit lui-même la limite : une seule passe trouve environ la moitié des failles que plusieurs passes réunies finissent par révéler, et les premières trouvées penchent vers le simple. Le billet avoue le mur — quand le processus devient « lancer dix fois et comparer à la main », il faut une vraie orchestration. Un studio qui livre le résultat d'une passe unique à un client ne vend pas un audit, il vend un ticket de loterie.
Une passe unique trouve environ la moitié des bugs que plusieurs passes finissent par sortir.
Une nouvelle ligne de maintenance
La valeur glisse donc du document vers la trace. Cela crée un travail dont les annonces ne parlent pas : maintenir le registre, arbitrer les needs_validation, dater les revalidations, expliquer au client pourquoi un constat confirmé en janvier ne l'est plus en juin. Un audit rejouable engage son auteur à chaque release. Ce n'est pas une bonne nouvelle commerciale pour tout le monde : plus de rigueur, plus de temps, et une responsabilité qui ne s'arrête plus à la remise du PDF.
En contrepartie, la conversation change de terrain. « Voici quarante pages » devient « voici ce qu'on a couvert, ce qu'on n'a pas couvert, et comment le rejouer ». Pour un site vitrine ou une boutique, l'arsenal complet est disproportionné ; le principe, lui, coûte presque rien : un tableau, des statuts, une date, une commande.
Trois signaux, et un contre-argument
Le contexte d'octobre 2026 va dans le même sens. Le WAF (Web Application Firewall) de Cloudflare sait désormais corréler une requête HTTP et sa réponse : il ne s'agit plus seulement de bloquer des tentatives, mais de repérer des exploitations réussies et des fuites de données que l'inspection requête seule laissait passer (21 octobre 2026). Même déplacement : la preuve de l'effet plutôt que le soupçon.
OpenAI raconte de son côté la découverte de failles critiques dans PHP, dont une attribuée à un agent utilisant GPT‑5.6 Sol, avec une découverte indépendante par Wiz et une coordination incluant les mainteneurs, Cloudflare et des agences gouvernementales (21 octobre 2026). L'entreprise parle d'une « Defender's Window » et annonce un milliard de dollars d'accès subventionnés. Le message implicite est plus inconfortable : le volume de constats va croître plus vite que la capacité humaine à les vérifier.
Shopify, enfin, demande aux développeurs d'applications d'agir dans la semaine, avec scans de sécurité assistés par IA, jetons à expiration et filtrage des journaux (20 octobre 2026). Trois éditeurs, trois façons de pousser l'audit dans la routine. Le contre-argument est net : ce sont des annonces d'éditeurs intéressés, l'engouement pour les « skills » de sécurité ressemble à une mode — le dépôt accumule les étoiles, ce qui ne prouve aucun résultat — et aucun benchmark indépendant ne mesure encore la reproductibilité de ces audits.
Trois questions avant de signer un audit
- Que contient le registre de couverture ? S'il n'existe pas, la couverture est une impression, pas une information.
- Quel statut pour chaque constat ? Confirmé, non résolu, réfuté. Un rapport qui ne distingue pas les trois mélange faits et intuitions.
- Comment rejoue-t-on après la prochaine release ? Si la réponse est « on refait un audit », le livrable est un événement, pas un outil.
Rien ne garantit que les clients paieront pour un fichier là où ils payaient pour un PDF. La question reste ouverte, et elle est commerciale autant que technique. Une chose est déjà acquise : un audit qu'on ne peut pas rejouer vieillit dès le lendemain de sa signature. Le reste — les phases, les validateurs, les verdicts — n'est que la manière sérieuse de le constater.