Systèmes multi-agents pour sécurité et revue de code : gouverner Claude Code et les agents

Quand plusieurs agents améliorent vraiment la revue de code

Les systèmes multi-agents pour sécurité et revue de code deviennent utiles quand ils créent de la séparation réelle : séparation des rôles, des preuves, des outils, des espaces de travail et de l’autorité de fusion. Lancer plusieurs agents en parallèle ne suffit pas. Si tous lisent le même résumé, partagent les mêmes hypothèses et valident les mêmes conclusions, le système produit seulement une certitude plus bruyante.

La bonne question est donc opérationnelle : quel agent possède le périmètre, quel agent modifie le code, quel agent cherche les failles, quel agent vérifie les tests et quel humain accepte la fusion ? Dans une revue de sécurité, la valeur vient du désaccord utile. Un agent implémenteur peut optimiser pour terminer la tâche ; un agent réviseur doit avoir la liberté de refuser, de demander une preuve ou de signaler un risque qui rend la modification inacceptable.

La recherche Anthropic sur les systèmes multi-agents, publiée le 13 août 2026 et vérifiée le 16 août 2026, met précisément l’accent sur la coordination, les ressources partagées, le conformisme, la communication et le risque de collusion. Nous lisons ce travail comme un rappel pratique : plus un système délègue à des agents, plus il doit rendre l’ownership observable.

Pour la sécurité du code, commencez par l’identité et la preuve. Qui a lu quoi ? Qui a modifié quoi ? Quel outil a été autorisé ? Quelle trace reste avant la fusion ? Notre guide Identité des agents IA : permissions, approbation par outil et piste d’audit prolonge ce point avec une méthode centrée sur les permissions et les journaux compréhensibles.

Choisir une topologie coordinateur, exécutants et réviseur

Une topologie saine commence par un coordinateur. Son rôle n’est pas de tout faire, mais de découper la demande, d’assigner les responsabilités et de maintenir la frontière de tâche. Il décide par exemple qu’un agent analyse le diff, qu’un autre vérifie les dépendances, qu’un troisième écrit ou corrige les tests, puis qu’un réviseur indépendant inspecte le résultat sans hériter des conclusions de l’implémenteur.

Les agents exécutants doivent recevoir un périmètre étroit. Un agent chargé de corriger une validation d’entrée n’a pas besoin de droits sur les secrets de production, les paramètres CI globaux ou les scripts de déploiement. Un agent chargé d’étudier une vulnérabilité peut travailler en lecture seule. Cette discipline réduit les collisions et rend les erreurs plus faciles à contenir.

Le réviseur indépendant mérite une place à part. Il ne doit pas seulement relire le résumé final du coordinateur. Il doit pouvoir inspecter le diff, relancer les tests pertinents, chercher les changements de permissions, repérer une exposition de secret, contester une dépendance ou demander une preuve supplémentaire. Dans une revue multi-agent, le consensus n’est pas une preuve ; la persistance d’un désaccord argumenté est parfois le signal de sécurité le plus important.

Le dernier rôle reste humain : autorité de fusion, acceptation du risque et décision de rollback. Les agents peuvent accélérer l’analyse, produire des hypothèses et élargir la couverture. La responsabilité de publication appartient à une personne ou une équipe identifiée. Pour structurer cette logique sur des systèmes d’agents qui apprennent et se testent dans le temps, l’article Agent mobile auto-amélioré : versions, tests et retour arrière montre pourquoi les harnais, les versions de scénario et les retours arrière doivent rester gouvernés.

Coordination, ressources partagées, conformisme et collusion

Le premier mode d’échec est la mauvaise coordination. Deux agents peuvent modifier la même zone de code, corriger le même symptôme de manière incompatible ou supposer que l’autre a traité une étape critique. Dans une revue de sécurité, cela se traduit par des tests qui passent localement mais échouent dans l’ensemble, des migrations incohérentes ou une mitigation appliquée seulement sur un chemin d’exécution.

