L'usine sans ouvrier¶

Un orchestrateur de développement 100 % automatisé — un système qui reçoit des tickets, lance des agents, fait tourner les tests et fusionne le code sans intervention humaine à chaque étape — ressemble davantage à une ligne de production qu'à une équipe de développeurs. Ce chapitre précise l'analogie, parce que c'est d'elle que dépend le choix des outils de contrôle.

Ce qui rapproche l'orchestrateur de l'usine¶

La partie Développement logiciel a montré que le SPC échoue sur le travail humain pour trois raisons : pièces uniques, faibles volumes, mesures hétérogènes. Un orchestrateur affaiblit les trois.

Objection au SPC logiciel	Équipe humaine	Orchestrateur d'agents
Faibles volumes	Quelques dizaines de tickets par mois	Des centaines à des milliers de runs
Pièces uniques	Chaque ticket est traité par une personne différente, d'humeur différente	Le même modèle, le même prompt et les mêmes outils traitent tous les tickets d'un type
Mesures hétérogènes	Saisies à la main, après coup	Télémétrie automatique de chaque run : tokens, durée, outils, tests
Causes identifiables	Difficile de dire « ce qui a changé » dans une équipe	Chaque run porte la version du modèle, du prompt, des skills, de l'environnement

Le dernier point est décisif. En SPC, un sous-groupe rationnel est un ensemble de mesures produites dans des conditions aussi identiques que possible, de sorte que la variation à l'intérieur du sous-groupe ne contienne que du bruit. Dans une équipe humaine, on ne sait jamais vraiment ce qui est constant. Dans un orchestrateur, on peut estampiller chaque run avec tout ce qui le conditionne, et regrouper exactement les runs produits dans les mêmes conditions.

À retenir

L'orchestrateur est le meilleur terrain du SPC qu'ait jamais connu le développement logiciel : beaucoup de runs, un « ouvrier » unique et versionné, une instrumentation gratuite. Les objections de Raczynski et Curtis perdent une grande partie de leur force — à condition de stratifier par type de tâche.

Ce qui l'en éloigne¶

Trois différences restent, et elles sont sérieuses :

La matière première varie toujours. Les tickets restent des pièces uniques. Un orchestrateur réduit la variation du producteur, pas celle des commandes. D'où l'importance de la stratification (une carte par type de tâche, par dépôt, par taille).
Le producteur peut tromper le contrôle (voir Causes spéciales propres aux agents).
Le producteur change sans prévenir : une mise à jour du modèle côté fournisseur, un défaut d'infrastructure, un changement de routage (voir le postmortem d'Anthropic).

Ce que montrent les données sur les PR d'agents¶

Le corpus AIDev¶

Le jeu de données AIDev recense les pull requests ouvertes par des agents de code sur GitHub. La version de juillet 2025 (Li, Zhang, Hassan, arXiv 2507.15003) porte sur plus de 456 000 PR de cinq agents (Codex, Devin, Copilot, Cursor, Claude Code) ; la version présentée à MSR 2026 en compte 932 791 (arXiv 2602.09185). Le constat d'ensemble du premier article : les PR d'agents « sont acceptées moins souvent », révélant un écart de confiance et d'utilité.

Des taux de fusion très dépendants de la méthode¶

Une étude de juillet 2026 (Mazloomzadeh, Morovati, Khomh, arXiv 2607.21832) estime, par un modèle à effets aléatoires par dépôt sur 9 428 PR d'agents, des probabilités de fusion de 84,3 % pour Claude, 73,5 % pour Codex, 63,9 % pour Cursor, 59,6 % pour Copilot et 43,0 % pour Devin, contre environ 85 % pour les humains. Sur un échantillon équilibré de PR fusionnées, les auteurs trouvent des taux de défauts « comparables ou inférieurs » à ceux des PR humaines, avec des différences le plus souvent non significatives.

Ces chiffres diffèrent sensiblement de ceux du corpus AIDev initial (Copilot y était autour de 35 %, chiffre lu sur une figure et à reconfirmer). La différence de méthode — sous-ensemble, période, modèle statistique — suffit à déplacer les taux de plusieurs dizaines de points.

Le taux de fusion n'est pas une mesure de qualité¶

Peralta et al. (mai 2026, arXiv 2605.22534) ont inspecté à la main 717 PR d'agents sur 11 048 PR fermées. Parmi les rejets :

35,7 % seulement sont de vrais échecs de l'agent ;
31,2 % viennent de contraintes de workflow (PR dupliquée, branche obsolète, processus du projet) ;
33,1 % n'ont pas de raison observable.

Parmi les PR fusionnées, 15,4 % ont nécessité une intervention du relecteur. Ehsani et al. (janvier 2026, arXiv 2601.15195) ajoutent que les taux de fusion sont les meilleurs pour la documentation, la CI et le build, les pires pour la performance et les correctifs, et que les PR rejetées sont plus grosses et échouent plus souvent à la CI.

Erreur fréquente : surveiller le taux de fusion

Le taux de fusion mélange la qualité du code, la politique du dépôt, la disponibilité des relecteurs et le type de tâche. Sous une carte de contrôle, il produira des signaux dont près des deux tiers ne concernent pas l'agent. C'est une mesure de résultat social, pas une caractéristique de qualité. Les caractéristiques utiles sont décrites dans le chapitre suivant.

Ce que font les éditeurs : des garde-fous structurels¶

Les principaux agents de code autonomes publient des garde-fous qui relèvent moins de la statistique que de l'architecture du contrôle :

GitHub Copilot (agent cloud) ne peut ni marquer sa PR comme prête, ni l'approuver, ni la fusionner ; la personne qui a demandé la PR ne peut pas l'approuver elle-même ; les workflows de CI ne se lancent qu'après approbation d'un humain ; il ne pousse que sur des branches copilot/ (documentation).
Claude Code en GitHub Actions n'accorde en mode automatisé aucun outil qui ne soit explicitement listé, refuse par défaut d'être déclenché par d'autres bots (« pour éviter que Claude se déclenche en boucle »), et la documentation recommande de relire les changements avant fusion (documentation).
Devin pousse dans la direction inverse : sa fonction de correction automatique répond aux commentaires de revue et itère sur les échecs de CI « sans que vous ayez besoin d'être dans la boucle » (documentation).

Lecture qualité

La règle de GitHub — celui qui commande ne peut pas réceptionner — est la séparation des tâches de l'audit et de la qualité industrielle. Aucun de ces éditeurs ne publie en revanche de consigne chiffrée d'échantillonnage (« relire X % des PR ») : le choix entre « tout relire » et « ne rien relire » est laissé à l'utilisateur. Le chapitre Échantillonnage et revue humaine propose un cadre pour cet entre-deux.