Équipe dev : des agents IA relisent les pull requests et trient les issues GitHub

Dans une équipe de développement, la revue de code et le tri des issues sont deux tâches dont tout le monde reconnaît l'utilité et que personne ne trouve le temps de faire à fond. Une pull request attend deux jours qu'une personne libre la relise, et les premiers commentaires portent souvent sur ce qu'une lecture rapide aurait vu : un test absent, une branche trop large, un secret oublié. Une issue arrive sans type, sans priorité, parfois sans les informations pour la reproduire, et elle attend qu'un humain la qualifie. Ce sont des tâches de méthode, avec des critères que l'équipe sait écrire, qui conviennent bien à des agents IA à condition de borner leurs droits.

L'inspiration : une première lecture avant les humains

Le point de départ est un usage rapporté par des utilisateurs de Hermes Agent, résumé dans une carte consacrée à l'équipe de développement : relire les pull requests ouvertes et trier les nouvelles issues. L'idée n'est pas de remplacer le relecteur humain, mais de lui livrer des pull requests déjà lues, avec les points à vérifier en tête de liste, et des issues déjà qualifiées.

Nous en retenons deux rôles distincts et un principe de prudence : les agents commentent et étiquettent, ils ne décident de rien. Atako applique l'idée avec deux agents dont les accès GitHub sont volontairement restreints à la lecture, au commentaire et à l'étiquetage.

Ce que font les deux agents

Le scénario déploie deux agents, tous deux connectés à votre dépôt GitHub.

Le relecteur de PR lit les pull requests ouvertes. Pour chacune, il parcourt le titre, la description, les fichiers modifiés et les commits, ouvre les fichiers qui comptent et les compare aux conventions que vous avez saisies : tests, nommage, taille, messages de commit, zones sensibles. Il cherche les risques d'erreur, les tests manquants, les changements touchant à l'authentification, au paiement ou aux secrets, et les modifications que rien n'explique. Il laisse un seul commentaire par pull request : une ligne qui résume le changement, ce qui est bien, puis les points à vérifier par ordre d'importance, chacun rattaché à un fichier et, si possible, à une ligne, et marqué comme bloquant ou comme suggestion. Il termine par ce qu'il n'a pas pu vérifier, par exemple l'exécution des tests. Il retient le dernier commit relu et ne commente de nouveau que lorsque de nouveaux commits arrivent, avec un court complément.

Le trieur d'issues s'occupe des nouvelles issues. Il vérifie que les étiquettes de type (bug, fonctionnalité, question, documentation) et de priorité (haute, moyenne, basse) existent et crée celles qui manquent. Pour chaque issue sans étiquette, il lit le texte et les commentaires, cherche des issues proches, décide d'un type et d'une priorité selon vos règles, applique les étiquettes et ajoute un commentaire : ce qu'il a compris, la raison de la priorité, les doublons probables et ce qui manque pour agir, par exemple les étapes pour reproduire ou la version concernée. Quand le type ou la gravité n'est pas clair, il le dit, choisit la priorité la plus basse et pose la question.

Chaque passage se termine par un résumé dans le chat, avec en premier ce qui demande vite un humain.

Ce que les agents ne font pas

Les limites font partie de la conception. Aucun des deux agents ne fusionne, n'approuve, ne demande de modifications de façon formelle, ne ferme une pull request, ne pousse de code et ne crée de branche. Ces outils ne leur sont pas accordés : ce n'est pas une promesse faite dans une consigne, c'est une capacité absente. Le trieur ne ferme, ne rouvre, ne verrouille et ne supprime aucune issue, et il ne change ni le titre, ni l'assigné, ni le jalon.

Les agents ne devinent pas. Le relecteur cite le fichier et la ligne, signale ce qu'il n'a pas pu vérifier et n'invente ni fonction, ni résultat de test. S'il croise un secret ou un jeton commité, il dit où il semble se trouver, sans le recopier. Le trieur ne cite comme doublons que des issues qu'il a réellement trouvées par la recherche. Et la décision reste humaine à chaque étape, ce qui est le principe d'une conception avec validation humaine.