Les ressources partagées aggravent ce risque. Un même worktree, une même file de tâches, un même cache, une même session de navigateur ou des identifiants communs créent des interférences. Un agent peut nettoyer un fichier temporaire dont un autre dépend, consommer un quota, écraser une branche, modifier une configuration ou laisser une session dans un état trompeur. Anthropic souligne que les ressources partagées exigent une coordination explicite ; côté revue de code, nous traduisons cela par des verrous, des espaces isolés, des propriétaires et des journaux.

Le conformisme est plus discret. Quand les agents partagent trop tôt leurs conclusions, la diversité d’approche peut disparaître. Un réviseur lit le raisonnement de l’implémenteur, adopte son cadre et manque la faille que sa mission devait justement découvrir. Pour préserver la variance utile, donnez au réviseur un accès aux faits bruts avant la synthèse : diff, tests, modèle de menace, dépendances, permissions, surface d’entrée et résultats de scan.

La communication reste nécessaire, mais elle doit être cadrée. Elle aide les agents à éviter le travail dupliqué, à signaler un blocage et à transmettre une preuve. Elle peut aussi produire une convergence excessive ou, dans des contextes de recherche, créer des comportements de collusion. Le bon contrôle n’est pas le silence total ; c’est une communication avec canaux, moments et contenus définis. Le coordinateur reçoit l’état d’avancement, le réviseur reçoit les artefacts vérifiables, et la fusion reçoit les désaccords non résolus.

Le confinement technique complète cette gouvernance. Un sandbox réduit la surface, mais il ne remplace pas les permissions, les propriétaires et les limites d’effet. Notre analyse Sandbox d’agent IA et permissions du téléphone : pourquoi les limites restent essentielles détaille cette distinction : une barrière d’exécution aide, mais les actions autorisées, les données accessibles et les effets externes restent le cœur du risque.

Construire une revue de sécurité indépendante avec plusieurs agents

Un workflow Claude Code multi-agent orienté sécurité peut commencer par un cadrage court : objectif du changement, surface touchée, modèle de menace, données sensibles, dépendances, permissions et critères de sortie. Le coordinateur écrit ce cadrage avant de déléguer. Sans ce document, chaque agent optimise sa propre interprétation et la revue devient difficile à arbitrer.

Ensuite, séparez l’implémentation de la revue. L’agent implémenteur reçoit la tâche de correction et les tests attendus. Il peut proposer un diff, ajouter des tests de régression et documenter les choix. Le réviseur adversarial reçoit une mission différente : trouver comment le changement échoue. Il inspecte les entrées non validées, les chemins d’autorisation, les erreurs de concurrence, les logs, les dépendances, les secrets, les fichiers générés et les effets de configuration.

La revue doit produire des preuves, pas seulement une appréciation. Exigez une liste des fichiers modifiés, les commandes de test lancées, les limites des tests, les résultats de scan, les permissions nouvelles ou supprimées, les dépendances ajoutées et les points non vérifiés. Quand un agent écrit « cela semble sûr », demandez la preuve qui soutient cette phrase. Quand un agent écrit « impossible à exploiter », demandez le chemin d’attaque testé.

Avant la fusion, la synthèse doit conserver les désaccords. Un point ouvert sur une permission, une dépendance ou une exposition de secret ne doit pas disparaître dans un résumé optimiste. L’humain de merge décide avec les preuves disponibles, pas avec une moyenne des avis d’agents. Les tests qui passent augmentent la confiance ; ils ne prouvent pas seuls la sécurité.

Confinement des outils, secrets, worktrees, files et budgets

Les agents de revue de code ont besoin d’un confinement explicite. Commencez par un snapshot de capacités : quels outils sont disponibles, quels dépôts sont lisibles, quels chemins sont modifiables, quelles commandes peuvent sortir du workspace, quels services externes peuvent être appelés et quels secrets sont inaccessibles. Un agent ne doit pas découvrir ses droits par essai-erreur pendant la tâche.

Isolez les worktrees et les identifiants. Un agent implémenteur travaille dans une branche ou un espace dédié. Un réviseur peut cloner ou lire le diff sans partager l’état mutable. Les identifiants de CI, registres de paquets, clouds, bases de données et systèmes de tickets doivent suivre le principe du moindre privilège. Les jetons à large portée transforment une erreur de revue en incident d’infrastructure.

