Comment Dutopilot construit Dutopilot : un produit bâti par ses propres agents

La plupart des entreprises qui vendent des outils de livraison logicielle construisent leur propre produit à l'ancienne, puis vous demandent de faire confiance à l'outil. Nous faisons l'inverse. Le produit de Dutopilot est construit par Dutopilot. Son dépôt est connecté au service hébergé exactement comme le serait celui d'un client. Les tickets se trouvent sur un tableau de projet, et des agents les planifient, les construisent, les relisent, les testent, les corrigent et les fusionnent. Chaque fusion dans la branche main se déploie en production.

Cet article montre comment cela fonctionne concrètement : la configuration, ce qui arrive à un ticket, comment des dizaines de changements, venus de personnes et d'agents, arrivent chaque jour sur la même branche main sans faire la queue les uns derrière les autres, ce qui se passe quand quelque chose casse, et ce que font encore les personnes de notre côté. Il présente aussi ce que nous avons mesuré, et ce que nous avons appris et que vous pouvez appliquer dans votre propre équipe.

Un mot sur ce qu'est Dutopilot, pour que la suite soit claire. Dutopilot est à la fois un service managé et un logiciel en tant que service. C'est une couche au-dessus des agents de code : il exécute Claude Code, Codex, OpenCode et Oh My Pi sur votre propre compte d'IA, sur une infrastructure cloud dédiée, et chaque client dispose d'un Forward Deployed Engineer qui le met en place autour de votre backlog et reste à vos côtés. Chaque agent est un membre d'équipe virtuel Dutopilot, et chacun peut exécuter des centaines de sous-agents en parallèle, sur tous les plans. Vous gardez le tableau de projet que vous utilisez déjà. Les agents font le travail de livraison.

Pourquoi construire le produit avec lui-même

Il y a trois raisons, et la première n'est pas du marketing.

La première raison est l'honnêteté. Un outil de livraison qui n'a jamais porté le travail de son propre créateur n'a pas été testé sur le client le plus exigeant qui soit : celui qui change d'avis tous les jours, dépose des tickets vagues, fusionne dans la précipitation et remarque chaque minute perdue. Quand notre propre produit attend une relecture bloquée, nous le ressentons l'après-midi même. Cette pression est une meilleure suite de tests que toutes celles que nous pourrions écrire exprès.

La deuxième raison est la vitesse du retour d'expérience. Quand un agent cale, tourne en boucle ou produit un changement que nous n'accepterions pas, la personne qui peut corriger Dutopilot est celle qui vient de ressentir le problème. Aucune file d'assistance ne sépare la douleur de la réparation. Un défaut que nous repérons devient tout de suite un ticket sur le tableau, et le correctif suit par le même pipeline.

La troisième raison est une preuve que vous pouvez inspecter. Quand nous disons que le pipeline tient face à de nombreux changements simultanés, nous décrivons notre propre dépôt, où des personnes et des agents fusionnent toute la journée dans la même branche main. Nous ne décrivons pas un projet de démonstration conçu pour faire bonne impression.

Rien de tout cela ne signifie que chaque client doit s'attendre à notre configuration exacte. Les clients choisissent leurs propres validations, leur propre tableau et leurs propres dépôts. Ce qui se transpose, c'est la méthode : un ticket entre, un changement vérifié et fusionné en sort, et une personne n'intervient qu'aux validations qui comptent pour vous.

La configuration : un tableau, un dépôt et un partage clair du travail

La configuration est volontairement simple, car un client doit pouvoir la reproduire.

Le tableau de projet

Tout travail commence par un ticket sur un tableau de projet. Le tableau est l'endroit où les personnes disent ce qu'elles veulent : une nouvelle capacité, un correctif, un changement de texte. Un ticket est écrit en langage courant, comme vous briefieriez un collègue. Il n'a pas besoin d'être une spécification. S'il manque quelque chose d'important, l'étape de planification pose la question.

Le dépôt

Le code du produit vit dans un seul dépôt, que le service Dutopilot hébergé lit et modifie grâce à une autorisation, comme il le ferait pour un client. Notre dépôt n'a aucune porte dérobée. Si une étape fonctionne pour nous, elle fonctionne par le même chemin que celui de votre dépôt.

