Quand on a commence a utiliser des assistants IA pour coder, on les faisait tourner un par un, sur un seul fichier, en sequentiel. Aujourd'hui, sur la plupart de nos missions, Singularity orchestre jusqu'a douze agents en parallele sur la meme base de code. Voici comment on a fait, ce qui casse quand on essaie naivement, et les garde-fous qu'on a du construire pour que ca tienne en production.
Pourquoi paralleliser au-dela d'un seul agent ?
Un agent IA seul, meme tres bon, est limite par la latence du modele : entre la generation de code, l'execution des tests et la revue, il passe l'essentiel de son temps a attendre. Sur un projet typique avec quinze tickets ouverts, on peut tres bien en avoir quatre qui touchent au front, trois au back, deux a l'infra, et le reste a la documentation. Ces tickets sont independants la plupart du temps. Les faire passer en serie, c'est gacher un facteur dix sur le delai de livraison.
Notre constat operationnel : sur une mission Orbital (six a dix semaines), passer d'un agent a douze agents fait tomber le temps de livraison effectif d'un facteur six a huit, pas douze. La difference va dans les frais de coordination — exactement le meme phenomene que dans une vraie equipe humaine. Mais six fois plus rapide a budget egal, c'est ce qui rend notre modele au forfait economiquement viable.
Un worktree git par agent, branche commune en aval
La premiere erreur qu'on a faite, c'est de laisser les agents committer directement sur la branche principale. Resultat : a chaque git pull, on heritait de conflits qui ne se reproduisaient pas localement. La premiere refonte serieuse de Singularity a impose une regle absolue : chaque agent travaille dans son propre git worktree, cree depuis la branche de base au moment ou son ticket est demarre.
Concretement, l'orchestrateur fait git worktree add dans un dossier ephemere, l'agent y opere comme dans un repo isole, et au moment du merge-back, l'orchestrateur rebase sur la base courante. Si le rebase casse, on traite le conflit comme un ticket a part. Aucun agent ne voit le travail des autres tant qu'il n'est pas integre. Cette isolation evite quatre-vingt-dix pour cent des collisions silencieuses qu'on avait au debut.
Un orchestrateur central, des agents stateless
Les agents eux-memes sont sans etat. Ils recoivent un ticket, un contexte (worktree, branche, contraintes) et une boucle d'execution. L'orchestrateur, lui, tient l'etat global : quel ticket est assigne a quel agent, quels worktrees sont actifs, quels merge-backs sont en attente, quelle branche est en cours d'integration. Cette separation est essentielle pour deux raisons.
Premiere raison : la reprise apres crash. Si un agent meurt en plein milieu d'un ticket — timeout du modele, OOM sur la machine, plantage du sandbox — l'orchestrateur le redemarre avec le meme contexte. Aucune information n'est perdue, le worktree est conserve, l'historique git est intact. Deuxieme raison : la deduplication des decisions. Si deux agents proposent simultanement des modifications contradictoires sur le meme fichier, l'orchestrateur en arbitre une et reaffecte l'autre apres rebase.
CI obligatoire avant chaque merge-back
Avant qu'un worktree d'agent soit integre, il doit passer la CI complete : lint, typecheck, tests unitaires, tests d'integration, et — quand applicable — tests end-to-end. Aucune exception. C'est non-negociable, meme si l'agent jure que tout fonctionne en local. Cette discipline a un cout : la CI tourne souvent, et la facture cloud associee n'est pas symbolique. Mais c'est exactement ce filet de securite qui nous permet de faire confiance a une integration automatique, sans revue humaine systematique sur les tickets simples.
Sur les tickets sensibles — modification de schema base de donnees, migration de pipeline CI, changement de protocole d'API — la revue humaine reste obligatoire avant le merge-back. C'est l'orchestrateur qui decide, en fonction de tags qu'on a poses sur les tickets. Les agents proposent, l'humain dispose, exactement comme on l'avait imagine au debut du projet.
Trois garde-fous qu'on a appris a la dure
Premier garde-fou : la detection des processus de test en arriere-plan. Plusieurs fois on a vu un agent lancer une suite de tests, croire qu'elle a echoue (parce qu'un autre processus tenait le port), et committer une "correction" inutile. Avant chaque run de tests, Singularity verifie qu'aucun processus de test du meme projet ne tourne deja. Si oui, il attend ou il signale l'incident a l'orchestrateur.
Deuxieme garde-fou : interdiction absolue de contourner les git hooks. Pas de --no-verify, pas de HUSKY=0, pas de suppression de .husky/. Si un hook echoue, le commit n'a pas eu lieu — il faut corriger la cause racine et relancer. Cette regle a permis d'eliminer une categorie entiere de regressions silencieuses qu'on avait sur les premieres versions de l'ADE.
Troisieme garde-fou : aucune action destructrice sans confirmation. git reset --hard, git push --force, suppression de branches, rm -rf — l'orchestrateur intercepte et demande l'aval d'un associe. Les agents sont autonomes pour creer, modifier et committer, jamais pour effacer. Cette regle parait severe mais elle a deja sauve plusieurs heures de travail sur des incidents qui auraient pu etre tres graves.
Bilan : douze agents, un seul produit coherent
Apres dix-huit mois d'iteration sur cette architecture, les chiffres parlent d'eux-memes : sur nos missions Orbital, le temps moyen de livraison est passe de huit semaines a deux semaines et demi pour un perimetre equivalent. Le nombre de bugs en production ne s'est pas degrade — au contraire, la CI obligatoire et la couverture de tests systematique l'ont fait baisser. L'IA n'a pas remplace nos developpeurs : elle a deplace leur role, de l'ecriture de code vers la supervision et l'arbitrage.
Le plus surprenant, c'est ce qu'on n'avait pas anticipe : les associes-experts de Meteor Factory passent maintenant plus de temps a faire de la revue de code et de l'architecture qu'a ecrire du code. C'est plus rentable, plus interessant, et c'est exactement ce a quoi devrait servir l'expertise senior. Le modele tient en production, on continue de l'iterer ticket apres ticket.