Comment encadrez-vous l'usage des assistants de code IA dans votre équipe ?

Traitez le code généré comme un brouillon venu d'un contributeur inconnu : rapide, utile, et tenu exactement au même standard de revue que le reste. Soyez explicite sur les endroits où c'est encouragé (boilerplate, tests, syntaxe inconnue, exploration) et ceux qui demandent une vigilance accrue (chemins sensibles pour la sécurité, licences, tout ce que l'auteur ne sait pas expliquer). Surveillez de près la charge de revue, parce que le goulot d'étranglement passe de l'écriture du code à sa relecture.

Ma règle est simple : celui qui ouvre la pull request possède chaque ligne dedans, et si vous ne savez pas expliquer pourquoi ça marche en revue, ça ne merge pas. Ce seul principe couvre l'essentiel du risque sans que j'écrive une charte que personne ne lit. Je l'encourage activement pour le gros ennuyeux, l'échafaudage de tests, les migrations, la syntaxe d'une bibliothèque inconnue, et pour explorer une approche rapidement. Je demande plus de prudence sur les chemins sensibles pour la sécurité et tout ce qui touche aux licences, et on ne colle pas de données clients dans des outils externes. L'effet que je surveille le plus, c'est la charge de revue. La production a nettement augmenté dans mon équipe et la revue est devenue la contrainte presque tout de suite, donc on a posé l'attente qu'un gros diff généré arrive avec le résumé de l'auteur sur ce qu'il faut regarder, et on refuse les pull requests énormes et dispersées beaucoup plus fermement qu'avant. L'autre chose que je surveille, ce sont les juniors, parce qu'on peut maintenant produire du code qui marche sans le comprendre, donc en tête-à-tête je leur demande de dérouler leur raisonnement plus souvent qu'avant.