Chaque changement est un petit travail distinct qui va directement sur la branche main. Nous ne gardons ni branches d'intégration de longue durée ni gros changement de livraison combiné à la fin. Des morceaux plus petits donnent des relectures plus petites, des annulations plus faciles et aucun embouteillage où une pièce en retard en bloque dix terminées.

Ce que font les personnes et ce que font les agents

Le partage est simple à énoncer. Les personnes décident de ce qui vaut la peine d'être fait et des endroits où un humain doit dire oui. Les agents font le travail de livraison entre les deux.

• Les personnes : rédigent et priorisent les tickets sur le tableau, répondent aux questions qu'un agent n'a pas pu trancher seul, valident les étapes qu'elles ont choisi de garder derrière une validation humaine, et prennent les décisions produit.
• Les agents : clarifient le ticket, le planifient, le découpent quand il est gros, écrivent le code et les tests, relisent le travail les uns des autres, lancent les contrôles qualité, réparent les échecs, fusionnent et déploient.

Derrière tout cela se trouvent vos comptes d'IA. Dutopilot exécute Claude Code, Codex, OpenCode et Oh My Pi sur votre propre abonnement ou votre propre clé, si bien que le coût du travail d'IA va sur un compte que vous contrôlez et que vous voyez exactement où il part. Les agents de votre plan ne passent pas par un seul goulet étroit. Chaque agent du plan se comporte comme un membre d'équipe virtuel Dutopilot qui peut confier des parties d'une tâche à autant de sous-agents en parallèle que le travail l'exige.

La vie d'un ticket, étape par étape

Voici ce qui arrive à un ticket, du moment où il est prêt jusqu'à sa mise en ligne. Un ticket traverse neuf étapes au total : architecte, planificateur, implémenteur, contrôle, trois relecteurs, correcteur automatique et QA. Nous décrivons le parcours dans l'ordre où vous le verriez. Les sept étapes numérotées ci-dessous regroupent ces neuf étapes, et les huit cartes de l'image montrent le même parcours.

1. Clarification et planification

Quand un ticket est marqué prêt, un agent le lit avec les parties du dépôt qu'il touche. Sa première mission n'est pas d'écrire du code. Sa première mission est de vérifier que le ticket peut être construit : l'objectif est-il clair, y a-t-il une contradiction, manque-t-il une décision que seule une personne peut prendre ?

Si le ticket est clair, un agent architecte et un agent planificateur le transforment en plan : quoi changer, dans quel ordre, ce qui pourrait mal tourner et comment savoir que cela a fonctionné. Un gros ticket est découpé en tickets plus petits, chacun pouvant être construit, relu et livré seul. Ce découpage compte : les petits tickets se terminent plus vite et coûtent moins cher à relire, et un problème sur l'un ne bloque pas les autres.

S'il manque quelque chose que seule une personne peut décider, l'agent pose la question, en termes simples, sur le ticket. Une réponse dans les mots de la personne suffit. Personne n'a à apprendre de formules particulières.

2. Construction dans un sandbox isolé

La construction a lieu sur une infrastructure cloud dédiée, dans un sandbox créé pour ce seul ticket. Le sandbox reçoit une copie neuve du dépôt, fait le travail, puis est détruit. Rien de l'exécution d'un ticket ne peut fuiter vers un autre.

Dans le sandbox, un agent de code (Claude Code, Codex, OpenCode ou Oh My Pi, sur votre compte) écrit le changement et les tests qui l'accompagnent. Comme le travail est réparti entre des sous-agents, l'un peut traiter les données pendant qu'un autre s'occupe de l'écran et qu'un troisième écrit les tests, le tout dans le même sandbox. Avant d'écrire quoi que ce soit, le sandbox fusionne la dernière version de la branche main dans sa copie de travail. Nous revenons sur l'importance de ce moment dans la section sur le travail à grande échelle.

3. Relecture indépendante

Quand la construction est terminée, le changement est ouvert sous forme de pull request, la manière habituelle de proposer un changement à la relecture. Les relecteurs sont des agents distincts qui n'ont pas écrit le code. Ils lisent le changement avec un regard neuf, le comparent au ticket et au plan, et cherchent les erreurs, les cas oubliés, les raccourcis risqués et les modifications qui s'éloignent du ticket.

