Comment relire le code écrit par l’IA en toute sécurité : la checklist réelle d’un développeur

L’IA écrit du code plus vite que n’importe quel humain. C’est à la fois sa plus grande force et ce qui devrait vous empêcher de dormir. Quand un développeur utilise GitHub Copilot, ChatGPT ou tout autre assistant de codage par IA, le résultat paraît soigné, se compile proprement et passe les tests de base. Ce qui lui manque souvent, c’est le raisonnement profond et contextuel qui permet de repérer le bug que vous ne trouverez qu’à la troisième semaine en production.

Relire du code écrit par l’IA n’est pas la même chose que relire du code écrit par un humain. Les humains font des erreurs prévisibles, à des endroits prévisibles. L’IA commet des erreurs plausibles partout, avec assurance. Cet article vous propose un cadre concret pour relire le code écrit par l’IA en toute sécurité, couvrant les failles de sécurité, les pièges logiques, la mauvaise gestion des erreurs et les outils qui accélèrent le processus sans rogner sur la rigueur.

Ce qui distingue le code de l’IA

Si vous relisez du code depuis des années, vous savez déjà que la personne qui a écrit une fonction comprend généralement ce qu’elle est censée faire, même quand le code est faux. Elle peut répondre à vos questions. Elle a une intention.

L’IA n’a pas d’intention au sens décrit plus haut. Elle génère un code statistiquement probable à partir d’un prompt. Elle a vu des millions d’exemples de code, y compris les mauvais. Quand elle produit un résultat, elle fait de la reconnaissance de motifs, pas de la résolution de problème.

L’illusion de la justesse

Le plus dangereux dans le code généré par l’IA, c’est à quel point il paraît correct. Il respecte les conventions de nommage. Il contient des commentaires. Il utilise une syntaxe moderne. Sa structure est souvent la bonne. Un développeur qui le parcourt rapidement l’approuverait sans hésiter.

Mais l’IA tombe régulièrement sur des modes de défaillance précis :

• Part du principe que les entrées sont idéales : le code de l’IA tient rarement compte de ce qui se passe quand les données sont mal formées, nulles ou hors de la plage attendue.
• Reproduit des schémas vulnérables : si les données d’entraînement contenaient du code peu sûr, le modèle peut reproduire cette faiblesse avec assurance.
• Simplifie à l’excès la concurrence : les conditions de course, les interblocages et les problèmes de thread-safety n’apparaissent presque jamais par défaut dans les résultats de l’IA.
• Passe à côté de la logique métier : l’IA ne connaît pas votre système. Elle ne peut pas savoir que user.balance ne doit jamais descendre sous zéro dans votre domaine.

Les schémas qui cassent en silence

Les schémas précis qui passent la relecture de code mais échouent en production :

Avant de lire la moindre ligne

Une bonne relecture de code ne commence pas avec le diff. Elle commence avant que vous n’ouvriez le fichier.

Adopter la bonne posture

Quand vous relisez du code humain, vous accordez le bénéfice du doute à son auteur. Vous supposez qu’il avait une raison pour ses choix. N’accordez pas cette indulgence au code produit par l’IA. Abordez-le comme vous aborderiez le code d’un stagiaire talentueux le premier jour, qui a lu tous les livres de programmation jamais écrits mais n’a jamais rien livré en production.

Ce n’est pas du cynisme, c’est de la calibration. Le code généré par l’IA est souvent bon. Mais il lui faut un relecteur doté du bon niveau de scepticisme.

La question n’est jamais « est-ce que ça a l’air correct\u00a0? ». C’est toujours « que faudrait-il qu’il soit vrai pour que ça échoue\u00a0? »

Savoir ce qu’on a demandé à l’IA

Avant de relire le code, trouvez quel prompt l’a généré. Ce n’est pas toujours possible, mais quand c’est le cas, lisez-le attentivement. Des prompts vagues donnent du code vague. Si le prompt était « écris une fonction de connexion », l’IA ne savait rien de votre gestion des sessions, de vos exigences de limitation de débit ou de votre standard de hachage des mots de passe. Tout ce qu’elle a supposé est une faille potentielle.

Les failles de sécurité à traquer en premier

C’est en matière de sécurité que le code de l’IA fait le plus de dégâts. Les risques ne sont pas théoriques. Ils sont précis et suivent des schémas prévisibles.

Vulnérabilités par injection

