Prompt Engineering
Obtenir des résultats fiables d’un modèle IA — volontairement, pas par chance.
La plupart des gens plafonnent avec l’IA après quelques semaines. Ils obtiennent des démos impressionnantes et des résultats non fiables, et ils accusent le modèle. Le problème vient rarement du modèle : un prompt est une spécification, et presque personne n’a appris à en écrire une. Ce parcours traite le prompting comme de l’ingénierie, pas comme du folklore. Vous commencez par la structure : ce que le modèle lit réellement, pourquoi l’ordre compte, et pourquoi « sois créatif » échoue là où un exemple travaillé réussit. Vous apprenez ensuite à mesurer, car un prompt qu’on ne sait pas évaluer est un prompt qu’on ne sait pas améliorer — c’est l’étape que presque tout le monde saute, et c’est elle qui sépare l’amateur du professionnel. Vient ensuite l’ingénierie du contexte, là où se trouve le vrai levier : ce que vous mettez autour de la question compte plus que la formulation de la question. Vous terminez sur les patterns de production — versionner, tester les régressions, maîtriser coût et latence, poser des garde-fous — ce qui décide si votre travail survit au contact d’utilisateurs réels. Pas d’astuces, pas de listes de mots magiques : ça vieillit mal. Les principes, non.
Ce que vous allez apprendre
Prérequis
- Aucune programmation requise
- Savoir écrire clairement dans une langue
- Accès à un assistant IA moderne
Débouchés
- Prompt Engineer
- Stratège contenu IA
- Spécialiste augmenté par l’IA (tout métier)
- Designer d’IA conversationnelle
Phases
Phase 1 — La structure
Arrêter de deviner. Comprendre ce que le modèle lit et pourquoi l’ordre change la réponse.
Durée estimée · 3-4 semainesCe que le modèle lit vraiment
Les tokens, la fenêtre de contexte et l’attention expliquent l’essentiel des comportements « bizarres ». Les maths ne sont pas nécessaires, le modèle mental si : il explique pourquoi un long prompt dérive et pourquoi une instruction placée à la fin l’emporte parfois.
Sujets couverts
Ce que vous allez construire
- Réparer un prompt défaillant en ne changeant que l’ordre
- Mesurer le coût en tokens de vos 5 prompts les plus utilisés
- Lancer le même prompt 10× et documenter la variance
Le prompt comme spécification
Rôle, tâche, contraintes, format, exemples. La plupart des mauvaises sorties viennent d’une demande sous-spécifiée, pas d’un modèle faible. Vous réécrirez des demandes floues en spécifications qu’un inconnu compétent pourrait exécuter — c’est précisément le niveau qu’attend le modèle.
Sujets couverts
Ce que vous allez construire
- Réécrire 10 prompts flous en spécifications
- Construire un template réutilisable pour votre tâche la plus fréquente
- Forcer une sortie JSON structurée et la valider
Les modes d’échec que vous rencontrerez
Apprenez à nommer ce qui a raté avant d’essayer de le réparer. Un modèle qui invente une source, un modèle qui ignore la moitié de vos instructions et un modèle qui répond à une question que vous n’avez pas posée sont trois bugs différents avec trois correctifs différents — les confondre est précisément pourquoi on réécrit un prompt pendant des heures sans progresser. Nommer la défaillance, c’est déjà la moitié du remède.
Sujets couverts
Ce que vous allez construire
- Constituer un catalogue de vos 5 échecs les plus fréquents, avec un exemple reproductible de chacun
- Provoquer volontairement une hallucination, puis la rendre impossible
- Trouver la longueur à partir de laquelle votre prompt ignore l’instruction n°1
Phase 2 — La mesure
Un prompt qu’on ne peut pas évaluer est un prompt qu’on ne peut pas améliorer. C’est la phase que tout le monde saute.
Durée estimée · 3-4 semainesConstruire un jeu de test
Vingt cas réels valent mieux que mille cas imaginés. Vous collecterez de vrais inputs — y compris les cas limites pénibles qu’on préfère ignorer — et définirez ce que « bon » veut dire avant d’optimiser.
Sujets couverts
Ce que vous allez construire
- Construire un jeu de 20 cas pour une tâche réelle
- Écrire la grille avant de regarder la moindre sortie
- Noter votre prompt actuel comme référence
Itérer sur des preuves
Changer une chose, relancer le jeu, comparer. C’est peu glamour et c’est tout le métier. Vous verrez aussi où le LLM-juge aide et où il vous ment discrètement.
Sujets couverts
Ce que vous allez construire
- Améliorer un prompt de 20 % sur votre grille — avec preuves
- Construire une feuille de score relancée à chaque changement
- Trouver un cas où le LLM-juge se trompe
Lire ses résultats honnêtement
Le plus dur dans l’évaluation n’est pas de construire le jeu de test — c’est de ne pas se mentir avec. Vous choisirez inconsciemment les cas que votre prompt gère déjà, vous noterez généreusement un vendredi soir, et vous retiendrez la réponse impressionnante plutôt que la réponse médiane. Vingt cas, c’est un petit échantillon : un écart de deux points est du bruit, pas un progrès, et le prendre pour un progrès est exactement comment une équipe se persuade pendant des mois qu’elle avance. Apprenez à distinguer un vrai gain d’un tirage chanceux, et à dire tout haut qu’un changement a empiré les choses.
Sujets couverts
Ce que vous allez construire
- Noter 20 sorties à l’aveugle, sans savoir quelle version du prompt les a produites
- Relancer votre meilleur prompt 5× et vérifier que votre « gain » survit à la variance
- Rédiger un changement qui a empiré les choses, et le partager à votre équipe
Phase 3 — Contexte & production
Passer du prompt malin au système qui tient avec de vrais utilisateurs, un vrai coût et un vrai risque.
Durée estimée · 4-6 semainesL’ingénierie du contexte
Le vrai levier n’est pas la formulation, c’est ce que vous mettez autour de la question. Récupération, compression, et savoir quoi omettre. La plupart des « le modèle est bête » sont des problèmes de contexte manquant.
Sujets couverts
Ce que vous allez construire
- Construire un Q&R ancré sur vos propres documents
- Réduire le contexte de 50 % sans perdre en qualité
- Forcer le modèle à citer sa source à chaque affirmation
Mettre en production et vivre avec
Versioning, coût, latence, modes de défaillance, garde-fous. Un prompt en production, c’est du code : il lui faut un historique, une suite de tests, et quelqu’un qui remarque qu’il casse à 3 h du matin.
Sujets couverts
Ce que vous allez construire
- Livrer un workflow propulsé par prompt à de vrais utilisateurs
- Diviser son coût par deux sans perdre en score
- Casser votre propre prompt par injection, puis le réparer
Travailler en multilingue
Presque tous les guides supposent que vous travaillez en anglais. Ici, la plupart des gens non. Les modèles sont mesurablement plus faibles hors de l’anglais, et plus faibles encore sur les dialectes — la darija marocaine mêle arabe, français et amazigh, change d’alphabet en milieu de phrase et n’a pas d’orthographe stabilisée : un modèle entraîné surtout sur de l’anglais n’a pas grand-chose à quoi se raccrocher. Les vraies questions sont : dans quelle langue faire raisonner le modèle, dans laquelle répondre, et comment évaluer une traduction quand on ne lit couramment qu’une des deux langues. Cette étape n’est pas décorative : si vos utilisateurs écrivent en darija, c’est tout le métier.
Sujets couverts
Ce que vous allez construire
- Construire un jeu de test d’inputs réels en darija, chaos orthographique compris
- Comparer « raisonner en anglais puis répondre en français » à « tout faire en français »
- Mesurer le coût en tokens du même texte en arabe vs en français
Questions
Le prompt engineering est-il encore une vraie compétence, ou les modèles vont-ils le rendre obsolète ?
La version « astuces » est déjà obsolète — les formules magiques ne marchent plus depuis des années. Ce qui demeure, c’est la spécification : énoncer une tâche précisément, décider ce que « bon » signifie, et le mesurer. De meilleurs modèles relèvent le plafond, ils ne lisent pas dans vos pensées. Ce parcours enseigne la partie qui survit aux montées de version.
Faut-il savoir coder ?
Pas pour les phases 1 et 2 — les parties les plus difficiles et les plus rentables sont l’écriture et l’évaluation, pas la programmation. La phase 3 touche à la récupération et à la production, où un peu de Python ou un outil no-code aide. Pour construire des applications plutôt que les exploiter, enchaînez sur le parcours Applications LLM.
Pourquoi tant insister sur l’évaluation ?
Parce que c’est ce qui sépare la démo du produit. Sans jeu de test, on règle à l’intuition : chaque changement semble être une amélioration et on ignore si on a cassé le cas précédent. Les équipes qui mesurent progressent régulièrement ; les autres tournent en rond pendant des mois. C’est aussi la partie la moins amusante, donc la plus négligée — et donc la plus rentable.
Est-ce que ça marche en français et en darija, ou seulement en anglais ?
Les principes se transfèrent — une spécification reste une spécification dans n’importe quelle langue. Les résultats, eux, ne se transfèrent pas uniformément : les modèles voient bien plus d’anglais que de français, et bien plus de français que de darija ; à qualité de prompt égale, la sortie se dégrade à mesure qu’on s’éloigne de l’anglais. C’est une contrainte réelle, pas une raison d’abandonner : cela signifie que votre jeu de test doit être dans la langue que vos utilisateurs écrivent vraiment, et que la langue de raisonnement et la langue de réponse sont une décision à prendre, pas à subir. Ce parcours le traite explicitement, parce qu’un guide qui suppose que tout le monde travaille en anglais ne sert à rien à la plupart de ceux qui le lisent ici.
Parcours liés
Envie de suivre ce parcours avec un coach et une cohorte ?
Découvrir la 212AY Academy →