Séparer le relecteur de l'auteur répond à la même logique qu'avec des personnes. Un auteur lit ce qu'il voulait écrire. Un relecteur lit ce qui est réellement là.

4. Contrôles qualité

En parallèle de la relecture, une série de contrôles qualité s'exécute. Un contrôle est une vérification automatique avec un résultat clair, réussi ou échoué : les tests, les vérifications de types et de style, un contrôle que le changement touche bien ce que le plan annonçait, et des vérifications sur des sujets comme la sécurité et l'apparence des pages.

5. La boucle d'auto-réparation

Quand un relecteur trouve un problème ou qu'un contrôle échoue, le ticket ne retourne pas à une personne. Il passe à une étape de réparation. Un agent correcteur lit l'échec exact, modifie le code et renvoie le changement dans la relecture et les contrôles. Cette boucle se répète tant qu'elle progresse. Si le même échec revient sans progrès, l'approche change au lieu de réessayer la même chose, et si le problème reste insoluble, le ticket s'arrête avec une explication claire qu'une personne peut exploiter.

6. Fusion

Quand tous les contrôles sont au vert et que la relecture est propre, le changement est fusionné dans main. La fusion se fait en squash, donc chaque ticket devient une seule entrée nette dans l'historique, facile à lire et facile à annuler. Si vous avez choisi de garder une validation humaine avant la fusion, le ticket attend alors cette validation et dit précisément à la personne ce qu'elle approuve.

7. Déploiement

Pour notre propre produit, une fusion dans main est une mise en production : le déploiement démarre seul et met le changement en production. Le ticket n'est fermé que lorsque le travail est réellement en ligne et vérifié, pas quand la pull request est fusionnée. Si un contrôle de déploiement échoue, il est traité comme tout autre échec : il revient comme du travail pour les agents, et non comme un message qui attend qu'une personne le remarque. Sur les projets clients, le travail s'arrête en préproduction ou en test, une personne met en production, et le ticket se termine là.

Un exemple détaillé (illustratif)

Travailler à grande échelle : beaucoup de tickets, beaucoup de personnes, une seule branche main

Un seul ticket qui traverse un pipeline propre est le cas facile. Le vrai test, c'est beaucoup de tickets à la fois alors que des personnes fusionnent aussi dans le même dépôt.

Sur notre dépôt, de nombreux tickets sont en cours en même temps, chacun dans son propre sandbox, et nos propres équipes fusionnent leurs changements dans main tout au long de la journée. Chacune de ces fusions modifie l'aspect de main. Un système qui ne fonctionne que lorsqu'un seul changement avance à la fois passerait l'essentiel de sa vie à attendre. Chaque membre d'équipe virtuel Dutopilot peut exécuter des centaines de sous-agents en parallèle, sur tous les plans.

Pourquoi rien n'attend qu'une branche se mette à jour

Une règle courante dans les équipes logicielles veut qu'une branche soit à jour avec main avant de pouvoir être fusionnée. Avec quelques personnes, c'est une petite gêne. Avec des dizaines de changements qui arrivent toute la journée, cela devient un piège : dès qu'un changement est fusionné, tous les autres changements ouverts sont de nouveau périmés, et doivent être rafraîchis et revérifiés. Sous forte charge, cette boucle ne finit jamais, et les gens passent leur journée à cliquer sur des boutons de mise à jour.

Nous refusons cette règle à dessein. À la place, chaque agent fusionne la dernière version de main dans son propre travail au moment où il en a besoin : avant d'écrire du code, puis juste avant les contrôles finaux. L'agent établit lui-même que son travail est compatible avec le main actuel, au lieu d'attendre que quelqu'un rafraîchisse sa branche.

Si main a bougé pendant le travail et que les deux changements ne se touchent pas, rien de plus n'est nécessaire. S'ils entrent en collision, l'agent résout le conflit dans sa propre copie, relance les contrôles et continue. Le coût est payé par le seul changement qui est entré en collision, et uniquement quand cela arrive. Tous les autres continuent d'avancer.

La même idée s'applique à toute ressource partagée

Nous appliquons le même test à tout ce que plusieurs changements partagent : le pool de sandboxes, le nombre de requêtes que nous pouvons envoyer à l'hébergeur de code, les comptes d'IA, la file de travail. Les questions sont toujours les mêmes. Cela fonctionne-t-il encore avec des dizaines d'auteurs à la fois ? Chaque attente se termine-t-elle d'elle-même ? Le coût de chaque cycle croît-il avec la quantité de travail actif, plutôt qu'avec la taille de tout le backlog ?