L’IA génère fréquemment du SQL, des commandes shell ou du HTML en concaténant des chaînes. C’est l’une des plus anciennes vulnérabilités du développement logiciel, et l’IA la reproduit constamment parce qu’une grande partie de ses données d’entraînement fait de même.

Points à vérifier :

# Red flag: AI-generated SQL with string concatenation
query = "SELECT * FROM users WHERE name = '" + username + "'"

# What it should look like
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (username,))

Copier le prompt

Chaque fois qu’une entrée utilisateur atteint une requête de base de données, une commande shell, un chemin de fichier ou un modèle HTML sans assainissement ni requête paramétrée, vous avez un risque d’injection. Recherchez en particulier la concaténation de chaînes impliquant des variables qui pourraient provenir de l’utilisateur.

Secrets codés en dur

L’IA génère parfois du code d’exemple avec des clés d’API, des mots de passe ou des tokens directement dans la source. Pire encore, elle produit parfois des identifiants réalistes mais factices, que les développeurs laissent en place en comptant les remplacer plus tard, ce qu’ils oublient de faire.

Lancez un scanner de secrets avant que tout code généré par l’IA ne soit fusionné. Des outils comme truffleHog, detect-secrets ou gitleaks les détectent automatiquement. Intégrez-les à votre pipeline CI et traitez-les comme bloquants.

Tout identifiant présent dans le code source est un identifiant divulgué, qu’il soit réel ou qu’il s’agisse d’un simple espace réservé que quelqu’un a oublié de remplacer.

Dépendances non sûres

L’IA peut suggérer des paquets obsolètes, non maintenus ou présentant des CVE connues. Elle ne peut pas consulter les registres de paquets pour y chercher des vulnérabilités. Elle ne sait pas quelle version d’une bibliothèque a reçu un correctif de sécurité critique le mois dernier.

Après avoir relu le code généré par l’IA, lancez vos outils d’audit des dépendances :

• npm audit pour les projets Node.js
• pip-audit ou safety pour Python
• bundle-audit pour Ruby

Toute dépendance introduite par le résultat de l’IA doit être vérifiée dans les bases de données de vulnérabilités actuelles avant la fusion.

Contrôles de logique et de justesse

La sécurité fait les gros titres, mais c’est sur la logique que le code de l’IA échoue le plus souvent. Ces bugs compilent, passent les tests et survivent à la relecture. Ils n’apparaissent que dans des conditions précises que l’IA n’a jamais envisagées.

Les cas limites que l’IA a ignorés

L’IA génère du code pour le cas nominal. Elle traite l’entrée décrite dans le prompt. Elle ne gère pas :

• Les collections vides ou les références nulles
• Les entrées situées exactement à la limite d’une plage valide
• Les appels concurrents à la même fonction
• Les délais d’attente réseau ou les réponses partielles
• Les scénarios de disque plein ou d’épuisement de la mémoire

Pour chaque fonction que vous relisez, demandez-vous : que se passe-t-il si l’entrée la plus importante est nulle ? Que se passe-t-il si cette fonction est appelée avec une liste vide ? Que se passe-t-il si l’appel réseau renvoie un 200 avec un corps vide ?

Si l’IA n’a pas répondu à ces questions dans le code, vous devez soit ajouter la gestion vous-même, soit renvoyer le code pour révision.

Une gestion des erreurs qui ne fait rien

L’IA adore générer des blocs try-catch. Le problème, c’est ce qu’elle met dans ces blocs. Les captures silencieuses sont partout. Journaliser console.log(err) puis continuer comme si de rien n’était est courant. Relancer une erreur générique alors que l’appelant avait besoin d’une erreur précise est presque systématique.

Chaque gestionnaire d’exceptions dans le code de l’IA mérite un examen individuel :

• Gère-t-il réellement l’erreur, ou se contente-t-il de la masquer ?
• Le code appelant sait-il qu’un problème est survenu ?
• Cette erreur est-elle journalisée de façon à pouvoir être retrouvée plus tard ?
• L’application est-elle dans un état cohérent une fois ce bloc catch exécuté ?

Erreurs de décalage d’un (off-by-one) et de bornes

Les bornes de boucle sont l’endroit où l’IA se trompe régulièrement, à un taux plus élevé que les humains. Le code de l’IA utilise fréquemment < là où <= est nécessaire, itère un élément au-delà de la fin d’un tableau, ou démarre une plage à 1 alors qu’elle devrait démarrer à 0. Ces bugs sont invisibles dans de petits tests et catastrophiques lorsqu’on traite des données réelles à grande échelle.