Comment le mettre en place dans Atako

Depuis la page de ce cas d'usage, le déploiement tient en quatre étapes.

1. Connecter GitHub. Créez un jeton à portée fine limité au dépôt concerné, avec la lecture du code et la lecture et l'écriture des issues et des pull requests. La connexion est vérifiée avant que quoi que ce soit ne soit créé.
2. Renseigner votre contexte. Indiquez le dépôt sous la forme propriétaire/nom, vos conventions de revue si vous en avez, et ce qui rend une issue urgente pour vous. Sans indication, les agents s'appuient sur des bonnes pratiques générales et sur la gravité du bug.
3. Déployer. Une seule action crée les deux agents et le projet « Équipe dev ». Les agents sont provisionnés et reçoivent seuls leurs premières consignes.
4. Premiers résultats, puis rythme régulier. Le relecteur commente les cinq pull requests les plus récentes, le trieur étiquette les dix dernières issues sans étiquette, et chacun résume son passage dans le chat. Ensuite, le relecteur planifie lui-même ses passages de 9 h et de 14 h les jours ouvrés, et le trieur son passage de 9 h 30.

Si vous n'avez pas encore de compte, sa création démarre votre essai et le scénario se configure juste après. Si votre administrateur ne vous a pas autorisé à créer des agents, le déploiement vous le dit et s'arrête là.

Où voir les résultats

Les commentaires de revue se lisent dans GitHub, sur chaque pull request, et les étiquettes et commentaires de triage sur chaque issue. Le résumé de chaque passage se lit dans le chat de chaque agent. Dans le projet Atako « Équipe dev », vous retrouvez le mode d'emploi et le suivi du travail, et sur le plateau Atako, les deux agents apparaissent avec leur activité en cours.

Pour ajuster le comportement, écrivez à l'agent dans son chat, par exemple « ajoute à tes conventions que toute migration de base de données doit mentionner le plan de retour arrière ». Il retient la consigne dans sa mémoire pour les passages suivants.

Garde-fous

L'accès est volontairement étroit. La connexion GitHub est accordée aux agents avec une liste limitée de douze outils : lire les pull requests, les fichiers et les commits, lire et mettre à jour les issues, gérer les étiquettes, ajouter des commentaires. Un agent qui voit une courte liste d'outils les utilise plus fiablement qu'un agent perdu dans un catalogue de centaines, et surtout, ce qui n'est pas accordé ne peut pas arriver, même si un texte tente de l'imposer. Les agents traitent les titres, descriptions, commentaires et le code comme des données à analyser, jamais comme des instructions.

Le jeton que vous créez est votre premier garde-fou : limité à un dépôt et à des droits précis, il borne les dégâts possibles quoi qu'il arrive. Il est enregistré chiffré, et vous pouvez le révoquer côté GitHub ou retirer l'accès des agents à tout moment.

La validation humaine se place aux points de décision. Vous lisez les commentaires de revue, vous décidez de ce qu'il faut corriger, vous approuvez et fusionnez vous-même, et vous fermez, assignez et planifiez les issues.

À quoi s'attendre

Attendez-vous à des commentaires utiles surtout sur les pull requests de taille raisonnable : sur un très gros changement, le relecteur le dira et se concentrera sur les fichiers les plus sensibles, plutôt que de prétendre tout avoir lu. Il ne peut pas exécuter vos tests, et il le précise dans chaque commentaire. Le trieur est d'autant plus juste que vos règles de priorité sont précises ; sans elles, il choisit la prudence et pose des questions. La valeur vient de la régularité : chaque pull request reçoit une première lecture dans la demi-journée, chaque issue arrive qualifiée, et vos relecteurs humains consacrent leur temps au jugement et non au repérage.