Série d'apprentissage de l'IA · Leçon 2 sur 4
L'écart entre une demande vague et une demande bien formulée dépasse souvent l'écart entre deux modèles. Un prompt n'est pas un souhait — c'est une spécification : un objectif, le contexte dont il dépend, les contraintes à respecter et la vérification à réussir.
Statut : plan. La démonstration à l'écran n'a pas encore été enregistrée — cet article est le plan qu'elle suivra, et il recevra la vraie démonstration une fois la leçon diffusée.
| Leçon | Sujet | Question traitée |
|---|---|---|
| 1 — L'usage des modèles | Niveau de modèle, contexte, tokens | De quel modèle cette tâche a-t-elle besoin ? |
| 2 — Prompt, projet et contexte | Structure du prompt, contexte permanent | Que place-t-on devant le modèle ? |
| 3 — Documentation, règles et skills | Structure du dépôt | Comment un dépôt reste-t-il cohérent d'une session à l'autre ? |
| 4 — Réduire le coût | Mesure, leviers, garde-fous | Comment dépenser moins sans perdre en qualité ? |
Ce que vous saurez faire
- Transformer une demande vague en un prompt qui tient la route
- Indiquer comment le résultat sera vérifié, pour que le modèle puisse se vérifier lui-même
- Configurer un projet pour que chaque session commence en connaissant déjà le travail — sans tout réexpliquer
S'appuie sur la leçon 1 : quel modèle, combien de contexte et à peu près quel coût. Cette leçon décide de ce qui entre dans ce contexte.
Hors périmètre : fichiers de règles, skills et structure documentaire du dépôt (leçon 3), et la réduction des dépenses (leçon 4). Dans cette leçon, « projet » désigne le contexte permanent que vous fournissez à un modèle, pas la configuration complète d'un dépôt.
Le prompt
Même modèle, deux prompts — la référence
- Une tâche réelle de ce projet passe par deux prompts sur le même modèle, côte à côte
- Le prompt n'a rien de magique — mais c'est souvent la plus grande variable
Anatomie du prompt — cinq parties
- Objectif — ce que vous voulez, en une phrase
- Contexte — les fichiers ou sections dont il dépend, cités plutôt que paraphrasés de mémoire
- Contraintes — ce qui ne doit pas changer, et quelles conventions s'appliquent
- Sortie — format, longueur et destination
- Terminé quand — la vérification que le résultat doit réussir
▶ show code▼ hide code
# Vague
Hide the lesson posts from the homepage.
# Structured
Goal: Hide posts marked `homepageExcluded: true` from the homepage
list, but keep them on /blog.
Context: src/lib/blog.ts — getListedPosts() and getHomepagePosts()
Constraints: Don't change getAllPosts(). `unlisted: true` still hides a
post from both lists.
Output: A minimal diff, no unrelated refactors.
Done when: Tests pass, and the homepage no longer lists the lessons
while /blog still does.
Critères d'acceptation — dites comment ce sera vérifié
- Les critères et les exemples donnent au modèle de quoi vérifier sa propre sortie
- La même tâche tourne avec et sans critères explicites — et chaque sortie est vérifiée par rapport à eux
Itérez sur le prompt, pas sur la sortie
- Quand une exécution échoue, le réflexe est de corriger la sortie à la main — résistez-y
- Diagnostiquez pourquoi le prompt a manqué sa cible, corrigez-le et relancez
- Sachez quand abandonner une conversation et repartir de zéro plutôt que de la corriger tour après tour
Le projet
Contexte permanent contre prompt ponctuel
| À placer dans… | Quand c'est vrai | Exemple |
|---|---|---|
| Le contexte permanent du projet | À chaque session | Stack, conventions, « ne jamais modifier src/components/ui/ » |
| Un prompt ponctuel | Pour cette tâche seulement | L'objectif, les fichiers concernés, la vérification d'acceptation |
- À l'écran : un projet est configuré, une instruction passe d'un prompt au contexte permanent — puis la différence est montrée
Contexte — délibéré, pas exhaustif
- Envoyez les fichiers pertinents, pas tout
- Citez la source réelle au lieu de la décrire de mémoire
- À l'écran : un long fichier collé en entier contre seulement la section utile, comparés sur la sortie et le coût en tokens
La liste du prompt
▶ show code▼ hide code
# Prompt Checklist — before you send
1. Goal stated in one sentence?
2. Context quoted from source, not paraphrased?
3. Constraints: what must not change?
4. Output format and destination stated?
5. "Done when" — a check the result can actually fail?
6. Anything here true for every session? Move it to project context.
7. Run failed? Fix the prompt, then rerun — don't hand-patch the output.
Vérifiez avant de vous y fier
Cette leçon ne nomme aucune fonctionnalité, limite ou tarif de produit précis. Avant l'enregistrement, chacun de ces points est vérifié dans la documentation actuelle du fournisseur :
- Le nom que l'outil présenté donne à sa fonction de contexte permanent, et ce qu'elle peut contenir
- Les limites de taille des fichiers joints ou de la base de connaissances du projet dans cet outil
- Si le modèle se comporte différemment avec le raisonnement étendu activé ou désactivé
- Si quelque chose ici contredit le guide de prompting actuel du fournisseur
Questions fréquentes
« Un prompt plus long n'est-il pas toujours meilleur ? » Non. Un prompt plus long avec le mauvais contexte est pire qu'un prompt court avec le bon. La structure l'emporte sur la longueur.
« Quand faut-il ouvrir une nouvelle conversation ? » Quand vous avez corrigé deux fois le même malentendu. Corrigez le prompt, puis repartez de zéro.
« Qu'est-ce qui va dans le contexte du projet ? » Tout ce qui est vrai à chaque session — la stack, les conventions, les interdits. Ce qui ne vaut que pour une tâche reste dans le prompt.
Ensuite : leçon 3
Un projet doté d'un bon contexte permanent fonctionne — jusqu'à ce que l'unité de travail devienne un dépôt entier. La leçon 3 découpe ce contexte en documentation, règles et skills, pour qu'un assistant d'IA cesse de s'écarter de ses propres conventions à chaque nouvelle session.