Par Kwame Boateng

Le codage assisté par l’IA est souvent décrit comme une version plus rapide de la programmation en binôme. Cette comparaison est désormais trop restrictive. Lorsqu’un agent peut inspecter un dépôt, modifier plusieurs fichiers, exécuter des outils, générer un aperçu et ouvrir une pull request, le problème central de la collaboration n’est plus simplement : « Peut-il écrire du code ? » Il est plutôt : « Les équipes peuvent-elles voir, examiner, approuver, puis reconstituer ce qui s’est passé ? »

C’est pourquoi le changement de conception le plus important au sein des équipes logicielles assistées par des agents pourrait être le passage des prompts privés à des espaces de travail visibles. Slack Code, par exemple, est décrit comme combinant des canaux de projet avec des agents de codage, l’audit des différences de code, des aperçus HTML en direct, des flux de feedback et d’approbation, l’archivage automatique et des journaux d’audit. L’application Copilot de GitHub a également ajouté un volet « My work » pour organiser les issues et les pull requests dans plusieurs projets. Ces fonctionnalités font émerger un principe pratique : le travail d’un agent devrait moins ressembler à une réponse opaque qu’à un ensemble de modifications progressant dans un processus de production contrôlé.

La conversation n’est pas le compte rendu du travail

Une conversation avec un agent peut être utile pour explorer une idée, mais elle constitue un système de référence peu fiable. Des détails importants peuvent être enfouis dans un long fil : quels fichiers ont été modifiés, quelles commandes ont été exécutées, quelles hypothèses l’agent a formulées, ce qu’un évaluateur a rejeté et si le résultat final diffère de la première proposition.

Un espace de travail durable rend ces détails consultables. Il devrait relier la demande à un dépôt ou à un projet précis, conserver le plan de l’agent, afficher les actions des outils et les modifications de fichiers, fournir des liens vers les tests et les aperçus, et consigner la personne qui a approuvé le résultat. L’interface exacte peut varier — outil de suivi des issues, pull request, canal de collaboration ou console d’agent — mais les informations devraient subsister après la fin de la session.

Cela est important pour des raisons d’ingénierie ordinaires, et pas uniquement pour la conformité. Si un bug apparaît deux semaines plus tard, une équipe a besoin de davantage que de la différence finale. Elle peut devoir connaître l’exigence initiale, le plan généré, les éléments de preuve issus des tests, les commentaires de l’évaluateur et si un humain a explicitement accepté un compromis risqué. Un compte rendu durable raccourcit cette enquête.

Cinq couches de travail visible

Les équipes qui adoptent des agents de codage peuvent traiter chaque modification comme un petit dossier consultable. Cinq couches sont particulièrement utiles :

  1. Intention : l’issue, les critères d’acceptation, les contraintes et le périmètre demandé.
  2. Plan : l’approche proposée par l’agent avant qu’il ne modifie les fichiers. Pour une tâche non triviale, il s’agit d’un point de contrôle nécessitant une approbation, et non d’un élément décoratif.
  3. Différence : les ajouts, suppressions, modifications de dépendances, changements de configuration et ressources générées exacts.
  4. Éléments de preuve : résultats des tests, sortie du linter, contrôles de sécurité, captures d’écran et aperçu en direct ou déployable, lorsque cela est pertinent.
  5. Compte rendu de décision : commentaires des évaluateurs, modifications demandées, approbation, rejet, restauration ou travail de suivi.

L’objectif n’est pas de faire passer chaque modification devant un comité lourd. Une faute de frappe et une modification du flux de paiement ne devraient pas être soumises à des contrôles identiques. Il s’agit de rendre le niveau d’examen proportionnel à l’impact potentiel.

Les approbations devraient être liées aux actions

« Humain dans la boucle » est une expression trop vague pour constituer un contrôle utile. Une personne peut approuver un plan sans voir la différence résultante, ou approuver une modification de code sans remarquer que l’agent a également modifié un fichier de déploiement. De meilleurs flux de travail précisent ce que l’approbation autorise.

Par exemple, une équipe peut autoriser automatiquement un agent à lire un dépôt et à exécuter des tests locaux, exiger une approbation avant toute écriture en dehors d’une branche désignée, puis exiger une approbation distincte avant la fusion ou le déploiement. Un agent pourrait proposer une migration de base de données, tout en étant interdit de l’exécuter en production. L’approche proposée par les Émirats arabes unis pour classer les tâches que les agents peuvent accomplir par rapport à celles qu’ils peuvent seulement recommander reflète ce schéma plus large : l’autonomie devrait être attribuée tâche par tâche, et non supposée globalement.

Les approbations doivent également avoir un périmètre et une date d’expiration. Une approbation pour « mettre à jour le texte de la page d’accueil » ne devrait pas autoriser silencieusement l’ajout d’un nouveau package d’analytique. Un plan approuvé hier ne devrait pas automatiquement couvrir une différence substantiellement modifiée aujourd’hui. L’interface devrait rendre ces limites visibles.

Les aperçus transforment l’examen en inspection

La revue de code est souvent plus facile lorsque les personnes peuvent inspecter le résultat plutôt que le déduire des fichiers sources. Un aperçu HTML en direct peut révéler des espacements incorrects, des états manquants, des contrôles inaccessibles ou une modification involontaire de la navigation qu’un évaluateur pourrait ne pas remarquer dans une différence textuelle.

