Skip to content
PKResources
Plan de la formation

Ingénierie agentique : la formation pratique · Module 6: L’ingénierie agentique en équipe

Revue de code et responsabilité quand les agents écrivent le code

Un agent peut écrire le code, mais il ne peut pas en être responsable. Fixez une règle simple, rendez l’agent visible dans les pull requests et protégez vos réviseurs.

Leçon 22 / 24 · ⏱ 8 min

Quand les agents écrivent une part croissante du code, deux choses se dégradent sans bruit. Les auteurs ne se sentent plus responsables d’un code qu’ils n’ont pas tapé. Les réviseurs reçoivent plus de pull requests, plus grosses, et finissent par approuver sans lire.

Les deux problèmes ont la même racine : personne n’a décidé à qui appartient le code écrit par un agent. Alors décidez-le.

Une règle : qui ouvre la PR en est responsable

J’applique une seule règle dans toutes les équipes avec qui je travaille. La personne qui ouvre la pull request est responsable de chaque ligne, exactement comme si elle l’avait tapée. « C’est l’agent qui a écrit ça » n’est jamais une réponse en revue.

  1. L’auteur briefePortée et critères d’acceptation
  2. L’agent construitCode, tests, résumé
  3. L’auteur réviseAutorevue complète d’abord
  4. PR avec contexteBrief, carte, questions ouvertes
  5. Revue par un pairJugement humain, pas une relance

↺ Ce que la revue trouve retourne à l’auteur, qui re-briefe l’agent ou corrige à la main

L’auteur se tient entre l’agent et le réviseur. Le réviseur ne devrait jamais être le premier humain à lire le code.

L’étape du milieu, c’est là que les équipes coupent les coins ronds. Si l’auteur n’a pas lu le diff, le réviseur fait le travail de l’auteur, avec moins de contexte.

Rendez l’agent visible

Cacher qu’un agent a écrit le code n’aide personne. Les réviseurs lisent autrement quand ils le savent : ils regardent de plus près les tests, les cas limites et les dépendances inventées.

## Quoi et pourquoi
Ajoute l’export CSV à la page des factures. Ferme le ticket lié plus bas.

## Comment ça a été construit
Assisté par un agent. J’ai écrit le brief (lien) et révisé chaque fichier.
L’agent a écrit : le service d’export, les tests. J’ai réécrit : le formatage des dates.

## Où regarder
- logique centrale : services/export.ts (mapping des colonnes, échappement)
- tests : export.test.ts, inclut guillemets et virgules dans les champs
- mécanique : enregistrement de la route, imports

## Non vérifié
- Exports de plus de 10 000 lignes (pas encore de fixture aussi grosse)

Le bloc « Où regarder » vient directement du guide de revue que vous demandez à l’agent, vu au module 4. L’auteur le vérifie, puis le transmet.

✕ Revue de façade

  • –L’auteur ouvre la PR sans l’avoir lue
  • –Une PR de 1 500 lignes par exécution d’agent
  • –Le réviseur demande à un agent de réviser, puis approuve
  • –Des tests modifiés passent sans commentaire
  • –Personne ne peut expliquer un choix de design

✓ Vraie responsabilité

  • +L’auteur fait son autorevue avant de demander une revue
  • +Des PR assez petites pour être lues d’une traite
  • +La revue par IA est une première passe; un humain décide
  • +Chaque test modifié est justifié en une phrase
  • +L’auteur peut défendre chaque décision, peu importe qui l’a tapée

Qui est responsable de quoi : testez-vous

🧠 Scénarios de responsabilité

Pointage: 0 / 4

  1. 1. Un bug part en prod dans du code écrit par un agent que l’auteur a seulement survolé. Qui est responsable du correctif?

  2. 2. Un bot de revue IA approuve une PR sans commentaire. Que devrait-il se passer?

  3. 3. Un réviseur demande pourquoi l’agent a choisi une nouvelle librairie. L’auteur ne le sait pas. Meilleur réflexe?

  4. 4. Une exécution d’agent a produit une PR de 2 000 lignes qui touche trois fonctionnalités. Que faites-vous?

Avant de continuer

✅ À retenir

0 / 5 complété