Prompts module 4 : métiers du projet, agents, évaluation et bibliothèque finale

Jour 44 · 16/12 — Gestion de projet : des notes de réunion aux actions

Objectif : transformer des notes brutes en décisions et actions sans que le modèle invente responsables ou dates.

Théorie 1/2 : le prompt faible

Résume cette réunion. (collage des notes)

Diagnostic : un résumé aplatit ce qui compte. Après une réunion, il faut trois listes : ce qui a été décidé, qui fait quoi pour quand, et ce qui reste ouvert. Un modèle a tendance à combler les trous : une action sans responsable en reçoit un, un vague « bientôt » devient une date. Demandez les listes, et des trous explicites.

Théorie 2/2 : le prompt corrigé

À partir des notes ci-dessous, produis trois listes :
1) Décisions : ce qui a été décidé, cité depuis les notes.
2) Actions : | action | responsable | échéance | tels que dans les
   notes ; écris [NONE] quand les notes ne nomment ni responsable ni date.
3) Questions ouvertes : ce qui a été soulevé et pas tranché.
Puis un point d'avancement de 3 lignes pour les absents.
N'utilise aucun nom ni aucune date absents des notes.
<notes>…</notes>

Pratique (30 min)

1. Écrivez les notes d'une réunion de projet imaginaire de 20 minutes (ou prenez des notes sur l'enregistrement public d'une réunion, par exemple celle d'un projet libre), avec au moins une action sans responsable.
2. Lancez le prompt faible et le corrigé. Dans la sortie corrigée, vérifiez chaque nom et chaque date dans les notes.
3. Fiche prompts/pm-meeting-actions.md.

Avec votre IA : « Voici mes notes de réunion et la liste d'actions que j'ai faite [coller]. Ne fais pas ta propre liste. Dis-moi quelles décisions ou actions des notes j'ai ratées, en citant la ligne d'où chacune vient. »

Synthèse (10 min)

Trois lignes : trois listes, [NONE] plutôt que des suppositions, le point pour les absents. Puis refaites les exercices sans notes.

Jour 45 · 17/12 — Gestion de projet : récits utilisateur, risques et estimations

Objectif : découper une fonction en récits qu'une équipe peut vérifier, lister les risques, et prendre les estimations d'un modèle pour ce qu'elles sont.

Théorie 1/2 : des récits avec critères d'acceptation

Un récit utilisateur (user story) nomme un utilisateur, un besoin et un bénéfice (« En tant que … je veux … afin de … »), avec des critères d'acceptation qui disent quand il est terminé. Un modèle propose bien un découpage et rédige bien des critères ; il ne connaît ni vos utilisateurs ni vos priorités. Donnez-lui le but et les contraintes, et demandez des récits petits et indépendants.

Fonction : les clients peuvent annuler une réservation en ligne
jusqu'à 24 h avant.
Utilisateurs : clients sur téléphone ; personnel sur le back-office.
Tâche : découpe en 6 récits au plus, chacun assez petit pour un
développeur en 2 jours, chacun avec 2 à 4 critères d'acceptation en
Given/When/Then. Marque tout récit qui dépend d'un autre.
Liste les questions auxquelles je dois répondre avant que les récits
soient prêts.

Théorie 2/2 : risques et estimations

Demandez des risques avec ce qui les montrerait tôt (un signal) et quoi faire (une réponse), et classez-les vous-même. Pour les estimations, un modèle ne connaît ni la vitesse de votre équipe ni votre code ; ses chiffres sont des suppositions au ton assuré. Servez-vous-en pour lister les tâches et leurs inconnues ; estimez avec l'équipe.

Pratique (30 min)

1. Choisissez une fonction d'un de vos projets. Lancez le prompt de récits ; corrigez-les à la main jusqu'à ce que chaque critère soit vérifiable.
2. Demandez cinq risques avec signal et réponse ; classez-les vous-même et gardez les trois premiers.
3. Fiche prompts/pm-stories-risks.md.

Avec votre IA : « Voici mes six récits utilisateur [coller]. Vérifie chacun selon INVEST (indépendant, négociable, porteur de valeur, estimable, petit, testable) et dis-moi, pour chaque lettre en échec, quelle phrase du récit en est la cause. »