Une conception correcte pour un ticket à la fois, mais qui cale ou exige une personne quand de nombreux tickets arrivent, est pour nous une mauvaise conception, aussi sûre qu'elle paraisse. C'est le premier test que doit passer chaque décision sur notre propre produit, et c'est la raison pour laquelle la configuration tient quand un client connecte un dépôt très actif.

Le nombre de tickets qu'un compte d'IA peut porter figure plus bas, dans « Les chiffres d'aujourd'hui ».

Quand les choses tournent mal

Des choses tournent mal dans tout pipeline de livraison. Un test déjà instable échoue, un service est brièvement indisponible, un agent comprend mal un ticket, un changement entre en collision avec un autre. Ce qui compte, c'est ce qui se passe ensuite, et si une personne doit d'abord s'en apercevoir.

D'abord l'auto-réparation

La plupart des échecs sont traités par la boucle de réparation décrite plus haut. Un contrôle échoué est lu, compris et corrigé par un agent, puis revérifié. Sur nos premiers projets clients, les agents ont réparé 150 échecs d'étape par eux-mêmes (les chiffres figurent dans la section dédiée). Chacun de ces cas est un moment où, dans une configuration plus classique, une personne aurait dû remarquer un build rouge, comprendre à qui revenait le problème et courir après un correctif.

Les défauts que Dutopilot détecte en lui-même deviennent des tickets

Dutopilot surveille son propre comportement. Quand il détecte un défaut en lui-même, par exemple un ticket qui attend sans raison, ou une étape qui échoue toujours de la même façon, il signale le problème sous forme de ticket sur son propre tableau de projet, étiqueté pour qu'il soit clair qu'il vient du système. Ce ticket est ensuite planifié, construit, relu et fusionné par les mêmes agents, comme n'importe quel autre. La boucle du schéma en haut est réelle : le comportement en production revient sur le tableau, puis dans le changement suivant.

C'est aussi pourquoi nous faisons confiance à la configuration de notre propre dépôt. Un problème ne vit pas dans la mémoire de quelqu'un ni dans un fil de discussion. C'est un ticket, avec un responsable, un plan et un statut.

Quelques exemples réels de défauts que Dutopilot a signalés contre lui-même puis corrigés. Il a déposé lui-même un signalement indiquant qu'une boucle du planificateur s'était bloquée, et l'a corrigée. Le tableau de bord a un jour dit à un client de corriger sa configuration alors que la panne venait de Dutopilot, et il l'a corrigé pour désigner la bonne partie.

Des arrêts qu'une personne peut résoudre seule

Parfois, la bonne action est de s'arrêter et de demander. Une décision manque, un choix a des conséquences, ou une validation que vous avez choisie demande un humain. Quand Dutopilot s'arrête, nous l'astreignons à un standard que nous appelons le libre-service : la personne qui lit la notification doit pouvoir résoudre l'arrêt seule, sans documentation et sans notre aide.

• Le message dit en termes simples ce qui s'est passé, avant tout détail technique.
• Elle dit à qui revient le problème : leur changement, ou la configuration.
• Elle propose la seule chose qu'ils peuvent faire. Quand il existe une option par défaut raisonnable, elle la prend et le leur dit, avec un moyen simple d'annuler.
• Une réponse dans les mots de la personne fonctionne. Il n'y a ni commande spéciale ni modification manuelle de quoi que ce soit.

Le détail technique (le nom du contrôle, le réglage concerné) vient en dernier, pour l'administrateur. Une notification qu'il faut raccourcir perd d'abord le détail technique, jamais l'explication claire.

Ce que font encore les personnes

Une automatisation qui prétend que les personnes sont inutiles n'est pas crédible, et ce n'est pas ce que nous avons construit. Les personnes font encore les trois choses que seules des personnes peuvent faire.

