Guides

Comment vérifier du code écrit par l'IA quand on ne sait pas coder

Publié: 3 juillet 2026 · Mis à jour: 3 octobre 2026

Si vous vous contentez de vérifier que ce que l’IA a construit fonctionne, vous ne vérifiez que la moitié : que cela fait ce que vous avez demandé. Ce qui ne se voit pas à l’écran, c’est ce qu’il fait d’autre. Quatre risques se logent là : une clé ou un mot de passe laissé à la vue de tous, des données qui partent vers un service que vous ne connaissez pas, quelque chose qui supprime ou exécute plus que prévu, et une bibliothèque (un morceau de programme écrit par d’autres, que votre projet réutilise) peu sûre, voire inventée. Aucun ne se manifeste pendant que vous testez et que tout va bien. Pour les couvrir, inutile de lire le code : il suffit de savoir quoi demander et où regarder.

« Ça marche » ne répond qu’à une question

Imaginez que vous demandiez à une IA un formulaire de réservation pour votre salon de coiffure. Vous enregistrez un rendez-vous d’essai, il s’affiche dans la liste, et vous validez. Ce test vous confirme que le rendez-vous est bien enregistré. Il ne vous dit pas si n’importe qui ayant le lien peut voir les rendez-vous des autres, ni où finit le numéro de téléphone de vos clientes.

Les éditeurs eux-mêmes le disent. Dans sa documentation, GitHub prévient que Copilot Chat peut générer du code qui paraît valide sans être correct, ni sur le fond ni sur la forme, et demande d’examiner et de tester soigneusement le code généré, « en particulier pour les applications critiques ou sensibles ». Anthropic le résume en une ligne dans la documentation de Claude Code : « Vous êtes responsable de l’examen du code et des commandes proposés pour la sécurité avant approbation. »

Même ceux qui vendent l’outil ne vous promettent pas qu’il suffit de voir que ça marche.

Les quatre risques que le résultat ne montre pas

Risque	Pourquoi vous ne le voyez pas en testant	Que demander à l’IA
Clés et mots de passe exposés	L’application marche aussi bien avec la clé rangée en lieu sûr qu’avec la clé collée dans un fichier public	« Quelles clés ce projet utilise-t-il, et où est rangée chacune ? »
Données qui partent, ou que n’importe qui peut lire	Vous testez connecté à votre compte et vous ne voyez que vos propres données	« À quels services extérieurs envoie-t-il des données, et lesquelles ? Que voit quelqu’un qui n’est pas connecté ? »
Suppressions et commandes en trop	Les dégâts arrivent le jour où quelque chose déraille, pas le jour du test	« Qu’est-ce que ça peut supprimer ou écraser ? Quelles commandes ça lance sur mon ordinateur ? »
Bibliothèques peu sûres ou inventées	Elles s’installent en arrière-plan et ne changent rien à ce que vous voyez	« Donne-moi la liste de tout ce que tu as installé, et à quoi sert chaque élément. »

Des clés à la vue de tous

Pour se connecter à d’autres services, votre projet utilise des clés d’API. Anthropic les décrit ainsi : « Votre clé API est une clé numérique d’accès à votre compte. Tout comme un numéro de carte de crédit, si quelqu’un obtient et utilise votre clé API, des frais seront facturés à votre compte. » La même page cite parmi les causes de fuite les plus fréquentes l’exposition accidentelle dans des dépôts de code publics (le dossier du projet mis en ligne, visible de tous). Et l’application tourne exactement pareil, que la clé soit bien rangée ou publiée.

Version française du même piège : la clé d’API de votre hébergeur. Beaucoup de projets tournent en France chez OVHcloud ou Scaleway, et un script qui inscrit un jeton en dur donne à quiconque le lit la main sur vos serveurs, pas seulement sur votre code. Demandez à l’IA de ranger les identifiants dans un fichier d’environnement plutôt que dans le code.

Des données qui partent, ou qui restent ouvertes