Le faire faire par un agent : une fois des récits écrits à la main, un agent qui a accès à votre gestionnaire de tickets peut créer les tickets à partir d'une liste validée : « Crée un ticket par récit de stories.md, avec les critères d'acceptation dans le corps et l'étiquette "ready" ; n'assigne personne. » Vous vérifiez que chaque ticket correspond au texte validé.

Synthèse (10 min)

Trois lignes : des récits aux critères vérifiables, des risques avec signaux, les estimations appartiennent à l'équipe. Puis refaites les exercices sans notes.

Jour 46 · 18/12 — Rédaction technique : le bon type de document

Objectif : demander le type de document dont le lecteur a besoin, pas « de la documentation ».

Théorie 1/2 : quatre types de documentation

Le cadre Diátaxis, de Daniele Procida, sépare quatre types : les tutoriels (apprendre en faisant, pour un débutant), les guides pratiques (les étapes pour atteindre un but, pour qui connaît les bases), la référence (description exacte, pour consulter) et l'explication (pourquoi les choses sont ainsi). « Écris la doc » les mélange ; un bon prompt en nomme un.

Théorie 2/2 : le prompt corrigé

Faible :  Écris la documentation de mon script de sauvegarde.
Corrigé : Écris un guide pratique : « Restaurer un fichier depuis la
          sauvegarde de la nuit ». Lecteur : un collègue qui connaît le
          shell mais n'a jamais utilisé ce script. N'utilise que les
          options de la sortie --help ci-dessous ; montre chaque commande
          dans un bloc de code et ce que le lecteur doit voir ensuite.
          Termine par « Si ça échoue », avec les deux erreurs les plus
          courantes du code source ci-dessous et leur sens.
          <help>…</help> <source>…</source>

Pratique (30 min)

1. Prenez un script ou un petit outil écrit pendant ce parcours. Demandez un guide pratique et une référence selon le modèle corrigé.
2. Suivez le guide pratique à la lettre dans un terminal neuf. Notez chaque endroit faux ou flou.
3. Fiche prompts/doc-howto.md.

Avec votre IA : « Voici une page de ma documentation [coller]. Dis-moi quel type Diátaxis elle essaie d'être, quelles phrases appartiennent à un autre type, et où ces phrases devraient aller. »

Synthèse (10 min)

Trois lignes : les quatre types, nommer le lecteur, de vraies entrées. Puis refaites les exercices sans notes.

Jour 47 · 19/12 — Rédaction technique : corriger pour le lecteur

Objectif : utiliser un modèle comme correcteur qui propose des changements que vous acceptez un par un.

Théorie 1/2 : corriger, pas réécrire

« Améliore ce texte » renvoie un nouveau texte avec la voix du modèle, souvent plus long, parfois avec des faits changés. Un prompt de correction pose les règles (les cours gratuits de rédaction technique de Google en donnent un bon jeu : phrases courtes, voix active, une idée par phrase, termes définis) et demande une liste de changements, chacun avec sa raison, que vous acceptez ou refusez.

Théorie 2/2 : le prompt corrigé

Corrige la section de README ci-dessous pour un lecteur qui découvre
le projet.
Règles : phrases de moins de 25 mots ; voix active ; définir chaque
terme à sa première apparition ; une consigne par étape numérotée ;
garder chaque commande et chaque fait à l'identique.
Sortie : un tableau | phrase d'origine | phrase proposée | règle |.
Ne change rien dans les blocs de code.
<section>…</section>

Pratique (30 min)

1. Prenez le README de votre bibliothèque de prompts. Lancez le prompt de correction.
2. Acceptez ou refusez chaque ligne ; pour chaque refus, écrivez pourquoi en un mot.
3. Comparez le résultat à l'original avec git diff --word-diff ; vérifiez qu'aucune commande n'a changé.
4. Fiche prompts/doc-edit.md.

Avec votre IA : « Interroge-moi sur la rédaction technique simple : montre-moi une phrase à la fois tirée d'un README typique, demande-moi de la réécrire selon les règles (courte, active, termes définis), puis compare ma version à la tienne et dis laquelle est la plus claire et pourquoi. »

Synthèse (10 min)

Trois lignes : corriger et non réécrire, les règles, faits et code intouchés. Puis refaites les exercices sans notes.

Jour 48 · 20/12 — Recherche d'emploi : un CV véridique d'autodidacte