• Choisir le travail. Ce qui va sur le tableau, dans quel ordre, et ce qui ne vaut pas la peine d'être fait. La priorité est une décision métier. Un agent peut estimer l'effort. Il ne peut pas savoir ce dont votre marché a besoin ce trimestre.
• Valider là où vous l'avez choisi. Vous décidez quelles étapes restent derrière une validation humaine : un plan, une maquette, une fusion, une mise en production. Une validation que vous choisissez est une vraie validation. Les agents l'attendent et disent précisément à la personne ce qu'elle approuve. Les étapes que vous n'avez pas choisies sont décidées par Dutopilot quand il est confiant, avec une trace claire et un moyen simple d'annuler.
• Prendre les décisions produit. Si une fonctionnalité existe, comment elle doit se ressentir, quel compromis accepter. Les agents transforment ces décisions en logiciel qui fonctionne. Ils ne remplacent pas le jugement qui les sous-tend.

Le résultat est une autre façon de vivre la journée de travail. Les personnes consacrent leur temps aux décisions et aux priorités. Elles lisent de courtes explications plutôt que de longs diffs. Elles cessent de surveiller les builds.

Les chiffres

Les chiffres ne servent que s'ils sont précis sur ce qu'ils comptent. Nous donnons deux séries distinctes et ne les mélangeons pas.

Sur nos premiers projets clients

Ces chiffres proviennent de nos premiers projets clients. Ils n'ont pas été mesurés sur le dépôt de Dutopilot lui-même, et nous ne les présentons pas comme tels. Les chiffres de notre propre dépôt sont mesurés séparément et figurent dans leur propre encadré plus bas.

Depuis juin 2026

Depuis juin 2026, les agents ont fusionné 127 tickets et mené à bien 539 tâches d'agent sur nos projets clients. Ces projets sont serpent.cloud, le site web d'une société de services, et un monorepo qui combine Salesforce et une application iOS native. Les deux derniers ne sont pas nommés ici. Chaque projet a sa propre configuration et ses propres validations, et sur les projets clients le travail s'arrête en préproduction ou en test et une personne décide du moment de la mise en production. Lisez ces chiffres comme une mesure d'étendue, pas comme le rythme d'un seul projet.

Sur la version actuelle, depuis le 19 août

Une seconde série, plus restreinte, a été mesurée sur les mêmes projets clients avec la version actuelle, à partir du 19 août :

• 0.4% des commits sur les branches de travail ont été écrits par un humain. Le reste a été écrit par des agents.
• 2% des tickets ont demandé une validation humaine.
• 54 minutes : le délai médian entre le premier commit et la fusion.
• 150 échecs d'étape ont été réparés par les agents eux-mêmes.
• 9 étapes composent le parcours d'un ticket.

La faible part de tickets demandant une validation vient de la façon dont ces projets ont configuré leurs validations. C'est un réglage, pas un plafond. Si vous voulez une personne à chaque fusion, vous pouvez l'avoir, et les chiffres seront alors différents, par choix.

Ce que nous avons appris, pour votre équipe

Voici les enseignements tirés de cette façon de travailler, valables pour toute équipe qui veut confier le travail de livraison à des agents.

Écrire les tickets pour un collègue compétent

La qualité du résultat suit la qualité du ticket. Un ticket qui énonce l'objectif, à qui il s'adresse et comment vous saurez qu'il a fonctionné est bien construit. Un ticket qui dit « améliorer le tableau de bord » reçoit d'abord une question de clarification. C'est un bon résultat, et c'est moins cher qu'une mauvaise construction.

Garder chaque changement petit

Les petits tickets passent la relecture plus vite, échouent moins souvent et sont faciles à annuler. Quand un travail est volumineux, l'étape de planification le découpe. Ne luttez pas contre ce découpage. Un gros changement est un risque que vous porteriez sinon pendant des jours.

Faire relire par des agents distincts

L'agent qui écrit le code ne doit pas être celui qui l'approuve. Une relecture indépendante détecte les erreurs que l'auteur ne voit pas, et ses constats vont directement dans la boucle de réparation au lieu d'atterrir sur le bureau d'une personne.

Faire des contrôles du code ordinaire

Tout ce qui a une réponse claire, comme savoir si un test a réussi ou si un fichier a changé, doit être décidé par un logiciel ordinaire, pas par l'avis d'un modèle. Réservez les modèles aux tâches de jugement : lire un changement, décider s'il correspond au ticket.

Concevoir pour beaucoup de monde dès le premier jour

