Comment relire le code généré par l'IA

Pour relire du code généré par l'IA, commencez par ce qui a changé (quels fichiers et pourquoi), puis testez vous-même le comportement avant de lire la moindre ligne de code. Ensuite, vérifiez les points où le code produit par l'IA se trompe le plus souvent : contrôles d'accès côté serveur manquants, secrets exposés au navigateur, données non validées, paquets ou fonctions inexistants, et modifications de choses que vous n'aviez jamais demandé de toucher.

L'IA écrit du code qui fonctionne en général et qui a souvent belle allure. Il est donc facile de l'approuver sans vraiment le vérifier. Ce guide présente une routine de relecture qui fonctionne que vous lisiez le code couramment ou pas du tout.

Proportionner la relecture au risque

Toutes les modifications ne demandent pas la même attention.

Étape 1 : voir ce qui a changé

Avant de juger le code, récupérez la liste des modifications :

• Si le projet est dans Git, regardez le diff : les fichiers et lignes modifiés depuis le dernier commit. Voir comment utiliser Git avec une app créée par IA.
• Ou demandez directement à l'IA :

Liste chaque fichier que tu as modifié lors de la dernière modification, et pour chacun explique en une phrase ce qui a changé et pourquoi.

Signaux d'alerte à ce stade : fichiers sans rapport avec la demande, fichiers supprimés, modifications de configuration ou de dépendances que vous n'aviez pas demandées.

Étape 2 : tester le comportement d'abord

Lire le code indique ce qu'il est censé faire ; tester indique ce qu'il fait réellement. Avant de lire :

• Essayez la modification comme un utilisateur normal, sur ordinateur et sur un écran de taille de téléphone.
• Essayez avec des données incorrectes : champs vides, texte très long, nombres négatifs, date passée.
• Essayez en étant déconnecté, puis avec un autre utilisateur.
• Refaites les parcours les plus importants : inscription, connexion, action principale, paiement.

Si le test échoue, vous avez évité de lire le code pour rien : signalez le problème clairement et laissez l'IA le corriger. Voir comment rédiger un bon rapport de bug.

Étape 3 : vérifier les autorisations côté serveur

C'est le point le plus important à vérifier. Les outils d'IA masquent souvent un bouton dans la page, mais laissent le serveur prêt à exécuter l'action pour quiconque la demande.

Pour chaque route ou fonction qui lit ou modifie des données, demandez-vous :

• Vérifie-t-elle que l'utilisateur est connecté ?
• Vérifie-t-elle que cet utilisateur a le droit d'accéder à cet enregistrement ?
• Cette vérification est-elle faite sur le serveur, et pas seulement dans la page ?

Pour chaque route API que tu as ajoutée ou modifiée, indique quel contrôle d'autorisation elle effectue côté serveur, en citant la ligne. Signale toute route qui n'en a pas.

Puis testez-le : connectez-vous en tant qu'utilisateur A, notez l'identifiant d'un enregistrement, reconnectez-vous en tant qu'utilisateur B et demandez cet enregistrement. La liste de contrôle de sécurité pour les apps créées par IA présente le test complet.

Étape 4 : chercher les secrets exposés

• Recherchez dans les fichiers modifiés tout ce qui ressemble à une clé ou à un mot de passe.
• Vérifiez que les clés secrètes sont lues depuis des variables d'environnement et utilisées uniquement dans le code serveur.
• Faites attention aux préfixes publics comme VITE_ ou NEXT_PUBLIC_ appliqués à des variables secrètes : ils sont intégrés au code du navigateur.

Voir comment protéger vos clés d'API.

Étape 5 : vérifier les données saisies et les erreurs

• Validation côté serveur. Les contrôles du navigateur peuvent être contournés. Les champs obligatoires, les longueurs, les formats et les valeurs autorisées doivent aussi être vérifiés par le serveur.
• Les requêtes de base de données utilisent des paramètres, et non un texte construit en joignant des données saisies par l'utilisateur à la requête.
• Les erreurs ne sont pas avalées. Un try/catch qui ne fait rien masque les échecs. Les erreurs doivent être journalisées, et l'utilisateur doit voir un message clair.
• Aucun détail interne n'est montré aux utilisateurs : les traces d'exécution et les erreurs de base de données doivent rester dans les journaux.

