Points de validation pour les agents de codage : où les arrêter avant la fusion

Un agent de codage capable d'ouvrir une pull request, c'est utile. Un agent de codage capable d'en fusionner une pendant que personne ne regarde, c'est une source de risque dotée d'un accès en écriture au dépôt. Tout le problème tient dans l'écart entre ces deux phrases. Dès qu'un agent peut pousser sur une branche, lancer les tests et cliquer sur « fusionner », la question n'est plus « peut-il faire le travail ? » mais « où s'arrête son autorité ? ».

La plupart des équipes répondent à cette question par accident. L'agent dispose des permissions que son environnement d'exécution lui a accordées, la revue se déroule dans le terminal où l'exécution a démarré, et la trace de qui a approuvé quoi ne vit que dans l'historique de défilement d'une seule personne. Ça tient jusqu'au jour où vous faites tourner trois agents sur deux dépôts et qu'un déploiement du vendredi expédie en production quelque chose que personne n'a lu. Le remède, c'est un point de validation — à condition qu'il s'agisse d'un véritable point de contrôle dans un système partagé, et non d'une habitude dont vous espérez que tout le monde s'y tiendra.

Ce système partagé, c'est ce que propose Sharkly. Des agents de codage, vous en avez déjà ; Sharkly transforme leurs exécutions en Tâches dotées de statuts, d'Assignés et d'une étape de revue qu'une personne doit effectuer délibérément. Cet article détaille le modèle opérationnel qui sous-tend tout cela : qui assigne le travail, qui l'exécute, qui le révise, qui l'accepte, et où placer précisément l'arrêt pour qu'un agent ne fusionne jamais sa propre modification sans revue.

Ce qu'est réellement un point de validation

Un point de validation, c'est un moment dans le cycle de vie d'une tâche où l'exécution automatisée s'arrête et attend qu'une personne décide de la suite. Pas un avertissement, pas une ligne de log qu'on fait défiler sans la voir : un état dans lequel le travail reste tant qu'un humain ne l'en fait pas sortir.

La distinction la plus importante est celle entre un agent qui propose une modification et un agent qui la met en production. Ouvrir une pull request, c'est une proposition. La fusionner, c'est une décision qui concerne la production. Ce sont deux actes d'autorité différents, et c'est dans le second que doit s'exprimer le jugement de l'équipe. Sharkly rend cette frontière explicite : même avec GitHub connecté, la fusion d'une pull request ne change pas le statut de la Tâche. La fusion reste une action humaine consignée, et non un effet de bord que l'agent déclenche en terminant.

Gardez cette frontière en tête, car la plupart des histoires d'« agent qui a cassé la prod » sont en réalité des histoires de point de validation manquant entre la proposition et la mise en production.

Le modèle opérationnel : assigner, exécuter, réviser, accepter

Sharkly répartit une tâche en quatre rôles, chacun avec une seule mission. Le contrat est simple : les Agents explorent, exécutent, testent et rendent compte ; les Personnes donnent la direction, accordent l'autorité et acceptent le résultat.

• Assigner. Une personne décrit le besoin et désigne l'Assigné. Une Tâche porte deux affectations distinctes : les Personnes qui y sont rattachées, et un unique Assigné d'exécution, à savoir l'Agent ou le Crew qui réalise le travail. Modifier l'une ne modifie pas l'autre.
• Exécuter. L'Assigné d'exécution réalise le travail dans un worktree git isolé, de sorte que les exécutions parallèles ne touchent pas aux fichiers les unes des autres. L'avancement, les blocages et les résultats remontent dans la Tâche.
• Réviser. Quand l'Agent a terminé, il laisse la Tâche en attente d'une revue humaine au lieu de la clôturer. Le diff, la sortie des tests et le résumé des modifications sont attachés à la Tâche, pas à un terminal.
• Accepter. Une personne examine les preuves et décide : demander des modifications, ou accepter et fusionner. L'acceptation est le geste final, et seule une personne l'accomplit.

L'intérêt n'est pas que Sharkly exécute l'agent. L'intérêt, c'est que les quatre rôles restent visibles au même endroit au lieu de se dissoudre dans le terminal qui se trouvait être ouvert. Pour une version plus approfondie du volet consacré à la revue, voir les agents de codage human-in-the-loop.

Faites du point de validation un statut, pas une habitude

Un point de validation qu'il faut se rappeler est un point de validation qu'on finira par sauter. Encodez-le donc dans le cycle de vie de la tâche.

Les statuts de Sharkly portent une signification système à travers leurs catégories. Backlog est un état de stationnement : une Tâche qui s'y trouve ne s'exécute pas, même avec un Agent assigné. C'est en la faisant passer dans une catégorie prête à être traitée que l'exécution peut commencer. Completed est un état terminal, et l'atteindre est un geste humain, non quelque chose que l'Agent s'accorde lui-même.

Le statut de la Tâche est délibérément distinct de l'état de travail de l'Agent. Tandis que le statut de cycle de vie affiche In Progress, l'Agent en dessous peut être en train de travailler, d'attendre une réponse humaine, d'attendre une revue humaine ou de signaler une erreur. C'est cette séparation qui constitue le point de validation : l'Agent peut terminer son exécution et signaler « en attente de revue humaine » sans que la Tâche franchisse jamais un état impliquant qu'elle a été livrée. Le travail revient dans la Tâche et s'y arrête jusqu'à ce que quelqu'un l'accepte.