Objectif : utiliser un modèle pour bien présenter de vraies preuves, jamais pour inventer de l'expérience.

Théorie 1/2 : le prompt faible

Écris-moi un CV pour un poste de DevOps junior.

Diagnostic : le modèle ne sait rien de vous, donc il écrit un CV générique avec des compétences et des résultats que vous n'avez pas. Un recruteur ou un entretien le découvrira. Pour un autodidacte, la force, ce sont les preuves : des projets avec un lien, ce que vous avez construit, ce que vous avez mesuré. Le travail du modèle est de formuler ces preuves pour une offre précise.

Théorie 2/2 : le prompt corrigé

Contexte : autodidacte, sans diplôme en informatique ; je postule à
l'offre ci-dessous. Mes preuves : <projects>(chaque projet : lien, ce
que j'ai construit, outils, ce que j'ai mesuré)</projects>
<offer>…</offer>
Tâche : écris la section « Projets » de mon CV pour cette offre :
3 projets au plus, le plus pertinent d'abord, 2 puces chacun,
commençant par un verbe, avec uniquement des faits tirés de mes preuves.
Puis liste les exigences de l'offre que mes preuves ne couvrent pas,
pour que je les traite honnêtement dans la lettre.

Pratique (30 min)

1. Écrivez votre fichier de preuves : chaque projet de ce parcours et des autres suivis, avec lien et faits.
2. Trouvez une vraie offre publique qui vous intéresse. Lancez le prompt corrigé.
3. Vérifiez chaque puce face à vos preuves ; barrez ce que vous ne pouvez pas prouver.
4. Fiche prompts/career-cv-projects.md (gardez vos preuves personnelles hors du dépôt public).

Avec votre IA : « Voici ma section Projets et l'offre [coller]. Joue un recruteur qui la lit en 30 secondes : que retiens-tu, qu'est-ce qui te fait douter, et sur quelle puce poserais-tu ta première question ? »

Synthèse (10 min)

Trois lignes : des preuves plutôt que des affirmations, une offre à la fois, la liste des manques. Puis refaites les exercices sans notes.

Jour 49 · 21/12 — Recherche d'emploi : s'entraîner à l'entretien

Objectif : répéter un entretien avec un modèle qui pose les questions, relance et fait un retour honnête.

Théorie 1/2 : le prompt faible

Donne-moi les questions d'entretien classiques pour un poste d'admin système, avec les réponses.

Diagnostic : des réponses apprises par cœur sonnent apprises par cœur, et les réponses du modèle ne sont pas votre expérience. L'entraînement marche quand le modèle joue le recruteur, pose une question à la fois, relance sur votre réponse, et fait un retour à la fin selon des critères que vous posez.

Théorie 2/2 : le prompt corrigé

