Le Guide du Développeur pour la Révision de Code Généré par IA

La révision de code a toujours consisté à attraper les erreurs avant qu'elles n'atteignent la production. Mais quand le code a été écrit par un assistant IA plutôt que par un collègue humain, la dynamique de la révision change fondamentalement. Les erreurs que l'IA commet sont différentes de celles qu'un humain commet, et les éléments que vous devez vérifier ne sont pas les mêmes que ceux que vous vérifieriez dans une révision par les pairs.

Ce guide couvre ce que les équipes expérimentées ont appris sur la révision de code généré par IA. Il est organisé par catégories de problèmes que les modèles d'IA produisent systématiquement, afin que vous puissiez passer en revue une liste de contrôle systématique plutôt que de vous fier à votre intuition développée pour le code écrit par des humains.

Pourquoi le code généré par IA nécessite des critères de révision différents

Les développeurs humains font des erreurs qui tournent autour de la fatigue, de la distraction et des lacunes de connaissances — un développeur fatigué oublie un cas limite, un distrait oublie de gérer une erreur, un junior utilise un anti-modèle parce qu'il ne connaît pas mieux. Les modèles d'IA font des erreurs qui tournent autour d'axes complètement différents : hallucination, cécité contextuelle et incohérence stylistique.

Un humain qui écrit une fonction qui ne gère pas les entrées nulles sait probablement mieux faire et a simplement oublié. Une IA qui écrit la même fonction ne sait vraiment pas si null est possible dans votre base de code à moins que vous ne le lui ayez explicitement dit. Cette distinction est importante car la correction est différente : un humain a besoin d'un rappel, mais l'IA a besoin d'une contrainte encodée dans le prompt ou détectée en révision.

Comprendre cette différence est le fondement d'une révision efficace du code IA. Vous ne vérifiez pas si le développeur a été attentif. Vous vérifiez si l'IA avait assez de contexte pour produire un code correct, et si sa sortie correspond aux conventions implicites de votre base de code qu'elle ne pouvait pas voir.

Point de contrôle 1 : API et imports hallucinés

Le problème le plus courant dans le code généré par IA est l'utilisation de bibliothèques, fonctions ou API qui n'existent pas. Les modèles d'IA sont entraînés à produire du code plausible, et ils généreront avec confiance des imports pour des paquets qui n'ont jamais été publiés et appelleront des méthodes qui n'ont jamais existé. Ce n'est pas malveillant — c'est le modèle qui interpole entre des paquets réels qu'il a vus pendant l'entraînement et invente un pont qui semble raisonnable.

// AI-generated code that looks plausible but imports a non-existent function
import { renderAsync } from 'react-dom'; // renderAsync does not exist
import { optimize } from 'lodash/fp/string'; // This path does not exist in lodash

// What you actually need
import { renderToString } from 'react-dom/server';

La solution est simple mais importante : vérifiez chaque import et chaque appel API par rapport à la documentation réelle. Ne supposez pas que parce que le code compile, les API sont correctes — certaines fonctions hallucinées ont des signatures d'apparence raisonnable qui passent la vérification TypeScript mais échouent à l'exécution. La révision devrait inclure une vérification rapide de tout import que vous ne reconnaissez pas.

Point de contrôle 2 : Gestion d'erreurs manquante

Les modèles d'IA ont tendance à générer le chemin heureux. Ils sont remarquablement bons pour écrire la logique principale d'une fonction — la boucle, la transformation, la valeur de retour — et remarquablement mauvais pour gérer ce qui se passe quand les choses tournent mal. Les requêtes réseau manquent de blocs catch. Les opérations sur fichiers manquent de gestion d'erreurs. Les fonctions asynchrones manquent de gestionnaires de rejet.

Ce n'est pas parce que l'IA ne peut pas écrire de gestion d'erreurs. Si vous le lui demandez explicitement, l'IA produira une logique try-catch approfondie. Le problème est que le comportement par défaut du modèle est d'écrire la version fonctionnelle la plus simple, et la gestion d'erreurs ne fait pas partie de ce défaut. Chaque révision de code généré par IA devrait inclure un passage qui ne regarde que les chemins d'erreur.

• Chaque fonction asynchrone devrait avoir un gestionnaire catch ou rejet.
• Chaque appel API externe devrait gérer les erreurs réseau, les timeouts et les formats de réponse inattendus.
• Chaque transformation de données devrait gérer null, undefined et les types inattendus.
• Chaque opération fichier ou base de données devrait gérer les erreurs de permission et les ressources manquantes.

Une technique utile consiste à exécuter un test simple : retirez les blocs try-catch du code généré par IA et voyez si la logique restante a encore du sens. Si c'est le cas, l'IA n'a probablement pas beaucoup réfléchi à la gestion d'erreurs. Si la logique dépend de la gestion d'erreurs pour fonctionner, l'IA l'a intégrée correctement.

Point de contrôle 3 : Décalages de style et de conventions

Chaque base de code a des conventions de style non écrites. L'équipe utilise des retours anticipés, pas des if imbriqués. Les messages d'erreur suivent un format spécifique. Les noms de variables utilisent un modèle particulier. Les modèles d'IA entraînés sur des millions de dépôts publics généreront du code qui reflète la moyenne statistique de tous ces dépôts, pas les conventions spécifiques de votre base de code.