Pour toute boucle ou plage du code généré par l’IA, parcourez manuellement la première itération, la dernière et le cas d’une collection sans aucun élément.

Les outils qui accélèrent votre relecture

La relecture manuelle est nécessaire mais ne suffit pas. Les outils automatisés détectent des catégories de problèmes que les humains manquent sous la pression du temps, et ils le font de façon constante.

Analyse statique et linters

L’analyse statique est votre première ligne de défense. Elle s’exécute avant qu’un humain ne regarde le code et détecte automatiquement les problèmes les plus faciles à repérer.

Outils recommandés par langage :

Configurez ces outils pour qu’ils s’exécutent automatiquement sur chaque pull request. Tout code généré par l’IA qui ne passe pas l’analyse statique ne doit pas passer à la relecture humaine.

Relecture de code assistée par l’IA

Il y a ici une ironie intéressante : l’IA est aussi l’un des meilleurs outils pour relire le code généré par l’IA. Un modèle différent, relisant le code avec un prompt axé sur la sécurité, repérera des schémas que le premier modèle a mal générés. Cela fonctionne parce que les deux modèles ont été entraînés différemment et ont des angles morts différents.

Faire relire le résultat d’une IA par une autre IA ne remplace pas la relecture humaine. C’est un filtre qui rend la relecture humaine plus rapide et mieux ciblée.

Utiliser les LLM de PicassoIA pour relire du code

Les grands modèles de langage de PicassoIA sont conçus précisément pour ce type de raisonnement. Vous pouvez coller un extrait de code, lui donner un prompt orienté relecture et obtenir une analyse structurée en quelques secondes, sans changer d’outil ni gérer de clés d’API.

Comment utiliser GPT 5 pour la relecture de code

GPT 5 est l’un des modèles les plus performants pour l’analyse de code. Sa force tient au contexte large : il peut garder une grande fonction en mémoire, identifier plusieurs problèmes qui interagissent et les expliquer clairement, un par un.

Étape par étape :

1. Ouvrez GPT 5 sur PicassoIA
2. Collez la fonction ou le module généré par l’IA que vous voulez faire relire
3. Utilisez cette structure de prompt :

Review this code for: (1) security vulnerabilities, (2) unhandled edge cases,
(3) error handling issues, (4) logic errors. For each issue found, explain
the risk and suggest a specific fix. Reference line numbers or variable names.

Copier le prompt

4. Examinez le résultat avec esprit critique. N’acceptez pas les suggestions aveuglément.
5. Recollez le code révisé et demandez-lui de revérifier les problèmes précis qu’il a signalés.

GPT 5.1 est aussi disponible pour les flux de travail basés sur des agents, si vous voulez automatiser des pipelines de relecture en plusieurs étapes.

Claude 4.5 Sonnet pour les audits de sécurité

Claude 4.5 Sonnet excelle particulièrement à repérer les failles de sécurité subtiles. Là où GPT privilégie l’étendue, Claude excelle en profondeur sur des scénarios de sécurité précis.

Pour une relecture axée sur la sécurité, Claude 4.5 Sonnet est particulièrement efficace avec des prompts qui lui demandent de raisonner pas à pas sur un modèle de menace. Par exemple : « Supposez qu’un attaquant contrôle le paramètre username. Suivez chaque chemin emprunté par ce paramètre dans ce code et identifiez les endroits où il pourrait être exploité. »

Claude 4 Sonnet et Claude Opus 4.7 sont aussi disponibles sur PicassoIA pour des tâches de relecture plus exigeantes ou des bases de code plus longues nécessitant un raisonnement plus approfondi.

DeepSeek R1 pour le raisonnement approfondi

DeepSeek R1 utilise un raisonnement en chaîne de pensée, ce qui le rend particulièrement bon pour suivre la logique dans des chemins de code complexes. Si vous avez une fonction avec plusieurs branches, des conditionnelles imbriquées ou une gestion d’état complexe, DeepSeek R1 raisonnera explicitement sur chaque branche au lieu de tout résumer à haut niveau.

DeepSeek V3.1 et Kimi K2 Instruct complètent les options pour les développeurs qui veulent faire passer le même code par plusieurs modèles et comparer les constats. Ce qui se recoupe entre les modèles est ce que vous devez corriger. Les désaccords méritent un examen manuel.

