GUIDE MMK · CRÉER

Apprendre à lire le code produit par une IA

Repérer les cinq endroits qui posent problème, sans devenir développeur.

Débutant8 min de lecture20 min par projetMis à jour le 26 juillet 2026
Photo : Nemuel Sereti / Pexels

LE CADRE DU GUIDE

Savoir où l’on va avant de commencer.

CE QUE VOUS ALLEZ OBTENIRRepérer les cinq endroits qui posent problème, sans devenir développeur.

Lire du code ne signifie pas tout connaître. Il faut pouvoir suivre le trajet d’une information, reconnaître les fichiers qui changent le comportement et vérifier les conséquences d’une modification.

Pour qui
Créateur d’application · Entrepreneur · Développeur débutant
Temps de mise en œuvre
20 min par projet
Coût
Gratuit avec un éditeur ; abonnement facultatif pour l’assistant.
Prérequis
Un projet de petite taille · Une copie de sauvegarde · Un environnement de test

POURQUOI J'AI ÉCRIT CE GUIDE

Un petit programme devait trier mes photos et supprimer les doublons. Il a annoncé : « 1 247 doublons supprimés ».

Il comparait les fichiers par leur nom. Deux appareils différents produisent des IMG_0042.jpg qui n'ont rien à voir. Pas de corbeille. Pas de sauvegarde.

Je n'avais pas besoin de savoir coder pour éviter ça. Il suffisait de lire deux mots : « supprime » et « par leur nom ».


LE RÉSULTAT

Savoir ce que fait un programme, où il peut vous coûter cher, et quoi demander pour le corriger.

Lire du code produit par une IA ne consiste pas à le comprendre ligne à ligne. Cela consiste à regarder cinq endroits précis, toujours les mêmes, qui concentrent l'essentiel des problèmes réels. Vingt minutes, aucune formation.

Ce que vous repartez avec : la checklist des cinq zones, le vocabulaire minimal pour demander une correction, deux prompts.


LE TEST DE DÉPART

  1. Sauriez-vous dire ce que fait le dernier programme qu'on vous a généré ?
  2. Savez-vous s'il envoie des informations quelque part ?
  3. Y a-t-il un mot de passe ou une clé écrite en clair dedans ?
  4. Sauriez-vous revenir en arrière si la dernière modification a tout cassé ?

La troisième coûte le plus cher quand la réponse est « je ne sais pas ».


LE PRINCIPE

On ne lit pas le code. On lit ses frontières. Ce qui entre, ce qui sort, ce qu'il touche. Un programme dangereux n'est presque jamais un programme mal écrit. C'est un programme qui a accès à quelque chose auquel il ne devrait pas avoir accès.

Le code généré fonctionne souvent, mais suppose beaucoup. Il suppose que le fichier existe, que la connexion marche, que la donnée a le bon format. Ces suppositions ne se voient pas quand tout va bien. Elles se voient le jour où ça casse, c'est-à-dire au pire moment.

Le pouvoir de correction vient du vocabulaire. « Ça marche pas » produit une réécriture aléatoire. « À la ligne 40, quand le fichier est vide, le programme s'arrête sans message » produit un correctif.

EN CLAIR — On ne lit pas le code. On lit ce qu'il touche.


LES CINQ ZONES

Zone 1 — Les secrets en clair

Cherchez : key, token, password, secret, api. Une longue suite de caractères aléatoires juste après, et c'est une clé d'accès écrite en clair.

Pourquoi c'est le premier point : si ce fichier est publié quelque part, la clé devient utilisable par n'importe qui — et souvent facturée sur votre compte.

Ce qu'on demande : « Sors les clés du code et fais-les lire depuis un fichier de configuration séparé, non publié. »

Zone 2 — Ce qui sort de votre machine

Cherchez : http, fetch, request, upload. Chaque occurrence est un endroit où le programme parle à l'extérieur.

La question : est-ce que j'ai demandé ce contact-là ? Un programme censé renommer des fichiers locaux n'a aucune raison d'appeler une adresse sur Internet.

Zone 3 — Ce qui supprime ou écrase

Cherchez : delete, remove, unlink, drop, overwrite, rm.

La question : sur quoi porte l'opération, exactement ? Existe-t-il une copie avant ?

Faites toujours tourner un programme qui supprime sur une copie du dossier, la première fois. Toujours.

Zone 4 — Les cas non traités

Cherchez l'absence de : try, except, catch, if not, else. Un programme sans gestion d'erreur fonctionne parfaitement tant que tout est normal.

Ce qu'on demande : « Que se passe-t-il si le fichier est vide, si la colonne attendue n'existe pas, si la connexion échoue ? Ajoute un message clair pour chacun de ces cas plutôt qu'un arrêt brutal. »

