La réponse courte
Examinez le code généré par l’IA au regard des mêmes exigences produit et des mêmes risques de production que toute autre modification. Vérifiez qu’il résout le problème visé, respecte les permissions, gère les échecs et peut être maintenu par l’équipe. Un build réussi est un point de contrôle utile. Il ne prouve pas que le comportement est correct ni que la version est prête.
Pourquoi la revue mérite plus d’attention
L’assistance de l’IA peut produire très rapidement une grande quantité de code à examiner. L’attention se déplace alors vers la manière dont les modifications sont expliquées et vérifiées. Le guide de revue de GitHub met l’accent sur les vérifications fonctionnelles, le contexte du projet, la supervision humaine et les tests. Lire le guide de revue de GitHub.
La question pratique pour un product owner est simple : l’ingénieur responsable de cette modification peut-il expliquer ce qu’elle fait, comment elle a été vérifiée et comment elle pourrait échouer ? Si la réponse repose entièrement sur l’explication fournie par l’outil lui-même, une revue plus poussée s’impose.
Rédigez les critères d’acceptation avant le correctif
Prenons l’exemple d’une fonctionnalité d’invitation à un compte. L’exigence est plus précise que « envoyer une invitation » : seul un administrateur autorisé peut inviter une personne, l’invitation appartient à la bonne organisation, l’expiration fonctionne et une demande répétée ne crée pas de comptes en conflit.
Consignez ces comportements par écrit avant d’examiner l’implémentation. Demandez ensuite au relecteur de démontrer chacun d’eux. Garder les critères séparés du code généré permet d’éviter une vérification circulaire dans laquelle des tests générés ne font que confirmer les hypothèses du même outil.
Inspectez les frontières qui portent le risque
- Identité : où l’utilisateur est-il authentifié et où ses permissions sont-elles vérifiées ?
- Données : une requête peut-elle lire ou modifier les données d’un autre client ?
- Échecs : que se passe-t-il après un délai d’expiration, une écriture partielle ou une requête en double ?
- Dépendances : chaque nouveau paquet est-il nécessaire, maintenu et bien celui que l’on voulait ?
- Exploitation : de quelles informations l’équipe support disposera-t-elle si la fonctionnalité tombe en panne ?
Ces questions constituent une structure de revue suggérée. La profondeur de l’examen doit dépendre des conséquences de la modification : le traitement des paiements et les permissions des comptes exigent un examen plus approfondi qu’un ajustement visuel réversible.
Vérifiez aussi l’environnement de développement
Le guide Secure Coding with AI de l’OWASP traite des risques qui apparaissent lorsque les outils de développement peuvent exécuter des commandes, installer des dépendances et accéder à des systèmes connectés. Limitez les accès inutiles et traitez avec prudence les instructions provenant de contenus de projet non fiables. Lire les recommandations de l’OWASP pour les outils de codage IA.
La routine de mise en production que nous proposons consiste à examiner le diff final, exécuter les vérifications qui couvrent le comportement modifié, passer en revue toute nouvelle dépendance et répéter le rollback lorsque la modification touche des données stockées. Gardez la modification suffisamment petite pour qu’un humain puisse réellement la comprendre.
Désignez un responsable du résultat
Le compte rendu de revue doit indiquer ce qui a été modifié, ce qui a été testé et quelles incertitudes subsistent. L’ingénieur qui approuve la mise en production assume ce jugement. L’assistance de l’IA fait partie de la façon dont l’équipe travaille ; la responsabilité du logiciel livré reste entre les mains des personnes.
Une autre IA peut-elle relire la modification ?
Elle peut apporter un regard supplémentaire, mais elle ne remplace ni un relecteur responsable ni les preuves issues du système en fonctionnement.
Chaque modification nécessite-t-elle une suite de tests importante ?
Non. Choisissez des vérifications qui répondent aux risques réels. Évitez d’ajouter des tests qui reformulent des détails d’implémentation sans démontrer un comportement utile.
Découvrez comment CloudCoder conçoit et vérifie ses logiciels, ou lisez notre introduction au développement assisté par l’IA.