Faire passer le même code généré par l’IA dans deux ou trois LLM différents est l’une des étapes de relecture au meilleur rapport gain-effort que vous puissiez faire. Cela prend cinq minutes et détecte ce qu’un seul relecteur manque.

Construire votre flux de relecture

Un bon processus de relecture ne s’improvise pas à chaque fois. C’est une checklist reproductible qui devient une habitude.

La checklist à réutiliser

Voici une checklist de relecture condensée pour le code généré par l’IA. Utilisez-la à chaque fois, sans sauter de phase.

Phase 1\u00a0: avant la lecture

• Est-ce que je connais le prompt qui a généré ce code\u00a0?
• Ai-je lancé les outils d’analyse statique\u00a0?
• Ai-je lancé un scanner de secrets\u00a0?
• Ai-je vérifié les nouvelles dépendances dans les bases de vulnérabilités\u00a0?

Phase 2\u00a0: sécurité

• Une concaténation de chaînes avec une entrée utilisateur atteint-elle du SQL, du shell ou du HTML\u00a0?
• Y a-t-il des identifiants, tokens ou clés d’API dans le code source\u00a0?
• Y a-t-il des appels réseau qui ne valident ni n’assainissent les réponses\u00a0?
• Y a-t-il des opérations sur des fichiers utilisant des chemins contrôlés par l’utilisateur\u00a0?
• Une fonction contourne-t-elle des contrôles d’authentification ou d’autorisation\u00a0?

Phase 3\u00a0: logique

• Que se passe-t-il avec des entrées nulles ou vides\u00a0?
• Que se passe-t-il aux valeurs limites (0, -1, max)\u00a0?
• Les gestionnaires d’exceptions traitent-ils réellement les erreurs ou les masquent-ils\u00a0?
• Les bornes de boucle sont-elles correctes\u00a0? Parcourez manuellement la première et la dernière itération.
• Cette fonction suppose-t-elle implicitement un ordre d’appel ou un état particulier\u00a0?

Phase 4\u00a0: tests

• Les tests existants couvrent-ils les nouveaux chemins de code\u00a0?
• Y a-t-il des tests pour les cas limites identifiés plus haut\u00a0?
• Les tests couvrent-ils les chemins d’échec, et pas seulement le cas nominal\u00a0?

Quand rejeter et quand itérer

Tout code généré par l’IA ne mérite pas une révision. Certains doivent être rejetés d’emblée.

Rejetez lorsque :

• Les failles de sécurité sont structurelles, et non superficielles (par exemple, toute l’approche d’authentification est viciée)
• La logique ne correspond pas à l’exigence métier, et l’écart est trop profond pour être corrigé
• Le code introduit un modèle d’architecture qui entre en conflit avec les conventions existantes

Itérez lorsque :

• Les problèmes sont localisés à des fonctions ou blocs précis
• La structure est correcte mais certains cas limites manquent
• La gestion des erreurs est insuffisante mais la logique centrale est saine

L’objectif n’est pas de corriger le code de l’IA jusqu’à ce qu’il passe la relecture. L’objectif est de livrer du code sûr et correct. Parfois, le chemin le plus efficace est une réécriture propre avec de meilleurs prompts.

Essayez sur PicassoIA

Si cet article vous amène à réfléchir à la manière dont les modèles d’IA raisonnent sur le code, la meilleure prochaine étape est de le tester vous-même. PicassoIA vous donne accès à GPT 5, Claude 4.5 Sonnet, DeepSeek R1, Kimi K2 Instruct, Gemini 3 Pro et des dizaines d’autres modèles, tous au même endroit, sans aucune configuration.

Prenez un morceau de code généré par l’IA que vous avez déjà. Faites-le passer dans deux ou trois modèles différents avec les prompts de relecture de cet article. Comparez ce que chacun trouve. Vous verrez immédiatement comment des styles de raisonnement différents détectent des problèmes différents, et vous aurez une image plus claire de vos véritables lacunes en relecture.

Les modèles disponibles sur PicassoIA ne servent pas qu’à écrire du code. Ils servent à raisonner sur le code, à l’auditer et à le rendre plus sûr. C’est cette boucle qui fait réellement fonctionner le développement assisté par l’IA : générer avec un modèle, relire avec un autre, livrer en toute confiance.