Joue le recruteur pour l'offre ci-dessous ; je suis un candidat
autodidacte. Pose une question à la fois et attends ma réponse.
Mélange : 3 questions techniques sur les outils de l'offre,
2 questions comportementales (« parlez-moi d'une fois où… »),
1 question sur un de mes projets tiré de mes preuves. Relance une fois
sur chaque réponse. Après la dernière, fais un retour par réponse :
était-elle précise, suivait-elle Situation / Tâche / Action / Résultat,
que manquait-il. Ne réponds pas aux questions à ma place.
<offer>…</offer> <evidence>…</evidence>

Pratique (30 min)

1. Lancez l'entretien simulé avec l'offre d'hier. Répondez d'abord à voix haute, puis tapez.
2. Pour chaque question technique, vérifiez ensuite les faits de votre réponse dans la documentation officielle.
3. Réécrivez vos deux réponses les plus faibles au format STAR et rejouez ces questions.
4. Fiche prompts/career-mock-interview.md.

Avec votre IA : « Je vais t'expliquer mon projet final de ce parcours en deux minutes. Interromps-moi comme un recruteur technique avec les trois questions les plus dures que tu trouves, une à la fois. »

Synthèse (10 min)

Trois lignes : un recruteur et non un corrigé, les relances, STAR. Puis refaites les exercices sans notes.

Jour 50 · 22/12 — Les prompts système des agents

Objectif : écrire le prompt système d'un petit agent : qui il est, ce qu'il peut faire, quand il s'arrête.

Théorie 1/2 : un agent lit le prompt autrement

Un agent est un modèle dans une boucle : il lit ses consignes, appelle des outils, lit les résultats, et continue jusqu'à décider qu'il a fini. Son prompt système est relu à chaque étape, par le modèle, sans vous pour préciser. L'article d'Anthropic « Building effective agents » (2024) conseille de commencer par le système le plus simple qui marche et de n'ajouter de l'autonomie que si nécessaire. Le prompt système d'un agent dit : son but, son environnement, les outils et quand utiliser chacun, les règles à ne jamais enfreindre, comment rendre compte, et quand s'arrêter pour demander à un humain.

Théorie 2/2 : faible et corrigé

Faible :  Tu es un agent DevOps serviable. Corrige tous les problèmes
          que tu trouves.

Corrigé : But : garder l'occupation disque du serveur de labo sous 80 %.
Environnement : VM de labo Debian 13 ; tu as les outils disk_usage,
list_large_files et delete_file.
Règles : ne supprime que des fichiers sous /var/tmp/lab de plus de
7 jours ; ne supprime jamais rien d'autre, n'utilise aucun autre dossier.
À chaque passage : 1) disk_usage ; 2) sous 80 %, rends compte et
arrête ; 3) list_large_files dans /var/tmp/lab ; 4) propose les
suppressions en liste et arrête : un humain approuve avant tout
appel à delete_file.
Compte rendu : occupation avant, fichiers proposés, taille totale.
Arrête-toi et demande si : un outil renvoie deux fois une erreur, ou
l'occupation dépasse 95 %, ou les fichiers ne sont pas dans /var/tmp/lab.

Pratique (30 min)

1. Choisissez une petite tâche récurrente à vous (ranger un dossier de téléchargements, vérifier que trois sites répondent). Écrivez le prompt système de son agent avec les six parties.
2. Lancez-le dans un agent de code limité à un dossier de labo (les articles du site sur OpenFox et Claude Code montrent comment en installer un sur des modèles locaux). Suivez chaque étape.
3. Notez où l'agent a hésité ou débordé ; corrigez une partie du prompt ; relancez.
4. Fiche prompts/agent-system-prompt.md.

Avec votre IA : « Voici le prompt système de mon agent [coller]. Joue l'équipe rouge : liste cinq situations où un agent qui le suivrait à la lettre ferait quand même quelque chose de nuisible ou d'inutile, et quelle ligne du prompt le permet. »

Synthèse (10 min)

Trois lignes : les six parties d'un prompt d'agent, le périmètre d'abord, les conditions d'arrêt. Puis refaites les exercices sans notes.

Jour 51 · 23/12 — Fichiers d'instructions de projet et contexte d'un agent

Objectif : écrire le fichier qu'un agent de code lit dans votre dépôt, court et vrai.

Théorie 1/2 : le fichier d'instructions

Les agents de code lisent un fichier à la racine du dépôt avant de travailler : AGENTS.md est un format ouvert lu par plusieurs agents ; Claude Code lit CLAUDE.md. Il contient ce qu'un agent ne peut pas deviner et dont il a besoin à chaque fois : comment construire et tester, les conventions, ce qu'il ne faut jamais toucher. L'article d'Anthropic « Effective context engineering for AI agents » décrit le contexte comme un budget limité : chaque ligne dispute l'attention du modèle à la tâche.

Théorie 2/2 : faible et corrigé

Faible :  C'est un super projet. Merci d'écrire du code de qualité et
          de suivre les bonnes pratiques. Sois prudent.

Corrigé : # Build and test
          uv sync; uv run pytest -q (must pass before any commit)
          # Conventions
          Python 3.13, ruff format; English in code and commits.
          # Never
          Edit files under migrations/ by hand; commit secrets;
          change the public API in api/ without saying so in the PR.
          # When unsure
          Stop and ask in the PR description.

Pratique (30 min)

