Agent de revue de sécurité : le design pattern employé par la GitHub Action d’Anthropic

Anthropic a publié durant l’été 2025 en open source une GitHub Action qui utilise Claude Code pour faire une revue de sécurité du code. Le concept : à chaque Pull Request un agent se lance, il lit le diff, cherche des vulnérabilités, puis poste ses conclusions en commentaire.

Nous avons analysé cette action qui nous semble intéressante a bien des égards et qui illustre un pattern clé en IA : de l’intelligence artificielle pour raisonner et du code déterministe pour cadrer, exécuter et intégrer ce raisonnement dans un système existant.

Le fonctionnement de l’action en détail

Une Github Action fonctionne habituellement sur un runner : une machine virtuelle capable d’installer des dépendances et d’exécuter des scripts et des commandes.

Dans le cas de cette action, un runner est donc instancié, puis Claude Code y est installé.

Ensuite, l’action va récupérer le contenu de la Pull Request, c’est à dire les changements apportés par le développeur. Elle utilisera Claude Code avec un prompt qui va lui permettre de raisonner sur ces changements et détecter d’éventuelles vulnérabilités. Au passage, le prompt impose une méthode d’analyse en plusieurs phases : comprendre le contexte du dépôt, comparer les changements aux pratiques existantes, puis évaluer les vulnérabilités potentielles. Ce n’est donc pas seulement une checklist OWASP plaquée dans un prompt. L’agent est explicitement invité à explorer le code pour comprendre les conventions locales. Le prompt impose aussi de consigner chaque vulnérabilité identifiée dans un fichier JSON structuré précis.

Enfin, un script va être capable d’ingérer le rapport et poster chaque vulnérabilité en commentaire sur la ligne incrimée sur la Pull Request.

Le pattern à retenir : l’IA pour le raisonnement, le code pour mettre en oeuvre

Si l’on prend de la hauteur sur le mécanisme explicité juste avant, l’IA ne parle pas directement à GitHub mais elle produit une donnée structurée qui elle sera utilisée par du code déterministe s’occupe ensuite de l’intégration sur Github.

C’est exactement le bon découpage : on laisse au modèle le raisonnement : lire un diff, comprendre une intention, repérer une rupture dans les pratiques du projet, formuler un scénario d’exploitation, proposer une correction. Et on garde dans du code classique ce qui doit rester robuste : appeler une API, analyser un fichier, éviter les doublons, poster un commentaire au bon endroit, échouer proprement.

Ce pattern est celui des skills bien fait : un workflow dans lequelle le modèle raisonne à l’endroit où le raisonnement apporte de la valeur des scripts et des entrées/sorties ayant des formats stricts. Cette façon de faire est la manière la plus solide de faire fonctionner l’IA, qui est un système probabiliste dans un contexte de SI d’entreprise nécessitant de la stabilité et de la robustesse.

Les bénéfices de cette action de sécurité pour une organisation

Le premier bénéfice est évident : automatiser un premier niveau de revue sécurité. Forcer ce type de revue de sécurité automatique n’est évidemment pas une promesse de sécurité absolue. Une revue de code automatisée par IA ne remplace pas une culture sécurité, ni des revues humaines, ni des audits sérieux sur les zones critiques… mais elle retire une partie de la charge cognitive répétitive. En effet, à chaque Pull Request, quelqu’un devrait se demander : est-ce qu’on introduit une injection SQL ? Est-ce qu’une vérification d’autorisation a sauté ? Est-ce qu’une donnée sensible se retrouve exposée ? Est-ce qu’un appel système manipule une entrée utilisateur ? En pratique, ces questions ne sont pas toujours posées avec la même rigueur, surtout quand l’équipe est sous pression. Un agent IA de revue de code bien paramétré remet ces questions sur la table de manière systématique.

La deuxième valeur est organisationnelle. Déployer cette action au niveau d’une organisation GitHub, via un ruleset, en fait une politique d’entreprise. On ne dépend plus de la maturité variable de chaque projet. Les dépôts activés héritent tous d’un même socle de revue. Pour une agence, une startup multi-produits ou une PME avec plusieurs équipes, c’est très concret. On peut ajouter une couche de sécurité transversale sans réorganiser toute la chaîne de développement.

Un exemple pour industrialiser des pratiques d’experts à l’ère de l’IA

Ce type d’action permet de se projeter sur la manière d’industrialiser des pratiques d’experts à l’ère de l’IA.

Pendant longtemps, beaucoup de pratiques d’experts restaient difficiles à industrialiser. On pouvait écrire des conventions, documenter des standards, organiser des formations. Dès qu’il fallaitcomprendre une intention, comparer à un contexte local ou évaluer un risque métier, l’humain était nécessaire. Les agents changent ça. Ils ne remplacent pas l’expert mais ils permettent de transformer une partie de son raisonnement en contrôle récurrent sous forme d’analyse contextualisée.

Si l’on reste au niveau du développement, on peut imaginer des GitHub Actions similaires, toujours simples. Par exemple pour vérifier que :

• une Pull Request respecte certaines conventions propres à une pile technique,
• une nouvelle variable d’environnement est bien documentée dans le .env.example,
• une migration de base de données est accompagnée d’un plan de retour arrière,
• une documentation API reste cohérente avec le code,
• une changement critique contient bien les tests attendus.

Ces contrôles existaient déjà mais étaient généralement portés par des humains… Dans le meilleur des cas, il s'appuyaient sur des outils déterministes quand la technologie le permettait, ce qui est loin d'être courant. Aujourd’hui, tous deviennent simples à exprimer et à mettre en oeuvre. Un linter classique est excellent lorsque la règle est formelle : “pas de variable inutilisée”, “pas de format invalide”, “pas de méthode dépréciée”. Beaucoup de sujets importants ne rentrent pas aussi bien dans une règle statique : “ce changement introduit-il un nouveau risque d’autorisation ?” ou “ce changement est-il cohérent avec l’architecture du module ?” sont des questions moins mécaniques.

Il faut noter qu’une Github Action comme celle d’Anthropic fonctionne parce qu’elle est bornée : le périmètre est clair, la sortie est structurée et les faux positifs sont explicitement combattus. L’intégration GitHub est gérée par du code classique. Les résultats arrivent dans le flux de travail naturel des développeurs.

C’est à mon sens le secret d’un bon agent : un outil avec une responsabilité limitée, un contexte bien préparé, une sortie exploitable et une intégration robuste. Le modèle compte bien sûr, mais à la lumière de ce qui vient d’être expliqué, on se rend compte que l’intégration sans coutûre avec le quotidien de l’utilisateur est au moins aussi importante.