L'IA a écrit le code. Qui assume le déploiement ?

Une pull request peut arriver avec une implémentation, des tests et une explication convaincante en quelques minutes. La personne qui relit reçoit un problème moins commode. Elle doit vérifier que les changements répondent aux besoins du produit, y compris quand quelque chose échoue.

Le volume de code à relire peut augmenter sans que l'équipe ait davantage de temps pour le comprendre. Tout approuver parce que les tests passent est tentant. Cela confie aussi la décision à des tests qui reproduisent peut-être la même hypothèse fausse que le code.

GitHub précise que la revue de Copilot peut manquer des problèmes et proposer des changements inutiles. La revue humaine reste nécessaire. Nous conseillons de l'organiser autour du comportement qui doit tenir après le déploiement.

Commencez par la règle à préserver

Imaginez une intégration qui reçoit une confirmation d'inscription et crée un billet. Le fournisseur peut renvoyer le même événement. La règle du produit impose un seul billet par inscription, même après plusieurs livraisons.

Une implémentation peut rechercher l'événement, vérifier son absence, puis enregistrer le billet. Chaque ligne paraît correcte. Pourtant, deux requêtes simultanées peuvent effectuer la recherche avant la première écriture.

Il faut donc vérifier où le système impose l'unicité. Une contrainte en base peut protéger l'écriture. Si le traitement envoie aussi un e-mail, la transaction locale ne rend pas cet envoi externe atomique. Il faut prévoir comment enregistrer le travail restant et reprendre la notification sans créer un autre billet.

Cet exemple est fictif. Il invite à chercher les décisions qui dépendent du comportement du système entier. Une fonction lisible ne résout pas la concurrence à elle seule.

Suivez le parcours complet

Suivez la donnée depuis son arrivée jusqu'à son effet final. Pour le billet, lisez la vérification de l'origine de l'événement, l'identification de l'inscription et l'enregistrement. Examinez ensuite la notification.

Lisez aussi les fichiers existants que le nouveau code appelle. Une fonction nommée createTicket peut envoyer un e-mail en interne. Un traitement d'erreur peut transformer un échec en réponse positive. Ces détails changent le résultat quand le fournisseur réessaie.

Demandez une courte justification pour chaque nouvelle dépendance. Si une bibliothèque remplace seulement une fonction déjà présente, retirez-la. Chaque dépendance ajoutée demandera encore de l'attention après la fermeture de la pull request.

Faites contredire le code par les tests

Écrivez les résultats attendus sans reprendre la structure de l'implémentation. Pour cette intégration, la revue pourrait exiger :

Situation	Résultat attendu
Le même événement arrive deux fois	Un seul billet
Deux livraisons arrivent ensemble	La règle d'unicité tient toujours
Le billet est enregistré et la notification échoue	La notification peut reprendre sans dupliquer le billet
L'origine de l'événement est invalide	Aucun billet créé

Le test de concurrence doit exercer la protection utilisée lors de l'écriture. Une base simulée qui renvoie toujours la réponse attendue peut masquer le défaut recherché.

Quand vous corrigez un bug, vérifiez que le test échoue sans la correction. Cela évite de célébrer un test qui n'a jamais observé le problème.

Réduisez le changement jusqu'à pouvoir l'expliquer

Mélanger une modification de comportement, une réorganisation des dossiers et une mise à jour de dépendances complique la revue. Demandez des livraisons séparées lorsque ces travaux sont indépendants.

Avant d'approuver, la personne responsable doit pouvoir décrire l'effet pour l'utilisateur, l'échec le plus probable et la façon de le détecter après publication. Elle n'a pas besoin de mémoriser chaque ligne. Elle doit savoir où regarder au premier signalement.

Notez aussi les limites du retour arrière. Revenir au code précédent n'annule pas automatiquement une migration destructive et ne rappelle pas un e-mail envoyé. Ces conséquences font partie de la décision de publier.

L'IA peut aider à examiner les changements et à proposer des cas oubliés. Servez-vous de cette aide. L'approbation exige toujours une modification que quelqu'un sait expliquer et maintenir quand le scénario idéal ne tient plus.