Il y a là deux défauts différents. Le projet peut envoyer des données à un service extérieur sans que vous le sachiez. Ou il peut les garder au bon endroit en laissant la porte ouverte. Supabase, un service qui stocke les données d’une application, prévient dans sa documentation qu’une table accessible de l’extérieur sans « sécurité au niveau des lignes » (RLS, en anglais Row Level Security) peut être lue et modifiée par n’importe quel rôle qui y a accès, et demande d’activer cette protection sur toutes ces tables. Selon la façon dont le projet est monté, ce « n’importe qui » peut englober bien plus de monde que vous ne l’imaginez. Avec votre compte de test, vous ne le remarquerez jamais.

En France, la loi s’en mêle aussi. Si ce que vous stockez ou envoyez est le nom, le téléphone ou l’e-mail d’un client, ce sont des données personnelles : le RGPD et la loi Informatique et Libertés s’appliquent, et c’est la CNIL qui veille. Quand votre application envoie ces données à un service situé hors de l’Union européenne, la CNIL rappelle que le transfert n’est possible que si un niveau de protection suffisant et approprié est assuré. C’est vous qui en répondez, pas l’outil qui a écrit le code. Ceci est une orientation, pas un conseil juridique : si votre projet manipule des données de clients, parlez-en à un professionnel.

Des suppressions et des commandes en trop

Un assistant qui travaille directement sur votre ordinateur, comme Claude Code, peut modifier des fichiers et lancer des commandes (des ordres écrits donnés à l’ordinateur). D’après la documentation d’Anthropic, en mode manuel, il vous demande la permission avant de le faire. En mode auto, qui est selon cette même page le mode de départ des sessions interactives dans le terminal (la fenêtre où l’on tape des commandes) et dans l’éditeur VS Code, ce n’est plus vous qui examinez chaque action : c’est un modèle d’IA distinct, qui bloque ce qu’il juge dangereux. Si vous voulez voir chaque demande, vérifiez dans quel mode vous êtes. Cette demande, c’est votre relecture : si vous cliquez sur accepter sans la lire, vous l’avez sautée. Garder une copie à laquelle revenir aide beaucoup ; nous l’expliquons dans les checkpoints de Claude Code face à git.

Des bibliothèques peu sûres ou inventées

Presque aucun projet ne part de zéro : il s’appuie sur des bibliothèques écrites par d’autres. L’OWASP, une fondation consacrée à la sécurité des logiciels, range parmi les risques des modèles de langage le fait de suggérer des bibliothèques peu sûres ou qui n’existent pas. Elle décrit aussi l’attaque qui suit : certains repèrent les noms que les assistants inventent souvent et publient des paquets malveillants sous ces noms-là. C’est la version lourde de conséquences d’une hallucination.

Comment vérifier sans lire une seule ligne

Commencez par les quatre questions du tableau, telles quelles. Ajoutez-en deux :

« Explique-moi ce que fait ce projet comme si je ne savais pas coder, et dis-moi ce qui pourrait mal tourner. »
« Que se passe-t-il si quelqu’un tape n’importe quoi dans le formulaire ? »

Puis vérifiez vous-même ce qui est à votre portée, et c’est plus que vous ne le pensez :

Ouvrez l’application dans une fenêtre de navigation privée, sans vous connecter, et essayez de voir des données que vous ne devriez pas voir.
Cherchez chaque bibliothèque de la liste par son nom. Si vous ne trouvez ni page officielle ni personne qui en parle, n’allez pas plus loin tant que l’IA ne vous a pas dit d’où elle la sort.
Lisez chaque demande d’autorisation avant de l’accepter. Si vous ne comprenez pas une commande, demandez à l’IA de vous l’expliquer simplement et de vous dire ce qui se passerait si elle tournait mal.
Demandez un deuxième avis. Une autre IA peut relire le même code et vous dire ce qui l’inquiète. Avant de le coller, passez-le dans notre Contrôle de confidentialité : il tourne dans votre navigateur et vous signale les clés d’API, les lignes du type « mot de passe : … », les e-mails et les numéros de téléphone, pour que vous ne les partagiez pas sans le vouloir.

