Ingénierie de Prompts & Architecture
Dépassez la conversation. Concevez des prompts sur lesquels une application peut compter.
Il y a un mur qu’on heurte après quelques mois d’usage quotidien de l’IA : les réponses sont assez bonnes pour impressionner un collègue, et très loin d’être assez bonnes pour être mises derrière un bouton que presse un client. Franchir ce mur, c’est l’objet de ce module, et ça n’a presque rien à voir avec les formulations astucieuses. Un prompt dans une fenêtre de chat a un filtre humain après lui : vous lisez la sortie, vous voyez qu’elle est fausse, vous relancez. Un prompt dans une application n’a pas ce luxe. Il doit rendre la même forme à chaque fois, échouer d’une manière que votre code sait rattraper, et encaisser des entrées que personne n’avait imaginées. On travaille donc ce que les gens sautent. La sortie structurée, parce que parser de la prose est la façon dont pourrissent les intégrations. Les exemples few-shot, parce qu’un exemple travaillé instruit plus qu’un paragraphe d’adjectifs. La décomposition, parce qu’une chaîne de trois étapes vérifiables vaut mieux qu’un prompt héroïque que personne ne sait déboguer. Et l’économie des tokens, parce qu’un prompt trop cher ou trop lent est cassé, quelle que soit sa qualité. Les formules magiques meurent à chaque nouvelle version de modèle. La spécification, l’évaluation et la structure, non.
Prérequis
- Plusieurs mois de travail régulier avec un assistant IA, ou le module 01
- Savoir lire du JSON — écrire du code est optionnel
- Une tâche réelle à automatiser, avec de vrais exemples
Ce que vous saurez faire après
- Forcer une sortie structurée conforme à un schéma et gérer les runs qui la cassent
- Concevoir des exemples few-shot qui enseignent le cas limite, pas seulement le cas nominal
- Découper une tâche en chaîne d’étapes vérifiables plutôt qu’un méga-prompt fragile
- Séparer prompt système et prompt utilisateur pour qu’une entrée non fiable ne réécrive pas vos règles
- Réduire coût en tokens et latence sans perdre en qualité, et le prouver avec un jeu de test
- Versionner un prompt et détecter une régression avant vos utilisateurs
Séances
Sortie structurée et schémas
Dès qu’un prompt alimente du code, la prose devient un passif. Vous forcerez du JSON conforme à un schéma, le validerez, et concevrez ce qui se passe quand un run vous ignore malgré tout — car ça arrivera. La plupart des intégrations qui « marchaient en test » sont mortes sur une phrase de préambule perdue avant l’accolade ouvrante.
Au programme
Conception few-shot et choix des exemples
Les exemples sont la partie la plus rentable d’un prompt et la plus mal utilisée. Trois exemples bien choisis battent deux pages d’instructions — mais le modèle copie tout ce qu’il voit, y compris vos tics involontaires. Vous apprendrez à choisir des exemples qui portent le cas difficile, et à repérer quand le modèle s’est ancré sur un motif que vous n’aviez pas l’intention d’enseigner.
Au programme
Chaînage, décomposition et patterns de raisonnement
Un prompt qui fait cinq choses est un prompt qu’on ne peut pas déboguer : quand il rate, on ignore laquelle des cinq a cassé. La décomposition échange un peu de coût et de latence contre la possibilité d’inspecter chaque étape. On traite chain-of-thought, tree-of-thought et l’auto-critique honnêtement — y compris les cas où les tokens supplémentaires n’achètent qu’une facture plus lourde.
Au programme
Prompts système et architecture
Un prompt système est la constitution de votre produit : il porte les règles qui doivent survivre à tout ce que tape un utilisateur. Cette séparation n’est pas cosmétique — c’est votre première défense contre quelqu’un qui colle « ignore tes instructions » dans un champ de formulaire. Vous concevrez la frontière entre règles fixes et entrée non fiable, et la testerez en attaquant votre propre prompt.
Au programme
Évaluer un prompt et le mettre en production
C’est la séance qui sépare la démo du produit, et celle qui agace le plus. Un prompt qu’on ne peut pas évaluer est un prompt qu’on ne peut pas améliorer — sans jeu de test, chaque changement ressemble à un progrès et on n’apprend jamais ce qu’on a cassé. Vingt cas réels, une grille écrite avant de regarder la moindre sortie, et la discipline de ne changer qu’une chose à la fois.
Au programme
Construire une application propulsée par prompt : prenez une tâche réelle, livrez un outil fonctionnel piloté par un prompt versionné qui rend une sortie structurée, et défendez-le avec un jeu de 20 cas montrant votre score avant/après, plus une régression que vous avez attrapée.
Proposé dans
Questions
Les modèles plus performants vont-ils rendre le prompt engineering inutile ?
La version « astuces » est déjà morte — les formules magiques ne marchent plus depuis longtemps, et c’est précisément pourquoi ce module n’en contient aucune. Ce qui survit, 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 ignorent toujours vos règles métier, vos données et votre définition du correct. Ce module enseigne la partie qui survivra au modèle que vous utilisez aujourd’hui.
Faut-il coder pour suivre ce module ?
Il faut savoir lire du JSON et accepter de cliquer dans un outil no-code ; il ne faut pas savoir développer. Les parties les plus dures et les plus rentables ici — concevoir des exemples, définir le « correct », construire un jeu de test, repérer son propre biais de sélection — relèvent de l’écriture et du jugement, pas de la programmation. Si vous voulez construire l’application autour du prompt plutôt que le prompt lui-même, c’est le module 03.
Est-ce que tout ça tient 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, non : les modèles voient beaucoup plus d’anglais que de français, et beaucoup plus de français que de darija ; à qualité de prompt égale, la sortie se dégrade à mesure qu’on s’éloigne de l’anglais, et un texte arabe coûte plus de tokens pour le même sens. C’est une contrainte à intégrer au design, pas une raison d’abandonner. Cela veut dire 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 sortie deviennent une décision assumée. On traite ça comme partie du travail, pas comme une note de bas de page.
Autres modules
Prêt à suivre ce module ?