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

Pour examiner le 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 zones où le code d'IA se trompe le plus souvent : contrôles d'autorisation manquants côté serveur, secrets exposés au navigateur, données non validées, paquets ou fonctions qui n'existent pas, et modifications de choses que vous n'avez jamais demandé de toucher.

L'IA écrit du code qui fonctionne généralement et qui paraît souvent soigné. C'est ce qui le rend facile à approuver sans vraiment vérifier. Ce guide propose une routine d'examen qui fonctionne que vous lisiez le code couramment ou pas du tout.

Adapter l'examen au risque

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

Étape 1 : Voir ce qui a changé

Avant de juger le code, obtenez la liste des modifications :

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

Énumère chaque fichier que tu as modifié lors du dernier changement, 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 la configuration ou des dépendances que vous n'avez pas demandées.

Étape 2 : Tester d'abord le comportement

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 téléphone.
• Essayez avec des données erronées : 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 économisé du temps de lecture; signalez le problème clairement et laissez l'IA le corriger. Voir comment rédiger un bon rapport de bogue.

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

C'est la chose la plus importante à vérifier. Les outils d'IA cachent 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 non seulement dans la page?

Pour chaque route d'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.

Testez ensuite : connectez-vous comme l'utilisateur A, notez l'identifiant d'un enregistrement, puis connectez-vous comme l'utilisateur B et demandez cet enregistrement. La liste de sécurité pour les apps créées par IA contient 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 à partir de variables d'environnement et utilisées uniquement dans le code serveur.
• Surveillez les 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 garder vos clés d'API en sécurité.

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

• Validation côté serveur. Les vérifications du navigateur peuvent être contournées. Les champs obligatoires, les longueurs, les formats et les valeurs autorisées doivent aussi être vérifiés par le serveur.
• Les requêtes à la base de données utilisent des paramètres, et non un texte construit en joignant les 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 les utilisateurs doivent voir un message simple.
• Aucun détail interne n'est montré aux utilisateurs : les traces d'appels et les erreurs de base de données appartiennent aux journaux.

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

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

• 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 : cherchez 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, donne le nom exact, à quoi il sert et si nous pourrions nous en passer.

Étape 7 : Vérifier que le code s'intègre

Le code peut fonctionner tout en rendant l'app plus difficile à modifier plus tard :

• Duplication. La même logique copiée à plusieurs endroits finira par diverger.
• Cohérence. Il doit suivre les modèles 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. D'anciennes versions laissées à côté des nouvelles.

Y a-t-il du code dans le projet qui n'est maintenant plus utilisé à cause de ce changement, ou une logique dupliquée ailleurs? Ne modifie rien; liste-le simplement.

Erreurs courantes

• Approuver parce que ça paraît propre. Un code soigné peut tout de même omettre un contrôle d'autorisation.
• Lire au lieu de tester. Testez d'abord; lisez ensuite.
• Ne tester que le cas idéal. Essayez des données erronées, le mauvais utilisateur et la déconnexion.
• Ignorer les modifications de fichiers non liés. Demandez pourquoi chaque fichier a changé.
• Faire entièrement confiance à l'auto-examen. Utilisez l'examen de l'IA comme première passe et confirmez par des tests.
• Examiner une semaine de modifications d'un coup. Examinez les petites modifications au fil de l'eau.

Liste de vérification

• Je sais quels fichiers ont changé et pourquoi, et rien d'étranger n'a été modifié.
• La modification fonctionne sur ordinateur et sur téléphone, avec des données erronées, déconnecté et avec un autre utilisateur.
• Chaque route de données vérifie la connexion et la propriété côté serveur.
• Aucun secret dans le code ni dans les paquets du navigateur.
• Les données saisies sont validées côté serveur; les requêtes utilisent des paramètres.
• Les erreurs sont journalisées, non ignorées, et ne sont pas montré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, au besoin, d'un second examen.

Examiner le code sur Mythex

• Le mode Question répond aux questions sur le code sans le modifier : idéal pour les demandes du type « explique chaque modification » ou « quelles routes n'ont pas de contrôle d'autorisation ». Voir Clavardage.
• La vue du 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 parcourir l'aperçu comme un utilisateur et de signaler les parcours brisés.
• Les points de contrôle vous permettent d'annuler une modification qui échoue à l'examen.

Si un développeur fait l'examen pour vous, comment travailler avec un développeur sur une app créée par IA explique la remise du travail; si l'examen révèle un bogue, voir comment déboguer une app créée par IA.

Questions