C'est aussi ce qui permet de faire tourner plusieurs agents en toute sécurité. Quand cinq agents parallèles dans des worktrees isolés arrivent tous dans la même colonne de revue, vous n'avez plus qu'un seul endroit pour les trier au lieu de cinq terminaux à surveiller.

Un exemple concret : du ticket à la pull request fusionnée

Suivons une seule Tâche de bout en bout, avec le format d'identifiant de Sharkly, du type SH-312.

1. Créez-la. Une personne crée SH-312, une tâche de correction de bug : « La recherche renvoie des résultats obsolètes après un changement de filtre. » La description contient l'objectif, la procédure de reproduction et les critères d'acceptation. Assigné : un Agent Claude Code rattaché au dépôt de recherche.
2. Cadrez-la. L'Agent explore le code et l'historique associé, confirme le périmètre et publie son plan dans la Tâche. La personne lit le plan et fait sortir SH-312 du Backlog vers un statut prêt, ce qui constitue le signal de départ.
3. Exécutez-la. L'Agent prend la Tâche en charge et travaille dans un worktree tout neuf. Il écrit le correctif, lance la vérification des types et la suite de tests, puis ouvre une pull request dont le titre contient SH-312 afin que Sharkly relie la PR à la Tâche.
4. Arrêtez-vous au point de validation. L'Agent ne fusionne pas. Il joint le résumé des modifications, la sortie des tests réussis et les limites connues, puis laisse SH-312 en attente de revue humaine. Le travail est revenu dans la Tâche.
5. Révisez. Une personne ouvre SH-312, lit le diff et les preuves dans une même vue, et remarque que le correctif touche un utilitaire de requête partagé. Elle laisse un commentaire demandant une modification plus ciblée. Sur une Tâche dont l'Assigné Agent est prêt, ce commentaire relance l'exécution : la boucle de demande de modifications reste ainsi consignée au lieu de repartir dans une conversation privée.
6. Acceptez et fusionnez. La seconde exécution passe la revue. La personne approuve la pull request, la fusionne et déplace SH-312 vers Completed. Comme la fusion ne clôture pas automatiquement la Tâche, l'acceptation et la fusion constituent deux décisions humaines consignées, et non une seule cascade automatique.

Chaque étape de cette chaîne reste inspectable par la suite, ce qui est tout l'intérêt d'un flux de travail traçable des exigences au code : vous pouvez répondre à « qui a approuvé ceci, et sur quelles preuves ? » sans fouiller dans l'historique de défilement de quelqu'un.

Où ne pas placer de point de validation

Multiplier les points de validation n'est pas automatiquement plus sûr : cela ajoute des frictions qui habituent les gens à cliquer sans lire. Placez un point de validation là où le coût d'une fusion erronée est réel. Pour une modification petite, bien définie et à faible risque confiée à un seul Agent, l'arrêt avant fusion suffit, et vous n'avez pas besoin d'ajouter un Crew ni des étapes d'approbation supplémentaires. Renforcez la revue quand le rayon d'impact est important : code partagé, migrations, tout ce qui touche à l'authentification ou à la facturation.

Le seul point de validation que vous ne supprimez jamais, c'est celui de la fusion. Un Agent peut explorer, écrire, tester et proposer toute la journée. Que sa modification atteigne votre branche principale est une décision humaine, et elle doit le rester même lorsque l'Agent a raison la plupart du temps. Associez la revue au niveau de la tâche de Sharkly à votre protection de branche existante pour que la plateforme fasse respecter ce que le flux de travail prévoit, et gardez les outils que votre équipe utilise déjà : connectez GitHub et assignez le ticket à un agent IA sans reconstruire votre processus.

Si vous faites déjà tourner plusieurs agents de codage et que vous perdez le fil entre ce qui a terminé, ce qui a échoué et ce qui vous attend, cette colonne de revue est la raison d'essayer Sharkly. Faites passer vos agents existants par cette colonne et gardez la décision de fusion là où elle doit être prise.

FAQ

Sharkly peut-il empêcher un agent de fusionner tout seul ? Oui. La fusion d'une pull request ne change pas le statut d'une Tâche dans Sharkly : une exécution se termine donc sur « en attente de revue humaine » plutôt que sur une modification mise en production. Associez cela à la protection de branche GitHub pour imposer les revues obligatoires au niveau du dépôt.

Quelle est la différence entre le statut de tâche et l'état de l'agent ? Le statut de tâche est la catégorie du cycle de vie (Backlog, Started, Completed, etc.). L'état de l'agent, c'est ce que fait l'exécution à l'instant présent : en train de travailler, en attente d'une réponse humaine, en attente de revue, ou en erreur. Une Tâche peut rester In Progress pendant que l'Agent vous attend.

Faut-il un Crew pour chaque tâche soumise à revue ? Non. Pour un travail petit et bien délimité, assignez la Tâche à un seul Agent et utilisez le point de validation avant fusion. Réservez le Crew aux objectifs qui nécessitent un Agent chef d'orchestre coordonnant plusieurs membres.