Un pipeline rapide pour un ticket mais bloqué à dix n'est pas rapide. Testez chaque règle dans le cas chargé : pas d'attente qu'une branche soit à jour, pas de créneau partagé jamais libéré, pas d'attente qui exige une personne pour se terminer.

Choisir ses validations humaines avec soin

Décidez quelles étapes demandent une personne et rendez ces validations réelles. Tout le reste doit avancer seul, avec une trace claire. Une validation choisie mais facile à contourner apprend aux gens à les ignorer.

Traiter un arrêt comme un message à un client

Chaque fois que le système s'arrête, rédigez la notification comme si elle serait lue par une personne qui n'a jamais entendu parler de l'outil. Si elle ne peut pas agir seule, la notification n'est pas terminée.

Ce que cela signifie pour votre équipe

Vous n'avez pas besoin de faire tourner une configuration comme la nôtre pour en profiter. La version pratique est une version managée.

Vous gardez votre tableau de projet et vos dépôts. Dutopilot s'y connecte (Jira, Linear, Notion, GitHub Issues ou Azure DevOps pour le backlog ; GitHub, GitLab, Bitbucket ou Azure DevOps pour le code ; Slack pour les notifications), et votre propre compte d'IA paie le travail d'IA, donc le coût reste entre vos mains. Les agents tournent sur une infrastructure cloud dédiée que nous gérons, et chaque ticket a son propre sandbox. Chaque membre d'équipe virtuel Dutopilot de votre plan peut orchestrer des centaines de sous-agents en parallèle, sur tous les plans. Le nombre de tickets en cours suit le nombre de membres d'équipe virtuels Dutopilot de votre plan (Solo jusqu'à 3, Team jusqu'à 15, Enterprise sans limite) et vos validations. Les plans sont facturés par membres d'équipe virtuels Dutopilot, pas par utilisateurs : toute votre équipe peut utiliser Dutopilot.

Le Forward Deployed Engineer

Chaque client dispose d'un Forward Deployed Engineer, un ingénieur de notre côté qui travaille avec vous plutôt qu'un service d'assistance derrière lequel vous faites la queue. Il connecte votre tableau et vos dépôts, lit votre code et vos conventions, met en place les contrôles et les validations que vous voulez, et règle les agents sur votre façon de travailler. Il reste aussi après le lancement : il observe comment vos premiers tickets avancent, ajuste là où les agents bloquent, et vous aide à décider quand assouplir ou durcir une validation.

Concrètement, vous obtenez des membres d'équipe virtuels Dutopilot et un ingénieur qui sait les faire travailler dans votre code, plutôt qu'un outil à apprivoiser seul. Le meilleur premier pas est modeste : un projet, quelques tickets et les validations avec lesquelles vous êtes à l'aise.

Questions fréquentes

Dutopilot construit-il vraiment Dutopilot ?

Oui. Le dépôt du produit lui-même est connecté au service Dutopilot hébergé, comme celui d'un client. Les tickets de son tableau de projet sont planifiés, construits, relus, testés, corrigés et fusionnés par des agents, et chaque fusion dans main se déploie en production.

Des personnes interviennent-elles malgré tout ?

Oui. Les personnes choisissent le travail, valident les étapes qu'elles ont décidé de garder derrière une validation humaine, et prennent les décisions produit. Les agents font le travail de livraison entre ces moments.

Que se passe-t-il quand un agent se trompe ?

Un relecteur ou un contrôle qualité le détecte, puis un agent correcteur le répare et le renvoie dans les contrôles. Si le problème ne peut pas être résolu, le ticket s'arrête avec une explication claire, qu'une personne peut exploiter seule.

Puis-je utiliser la même configuration sur mon propre backlog ?

Oui. Vous gardez votre tableau de projet et vos dépôts, et Dutopilot exécute Claude Code, Codex, OpenCode et Oh My Pi sur votre propre compte d'IA. Un Forward Deployed Engineer le met en place autour de votre backlog et des validations que vous voulez.

Comment de nombreux tickets et de nombreuses personnes fusionnent-ils dans une seule branche main ?

Chaque agent fusionne la dernière version de main dans son propre travail au moment où il en a besoin, au lieu d'attendre que sa branche soit rafraîchie. Ainsi, aucun changement n'attend un autre, et un dépôt très actif continue d'avancer.