Bien prompter une IA de code : la méthode qui change tout

« Fais-moi une todo-list » et « écris une fonction addTask qui ajoute une tâche à un tableau, avec un titre et une date, et écris trois tests pour vérifier qu’elle marche » ne donnent pas le même résultat, avec la même IA, sur le même projet. La différence n’est pas la chance : c’est la méthode. Voici celle que documentent, chacun de leur côté, Anthropic et GitHub.

Donner du contexte, pas juste une demande

La documentation officielle de Claude propose une image utile : traite l’IA comme « une employée brillante, mais nouvelle, qui ne connaît pas encore tes habitudes ». Plus tu expliques précisément ce que tu veux, meilleur est le résultat. Elle propose même une règle simple pour vérifier ton propre prompt : montre-le à un collègue qui n’a presque aucun contexte sur la tâche. S’il serait perdu, l’IA le sera aussi.

Concrètement, ça veut dire préciser le format de sortie attendu, les contraintes, et donner des exemples quand c’est possible. La documentation de GitHub Copilot recommande la même logique dans l’autre sens : commence par une description générale de l’objectif, puis ajoute les exigences précises une par une, et évite les termes vagues comme « ça » ou « ce truc » quand plusieurs éléments pourraient correspondre.

Avant : « améliore le formulaire d’inscription » Après : « le formulaire d’inscription doit refuser un mot de passe de moins de 8 caractères et afficher le message d’erreur sous le champ concerné, pas dans une popup »

Dans les deux cas, la question à te poser avant d’envoyer le message est la même : si tu donnais ce prompt à un camarade qui n’a jamais vu ton projet, saurait-il exactement quoi faire ? Si la réponse est non, l’IA butera sur les mêmes zones d’ombre que lui.

Donner un rôle à l’IA, et dire pourquoi

La documentation de Claude sur le prompt engineering propose une autre astuce simple : donner un rôle à l’IA en début de conversation. Une seule phrase change déjà le résultat, par exemple « tu es un développeur pédagogue : à chaque fois que tu proposes du code, explique en deux phrases pourquoi tu as fait ce choix plutôt qu’un autre. » Pour un étudiant qui apprend en même temps qu’il construit, ce réglage de départ transforme l’IA en quelque chose qui explique, pas seulement en quelque chose qui produit.

La même documentation ajoute un principe qui sert tous les jours : expliquer le pourquoi, pas seulement le quoi. Son exemple est parlant. Plutôt que d’écrire « n’utilise jamais de points de suspension », il est plus efficace d’écrire « ta réponse sera lue à voix haute par une synthèse vocale, donc n’utilise jamais de points de suspension, parce que la synthèse vocale ne saura pas les prononcer. » Une IA de code réagit pareil : si tu expliques que tel fichier ne doit jamais être modifié parce qu’il est généré automatiquement, ou que telle bibliothèque est à éviter parce qu’elle a été abandonnée, l’IA généralise cette raison à des cas que tu n’as pas prévus, au lieu de se contenter d’obéir une seule fois.

Découper une tâche complexe en petites tâches

La documentation de GitHub Copilot est directe sur ce point : « si tu veux qu’une IA termine une tâche complexe ou large, découpe la tâche en plusieurs tâches simples et petites. » Un exemple qu’elle donne : plutôt que de demander « génère un mots-croisés » d’un coup, on demande d’abord la grille de lettres, puis la recherche des mots, puis l’assemblage des deux.

La documentation de Claude Code illustre la même idée avec un tableau avant/après : plutôt que « ajoute des tests pour foo.py », préciser « écris un test pour foo.py qui couvre le cas où l’utilisateur est déconnecté, sans utiliser de mocks ». Le niveau de détail change tout : la première version laisse l’IA deviner ce qui compte vraiment, la seconde ne laisse rien au hasard.

Demander un plan avant le code

Une erreur fréquente : demander directement du code sur un projet qu’on ne connaît pas encore soi-même en détail. Le résultat peut sembler correct sans résoudre le bon problème. La documentation de Claude Code recommande un déroulé en quatre temps : explorer (lire le projet, poser des questions, sans rien modifier), planifier (demander un plan détaillé), implémenter (exécuter le plan validé), committer (enregistrer le résultat avec un message clair).

Un prompt qui applique ce déroulé :

Explore le dossier src/auth et explique-moi comment
fonctionne la connexion actuellement.

puis, une fois la réponse lue :

Je veux ajouter la connexion par email. Quels fichiers
faut-il modifier ? Propose-moi un plan avant de toucher au code.

Ce n’est qu’après avoir lu et validé ce plan qu’on demande l’implémentation.

Exiger un moyen de vérifier

Une IA de code s’arrête quand le résultat « a l’air » terminé. Sans rien pour vérifier objectivement, cette impression est la seule information disponible, et elle se trompe parfois. La documentation de Claude Code conseille de toujours donner un moyen de vérification : un test, une capture d’écran à comparer, un résultat attendu précis.

Avant : « implémente une fonction qui valide les adresses e-mail » Après : « écris une fonction validateEmail. Cas de test : “user@exemple.com” doit être valide, “invalide” ne doit pas l’être, “user@.com” ne doit pas l’être non plus. Lance les tests une fois la fonction écrite. »

La seconde version donne à l’IA (et à toi) un critère net pour savoir si c’est vraiment terminé, plutôt qu’une impression.

Relire, et itérer sans t’énerver

Aucun guide officiel ne prétend qu’une IA de code a toujours raison. La documentation de GitHub Copilot le dit sans détour : « elle peut se tromper, donc valide toujours le code suggéré et comprends-le avant de l’utiliser. » Et si le résultat ne convient pas du premier coup, la même documentation recommande simplement de reformuler et réessayer, plutôt que d’insister sur un prompt qui n’a pas fonctionné.

La documentation de Claude Code va plus loin sur ce point précis : si tu as corrigé la même erreur plus de deux fois dans la même conversation, le contexte est probablement encombré d’essais ratés. Mieux vaut effacer (/clear) et repartir avec un prompt plus précis, qui intègre ce que tu viens d’apprendre, qu’insister indéfiniment.

À retenir

• Donne du contexte comme si tu expliquais la tâche à quelqu’un qui découvre tout : format attendu, contraintes, exemples.
• Découpe une tâche complexe en plusieurs demandes simples plutôt que tout demander d’un coup.
• Demande un plan avant le code dès que la tâche touche plusieurs fichiers ou un projet que tu ne connais pas encore bien.
• Donne toujours un moyen de vérifier objectivement le résultat : un test, un cas précis, une capture d’écran de référence.
• Relis ce que l’IA propose avant de l’utiliser, et si ça ne marche pas après deux corrections, repars avec un prompt plus précis plutôt que d’insister.

Des modèles de prompts prêts à copier pour chacune de ces étapes se trouvent dans la skill prompts-vibe-coding.