Totaux, sur les trois projets clients : 127 tickets fusionnés et 539 tâches d’agents exécutées depuis juin 2026.
Version actuelle, mesurée à part depuis le 19 août : 0.4% de commits humains sur les branches et 2% des tickets ayant besoin d’une validation humaine, sur les mêmes projets clients.
Rapidité : une médiane de 54 minutes entre le premier commit et la fusion, sur la même version actuelle et les mêmes projets clients.
Le défi
Dutopilot livre des projets clients avec le pipeline qu’il vend. Tous les chiffres de cette page ont été mesurés sur trois projets clients : le site d’une société de services Salesforce, le site de serpent.cloud, et un monorepo qui contient du code Salesforce et du code iOS natif. Aucun n’a été mesuré sur le dépôt de Dutopilot lui-même. L’objectif : laisser les membres d’équipe virtuels Dutopilot porter le travail de livraison courant et réserver les décisions aux personnes du client.
Avant le pipeline, le travail courant d'un ticket reposait sur des personnes : l'une écrivait le plan, une autre construisait la modification, relisait la pull request, relançait les vérifications en échec et cliquait sur fusionner. Ce travail est nécessaire, et il est surtout répétitif.
Avant et après
| Étape | Avant | Maintenant |
|---|---|---|
| Plan | Une personne l'écrit. | Un agent le propose. Une personne le valide quand le changement est nouveau ou risqué. |
| Construction | Une personne. | Un agent, sur sa propre branche. |
| Vérifications | Une personne les attend et relance les échecs. | Un seul verdict global. Les échecs vont directement à un agent correcteur. |
| Revue | Une personne de votre équipe, quand elle a le temps. | Des membres d’équipe virtuels Dutopilot distincts comme relecteurs, sur chaque pull request. |
| Fusion | Une personne clique sur le bouton. | La pull request se fusionne toute seule quand tout est vert, sous protection de branche. |
| Mise en production (sur ces projets clients) | Une personne décide. | Une personne décide toujours. |
Comment ça marche
Chaque ticket du tableau de projet passe par neuf étapes : architecte, planificateur, implémenteur, contrôle, trois relecteurs, autofixer et QA. Autour d’elles, les personnes fixent une fois par projet les points de validation humaine, le pipeline prend en charge le ticket avant la première étape, et une personne met en production après la dernière. Ces trois points ne sont pas des étapes. Le ticket montre où il en est.
- Architecte : propose un plan au niveau des fichiers, les flux de données et un plan de tests avant d'écrire le moindre code. Une personne le valide quand la modification est nouvelle ou risquée.
- Planificateur : transforme l’architecture validée en une liste ordonnée de tâches pour l’implémenteur.
- Implémenteur : écrit la modification sur sa propre branche.
- Contrôle : lance les vérifications automatiques sur la pull request et rend un seul verdict.
- Premier relecteur : un agent distinct lit la modification de son côté.
- Deuxième relecteur : un autre agent distinct lit la modification indépendamment.
- Troisième relecteur : un troisième agent distinct lit la modification indépendamment.
- Autofixer : répare ce qu'une vérification ou un relecteur a relevé, puis le contrôle repasse.
- QA : la modification est fusionnée vers staging ou test, et la QA teste le résultat.
Sur ces projets clients, le travail fusionné arrive dans l’environnement de préproduction ou de test, et une personne met en production. Dutopilot construit aussi son propre produit de la même façon.
Un ticket, du tableau à la fusion
Voici un ticket illustratif des projets de sites web, pour montrer ce que produit chaque étape : "Ajouter un filtre par secteur à la page des études de cas".
| Étape | Ce qui se passe |
|---|---|
| Ticket | Une personne produit l'écrit avec le résultat attendu et ce à quoi ressemble « terminé », puis le marque prêt. |
| Architecte et planificateur | L'architecte publie les fichiers qu'il va modifier et les tests qu'il va ajouter, et le planificateur liste les tâches. Une personne valide, car cela change le comportement d'une page. |
| Implémenteur | L'implémenteur construit la modification sur sa propre branche et ouvre une pull request. |
| Contrôle | Lint, build et tests s'exécutent. Un test échoue. |
| Autofixer | L'autofixer reçoit le journal de l'échec, corrige le code, et le contrôle passe à l'exécution suivante. |
| Relecteurs | Les relecteurs laissent des commentaires. L'autofixer y répond et les vérifications repassent. |
| QA | La pull request est fusionnée vers staging ou test et la QA teste le résultat. |
| Mise en production (une personne) | Sur ces projets clients, une personne met en production. |
Sur la version actuelle, le délai médian entre le premier commit et la fusion est de 54 minutes.
Quand quelque chose échoue
Les échecs sont normaux, le pipeline les anticipe. Une vérification en échec ou une remarque de revue repart vers un correcteur, avec le journal ou le commentaire exact. Un test qui échoue au hasard est relancé et réparé, pour ne pas bloquer un travail correct. Depuis le 19 août, le pipeline a réparé 150 échecs d'étape tout seul. Quand une correction n'avance plus, ou que le risque augmente, l'exécution s'arrête et le ticket sollicite une personne.
Résultats
| Mesure | Résultat | Période et périmètre |
|---|---|---|
| Tickets fusionnés | 127 | Depuis juin 2026, sur les trois projets |
| Tâches d’agents exécutées | 539 | Depuis juin 2026, sur les trois projets |
| Commits humains sur les branches | 0.4% | Version actuelle, depuis le 19 août |
| Tickets ayant demandé une validation humaine | 2% | Version actuelle, depuis le 19 août |
| Délai médian entre le premier commit et la fusion | 54 minutes | Version actuelle, depuis le 19 août |
| Échecs d’étape réparés par le pipeline | 150 | Version actuelle, depuis le 19 août |
Toutes les lignes viennent des trois projets clients. Les deux premières lignes sont des totaux sur toute la période. Les autres lignes sont mesurées sur la version actuelle uniquement, il ne faut donc pas comparer les deux groupes entre eux.
Ce que font encore les personnes
- Décider de l’architecture de tout ce qui est nouveau ou risqué avant d’écrire du code.
- Valider les changements dans les zones où une erreur coûte cher.
- Décider de la mise en production, sur ces projets clients.
- Répondre quand un ticket s’arrête et demande une décision.
Les validations sont votre choix. Le guide sur le choix des étapes soumises à validation montre comment les équipes les paramètrent.
Concrètement : une personne produit écrit et ordonne les tickets, un ingénieur valide les plans et les changements sensibles, et un responsable de livraison décide des releases. Le reste du temps, personne n'a à surveiller, et le ticket dit quand une personne est nécessaire.
Chaque client a un Forward Deployed Engineer
Un Forward Deployed Engineer de Dutopilot travaille avec votre équipe dès le premier jour. Il n'écrit pas le code de votre produit. Il adapte le pipeline à votre façon de travailler.
- Mise en route : il connecte vos outils avec vous et choisit la première tranche du backlog.
- Tickets prêts à traiter : il convient avec votre product owner d'un court modèle de ticket, pour que les agents reçoivent un travail clair.
- Validations et points de contrôle : il définit quels plans et quelles parties du code exigent une personne, selon la façon dont votre équipe relit.
- Amélioration continue : il passe en revue avec vous les tickets bloqués et les résultats, et déplace les points de contrôle à mesure que la confiance grandit.
Ce que cela change pour votre équipe
Un compte Claude Ultra livre environ 50 tickets de taille moyenne par semaine (environ 25 fichiers modifiés par ticket en moyenne), soit environ 200 par mois, quand assez de membres d’équipe virtuels Dutopilot l’utilisent. Avec Solo, la petite équipe Dutopilot (jusqu’à 3 membres d’équipe virtuels) garde un compte à environ 100 tickets par mois ; avec Team, vous obtenez environ 200 tickets par mois par compte Claude Ultra connecté. 8 membres d’équipe virtuels Dutopilot peuvent terminer environ 50 tickets en une seule journée, ce qui consomme à peu près l’allocation IA hebdomadaire d’un compte. Chaque agent d’une offre est un membre d’équipe virtuel. Chaque membre d’équipe virtuel peut exécuter des centaines de sous-agents en parallèle, sur toutes les offres, et l’offre Enterprise ne limite pas le nombre d’agents. Les offres sont facturées par membre d’équipe virtuel Dutopilot, pas par utilisateur : toute votre équipe peut utiliser Dutopilot. Dutopilot fonctionne avec Jira, Linear, Notion, GitHub Issues et Azure DevOps pour votre backlog, avec GitHub, GitLab, Bitbucket et Azure DevOps pour votre code, avec Slack, et avec Claude Code, Codex, OpenCode et Oh My Pi comme IA. Pour le voir sur une tranche de votre propre backlog, réservez un appel.