1. Écrivez le AGENTS.md du dépôt de votre bibliothèque : comment lancer un prompt, comment lancer les tests (vous les aurez au jour 56), le modèle de fiche, ce qu'il ne faut jamais changer.
2. Donnez une petite tâche à un agent de code dans le dépôt (ajouter une fiche à partir d'une description). Vérifiez s'il a suivi chaque ligne du fichier.
3. Coupez toute ligne dont l'agent n'a pas eu besoin ; ajoutez celle qui lui a manqué.

Avec votre IA : « Voici mon AGENTS.md [coller]. Pour chaque ligne, dis-moi si un agent pourrait vérifier qu'il la suit, et propose une formulation vérifiable pour celles où il ne pourrait pas. »

Le faire faire par un agent : les agents peuvent mettre à jour leur propre fichier d'instructions quand ils apprennent quelque chose sur le projet. Demandez le changement sous forme de proposition dans une pull request, jamais en modification silencieuse, et lisez-le : une ligne fausse dans ce fichier égare chaque passage suivant.

Synthèse (10 min)

Trois lignes : ce qui va dans le fichier, le contexte comme budget, des lignes vérifiables. Puis refaites les exercices sans notes.

Jour 52 · 24/12 — Descriptions d'outils : le prompt dans l'outil

Objectif : écrire une description d'outil qu'un agent utilise au bon moment, avec les bons arguments.

Théorie 1/2 : pourquoi les descriptions comptent

Quand un agent a des outils (des fonctions, ou des serveurs qui parlent le Model Context Protocol, publié par Anthropic en novembre 2024), il choisit lequel appeler d'après leur nom, leur description et le schéma de leurs paramètres, et rien d'autre. La documentation d'Anthropic sur l'usage des outils désigne des descriptions détaillées comme le facteur le plus important de la performance d'un outil, et son article « Writing effective tools for agents » (2025) ajoute : des noms clairs, des descriptions qui disent quand l'utiliser et quand ne pas l'utiliser, des paramètres avec formats et exemples, et des messages d'erreur qui disent à l'agent quoi faire ensuite.

Théorie 2/2 : faible et corrigé

Faible :
{"name": "check", "description": "Checks a site.",
 "input_schema": {"type": "object", "properties": {"s": {"type": "string"}}}}

Corrigé :
{"name": "check_https_site",
 "description": "Fetches https://HOST/ once and returns the HTTP status
  code, the response time in ms and the certificate expiry date. Use it
  to check that a public website answers. Do not use it for internal
  hosts or for anything other than the home page. On timeout it returns
  status 0: retry once, then report the site as down.",
 "input_schema": {"type": "object", "required": ["host"],
  "properties": {"host": {"type": "string",
   "description": "Hostname only, no scheme or path, e.g. www.example.com"}}}}

Les descriptions d'outils s'écrivent souvent en anglais, comme le code ; ce qui compte est le contenu : quoi, quand, quand pas, format, erreurs.

Pratique (30 min)

1. Écrivez l'outil corrigé sous forme de petit script qui fait ce que dit sa description (Python urllib ou curl), et sa description en JSON.
2. Exposez-le à un agent qui accepte des outils personnalisés (un serveur MCP, ou l'interface d'appel d'outils de votre moteur). Faites-lui trois demandes : une qui en a besoin, une qui n'en a pas besoin, une avec une URL au lieu d'un nom d'hôte.
3. Notez chaque appel et ses arguments. Corrigez la description là où l'agent s'est trompé ; relancez.
4. Fiche prompts/tool-description.md avec les trois demandes comme tests.

Avec votre IA : « Voici trois descriptions d'outils [coller]. Pour chacune, écris deux demandes d'utilisateur où un agent choisirait probablement le mauvais outil ou passerait un mauvais argument à cause de la description, et dis quels mots en sont la cause. »

Synthèse (10 min)

Trois lignes : le nom, la description avec quand et quand pas, des paramètres avec exemples, des erreurs avec la suite. Puis refaites les exercices sans notes.

Jour 53 · 25/12 — Tester les prompts : cas et assertions

Objectif : transformer vos vérifications en cas de test qu'un programme exécute.

Théorie 1/2 : un jeu de tests pour un prompt

Depuis le jour 8, vous vérifiez les prompts en lisant. Pour comparer des versions et des modèles, les vérifications doivent tourner seules. Un jeu de tests de prompt contient des entrées et, pour chacune, des assertions sur la sortie : contient ceci, ne contient pas cela, est un JSON valide, fait moins de N mots, égale une valeur. Le guide d'Anthropic sur les évaluations et celui d'OpenAI donnent le même conseil : écrire les tests à partir de vraies tâches, inclure les cas limites, préférer des vérifications notées par un programme, et garder le jeu quand on change le prompt.

Théorie 2/2 : écrire le vérificateur

function check(output, assertion) {
}

function check(output, assertion) {
  if (assertion.type === 'contains') return output.includes(assertion.value);
  if (assertion.type === 'not-contains') return !output.includes(assertion.value);
  if (assertion.type === 'max-words') {
    const words = output.trim().split(/\s+/).filter(Boolean);
    return words.length <= assertion.value;
  }
  return false;
}

Pratique (30 min)

1. Prenez trois fiches de votre bibliothèque. Pour chacune, écrivez cinq cas de test dans un fichier tests/<fiche>.json : variables d'entrée et liste d'assertions.
2. Prévoyez pour chaque fiche un cas « piège » : le journal sain, la tentative d'injection, l'alerte ambiguë.
3. Passez-les une fois à la main, en notant réussite ou échec par assertion. Ce sera la référence de demain.

Avec votre IA : « Voici une fiche de prompt et mes cinq cas de test [coller]. Propose trois cas de plus qui attraperaient une régression que mes cas ratent, et dis pour chacun quelle assertion échouerait. »

Synthèse (10 min)

Trois lignes : ce que contient un cas de test, des assertions notées par un programme, le cas piège. Puis refaites les exercices sans notes.

Jour 54 · 26/12 — Tester les prompts : promptfoo, plusieurs modèles, des juges

Objectif : lancer automatiquement les tests d'un prompt sur deux modèles, et connaître les limites d'un modèle juge.

Théorie 1/2 : promptfoo

promptfoo est un outil libre en ligne de commande : un fichier YAML liste les prompts, les fournisseurs (modèles, y compris locaux via Ollama) et les tests avec leurs assertions ; promptfoo eval lance toutes les combinaisons et affiche une grille réussite/échec. Parmi les types d'assertion intégrés : contains, icontains, not-contains, regex, is-json et javascript.

prompts:
  - file://prompts/ops-alert-routing.txt
providers:
  - ollama:chat:MODEL_A
  - ollama:chat:MODEL_B
tests:
  - vars: {alert: "disk /var 95% full on web1"}
    assert:
      - type: is-json
      - type: javascript
        value: JSON.parse(output).team === 'systems'
  - vars: {alert: "Coffee machine offline"}
    assert:
      - type: javascript
        value: JSON.parse(output).team === 'other'

Théorie 2/2 : un modèle comme juge

Certaines qualités (ton, clarté, complétude selon une grille) demandent du jugement. L'assertion llm-rubric de promptfoo demande à un modèle de noter la sortie selon votre grille. C'est utile et faillible : les juges ont des biais (par exemple envers les réponses plus longues, ou envers leur propre style) ; écrivez une grille précise, vérifiez à la main un échantillon des verdicts, et gardez des assertions en code partout où elles suffisent.

Pratique (30 min)

1. Avec Node.js installé : npx promptfoo@latest init dans votre bibliothèque, puis écrivez promptfooconfig.yaml pour la fiche de routage d'alertes avec deux modèles locaux.
2. npx promptfoo@latest eval, puis npx promptfoo@latest view. Comparez avec la référence faite à la main hier.
3. Cassez exprès le prompt (retirez la définition de « other ») : le test piège doit échouer. Sinon, corrigez le test.

Avec votre IA : « Voici ma grille pour une réponse de support [coller]. Réécris-la pour que deux personnes qui notent la même réponse soient presque toujours d'accord, et donne une réponse qui la réussit et une qui l'échoue. »

Le faire faire par un agent : maintenant que vous avez écrit une configuration à la main, un agent de code peut convertir vos autres fichiers tests/*.json en tests promptfoo et lancer la suite : « Convertis chaque fichier de tests/ en tests de promptfooconfig.yaml avec les mêmes assertions, lance promptfoo eval sur les deux modèles locaux, et donne-moi le taux de réussite par fiche. » Vous vérifiez que chaque assertion convertie veut dire la même chose que l'originale.

Synthèse (10 min)

Trois lignes : ce que lance promptfoo, pourquoi deux modèles, jusqu'où croire un juge. Puis refaites les exercices sans notes.

Jour 55 · 27/12 — Projet final 1 : choisir et auditer

Objectif : choisir les dix prompts de votre bibliothèque finale et auditer chacun selon la fiche.

Théorie 1/2 : ce qu'est le projet final

Un dépôt public avec dix prompts que vous utilisez vraiment, au moins cinq métiers couverts, chacun en fiche complète (but, prompt, entrées, sortie, critères, historique), chacun avec des tests automatisés lancés sur deux modèles, un README qui explique comment les utiliser et les tester, et un court rapport sur trois prompts améliorés avec résultats mesurés. C'est la preuve de votre CV (jour 48).

Théorie 2/2 : la grille d'audit

Pour chaque prompt candidat, notez de 0 à 2 : rôle et contexte, tâche, contraintes, entrées balisées comme données, format de sortie, exemples (si besoin), critères de réussite, porte de sortie (« non précisé », [MISSING], other), risque d'injection traité s'il lit des données extérieures, rien de privé dedans.

Pratique (30 min)

1. Listez toutes vos fiches ; choisissez-en dix qui couvrent au moins cinq métiers et que vous réutiliseriez vraiment.
2. Auditez chacune avec la grille ; notez le score dans sa fiche.
3. Ouvrez dans votre dépôt un ticket par fiche notée sous 14 sur 20, qui dit quoi corriger.

Avec votre IA : « Voici une de mes fiches de prompt [coller]. Note-la selon ma grille d'audit, une ligne par critère avec une raison, et désigne le seul changement qui ferait le plus monter le score. »

Synthèse (10 min)

Trois lignes : ce que contient le projet final, la grille d'audit, les tickets ouverts. Puis refaites les exercices sans notes.

Jour 56 · 28/12 — Projet final 2 : écrire les tests

Objectif : chaque prompt de la bibliothèque a une suite de tests automatisés avec un cas piège.

Théorie 1/2 : une bonne suite

Cinq à dix cas par prompt : des entrées typiques, des entrées limites, au moins un piège (injection, information manquante, entrée hors des étiquettes), et un cas qui vérifie que le prompt dit « je ne sais pas » quand il le doit. Des assertions notées par du code d'abord ; un juge à grille seulement pour ce que le code ne sait pas noter.

Théorie 2/2 : vérifier qu'un test peut échouer

Pour chaque prompt, cassez-le une fois exprès (retirez la porte de sortie, retirez les balises, changez le format) et lancez la suite : au moins un test doit échouer. Une suite qui reste verte sur un prompt cassé ne protège rien ; c'est l'idée de mutation du jour 30, appliquée aux prompts.

Pratique (30 min)

1. Écrivez les tests promptfoo des dix prompts (l'astuce agent du jour 54 peut aider, après avoir écrit les premiers vous-même).
2. Cassez chaque prompt une fois ; confirmez qu'un test échoue ; restaurez-le.
3. Commitez avec un message qui liste, par prompt, quel test a attrapé la mutation.

Avec votre IA : « Voici un prompt et sa suite de tests [coller]. Propose une mutation du prompt que ma suite n'attraperait pas, et le test qui l'attraperait. »

Synthèse (10 min)

Trois lignes : ce que contient une bonne suite, le piège sans réponse, la vérification par mutation. Puis refaites les exercices sans notes.

Jour 57 · 29/12 — Projet final 3 : lancer, échouer, corriger

Objectif : lancer toute la bibliothèque sur deux modèles, corriger les échecs avec la boucle du jour 8, et mesurer.

Théorie 1/2 : lire une grille de résultats

Une grille prompts × modèles × tests montre trois motifs : un test qui échoue sur tous les modèles (le prompt ou le test est faux), un test qui échoue sur un seul modèle (le prompt s'appuie sur les habitudes d'un modèle), et un prompt qui passe partout mais de justesse (fragile). Corrigez d'abord le premier.

Théorie 2/2 : un changement, mesuré

Pour chaque correction, la boucle du jour 8 : nommer la cause, changer une chose, relancer toute la suite sur les deux modèles, ne garder le changement que si le taux de réussite monte et que rien d'autre ne casse. Notez l'avant et l'après dans ## History : ce tableau est l'écart mesuré que vous montrerez.

Pratique (30 min)

1. Lancez toute la suite sur les deux modèles ; gardez les résultats (promptfoo eval -o results.json).
2. Corrigez les trois pires prompts avec un changement chacun ; relancez après chaque.
3. Écrivez l'avant et l'après de ces trois-là dans leurs fiches.

Avec votre IA : « Voici les sorties en échec d'un prompt et son test [coller]. Classe chaque échec (information manquante, tâche mal comprise, format ignoré, invention, test trop strict) et propose un changement, pas plus. »

Le faire faire par un agent : une fois des prompts corrigés à la main avec la boucle, un agent peut faire tourner la boucle sur les autres : « Pour chaque prompt sous 80 % de réussite, propose exactement un changement, relance toute la suite sur les deux modèles, et ne garde le changement que si le taux monte et qu'aucun autre test n'échoue ; écris l'avant et l'après dans l'historique de la fiche. » Vous relisez chaque changement gardé et son diff.

Synthèse (10 min)

Trois lignes : les trois motifs, un changement mesuré, l'avant et l'après. Puis refaites les exercices sans notes.

Jour 58 · 30/12 — Projet final 4 : documenter et publier

Objectif : rendre la bibliothèque utilisable par quelqu'un d'autre en dix minutes, et la publier.

Théorie 1/2 : le README

Le README répond, dans cet ordre : ce qu'est la bibliothèque ; comment lancer un prompt ; comment lancer les tests et sur quels modèles ; le modèle de fiche ; la liste des prompts par métier avec leur taux de réussite ; la règle de masquage (rien de privé dans les prompts ni les tests) ; la licence. Appliquez-lui les règles de correction du jour 47.

Théorie 2/2 : le rapport d'amélioration

Une courte page, REPORT.md : trois prompts améliorés. Pour chacun : la version faible, le diagnostic dans les termes du parcours, la version corrigée, les résultats des tests avant et après sur les deux modèles, et ce que vous en avez appris. Des faits seulement : si un changement n'a pas aidé, dites-le.

Pratique (30 min)

1. Écrivez le README et REPORT.md.
2. Cherchez tout ce qui serait privé dans le dépôt : git grep -nE "password|token|@|BEGIN .*KEY" et lisez chaque résultat ; vérifiez que les adresses sont des adresses de documentation.
3. Demandez à quelqu'un (ou à vous-même sur une machine neuve) de cloner le dépôt et de lancer un prompt et ses tests avec le seul README. Corrigez ce qui a bloqué.
4. Rendez le dépôt public. Livrable du module 4 : son lien.

Avec votre IA : « Voici mon README [coller]. Tu es un développeur qui n'a jamais vu ce dépôt. Liste dans l'ordre les étapes que tu suivrais pour lancer un prompt et ses tests, et arrête-toi à la première étape où le README ne te dit pas quoi faire. »

Synthèse (10 min)

Trois lignes : l'ordre du README, le rapport des trois améliorations, la vérification de confidentialité. Puis refaites les exercices sans notes.

Jour 59 · 31/12 — Bilan final

Objectif : passer la liste de fin de parcours et prévoir la suite.

Théorie 1/2 : le parcours en sept phrases

Un modèle prolonge du texte : donnez-lui les faits qu'il ne peut pas deviner. Une donnée n'est jamais une consigne : balisez-la, et mettez les vraies défenses dans le code. Un prompt est une tâche avec des critères de réussite vérifiables. Changez une chose à la fois et mesurez. La sortie structurée se vérifie par du code. Un modèle ne peut pas se vérifier lui-même : la vérification est extérieure. Un prompt qu'on ne peut pas tester est une phrase dont on espère qu'elle marche.

Théorie 2/2 : révision mêlée

Pratique (30 min)

1. Passez la liste de la page du parcours ; cochez ce que vous pouvez montrer, avec le lien vers la preuve.
2. Pour chaque case que vous ne pouvez pas cocher, notez la séance à refaire et quand.
3. Choisissez votre prochain parcours sur ce site, et la première fiche de prompt que vous ajouterez à votre bibliothèque pour lui.

Avec votre IA : « Interroge-moi sur tout ce parcours : douze questions, une à la fois, qui mêlent les fondations (contexte, échantillonnage, injection, sortie structurée, auto-vérification) et les métiers (une question par famille de métiers). Après chaque réponse, dis-moi quel jour du parcours relire si je me suis trompé. »

Synthèse (10 min)

Écrivez de mémoire les sept phrases. Puis refaites chaque exercice du parcours raté au moins une fois.