En voyant le backlog comme une file de tâches petites et bien décrites. Des agents IA peuvent prendre les tickets d’un backlog Jira un par un, construire chaque changement sur sa propre branche et ouvrir une pull request, pendant que vos équipes gardent les décisions qui comptent. Le sujet tient moins à l’agent qu’à la préparation de vos tickets.
Commencez par trier le backlog
Les agents n’ont pas besoin d’un backlog parfait, mais de tickets qu’ils peuvent mener à bien. Trier le backlog en quatre groupes avant de commencer évite la plupart des exécutions inutiles.
| Type de ticket | À confier à un agent ? | À faire d’abord |
|---|---|---|
| Résultat clair, périmètre réduit, vérifiable | Oui | Confiez-le tel quel. |
| Bonne idée, description floue | Pas encore | Précisez ce que « terminé » signifie et indiquez la zone du code. |
| Deux tâches dans un seul ticket | Non | Scindez-le en deux tickets. |
| Demande une décision de design ou de produit | Non | Faites d’abord décider une personne, puis notez la décision sur le ticket. |
Jira peut vous aider à repérer les premiers candidats. Son langage de requête, le JQL, permet d’enregistrer un filtre qui liste les tickets par statut, étiquette ou ancienneté, comme le décrit le guide JQL d’Atlassian. Commencez par un filtre sur les petits tickets déjà bien décrits.
À quoi ressemble un ticket qu'un agent peut terminer
Voici un exemple, écrit comme le ferait un product owner dans Jira. Il est petit, il dit ce que « terminé » veut dire et il indique où se situe le travail.
PAY-214 : ajouter l'export CSV à la page des factures
Résultat : un utilisateur de la finance peut télécharger la liste de factures filtrée au format CSV.
Terminé quand : le fichier a les mêmes colonnes que le tableau, respecte le filtre affiché à l'écran, et un test couvre le cas d'une liste vide.
Périmètre : la page des factures et son API. Hors périmètre : l'export PDF.
Il faut environ une minute pour l'écrire. Sans les trois dernières lignes, c'est le genre de ticket qu'un agent doit deviner, et c'est des devinettes que naissent les reprises.
Un ticket, étape par étape
Voici PAY-214 qui traverse les neuf étapes du pipeline Dutopilot : architecte, planificateur, implémenteur, contrôle, trois relecteurs, autofixer et QA. Avant la première étape, les personnes fixent une fois par projet les points de validation humaine et le ticket est pris en charge. Après la dernière, une personne met en production.
| Étape | Ce que fait l'agent | Ce que vous voyez |
|---|---|---|
| Avant les étapes : prise en charge | Lit PAY-214 et la page de conception à laquelle il renvoie, puis confirme que le ticket est prêt. | Un commentaire indiquant que le ticket est pris en charge et prêt. |
| 1. Architecte | Propose les fichiers à modifier (la page des factures et l'endpoint d'export), le flux des données et les tests à ajouter. | Le plan en commentaire. Une personne désignée le valide avant que le moindre code soit écrit. |
| 2. Planificateur | Transforme le plan validé en une liste ordonnée de tâches pour l'implémenteur. | La liste des tâches sur le ticket. |
| 3. Implémenteur | Écrit la modification sur sa propre branche dans un bac à sable isolé et ouvre une pull request. | Une branche nommée d'après le ticket et une pull request liée à PAY-214. |
| 4. Contrôle | Lance lint, build et tests, puis rend un verdict unique. | Un seul résultat de contrôle sur la pull request, au lieu d'un éparpillement de signaux. |
| 5 à 7. Trois relecteurs | Trois membres d’équipe virtuels Dutopilot distincts lisent la modification chacun de leur côté. L'un remarque que l'export ignore le filtre affiché à l'écran. | Des commentaires de relecture sur la pull request, écrits comme le ferait une personne de votre équipe. |
| 8. Autofixer | Un agent correcteur reçoit le commentaire ou le journal en échec, répare le code, et le contrôle repasse. | Un nouveau commit et un nouveau résultat de contrôle. |
| 9. QA | Quand tous les contrôles sont verts, la pull request est fusionnée dans le respect de votre protection de branche et arrive dans votre environnement de test, où la QA teste le résultat. | Le ticket passe à votre statut de test. |
| Après les étapes : mise en production | Attend une personne, puis déploie par le même pipeline. | Une demande d'approbation de la mise en production. |
Deux points attendent une personne par défaut : le plan et la mise en production. Tout ce qui se passe entre les deux tourne sans surveillance, et chaque étape écrit dans le ticket : vous lisez l'histoire après coup au lieu d'y assister.
Faire avancer beaucoup de tickets sans collisions
La difficulté d’un gros backlog n’est pas un ticket, ce sont de nombreux tickets en même temps. Donnez à chaque ticket sa propre branche, faites attendre les tickets qui dépendent d’un autre, et limitez le nombre d’exécutions simultanées à ce que votre équipe peut relire. Si deux tickets touchent les mêmes fichiers, traitez-les l’un après l’autre.
Imaginons que PAY-215 soit un bouton d'export sur le tableau de bord, qui a besoin de l'endpoint de PAY-214. Marquez-le comme bloqué par PAY-214 dans Jira : il attend, puis démarre à partir d'un code qui contient déjà l'endpoint. Deux tickets sans lien, comme un changement de texte et un nouveau rapport, avancent côte à côte sans se gêner. Avant de démarrer, chaque ticket récupère de lui-même le dernier code de votre branche principale : aucun ticket n'attend que quelqu'un mette une branche à jour à la main.
Ce que vous configurez
- Connectez votre projet Jira et votre hébergeur de code (GitHub, GitLab, Bitbucket ou Azure DevOps).
- Choisissez la partie du backlog par laquelle commencer, par exemple un label ou un filtre enregistré.
- Indiquez qui valide le plan et la mise en production, et les parties du code qui exigent un relecteur désigné.
- Connectez votre propre abonnement Claude ou Codex, ou une clé API.
La plupart des équipes lancent leur premier ticket en moins d'une semaine.
Ce que fait votre Forward Deployed Engineer
Chaque client Dutopilot a un Forward Deployed Engineer (ingénieur déployé auprès du client) : un ingénieur de Dutopilot qui travaille avec votre équipe, pas une file de support. Il n'écrit pas le code de votre produit. Il adapte le pipeline à votre façon de travailler.
- Prise en main : il connecte vos outils avec vous et choisit la première partie du backlog.
- Tickets prêts : il passe en revue les premiers tickets avec votre product owner et vous vous accordez sur un court modèle comme celui ci-dessus.
- Validations et points de contrôle : il définit quels plans et quelles parties du code exigent une personne, et lesquels non, selon la façon dont votre équipe relit réellement.
- Premiers lancements : il suit les premiers tickets avec vous et corrige tout ce qui bloque une exécution.
- Suivi : il examine avec vous les tickets bloqués et les remarques de relecture, puis assouplit ou durcit les points de contrôle selon ce que montre l'historique.
Comment Dutopilot s’y prend
Dutopilot se connecte à votre backlog Jira et le traite avec son pipeline en neuf étapes : il planifie le changement, le construit dans un bac à sable isolé, lance les tests et les contrôles qualité, le fait relire par trois relecteurs distincts, corrige ce qui échoue et fusionne dès que les accords que vous avez choisis sont réunis. Chaque étape est reportée sur le ticket : le backlog montre donc toujours où en est chacun.
Vos protections de branche et vos relectures obligatoires continuent de s’appliquer, et nous ne conservons jamais de copie de votre dépôt. Outre Jira, Dutopilot fonctionne avec Linear, Notion, GitHub Issues et Azure DevOps pour le backlog, ainsi qu’avec Slack. Le guide sur le passage d’un ticket Jira à une pull request fusionnée suit un ticket du début à la fin.
Les causes fréquentes d’un blocage
- La description n’a pas de critères d’acceptation : l’agent doit deviner ce que « terminé » veut dire.
- Le ticket mélange deux tâches : la pull request devient trop grosse pour être relue.
- Les tests sont lents ou instables : impossible de savoir si le changement fonctionne.
- Aucun approbateur n’est désigné : une pull request terminée reste en attente.
Corrigez cela dans le backlog et le taux de réussite grimpe, sans rien changer à l’agent.
Là où vos équipes gardent la main
- Avant l’écriture du code : une personne décide de l’architecture de tout ce qui est nouveau ou risqué.
- À la fusion : une personne désignée valide les changements dans les zones les plus sensibles.
- À la mise en production : elle suit votre propre processus.
Ajoutez des validations où vous le souhaitez, et retirez-les à mesure que la confiance grandit. Le guide sur le choix des étapes soumises à validation explique comment décider.
Questions fréquentes
Les agents IA ont-ils besoin d’un backlog propre ?
Non, mais chaque ticket confié à un agent doit avoir un résultat attendu clair, un périmètre réduit et un moyen de le vérifier. Laissez les tickets confus dans le backlog et triez-les d’abord.
Que se passe-t-il quand un agent est bloqué ?
Un bon paramétrage fait en sorte que l’agent le signale sur le ticket et s’arrête, au lieu de deviner. Dans Dutopilot, le ticket indique ce qui le bloque et ce qu’une personne peut faire, et une réponse d’une personne permet au travail de reprendre.
Peut-on utiliser notre propre abonnement IA ?
Oui. Dutopilot fonctionne avec votre propre compte Claude ou ChatGPT (Codex), ou une clé API, avec Claude Code, Codex, OpenCode ou Oh My Pi comme agent de code : les membres d’équipe virtuels Dutopilot travaillent donc selon les conditions et les limites que vous avez déjà.
Au bout de combien de temps le premier ticket tourne-t-il ?
La plupart des équipes lancent leur premier ticket en moins d'une semaine : vous connectez le backlog et le projet, vous pointez Dutopilot sur une partie du backlog, puis vous élargissez peu à peu.