La délégation a besoin d’un cadre
La prochaine étape utile dans le développement logiciel assisté par l’IA ne consiste pas à accorder davantage d’indépendance aux agents de codage. Il s’agit plutôt de doter la délégation humaine d’un plan de contrôle durable. La spécification Symphony d’OpenAI pour l’orchestration de Codex arrive à point nommé : au lieu de demander aux ingénieurs de superviser une multitude de sessions d’agents, le système de suivi des problèmes devient le système de référence. Le travail s’exprime sous forme de tâches. Chaque tâche peut être associée à un espace de travail d’agent. Les humains examinent les résultats, enregistrent les tâches de suivi et veillent à ce que le tableau reste aligné sur les priorités du produit. Cela peut sembler n'être qu'un détail du flux de travail, mais c'est bien plus important qu'une énième démonstration d'un modèle écrivant du code. Cela met en évidence le véritable goulot d'étranglement de l'ingénierie des agents : non pas la génération brute, mais la capacité humaine à attribuer, délimiter, observer, interrompre et accepter le travail sans perdre le fil.
C’est précisément là que la thèse de l’« humain dans la boucle » prend tout son sens. Un développeur ne peut pas « orchestrer » l’IA de manière responsable en surveillant cinq terminaux défiler simultanément tout en espérant que le bon contexte reste en mémoire de travail. Ce style de supervision n’est pas évolutif, car il traite le cerveau humain à la fois comme une file d’attente, un tableau de bord, un journal d’audit et une couche de validation. Dès que plusieurs agents fonctionnent en parallèle, une dette de coordination apparaît. Quelle tâche est active ? Qu’est-ce que l’agent a modifié ? Quelle branche contient la tentative prometteuse ? Quel échec a généré des connaissances utiles ? Quelle idée faut-il abandonner ? Si ces réponses ne se trouvent que dans les transcriptions de discussion et les tampons des terminaux, l’organisation n’a pas adopté le développement agentique. Elle a adopté le bruit agentique.
Le système de suivi des problèmes est un support plus adapté à ce travail, car il représente déjà l’intention, la responsabilité, la priorité, les critères d’acceptation et l’historique. Ce sont là les aspects humains du développement logiciel qui ne disparaissent pas lorsque la production de code devient moins coûteuse. En réalité, ils gagnent en valeur. Lorsqu’un agent se charge d’un ticket bien cerné, l’équipe peut comprendre la raison d’être du travail avant même de consulter le diff. Lorsque l’agent ouvre une pull request, les relecteurs peuvent évaluer le résultat par rapport à la tâche, et non par rapport à une vague promesse formulée dans une invite. Lorsqu’un réviseur découvre un problème architectural plus vaste, la solution n’est pas de laisser l’agent improviser à travers le code. La solution consiste à créer un nouveau ticket, à rendre le compromis visible et à décider s’il a sa place dans le plan actuel.
L'approbation devient une infrastructure du produit
La récente modification apportée par GitHub, qui permet à la révision de code de Copilot d’approuver des pull requests lorsqu’elle est explicitement activée, illustre ce même principe sous un autre angle. La fonctionnalité est désactivée par défaut et configurable au niveau de l’entreprise, de l’organisation, du dépôt et du chemin d’accès. C’est important. Ce qui est intéressant, ce n’est pas qu’un système d’IA puisse indiquer qu’une pull request semble prête. Ce qui est intéressant, c’est de savoir où se situe l’autorisation de prendre en compte ce jugement. Un dépôt peut l’autoriser pour certains chemins et pas pour d’autres. Les administrateurs peuvent le désactiver complètement. Les nouveaux commits annulent l’approbation, tout comme ils le feraient pour un réviseur humain. En d’autres termes, l’outil est utile parce que l’organisation humaine définit quand le jugement de l’outil a force de procédure.
C’est là le bon modèle pour un développement « agentique ». La révision automatisée doit réduire le temps que les humains consacrent à l’analyse mécanique, mais elle ne doit pas pour autant se substituer discrètement à la responsabilité humaine. Un agent de révision de code peut détecter des problèmes de style, une logique suspecte, des tests manquants et des failles de sécurité évidentes. Il peut constituer un premier filtrage utile avant qu’un ingénieur senior ne se penche sur le diff. Mais la question cruciale reste d’ordre humain : cette modification doit-elle exister, sous cette forme, à ce moment précis, pour ce système ? Ce jugement dépend de l’historique des incidents, des engagements pris envers les clients, des limites réglementaires, des contraintes opérationnelles et de l’orientation architecturale. Une grande partie de ce contexte n’est que partiellement consignée par écrit. Une partie est répartie entre différentes personnes. Un modèle peut aider à mettre en évidence des éléments probants, mais il ne peut assumer la responsabilité à lui seul.
Les équipes les plus prudentes considéreront donc l’approbation comme une infrastructure, et non comme une simple formalité. Elles définiront quelles actions sont réversibles, quels chemins sont sensibles, quels workflows nécessitent une confirmation humaine, et quelles modifications doivent inclure des tests qui échouent avant de réussir. Elles feront la distinction entre « l’agent peut proposer » et « l’agent peut fusionner ». Elles conserveront des journaux de décisions, et non de simples journaux de jetons. Elles résisteront également à une tentation subtile : utiliser l’automatisation pour donner à un travail risqué l’apparence d’une routine. L’intérêt d’un plan de contrôle n’est pas d’éliminer toute friction. Il s’agit d’introduire de la friction là où les conséquences le justifient.
Lorsque la génération de code devient omniprésente, la ressource rare n’est pas la saisie. C’est le jugement humain fiable appliqué à la bonne échelle.
Le comité peut empêcher la prolifération des agents
La prolifération des agents est facile à provoquer. Un développeur ouvre plusieurs sessions, demande à chacune d’explorer une solution, et reçoit un ensemble de branches, de résumés, de correctifs partiels et d’explications assurées. Une partie du travail est utile. Une partie est redondante. Une autre résout avec élégance le mauvais problème. Sans plan de contrôle, l’équipe doit reconstituer l’intention a posteriori. Cette reconstitution est coûteuse, et elle intervient souvent lors de la revue, alors que l’attention est déjà limitée.
Un tableau des tâches change la donne. Il rend le périmètre explicite avant l’exécution. Il donne à chaque tâche d’agent une raison d’être. Il crée également un espace dédié pour stocker les découvertes qui ne relèvent pas de la tâche en cours. Si un agent repère une opportunité de refactorisation d’un module partagé, cela devrait devenir une tâche candidate distincte, et non une réécriture imprévue au sein d’une correction de bogue. Si un réviseur remarque qu’un correctif dépend d’une invariante manquante, cette invariante doit devenir un critère d’acceptation ou un ticket de suivi. Cela empêche l’agent de transformer chaque observation locale en action globale. Cela évite également aux humains d’être contraints de trancher une douzaine de questions architecturales au sein d’une pull request surchargée.
C’est là que l’orchestration humaine va au-delà de la simple « révision du résultat ». L’orchestration consiste à concevoir les voies sur lesquelles les agents évoluent. Elle consiste à déterminer quelles tâches se prêtent à une exploration autonome et lesquelles nécessitent au préalable une discussion sur la conception. Elle consiste à gérer un backlog sur lequel les agents peuvent agir sans que l’ambiguïté ne se transforme en autorité accidentelle. Le développeur s’apparente moins à un dactylographe qu’à un chef d’orchestre des contraintes : il définit la partition, laisse les instruments jouer leur partition, interrompt la représentation lorsque le résultat s’écarte du cours normal et décide de ce qui doit figurer dans la version finale.
Les logiciels scientifiques montrent pourquoi la validation ne peut pas être externalisée
Le rapport de terrain d’OpenAI sur l’IA agentique dans le calcul scientifique renforce cette même leçon. Les agents peuvent accélérer les travaux de maintenance, de migration, d’optimisation et de packaging, en particulier pour les équipes disposant de capacités d’ingénierie limitées. Mais le rapport met également en évidence un défi persistant : la validation de la justesse scientifique du résultat dépend toujours du jugement humain. Cet avertissement s’applique directement aux équipes logicielles classiques. Un agent de codage peut faire passer les tests avec succès tout en ayant une mauvaise compréhension du domaine. Il peut optimiser la mauvaise métrique, conserver un bug parce que les tests existants l’intègrent, ou produire une abstraction plausible qui va à l’encontre de la manière dont les clients utilisent réellement le produit.
C’est pourquoi le système de suivi des problèmes ne doit pas se contenter d’indiquer « corriger le bug ». Il doit s’accompagner de preuves. Quel comportement est incorrect ? Quel impact sur l’utilisateur est important ? Quel test d’acceptation prouve que le bug a été corrigé ? Quelles contraintes ne doivent pas changer ? Une tâche rédigée par un humain n’est pas de la bureaucratie lorsqu’un agent l’exécute ; c’est le tableau de bord. Plus la tâche décrit précisément le résultat attendu, plus il est facile pour les agents et les relecteurs de s’accorder sur la réalité. Plus la tâche est mal formulée, plus le modèle comble les lacunes par des probabilités.
Conclusion
L’avenir du développement assisté par l’IA ne sera pas remporté par les équipes qui se contentent de faire fonctionner le plus grand nombre d’agents. Il sera remporté par les équipes qui savent où commence et où finit l’autonomie. L’orchestration de type « symphonie », les validations par l’IA et les pull requests générées par des agents convergent tous vers le même modèle opérationnel : les humains définissent le travail, les agents en exécutent des parties délimitées, les réviseurs automatisés allègent la charge mécanique, et les réviseurs humains conservent l’autorité sur les conséquences. Le système de suivi des tickets devient un plan de contrôle, car c’est là que l’intention, la priorité, les preuves et la responsabilité peuvent se rejoindre.
C’est une approche plus discrète que l’autonomie totale, mais c’est une meilleure approche d’ingénierie. La qualité logicielle n’a jamais découlé de l’activité seule. Elle résulte de décisions rigoureuses rendues visibles au fil du temps. L’IA peut augmenter la quantité de code qu’une équipe peut tenter de développer. C’est l’orchestration humaine qui détermine lesquelles de ces tentatives méritent d’intégrer le système.