Les aperçus ne constituent pas une preuve de correction. Ils devraient être placés à côté des tests et de l’examen du code source, et non les remplacer. Mais ils créent un objet commun de discussion : un évaluateur peut désigner un écran, un état ou une interaction précis et laisser un commentaire attaché à la modification proposée.

Cela est particulièrement précieux lorsque des non-spécialistes participent à l’examen. Un chef de produit peut ne pas être en mesure d’évaluer une modification du framework, mais être la personne adéquate pour confirmer que le flux de travail correspond à l’exigence. Un designer peut valider une régression visuelle. Un spécialiste de la sécurité peut se concentrer sur les autorisations et la gestion des données. L’espace de travail assisté par un agent peut orienter chaque question vers la personne la mieux placée pour y répondre.

Les différences ont besoin de contexte, pas seulement de couleurs

Une différence familière en rouge et vert reste essentielle, mais les modifications générées par un agent peuvent être suffisamment étendues pour submerger un évaluateur. Les équipes devraient demander aux agents de maintenir les commits ou les groupes de modifications dans un périmètre restreint, d’expliquer pourquoi chaque fichier important a été modifié et d’identifier séparément les fichiers générés ou provenant de fournisseurs.

Les questions utiles pour une revue comprennent :

  • Quel comportement visible par l’utilisateur a changé ?
  • Quels fichiers ont été modifiés uniquement pour prendre en charge l’implémentation ?
  • Quelles hypothèses l’agent a-t-il formulées concernant le comportement existant ?
  • Quels tests ont été ajoutés, modifiés ou non exécutés ?
  • Cette modification pourrait-elle avoir une incidence sur les autorisations, la conservation des données, la facturation ou les API externes ?

Ces questions transforment la revue, qui n’est plus une demande vague consistant à « y jeter un œil », en un examen reproductible. Elles contribuent également à mettre au jour un mode d’échec courant : une fonctionnalité plausible accompagnée d’une mise à jour incomplète des tests ou d’une modification accidentelle de la configuration.

Archiver le raisonnement qui compte

Préserver chaque jeton de chaque conversation avec un modèle n’est pas automatiquement utile. Les historiques longs peuvent être coûteux à stocker et difficiles à parcourir, tandis que les recherches sur la condensation du contexte avertissent que les résumés peuvent perdre des informations importantes. Une piste d’audit pratique devrait donc préserver les éléments pertinents pour les décisions plutôt que de tout enregistrer sans discernement.

Au minimum, conservez la demande, le plan approuvé, le diff final, les résultats des outils et des tests, la référence de prévisualisation ou de déploiement, les décisions des réviseurs et toute exception accordée. Si un agent a utilisé des sources externes ou récupéré des documents internes, consignez les références aux sources pertinentes ainsi que le moment où elles ont influencé la modification. Pour les travaux à haut risque, il peut être justifié de conserver l’intégralité des interactions et du journal d’exécution.

Rendez les enregistrements détectables en cas de falsification lorsque les enjeux l’exigent, et définissez les règles de conservation avant qu’une crise ne survienne. Une piste d’audit qui disparaît lorsqu’un canal est archivé — ou qui ne permet pas de distinguer un résultat modifié du résultat original — ne permettra pas de mener une enquête sérieuse.

Ce que cela change pour les carrières dans le logiciel

La compétence émergente ne consiste pas simplement à rédiger de meilleurs prompts. Elle consiste à concevoir un travail qu’une autre personne peut inspecter et auquel elle peut faire confiance. Les développeurs devront savoir définir des critères d’acceptation, décomposer les tâches, examiner des diffs à grande échelle, concevoir des tests pertinents et décider à quel moment un agent doit s’arrêter et demander des précisions.

Les professionnels des produits et du design joueront un rôle accru dans l’examen des prévisualisations et la clarification de l’intention. Les ingénieurs QA peuvent contribuer à définir les étapes d’approbation et les cas d’échec. Les responsables de l’ingénierie devront mesurer le débit sans récompenser la prise de risques invisible. Les rédacteurs techniques et les spécialistes des opérations peuvent contribuer en rendant les décisions, les exceptions et les runbooks pérennes.

Un exercice utile consiste à prendre une fonctionnalité courante et à cartographier sa chaîne de preuves : demande, plan, branche, diff, tests, prévisualisation, approbation, mise en production et restauration. Demandez-vous ensuite à quel endroit un futur coéquipier serait contraint de deviner. Chaque supposition est une candidate pour un meilleur espace de travail, une autorisation plus claire ou un enregistrement plus durable.

Une règle de fonctionnement simple

Laissez les agents avancer rapidement dans un cadre visible et réversible. Donnez-leur un espace de travail défini, limitez les actions sensibles, exigez une approbation aux étapes importantes, associez les preuves à la modification et conservez la décision finale. L’objectif n’est pas de ralentir l’automatisation jusqu’à ce qu’elle ressemble au développement manuel. Il est de rendre la rapidité compatible avec la responsabilité.

Dans le développement assisté par des agents, le meilleur collaborateur n’est pas le système qui produit le plus de code de manière isolée. C’est le système dont le travail peut être compris, remis en question, approuvé, annulé et utilisé pour tirer des enseignements.