Les agents peuvent écrire davantage de code, mais ils ne doivent pas prendre de décisions seuls
Le tournant dans le développement assisté par l’IA ne réside pas dans la génération de code, mais dans la manière dont l’équipe décide de ce qui sera validé. Les agents sont déjà capables de rédiger des fonctions, de proposer des corrections, de réécrire des tests, de résumer les différences et d’ouvrir des pull requests qui semblent irréprochables à première vue. C’est utile, mais cela ne supprime pas le travail de coordination. En effet, plus l’agent produit rapidement des résultats, plus l’équipe doit définir avec précision la frontière entre ce que l’agent peut faire de son propre chef et ce qui doit rester une décision humaine. GitHub l’exprime clairement : une invite vous donne un résultat ponctuel, tandis qu’un workflow fiable nécessite des vérifications, du contexte et des contrôles. Dans la pratique, cela signifie que le développeur ne disparaît pas. Il devient celui qui conçoit le système de livraison, et pas seulement la ligne de code.
Cette idée est trop souvent présentée comme une question de productivité, alors qu’il s’agit en réalité d’une question de gouvernance. Lorsqu’une équipe confie une tâche à un agent, elle ne se contente pas de déléguer la vitesse de frappe. Elle délègue une partie de l’intention, du contexte, de la séquence de travail et de la responsabilité du résultat. Si le périmètre est flou, l’agent comble les lacunes avec tout ce qu’il peut déduire. Si les autorisations sont trop larges, il peut apporter des modifications qui passent les tests mais qui rompent l’architecture, un contrat d’API ou une hypothèse métier que seul un humain pourrait connaître. Un workflow adéquat ne cherche pas à faire en sorte que le modèle « fasse ce qu’un humain ferait, mais plus rapidement ». Il vise à rendre la délégation explicite, délimitée et réversible.
La nouvelle unité de contrôle est la règle de révision
OpenAI a concrétisé ce principe dans son article sur les règles personnalisées de révision de code pour Codex. Certains commentaires reviennent sans cesse : préserver une ancienne API, éviter d’enregistrer les données clients, ne pas renommer un symbole qui alimente un autre service, ou respecter une contrainte locale que les nouveaux contributeurs ne peuvent en aucun cas deviner. La leçon est simple : si les relecteurs répètent la même explication, c’est que cette explication mérite d’être consignée par écrit. Placez-la à proximité du code, dans un fichier tel que AGENTS.md, et vous transformerez ainsi les connaissances orales en une interface lisible à la fois par les humains et par les agents.
Ce changement est important car il fait remonter la révision en amont. Au lieu d’espérer qu’un modèle « comprenne » l’historique d’un dépôt, vous encodez les invariants qui comptent réellement : la rétrocompatibilité, les limites des données, les restrictions d’accès, les conventions de sécurité et les chemins de secours acceptables. Une bonne règle de révision n’est pas un roman. Elle est courte, ciblée et exploitable. Elle indique ce qui ne doit pas changer, pourquoi c’est sensible et quelle alternative plus sûre est acceptable. C’est exactement ce dont les agents ont besoin lorsqu’ils travaillent sur une base de code qu’ils ne connaissent pas encore bien. Et c’est exactement ce que les humains veulent revoir lorsqu’ils révisent une modification proposée par l’automatisation.
Le piège ici serait de transformer les règles en bureaucratie. Si tout devient une règle, plus rien n’a de poids. Les meilleures règles protègent une décision dont l’erreur coûterait cher. Elles traitent de la compatibilité, des données, de la sécurité, des effets secondaires ou d’exceptions véritablement problématiques. Elles ne remplacent pas les tests ; elles complètent ce que les tests ne peuvent pas exprimer. Les tests détectent les régressions déterministes. Les règles de révision rappellent à chacun ce qu’un diff d’apparence propre ne doit tout de même pas faire, même lorsque la compilation est réussie.
Les pull requests volumineuses ne sont pas un avantage ; elles représentent un coût cognitif
Le deuxième changement provient de la structure même du travail. Dans son article sur les pull requests empilées, GitHub souligne qu’un agent hautement productif pousse naturellement les équipes vers des diff gigantesques. C’est compréhensible : si un modèle peut accomplir en un seul passage ce que plusieurs humains feraient par étapes, il a tendance à regrouper tout en une seule pull request. Le problème n’est pas d’ordre esthétique. Il est d’ordre mental. Une révision ne s’améliore pas simplement parce qu’elle traite davantage de lignes par minute. Elle s’améliore lorsque chaque couche de modification reste suffisamment petite pour être comprise, validée et corrigée sans perdre le fil.
La décomposition aide à maintenir les humains dans la boucle précisément parce qu’elle préserve l’orientation. Chaque couche possède son propre objectif, sa base, son ensemble de révision et ses vérifications. Vous pouvez lire le bas de la pile avant le haut, laisser des contrôles déterministes s’exécuter à chaque couche et attribuer les bonnes parties de la modification aux bonnes personnes. Une couche qui touche au modèle de données ne nécessite pas le même jugement qu’une couche qui touche à l’interface utilisateur ou au câblage des agents. En d’autres termes, la pile n’est pas seulement une technique d’organisation. C’est un outil de compréhension. Elle empêche la requête de pull (PR) gigantesque de masquer la véritable décision.
Cela s’avère encore plus utile lorsque les équipes intègrent des agents dans de véritables flux de travail. Un agent peut tout à fait gérer le tri des incidents, la synchronisation de la documentation ou la maintenance à faible risque. Mais dès que la portée de la modification s’élargit, la structure de livraison doit rendre le raisonnement visible. Sans cela, on se retrouve avec une machine qui produit beaucoup, mais que personne ne peut réviser correctement. La vitesse augmente, mais la qualité des décisions diminue.
Le rôle du développeur évolue, mais la responsabilité ne disparaît pas
L’argument le plus séduisant concernant les agents est que le développeur « devient un orchestrateur ». Cette description est juste, mais elle peut facilement prêter à confusion. Orchestrer ne signifie pas applaudir l’autonomie du modèle et se mettre en retrait. Cela signifie choisir le contexte, limiter la portée des répercussions, définir les points d’arrêt et décider où l’approbation humaine reste obligatoire. GitHub décrit cela comme un « plan de contrôle » : les agents gèrent les tâches ambiguës et fortement dépendantes du contexte, tandis que des vérifications déterministes — lint, tests, build, sécurité — prennent le relais avant toute fusion. Cela fonctionne parce que la machine ne décide pas de tout ; elle s’inscrit dans une chaîne où certaines étapes sont mécaniques et d’autres nécessitent un jugement.
Une autonomie utile, des limites visibles. C’est la règle qui fait défaut dans de nombreuses démonstrations tape-à-l’œil. Un agent peut aider à faire avancer une tâche plus rapidement, mais la question importante reste la suivante : qui est responsable si la modification est erronée ? Qui confirme qu’une exception est acceptable ? Qui décide qu’une suite de tests réussie ne suffit pas parce que le code modifie un comportement métier que les tests ne couvrent pas ? Tant que ces réponses restent du ressort de l’humain, le système a une orientation claire. Dès qu’elles sont implicitement transférées au modèle, on ne parle plus d’orchestration, mais d’aveuglement.
Dans la pratique, il convient de distinguer deux types de tâches. Le premier est général, répétitif, parfois exploratoire : préparer une migration, proposer une refactorisation, synchroniser les tests et la documentation, ou rédiger un premier jet. Le second est délicat : approuver une modification rompant la compatibilité, élargir les autorisations, intervenir sur un parcours de paiement, modifier un contrat externe ou accepter une exception de sécurité. Les agents excellent dans le premier type de travail. Les humains doivent garder le contrôle du second.
Ce qu’un référentiel doit consigner explicitement
Un référentiel qui souhaite utiliser sérieusement des agents doit transformer les habitudes tacites en instructions visibles. Cela ne nécessite pas un règlement de cinquante pages. Il suffit de quelques règles bien choisies, rédigées à un endroit où les agents et les réviseurs peuvent les consulter au bon moment. En pratique, un bon point de départ ressemble à ceci :
- des règles de domaine dans
AGENTS.mdou un fichier équivalent, placé à proximité du code qu’elles régissent ; CODEOWNERSafin que la responsabilité de la révision soit explicite ;- des branches protégées et des validations obligatoires pour les modifications à haut risque ;
- des vérifications déterministes obligatoires : tests, lint, compilation, analyse de sécurité ;
- des règles de repli claires : quand l’agent doit s’arrêter et faire appel à un humain ;
- des consignes de compatibilité ou de migration pour les interfaces et contrats publics.
L’essentiel n’est pas la liste en elle-même, mais le fait qu’elle soit régie par des règles. Celles-ci doivent être courtes, testées sur des différences réelles, et supprimées si elles génèrent trop de bruit. Une règle utile modifie réellement le processus de révision. Si vous pouvez la supprimer sans changer le comportement du réviseur, c’est qu’elle est probablement trop faible ou trop vague. À l’inverse, si une règle continue de se déclencher pour le même risque majeur, c’est qu’elle a mérité sa place dans le référentiel.
Quand faut-il encore dire « non » à l’agent ?
Il existe des situations où la meilleure utilisation d’un agent consiste à le laisser préparer le terrain, puis à redonner les commandes à un humain avant que quoi que ce soit ne soit validé. C’est la bonne approche pour les modifications impliquant des données sensibles, des autorisations, des clés, des secrets, des migrations irréversibles, des chemins de secours ou des contrats qui s’étendent au-delà du référentiel. C’est également la bonne approche lorsque le code semble correct mais que l’intention ne l’est pas : un test peut afficher un résultat positif même si la modification introduit une ambiguïté au niveau du produit, un risque de non-conformité ou un comportement que les opérateurs ne peuvent accepter.
L’automatisation doit réduire les frictions, et non diluer la responsabilité.
Le rôle de l’humain ne se limite donc pas à corriger les erreurs des agents. Il consiste à définir les exceptions, à interpréter les signaux faibles et à garder le contrôle sur les changements de périmètre. Plus les agents deviennent performants dans la production de code, plus l’équipe doit faire preuve de discipline pour encadrer cette production. Ce n’est pas un recul. C’est le prix normal à payer pour un système plus puissant.
Un modèle simple pour une équipe qui souhaite avancer sans se perdre
Si une équipe souhaite adopter cette approche sans se noyer dans la bureaucratie, elle peut commencer par un tout petit workflow concret. Choisissez une tâche bien délimitée — synchronisation de la documentation et des tests, une correction à faible risque ou le triage des tickets — puis définissez le niveau d’autonomie de l’agent, les limites d’autorisation et la validation à laquelle il doit satisfaire. Écrivez une ou deux règles AGENTS.md pour les invariants que vous répétez sans cesse. Demandez ensuite à l’agent de travailler sur une pull request ou un ensemble de pull requests suffisamment restreint pour rester lisible, avec des vérifications déterministes requises avant toute révision humaine.
- Commencez petit et de manière ciblée, et non avec un assistant polyvalent.
- Notez les règles que les relecteurs appliquent déjà systématiquement.
- Veillez à ce que les modifications restent suffisamment modestes pour ne pas nuire à la compréhension.
- Laissez les tests et la sécurité bloquer ce qui peut l’être automatiquement.
- Réservez l’approbation humaine aux changements de contexte, de risque ou de portée.
- Réviser les règles lorsqu’elles deviennent du bruit plutôt qu’un signal.
Ce modèle est délibérément dépourvu de glamour. C’est précisément pour cela qu’il fonctionne. Il confère à l’IA un rôle utile sans lui accorder de souveraineté. Il réduit les frictions sans diminuer la vigilance. Et il permet à une équipe d’augmenter sa capacité de livraison sans perdre de vue les raisons pour lesquelles un changement doit être accepté ou rejeté.
Le véritable avantage des agents réside dans l’échelle du travail humain, et non dans la disparition du jugement humain
Si l’on examine les workflows les plus performants aujourd’hui, le message est assez cohérent. Les agents gagnent en capacité ; les équipes les plus performantes deviennent plus explicites. Elles rédigent leurs règles, fractionnent leurs pull requests, protègent leurs branches et désignent une seule personne chargée de donner le feu vert final. Les gains de vitesse sont réels, mais ils apparaissent plus clairement lorsque l’autonomie s’inscrit dans un système que les humains comprennent encore. C’est là que l’IA apporte une réelle aide : elle accélère l’exécution, pas l’abdication.
Dans la pratique, l’objectif ne devrait pas être de « faire en sorte que l’IA fasse notre travail à notre place ». Il devrait être de « faire en sorte que l’IA fonctionne dans un cadre que nous comprenons et acceptons ». Les équipes qui réussissent le mieux avec les agents seront probablement celles qui acceptent une vérité simple : on peut déléguer beaucoup de code, beaucoup de tâches répétitives et beaucoup de préparation. On ne délègue pas la responsabilité finale. Tant que cette limite reste claire, les agents restent des amplificateurs. Dès qu’elle s’estompe, ils ne deviennent qu’une source supplémentaire de complexité.