Étape 6 : vérifier que tout est réel

Les modèles d'IA produisent parfois du code qui semble juste mais fait référence à des choses qui n'existent pas.

• Paquets : chaque nouvelle dépendance doit être un paquet réel et maintenu, portant exactement ce nom. Méfiez-vous des noms qui ressemblent à des fautes de frappe de paquets populaires.
• Fonctions et options d'API : si le code appelle une fonction de bibliothèque ou une option d'API externe que vous ne connaissez pas, vérifiez la documentation officielle.
• Code provisoire : recherchez TODO, mock, fake, des données d'exemple codées en dur ou des fonctions qui renvoient une valeur fixe.

As-tu ajouté de nouveaux paquets ? Pour chacun, indique le nom exact, à quoi il sert, et si nous pourrions nous en passer.

Étape 7 : vérifier que cela s'intègre

Le code peut fonctionner tout en rendant l'app plus difficile à faire évoluer :

• Duplication. La même logique copiée à plusieurs endroits finira par diverger.
• Cohérence. Il doit suivre les schémas utilisés dans le reste de l'app.
• Taille. Une demande de 20 lignes qui a produit 600 lignes mérite une question.
• Code mort. Des anciennes versions laissées à côté des nouvelles.

Y a-t-il du code dans le projet devenu inutilisé à cause de cette modification, ou une logique dupliquée ailleurs ? Ne change rien ; liste simplement ces éléments.

Erreurs courantes

• Approuver parce que ça a l'air propre. Un code net peut tout de même oublier un contrôle d'accès.
• Lire au lieu de tester. Testez d'abord ; lisez ensuite.
• Ne tester que le cas idéal. Essayez les mauvaises données, le mauvais utilisateur et la déconnexion.
• Ignorer les fichiers modifiés sans rapport. Demandez pourquoi chaque fichier a changé.
• Faire entièrement confiance à l'auto-relecture. Utilisez la relecture de l'IA comme première passe et confirmez par des tests.
• Relire une semaine de modifications d'un coup. Relisez les petites modifications au fur et à mesure.

Liste de contrôle

• Je sais quels fichiers ont changé et pourquoi, et rien de sans rapport n'a changé.
• La modification fonctionne sur ordinateur et sur téléphone, avec des données incorrectes, en étant déconnecté et avec un autre utilisateur.
• Chaque route qui accède aux données vérifie la connexion et la propriété côté serveur.
• Aucun secret dans le code ni dans les fichiers du navigateur.
• Les données saisies sont validées côté serveur ; les requêtes utilisent des paramètres.
• Les erreurs sont journalisées, pas avalées, et pas affichées en détail aux utilisateurs.
• Les nouveaux paquets sont réels et nécessaires ; aucune fonction inventée ni aucun code provisoire ne subsiste.
• Les modifications à haut risque ont fait l'objet d'une lecture attentive et, si nécessaire, d'un second relecteur.

Relire le code sur Mythex

• Le mode Question répond à des questions sur le code sans le modifier, idéal pour les demandes « explique chaque modification » et « quelles routes n'ont pas de contrôle d'accès ». Voir Chat.
• La vue Code affiche l'arborescence des fichiers, l'éditeur et le terminal sur tous les forfaits (en lecture seule sur le forfait Gratuit, modifiable sur Pro), pour que vous lisiez vous-même ce qui a changé. Voir Éditeur de code.
• /test demande à l'agent de cliquer dans l'aperçu comme un utilisateur et de signaler les parcours cassés.
• Les points de contrôle vous permettent d'annuler une modification qui échoue à la relecture.

Si un développeur relit le code pour vous, comment travailler avec un développeur sur une app créée par IA explique la passation ; si la relecture révèle un bug, voir comment déboguer une app créée par IA.

Questions