Le nouveau problème ne se limite plus au simple code généré
Les équipes de développement entrent dans une phase où les contributions impliquent de plus en plus souvent un agent à un moment ou à un autre du processus. La question n’est plus seulement : faut-il utiliser l’IA pour coder ? Elle devient beaucoup plus opérationnelle : comment garder le contrôle lorsque des pull requests, des corrections de tests, des mises à jour de documentation et des propositions de refactorisation peuvent être générées avant même qu’un responsable de maintenance n’ait reconstitué le contexte ? Il s’agit d’un changement de rythme, mais aussi d’un changement de gouvernance.
Un article récent du blog GitHub consacré aux contributeurs « AI-first » décrit clairement cette évolution du point de vue de l’open source. Les responsables de maintenance, comme l’équipe AutoGPT, ne se demandent plus si les agents vont ouvrir des pull requests. Ils partent du principe que ces contributions existent déjà et organisent le dépôt de manière à ce qu’elles soient utiles, vérifiables et rejetables. La réponse intéressante ne consiste pas à fermer la porte à toute contribution assistée. Elle consiste à déplacer les règles vers les endroits que les agents inspectent réellement : fichiers d’instructions, modèles de pull requests, exigences de test, vérifications CI, conventions de résolution des commentaires et limites d’accès.
Cela revêt une importance particulière pour OrkestrAI et pour toute équipe souhaitant déléguer davantage de travail sans pour autant déléguer la responsabilité. Un agent peut accélérer la production d’un diff, mais il ne connaît pas l’historique des incidents, les compromis liés au produit, les risques juridiques, les contraintes des clients, ni les raisons pour lesquelles une architecture a été acceptée malgré ses imperfections. Ce sont toujours les humains qui détiennent ce contexte. Le référentiel doit donc devenir un environnement qui aide l’agent à effectuer le travail mécanique tout en rendant impossible l’effacement de la décision humaine.
Le dépôt devient une interface de gestion
Dans un workflow traditionnel, le dépôt stockait principalement du code, des tests, de la documentation et des règles d’intégration continue (CI). Avec les agents, il devient également une interface de gestion. Les instructions ne sont plus rédigées uniquement à l’intention des nouveaux arrivants humains ; elles doivent être lisibles par des outils qui exploreront le projet, modifieront des fichiers, exécuteront des commandes et proposeront des mises à jour. C’est la logique qui sous-tend des fichiers tels que AGENTS.md, les consignes spécifiques à un répertoire ou les compétences spécialisées qui expliquent comment tester, documenter ou répondre à une révision.
L’erreur serait de croire qu’un long document de politique suffit. Les agents sont littéraux, rapides et parfois très persuasifs lorsqu’ils se trompent. Une règle enfouie dans un wiki interne ne protège rien si l’agent ne la charge jamais lorsqu’il modifie le code. Une convention de révision ne protège rien si elle n’est pas liée au modèle de pull request, aux vérifications obligatoires ou à une action concrète qu’un responsable de maintenance peut vérifier. Une bonne pratique consiste à rapprocher les règles du lieu d’exécution : près du module concerné, au sein de la pull request, au sein de l’intégration continue (CI), au sein des autorisations, au sein des tests et au sein des critères de fusion.
Cela modifie également le rôle des ingénieurs seniors. Leur travail ne consiste plus seulement à réviser ligne par ligne. Il s’agit de concevoir le système de délégation : quelles tâches l’agent peut-il effectuer seul ? Quelles commandes nécessitent une validation ? Quelles données ne doivent jamais quitter l’environnement ? Quelle preuve de test est acceptable ? Quel type de modification doit être rejeté même si le diff semble correct ? L’ingénieur senior devient à la fois architecte, réviseur, responsable qualité et concepteur de garde-fous.
Les bonnes barrières de sécurité sont visibles et vérifiables
Les exemples évoqués par GitHub sont révélateurs. Exiger un modèle complet de pull request peut sembler banal, mais c’est un levier puissant lorsqu’il oblige l’auteur, qu’il s’agisse d’un humain ou d’un agent, à préciser son intention, la portée de son travail et son plan de test. Une pull request générée par une IA qui ne précise pas comment elle a été vérifiée mérite un niveau de confiance différent de celui d’une pull request accompagnée d’un scénario reproductible. Le plan de test n’est pas de la bureaucratie : c’est la trace minimale qui permet au réviseur de comprendre ce qui a été testé, ce qui ne l’a pas été, et sur quoi il faut concentrer son attention.
Une autre mesure de protection utile consiste à faire de l’intégration continue (CI) une règle impérative, et non une simple suggestion. Lorsque les seuils de couverture, les tests critiques, le linting ou les analyses de sécurité sont obligatoires, l’agent peut proposer des corrections, mais il ne peut pas redéfinir ce que signifie « prêt ». C’est là une différence fondamentale. Dans un workflow fragile, l’agent génère un diff convaincant et l’humain doit deviner ce qui manque. Dans un workflow régulé, l’agent génère un diff, le dépôt applique ses règles, puis l’humain évalue les domaines que les règles ne peuvent pas couvrir : l’architecture, l’adéquation au produit, la lisibilité, la maintenabilité et le risque opérationnel.
Les responsables de maintenance mentionnent également des détails très concrets, comme l’exigence d’un commit spécifique avant qu’un fil de discussion de révision puisse être clôturé. Ce genre de règle peut sembler insignifiante, mais elle répond à un comportement réel : certains agents peuvent marquer une conversation comme clôturée sans avoir réellement corrigé le code. Le contrôle humain n’est donc pas un slogan philosophique. Il s’agit d’un ensemble de petits verrous observables qui empêchent les raccourcis dangereux de se transformer en fusion.
L’examen d’une pull request générée par un agent nécessite une liste de contrôle différente
Un deuxième article de GitHub souligne que les pull requests générées par des agents sont déjà suffisamment nombreuses pour affecter la capacité de révision. Le risque principal ne réside pas toujours dans un code manifestement défectueux. Le risque provient souvent d’un code qui semble complet. Un agent peut reproduire des schémas, ajouter des fonctions auxiliaires, respecter la nomenclature existante, combler des lacunes apparentes et rédiger une explication plausible. Mais il peut passer à côté de la raison profonde d’une contrainte, dupliquer une logique déjà existante, ignorer un cas limite connu de l’équipe ou oublier une vérification d’autorisation sur une branche d’exécution rarement utilisée.
La révision humaine doit donc commencer par l’intention : quel problème cette pull request prétend-elle résoudre, et le diff prouve-t-il réellement cette compréhension ? Viennent ensuite les limites : entrées vides, limites de taille, autorisations, erreurs réseau, migrations, compatibilité, accessibilité, performances et retour en arrière. Viennent enfin les preuves : existe-t-il un test qui échoue avant la modification et qui réussit après celle-ci ? Le scénario manuel est-il reproductible ? Des journaux ou des captures d’écran utiles sont-ils joints ? L’auteur humain comprend-il suffisamment bien la modification pour la défendre en production ?
Cette liste de contrôle permet d’éviter deux extrêmes. Le premier consisterait à rejeter toute contribution assistée en la considérant comme du bruit. Cela reviendrait à gaspiller une véritable capacité d’exécution, notamment pour les tâches répétitives, la documentation, les tests, les corrections mineures et l’analyse de régression. Le second serait d’accepter la rapidité comme gage de qualité. Une équipe mature fait le contraire : elle étend le champ d’application de l’automatisation tout en renforçant les points de contrôle où le jugement est nécessaire.
Les workflows « agentic » ne remplacent pas le CI/CD
Les workflows « agentic » de GitHub illustrent cette même orientation. L’idée est de décrire les tâches du dépôt en Markdown et de laisser les agents les exécuter au sein de GitHub Actions : triage, rapports quotidiens, amélioration des tests, documentation ou simplification ciblée. Le message le plus important n’est pas que tout peut être automatisé. C’est que l’automatisation par agents doit compléter le CI/CD, et non le remplacer. Les pipelines déterministes restent essentiels pour la compilation, les tests, l’analyse et la mise en production. Les agents sont plus utiles pour les tâches ambiguës, répétitives et contextuelles qui préparent le travail humain.
Cette distinction évite aux équipes une confusion courante. Un agent peut ouvrir une pull request de documentation après avoir détecté une modification de l’API. Il peut proposer un test couvrant une branche négligée. Il peut résumer l’état d’un dépôt le matin. Mais la décision de publier, de modifier une politique de sécurité, de modifier un contrat public ou de supprimer une compatibilité doit rester inscrite dans un cadre de gouvernance explicite. L’automatisation accélère la préparation ; elle ne doit pas se substituer à la prise de décision.
Dans la pratique, chaque organisation devrait classer les tâches en trois groupes. Premièrement, les tâches que l’agent peut exécuter et proposer avec un risque limité, telles qu’un projet de note ou une analyse initiale. Deuxièmement, les tâches que l’agent peut préparer mais qui nécessitent une révision humaine obligatoire, telles qu’une refactorisation ou une correction de bogue. Enfin, les tâches que l’agent ne doit pas exécuter sans autorisation préalable, telles que les opérations impliquant des informations confidentielles, les modifications d’infrastructure, les migrations irréversibles ou les actions de mise en production.
Ce que les équipes peuvent faire dès maintenant
La première mesure consiste à expliciter les règles du dépôt. Si les humains doivent expliquer verbalement à chaque nouveau venu comment tester un module, l’agent ne le saura pas non plus. Documenter les commandes de test, les invariants métier, les modules sensibles, les schémas interdits et les critères de révision n’est plus seulement une question de bonne pratique. C’est une condition pour que la délégation assistée ne se traduise pas par une charge de travail supplémentaire pour les réviseurs.
La deuxième mesure consiste à exiger des justificatifs pour chaque contribution. Une pull request assistée par l’IA doit comporter un périmètre clair, la liste des fichiers modifiés, un plan de test, les limitations connues et les points sur lesquels l’auteur humain a revu le résultat. Si un agent a apporté son aide, ce n’est pas un problème ; le préciser aide en fait les relecteurs à s’adapter. Mais l’auteur humain doit rester responsable du résultat. La mention « généré par l’IA » ne doit jamais servir de prétexte pour déposer un diff que personne ne comprend.
La troisième mesure consiste à mettre en place des contrôles de sortie. Les tests obligatoires, la couverture minimale, les règles de sécurité, la protection des branches, les paramètres par défaut en lecture seule et les validations explicites réduisent le nombre de décisions improvisées. Ils offrent également aux agents un cadre plus clair : ceci est autorisé, cela échoue, ceci nécessite une intervention humaine. Les meilleures barrières de sécurité ne ralentissent pas l’équipe ; elles évitent que le même débat ne se répète à chaque pull request.
Conclusion : l’agent exécute, l’équipe gouverne
L’illustration historique du premier bug informatique est un rappel utile : dès le début, les logiciels se sont améliorés lorsque les humains ont rendu les erreurs observables. Les agents de codage ne changent pas cette règle. Ils ne font que rendre la boucle plus rapide et plus dense. Plus il devient facile de produire un correctif, plus il devient essentiel de savoir qui décide, quelle preuve est requise, quelles limites s’appliquent et comment le système empêche un raccourci de passer inaperçu.
Pour une équipe moderne, maintenir les humains dans la boucle ne signifie pas ralentir l’IA. Cela signifie concevoir un environnement où l’IA peut apporter son aide sans confondre rapidité et autorité. Le référentiel devient le lieu où les règles sont codées, l’intégration continue (CI) devient le premier filtre, la revue humaine devient l’espace de jugement, et la mise en production reste une décision responsable. C’est cette combinaison, bien plus que la génération de code en elle-même, qui fera la différence entre une expérience brillante et une pratique d’ingénierie durable.