Contrôlez aussi les files, les budgets et l’arrêt. Un agent en boucle peut consommer du temps, des tokens, des quotas API ou verrouiller une ressource. Définissez un budget, un propriétaire de file, une condition d’annulation et une sortie attendue. L’annulation stoppe le travail restant ; elle ne remonte pas automatiquement les effets externes déjà accomplis. Si un agent a publié un artefact, supprimé une branche distante ou ouvert une PR, il faut une procédure de récupération observable.

Dans nos travaux FoneClaw, nous avons appris que les files et la reprise changent la qualité perçue d’un agent. Une tâche stoppée doit rester compréhensible : ce qui a commencé, ce qui a été approuvé, ce qui reste bloqué. Pour les mécaniques Android de sessions et de reprise, File de tâches d’agent IA sur Android : sessions et reprise explique comment l’isolation des tâches aide l’utilisateur à garder le contrôle quand plusieurs demandes coexistent.

Ce que cette gouvernance apprend aux agents Android

L’analogie avec FoneClaw porte sur la gouvernance des effets, pas sur l’architecture Claude Code. Un agent de code agit sur fichiers, commandes, dépendances et pipelines. Un agent Android agit près d’un espace personnel : messages, appels, notifications, réglages, écran courant, navigation et données de compte. Dans les deux cas, l’utilisateur a besoin de limites visibles et d’un chemin de récupération.

Côté FoneClaw, nous construisons cette logique autour de tâches Android prises en charge, d’approbations visibles, d’arrêt, de relance et de récupération de permissions. Quand une action engage l’utilisateur, l’interface doit montrer ce qui va être fait. Quand Android demande une permission ou que l’état de l’application bloque le parcours, le produit doit guider la reprise plutôt que prétendre que l’action est terminée.

Les leçons multi-agents nous aident à mieux nommer les risques : ressources partagées, files concurrentes, outils trop larges, convergence trop rapide, traces insuffisantes. Elles renforcent notre direction produit : faire de l’autonomie une séquence gouvernée, avec des outils explicites et des résultats observables. Les capacités actuelles sont maintenues sur la page Fonctionnalités FoneClaw, et les informations d’installation à jour se trouvent sur la page Télécharger FoneClaw.

Cette approche protège aussi la récupération. Sur téléphone comme dans le code, un bouton d’arrêt interrompt la suite du parcours ; il ne rend pas magiquement réversibles les effets déjà validés. Notre travail consiste donc à placer la confirmation avant les étapes importantes, à rendre le résultat visible et à proposer une reprise claire quand l’environnement Android demande une action de l’utilisateur.

Checklist de publication pour revue de code multi-agent

Avant le lancement, nommez le propriétaire humain, le coordinateur, les agents exécutants et le réviseur indépendant. Définissez le modèle de menace, les fichiers autorisés, les outils accessibles, les secrets exclus, les budgets et les conditions d’arrêt. Un agent sans propriétaire ni fin définie devient une source de risque.

Pendant l’exécution, gardez les artefacts séparés. L’implémenteur produit un diff et des tests. Le réviseur produit une critique indépendante. Le coordinateur suit l’état, mais ne transforme pas un désaccord en consensus par simplification. Les ressources partagées doivent avoir un verrou, une file ou un propriétaire explicite.

Avant la fusion, vérifiez les preuves : diff, tests, dépendances, permissions, migrations, logs, exposition de secrets, rollback et points non vérifiés. Les conclusions du réviseur restent visibles au moment de la décision. Après incident, conservez la chronologie : quel agent a agi, quel outil a été utilisé, quelle approbation existait, quel effet doit être corrigé.

• Un rôle par agent, avec droits minimaux.
• Un réviseur indépendant, avec autorité de rejet.
• Des ressources partagées isolées ou verrouillées.
• Des preuves vérifiables avant fusion.
• Un arrêt clair et un plan de récupération pour les effets déjà produits.