Pepper-orchestrator a réalisé trois lots en 1 heure et 52 minutes sans codage manuel

Un agent d’IA peut assez bien assembler un prototype tant qu’une personne peut garder l’intégralité du projet en tête. Ensuite apparaissent les difficultés habituelles : une modification d’API affecte un dépôt voisin, deux agents d’exécution modifient le même fichier et les tests ne valident que les hypothèses sur lesquelles le code a été écrit. Maksim Nikitin, auteur du studio ITSalt, propose de résoudre ce problème non pas en allongeant le prompt, mais en séparant les responsabilités.

Son plugin pepper-orchestrator pour Claude Code et Codex transforme un objectif important en un programme composé de petits lots de travaux. Chaque lot reçoit son propre contexte, une branche ou une copie de travail, des chemins autorisés, des dépendances et des critères d’acceptation vérifiables. L’orchestrateur n’écrit pas lui-même le code des modules : il conserve une vue d’ensemble, détermine l’ordre d’exécution et transmet le résultat à un évaluateur indépendant.

À quoi cela ressemble dans un cas simple

La démonstration consistait à créer une application destinée à un spécialiste des achats. L’utilisateur téléverse des contrats au format texte et obtient un tableau indiquant le numéro, le fournisseur, le montant et le délai de livraison. Des pièges avaient été délibérément laissés dans les documents : un acompte figurait à côté du prix, la limite « ne dépassant pas 600 000 roubles » ressemblait à un montant total et le délai de paiement pouvait être confondu avec le délai de livraison.

L’orchestrateur a décomposé le travail en trois lots : un moteur d’analyse des documents, une interface dotée d’un système de design et une note explicative. Les parties indépendantes ont été envoyées dans des copies distinctes du dépôt. Les fichiers partagés devaient être modifiés séquentiellement ; les chevauchements étaient donc visibles avant même le début du travail, plutôt qu’au moment de la fusion.

Après 1 heure et 52 minutes, les trois lots étaient officiellement terminés. L’auteur n’avait écrit aucun code à la main : il avait pris les décisions produit et arbitré les actions litigieuses. Cette précision est importante : il ne s’agit pas d’une usine logicielle autonome, mais d’un système dans lequel l’humain reste propriétaire du programme et contrôle les autorisations, la fusion et la publication.

Pourquoi des tests au vert ne suffisaient pas

La première version du moteur a réussi ses propres tests, mais un évaluateur indépendant a reformulé les clauses contractuelles et découvert trois erreurs manifestes. L’acompte était interprété comme le montant total, la limite comme le prix du contrat et le délai de paiement comme le délai de livraison. Le lot a été renvoyé pour correction, après quoi les valeurs douteuses ont été signalées comme nécessitant une vérification.

Le produit a ensuite été testé par trois « clients » distincts : un utilisateur bienveillant, un utilisateur volontairement négligent et un concurrent recherchant les cas limites. Le dernier a détecté deux autres erreurs dans l’interprétation du montant et de l’avenant en vigueur. Un déploiement sur un environnement vierge a révélé des délais d’expiration qui n’apparaissaient pas sur la machine du développeur, ainsi que six ambiguïtés dans les instructions.

L’idée d’ingénierie centrale est simple : lorsqu’un agent annonce que le travail est « terminé », il s’agit d’une déclaration, pas d’une preuve. L’agent d’exécution et l’évaluateur ne doivent pas partager exactement le même contexte, sans quoi le second hérite des hypothèses du premier. Il faut vérifier non seulement le code, mais aussi le comportement du produit : avec des données reformulées, sur une machine vierge et au moyen de scénarios représentant des utilisateurs aux intentions différentes.

Dans quels cas cette approche est réellement utile

L’orchestration se justifie lorsqu’une tâche touche plusieurs modules ou dépôts, que le travail peut être réparti par fichiers et que le résultat peut être décrit par des critères observables. Pour une petite correction, une telle architecture ne ferait qu’ajouter de la journalisation, des copies du dépôt et le coût de sessions d’agents supplémentaires.

La portée des preuves reste également limitée : les chiffres proviennent du cas personnel de l’auteur du plugin, sans comparaison avec un développement classique ni mesure indépendante de la qualité. Les 1 heure et 52 minutes ne peuvent donc pas être considérées comme une mesure universelle de l’accélération.

La conclusion pratique pour une équipe est la suivante : commencez par définir un objectif unique, les limites des lots et leurs dépendances ; séparez ensuite l’exécution de la vérification ; réservez enfin les actions irréversibles à un humain. La valeur d’un orchestrateur ne tient pas au nombre d’agents, mais au fait qu’il rend explicites l’état, les responsabilités et les critères d’acceptation.