Du ticket à la PR
Quand un bogue ou une tâche est déposé, un agent IA rassemble le contexte, rédige le correctif, fait rouler les tests et ouvre une proposition — qu'un humain révise, jamais fusionnée toute seule.
Pensez à un apprenti dans un atelier de réparation. Un travail entre, l'apprenti sort le dossier, fait la préparation standard et étale la réparation proposée sur l'établi — puis le maître mécanicien l'inspecte avant que quoi que ce soit retourne au client. L'agent est l'apprenti; la pull request est l'établi.
Le problème, en mots simples
Un ticket est déposé — un bogue, une petite tâche. Puis il attend. Des jours passent entre « déposé » et « quelqu'un le regarde vraiment ». Et la plupart des tickets suivent des motifs que votre équipe a corrigés cent fois : mettre à jour une dépendance, calmer un test capricieux, ajouter une ligne de journal manquante, documenter un champ que personne n'a documenté. Chacun coûte quand même à un ingénieur la même mise en route — lire le ticket, trouver les bons fichiers, se rappeler les conventions, écrire le correctif, faire rouler les tests — avant même que la vraie réflexion commence.
Ce que nous mettons en place
L'agent reçoit des outils pour travailler avec votre hébergeur de code (GitHub ou GitLab, par des outils MCP à accès étroitement limité — il ne peut toucher que les dépôts qu'on lui a confiés). Il fouille la base de code et les commits récents pour le contexte, et quand le ticket vient de la surveillance, il lit la trace — l'enregistrement de l'exécution fautive. Puis il rédige le correctif sous forme de pull request (une proposition de changement qui doit être révisée avant de rejoindre le code), fait d'abord rouler la suite de tests, et publie un résumé expliquant ce qu'il a changé et pourquoi. Un humain révise et fusionne, demande des changements ou ferme. Et quand le vrai correctif n'est pas du code — un trou de documentation, une étape de procédure manquante — l'agent le dit au lieu de forcer un changement de code.
Comment ça fonctionne, étape par étape
- Un ticket est déposé
Un rapport de bogue, une petite tâche, ou une alerte sortie de la surveillance.
- L'agent rassemble le contexte
Les fichiers pertinents, les commits récents dans le secteur, et la trace quand le ticket est arrivé par une alerte.
- Il rédige un correctif
Une pull request petite et ciblée. Quand le code n'est pas la bonne réponse, il propose plutôt le changement de documentation ou de procédure.
- Les tests roulent avant que quiconque regarde
La suite de tests passe en premier : un résultat rouge n'atterrit jamais dans la file d'un réviseur.
- Il s'explique
Un résumé de ce qui a changé et pourquoi accompagne la proposition — le réviseur commence par le raisonnement, pas seulement le diff.
- Un humain décide
Réviser, fusionner, demander des changements ou fermer. Rien ne rejoint votre base de code sans surveillance.
Ce qui change pour vous
Avant : les tickets routiniers attendaient des jours le premier regard d'un ingénieur, et chaque correctif partait d'une page blanche. Après : une première tentative crédible attend souvent l'ingénieur à son arrivée, la révision part d'un brouillon, et les pull requests deviennent plus petites et plus faciles à réviser. Les tickets qui étaient en réalité des trous de documentation sont nommés comme tels tôt, au lieu de traîner en ingénierie. Ce qu'il ne fera pas : il ne fusionnera pas son propre travail — la barrière de révision humaine est le but, pas une limite — et les problèmes coriaces et inédits appartiennent encore à vos ingénieurs.