Zone 5 — Ce qu'on installe

Cherchez : import, require, install. Chaque ligne ajoute un composant écrit par quelqu'un d'autre.

La question : ce nom existe-t-il vraiment, et est-il connu ? Les assistants inventent parfois des noms plausibles. Un nom inventé installé sans vérification est un vrai risque, parce que quelqu'un peut avoir enregistré ce nom exprès.


L'OBJECTION

« Cinq zones, c'est une illusion de contrôle : les vrais problèmes sont ailleurs, dans la logique. » Un développeur a raison de le dire.

Je l'assume. Ce guide ne détecte pas les erreurs de logique. Il détecte les dégâts irréversibles : suppression, fuite de clé, appel réseau non voulu. Ce n'est pas la même ambition, et il ne faut pas la confondre.

Pour un non-développeur, la question n'est pas « ce code est-il bon ». C'est « ce code peut-il me coûter cher ». Les cinq zones répondent à la seconde, et seulement à elle.


PROMPTS

Faire expliquer avant d'exécuter

Explique ce programme à une personne qui ne code pas. Réponds en
cinq points : 1) ce qu'il fait, en une phrase ; 2) les fichiers ou
dossiers qu'il lit ; 3) ceux qu'il modifie ou supprime ; 4) les
adresses ou services extérieurs qu'il contacte ; 5) ce qui se passe
si une donnée manque. N'utilise aucun terme technique non expliqué.

L'audit croisé

Voici un programme produit par un autre assistant. Sans le
réécrire, signale : les identifiants ou clés en clair, les
opérations destructives, les appels réseau, les cas d'erreur non
traités, et les composants importés dont le nom te paraît douteux.
Classe par gravité.

Le second s'utilise dans une autre conversation, idéalement avec un autre assistant. Un modèle relit mal ce qu'il vient d'écrire, exactement comme un auteur relit mal son propre texte.


AVANT / APRÈS

Un programme doit trier les photos d'un dossier par date et supprimer les doublons.

AVANT — exécuté directement sur le dossier photos

Le programme fonctionne. Il annonce : « 1 247 doublons supprimés ».

Sauf que la détection reposait sur le nom du fichier, pas sur le contenu. Deux appareils différents produisent les mêmes noms sans produire les mêmes images. Pas de corbeille. Pas de sauvegarde.

APRÈS — vingt minutes de lecture, sur une copie

Avant d'exécuter, le prompt 1. La réponse indique, au point 3 : « supprime des fichiers du dossier source, sans copie de sauvegarde ». Et au point 2 : « compare les fichiers par leur nom ».

Deux informations suffisent. La demande devient :

« Ne supprime rien. Déplace les doublons dans un sous-dossier "à vérifier". Compare les fichiers par leur contenu, pas par leur nom. Affiche la liste avant d'agir et demande confirmation. »

Le programme déplace 89 fichiers au lieu d'en supprimer 1 247. Sur les 89, douze n'étaient pas des doublons.

Ce qui a changé : aucune compétence technique acquise. Une réponse lue en français, deux mots repérés, une demande précise formulée. C'est tout le contenu de ce guide.


CE QUE JE FAIS, MOI

Je fais tourner sur une copie. Toujours. C'est la seule règle que je n'ai jamais transgressée depuis les 1 247 photos.

Je fais relire par un autre assistant, dans une autre conversation. Un modèle défend ce qu'il vient d'écrire, exactement comme nous.

Ce que je néglige : les composants installés. Je vérifie rarement les noms. C'est un vrai angle mort, et je le laisse ouvert en connaissance de cause.


ERREURS FRÉQUENTES

ErreurCe qu'elle produitLa correction
Exécuter avant de faire expliquerOn découvre l'effet après coupPrompt 1, systématiquement
Tester sur les vraies donnéesDes erreurs irréversiblesUne copie, la première fois
Publier un fichier contenant une cléUn accès utilisable par n'importe quiZone 1, avant tout partage
Faire relire par l'assistant qui a écritIl défend sa propre logiqueUne autre conversation
Dire « ça marche pas »Une réécriture aléatoireLa ligne, la donnée, le comportement

POINTS DE CONTRÔLE

  • Je peux dire en une phrase ce que fait le programme
  • Aucune clé ni mot de passe en clair
  • Je connais tous les points de contact avec l'extérieur
  • Il a tourné une première fois sur une copie
  • Les erreurs produisent un message, pas un arrêt brutal
  • Les composants installés portent des noms vérifiés

Vous n'avez pas besoin de comprendre le code. Vous avez besoin de savoir ce qu'il peut détruire.

ACTUALITÉS ASSOCIÉES

Ce qui peut faire évoluer ce guide.