Une réserve sur la méthode : l’IA peut se tromper en expliquant son propre code. Si une réponse reste vague ou change quand vous reposez la question, prenez-le comme un signal pour ralentir. Et si l’IA se met à toucher à des choses que vous n’avez pas demandées, le problème est peut-être ailleurs ; nous en parlons dans pourquoi l’IA modifie le mauvais fichier.

Quand regarder le résultat suffit

Tout dépend de qui paie l’erreur.

Pour un projet rien que pour vous, sans les données de personne d’autre et sans clé qui puisse vous coûter de l’argent (une calculette, un petit programme qui trie vos photos, à condition d’en avoir une copie), regarder le résultat suffit en général. Testez, apprenez, ne vous mettez pas la pression.

Dès qu’il y a des utilisateurs, des données ou l’argent d’autres personnes, regarder le résultat ne suffit plus. Une boutique en ligne, les réservations d’un commerce ou les factures d’un cabinet comptable en font partie. Les questions ci-dessus vous permettent d’arriver bien préparé, mais avant la mise en ligne, faites relire le projet par quelqu’un qui sait lire du code.

Si c’est déjà en ligne et que quelque chose vous inquiète

D’abord, les clés. Si vous pensez qu’une clé a fuité, Anthropic recommande de la révoquer immédiatement. Cela se fait sur le site du service qui vous l’a fournie, puis vous en créez une nouvelle.

Pour tout le reste, en France, il existe 17Cyber, le service public d’assistance en ligne de Cybermalveillance.gouv.fr. Il propose gratuitement un diagnostic et des conseils aux particuliers, entreprises, associations et collectivités victimes de cybermalveillance.

En résumé

Voir que ça marche n’est que la première étape. Posez les quatre questions, vérifiez de vos propres mains ce que vous pouvez, et faites appel à quelqu’un dès que les données ou l’argent d’autres personnes sont en jeu.

Pour savoir quoi ne jamais coller dans un chat, voyez la liste courte de ce qu’il ne faut pas partager avec ChatGPT. Et si vous choisissez encore avec quoi construire, notre outil gratuit IA pour développeurs, qui sert aussi aux débutants malgré son nom, vous aide à choisir un assistant, à l’installer sur votre système et à démarrer avec des réglages qui font de la relecture des changements une habitude.

Questions fréquentes

Quels risques prend-on en vérifiant seulement le résultat, sans regarder le code ? +

Tester le résultat vous dit que l'application fait ce que vous avez demandé, pas ce qu'elle fait d'autre. Quatre choses passent à travers : une clé ou un mot de passe laissé à la vue de tous, des données qui partent vers un autre service ou que n'importe qui peut lire, des actions qui suppriment ou exécutent plus que prévu, et des bibliothèques peu sûres ou carrément inventées. Aucune ne se remarque tant que tout fonctionne.

Comment vérifier du code écrit par l'IA si je ne sais pas lire le code ? +

Avec des questions plutôt qu'avec de la lecture. Demandez à l'IA quelles clés le projet utilise et où elle les a rangées, à quels services il se connecte et quelles données il envoie, ce qu'il peut supprimer ou modifier, et ce qu'elle a installé. Vérifiez ensuite vous-même ce qui est à votre portée : ouvrez l'application sans vous connecter, cherchez chaque bibliothèque par son nom et lisez les commandes qu'on vous demande d'approuver.

Peut-on se fier à l'explication que l'IA donne de son propre code ? +

C'est un point de départ, pas une garantie. GitHub prévient que son assistant peut générer du code qui paraît valide sans être correct, et l'explication peut se tromper de la même façon. Recoupez les réponses importantes avec une vérification que vous faites vous-même, ou avec une personne qui sait lire du code dès qu'il y a les données ou l'argent d'autres gens en jeu.

Que faire si j'ai déjà mis en ligne une application faite avec l'IA et que je soupçonne un problème ? +

Si vous pensez qu'une clé a fuité, Anthropic recommande de la révoquer immédiatement. Cela se fait sur le site du service qui vous a fourni la clé, puis vous en créez une nouvelle. Pour le reste, en France, le service public 17Cyber de Cybermalveillance.gouv.fr propose gratuitement un diagnostic et une assistance en ligne aux particuliers, entreprises, associations et collectivités.