Le résultat est un code qui fonctionne mais semble étranger. Il utilise une convention de nommage, une structure de modules ou un modèle de gestion d'erreurs différent du code environnant. Ce genre d'incohérence s'accumule rapidement — cinq fonctions générées par IA écrites avec cinq styles implicites différents créent une base de code qui semble incohérente et est plus difficile à maintenir.

La meilleure atténuation est d'inclure des exemples de style dans vos prompts. Collez une fonction représentative du même module et dites utilise ce style. Cela donne à l'IA une référence concrète qui remplace son défaut d'entraînement. Pendant la révision, vérifiez que le code généré aurait pu être écrit par la même personne qui a écrit le module environnant.

Point de contrôle 4 : Surabondance d'ingénierie et abstraction inutile

Les modèles d'IA ont un fort biais vers l'abstraction. Face à un problème simple, ils généreront souvent une hiérarchie de classes, une interface, une fabrique et trois fonctions utilitaires — là où une seule fonction aurait suffi. Cette tendance vient des données d'entraînement, qui surreprésentent les bibliothèques open source bien structurées et sous-représentent les scripts simples et les fonctions à usage unique.

Les modèles d'IA par défaut font de la sur-ingénierie. Votre révision devrait par défaut privilégier la simplicité. Chaque abstraction introduite par l'IA doit justifier son existence face à une alternative plus simple.

Pendant la révision, demandez-vous : ce code a-t-il besoin d'une classe, ou une fonction ferait-elle l'affaire ? Cette interface est-elle utilisée par plus d'une implémentation ? Extraire cette utilitaire économiserait-il assez de répétitions pour justifier l'indirection ? Si la réponse à l'une de ces questions est non, l'IA a probablement sur-ingéniéré et la version plus simple est meilleure.

Point de contrôle 5 : Vulnérabilités de sécurité

Les modèles d'IA sont entraînés sur du code qui contient des vulnérabilités de sécurité. Ils apprennent des motifs à partir de ce code, y compris les motifs vulnérables. Bien que les modèles modernes soient meilleurs pour éviter les problèmes évidents comme l'injection SQL, ils produisent encore du code avec des problèmes de sécurité subtils qu'un relecteur doit détecter.

• Vérifiez la présence de secrets codés en dur, de clés API ou d'identifiants dans le code généré.
• Assurez-vous que les entrées utilisateur sont validées et assainies avant utilisation.
• Vérifiez que les contrôles d'authentification et d'autorisation sont présents sur les opérations protégées.
• Assurez-vous que les requêtes SQL générées utilisent des requêtes paramétrées, pas de concaténation de chaînes.
• Vérifiez que les chemins de fichiers ne sont pas construits à partir d'entrées non fiables sans assainissement.

Un passage de révision axé sur la sécurité est non négociable pour le code généré par IA qui traite des données sensibles ou des entrées utilisateur. L'IA ne sait pas quelles parties de votre système sont critiques pour la sécurité à moins que vous ne le lui disiez. En cas de doute, exécutez un outil d'analyse statique sur le code généré avant de le fusionner.

Point de contrôle 6 : Cohérence avec l'architecture existante

Les modèles d'IA voient chaque requête de manière isolée. Ils ne savent pas que votre équipe a décidé le trimestre dernier d'utiliser React Query pour toutes les récupérations de données, que l'API renvoie toujours des clés en camelCase, ou que le projet utilise un modèle de gestion d'état spécifique. Le code qu'ils génèrent sera cohérent en interne mais peut violer des décisions architecturales qui ne sont pas visibles dans le fichier courant.

C'est là que le relecteur humain apporte le plus de valeur. Vous connaissez les décisions qui sont documentées dans vos ADR, les motifs qui ont émergé des discussions d'équipe, et les contraintes de conception qui ne sont capturées dans aucun fichier unique. Révisez le code généré par IA par rapport à ces contraintes invisibles, pas seulement par rapport à l'exactitude et au style.

Construire un processus de révision durable

Alors que l'IA génère davantage de votre base de code, le processus de révision doit passer à l'échelle. Une équipe de quatre personnes qui révise chaque ligne générée par IA manuellement va s'épuiser. L'approche durable combine des vérifications automatisées avec une révision humaine ciblée.

Les vérifications automatisées devraient détecter les imports hallucinés, les violations de style, la gestion d'erreurs manquante et les problèmes de sécurité courants avant qu'un humain ne voie le code. Cela réduit la révision spécifique à l'IA à un ensemble plus restreint de préoccupations : la cohérence architecturale, les décisions de conception et les problèmes subtils que les linters ne peuvent pas détecter.

L'objectif n'est pas d'éliminer la révision humaine du code généré par IA. C'est de rendre cette révision aussi efficace que possible en filtrant les problèmes que les outils peuvent détecter automatiquement et en réservant l'attention humaine aux jugements que seuls les humains peuvent porter. Avec le bon processus, réviser du code généré par IA devient plus rapide et plus fiable que réviser du code écrit par un humain — car les erreurs de l'IA sont plus prévisibles.