Prompts module 3 : les métiers qui construisent, du code à l'architecture

Jour 29 · 01/12 — Développeur : la relecture de code

Objectif : obtenir une relecture qui trouve de vrais défauts, classés, au lieu de remarques de style.

Théorie 1/2 : le prompt faible

Relis mon code. (collage de 300 lignes)

Diagnostic : ni but du code, ni critères, ni priorité. Le modèle renvoie une douzaine de remarques de nommage et de commentaires, avec au milieu un vrai bug que vous risquez de rater. Un prompt de relecture dit ce que la modification doit faire, ce qui compte (justesse, sécurité, puis style), et demande des constats avec chacun un cas d'échec concret.

Théorie 2/2 : le prompt corrigé

Contexte : fonction Python 3.13 qui analyse des fichiers CSV de
commandes envoyés par des clients ; elle tourne sur un serveur.
Tâche : relis le diff ci-dessous pour trouver des défauts, dans cet
ordre de priorité : 1) résultats faux, 2) plantages sur entrée
invalide, 3) sécurité, 4) clarté.
<diff>…</diff>
Sortie : 8 constats au plus, du plus grave au moins grave, chacun
avec : la ligne, l'entrée qui le déclenche, ce qui se passe, la plus
petite correction. Pas de style sauf s'il cache un défaut. Si une
catégorie est vide, dis-le.

Pratique (30 min)

1. Prenez une fonction écrite récemment. Plantez deux bugs : un décalage d'une unité et une entrée vide non vérifiée.
2. Lancez le prompt faible et le corrigé. Chacun a-t-il trouvé les bugs plantés ? À quel rang ?
3. Pour chaque constat, écrivez un test qui le montre, ou marquez-le faux.
4. Fiche prompts/dev-code-review.md ; le fichier aux bugs plantés devient son cas de test.

Avec votre IA : « Voici ma fonction [coller]. Ne la relis pas. Pose-moi cinq questions qu'un relecteur attentif poserait sur les cas limites (vide, énorme, mauvais type, concurrent, malveillant), une à la fois, et dis-moi après chacune si ma réponse révèle un bug. »

Synthèse (10 min)

Trois lignes : but et priorité, un cas d'échec par constat, le test aux bugs plantés. Puis refaites les exercices sans notes.

Jour 30 · 02/12 — Développeur : demander des tests

Objectif : obtenir des tests qui échoueraient sur une implémentation fausse, pas des tests qui recopient le code.

Théorie 1/2 : le prompt faible

Écris des tests unitaires pour cette fonction. (collage)

Diagnostic : avec le seul code, le modèle écrit des tests qui affirment ce que fait le code, bugs compris. Les tests doivent venir de ce que la fonction est censée faire. Donnez la spécification et les cas limites, demandez des tests à partir d'eux, et vérifiez les tests en cassant le code : un test qui passe encore sur du code cassé ne teste rien.

Théorie 2/2 : le prompt corrigé

Écris des tests pytest pour slugify(title) à partir de cette seule
spécification :
- minuscules ; espaces et ponctuation deviennent un seul tiret ;
- accents retirés ("Été" -> "ete") ; pas de tiret au début ni à la fin ;
- vide ou seulement de la ponctuation -> "" ; 60 caractères max,
  coupé à un tiret.
Contraintes : un test par règle, plus les cas limites que la spec
implique selon toi (listés à part pour que je les accepte ou les
refuse) ; utilise pytest.mark.parametrize ; pas de mocks.
Sortie : le fichier de tests seulement.

Pratique (30 min)

1. Écrivez slugify vous-même à partir de la spécification, en Python.
2. Générez les tests avec le prompt corrigé ; lancez-les avec pytest.
3. Cassez votre fonction de trois façons (plus de retrait des accents, tiret final gardé, coupe à 61). Après chacune, les tests doivent échouer. Notez quelle mutation a survécu.
4. Fiche prompts/dev-tests-from-spec.md.

Avec votre IA : « Voici une spécification [coller]. Liste les cas limites qu'elle ne tranche pas (entrées ambiguës), sous forme de questions auxquelles je dois répondre avant d'écrire le moindre test. N'écris pas les tests. »

Le faire faire par un agent : maintenant que vous avez vérifié des tests contre des mutations à la main, un agent de code peut écrire les tests et lancer lui-même les mutations : « Écris des tests pytest pour slugify à partir de SPEC.md seulement, puis applique trois mutations à slugify une par une, lance les tests après chacune, et dis-moi laquelle a survécu ; restaure le fichier à la fin. » Vous relisez quand même les tests : un agent peut aussi écrire des tests qui passent pour une mauvaise raison.

Synthèse (10 min)

Trois lignes : tests depuis la spec, cas limites listés à part, mutations comme vérification. Puis refaites les exercices sans notes.

Jour 31 · 03/12 — Développeur : déboguer avec un modèle

Objectif : donner au modèle une reproduction minimale et obtenir des hypothèses testables.

Théorie 1/2 : le prompt faible

Ça marche pas, voici tout mon projet. (zip de 40 fichiers)

Diagnostic : trop et trop peu. Trop de code dilue le contexte (jour 1) ; trop peu d'information sur l'échec : ce que vous avez lancé, ce que vous attendiez, ce que vous avez obtenu. L'« exemple minimal reproductible » de Stack Overflow est la même discipline : le plus petit code qui échoue encore, l'erreur exacte, le résultat attendu.

Théorie 2/2 : le prompt corrigé

Contexte : Node.js 22, un script qui lit une configuration JSON.
<code>(les 15 lignes qui échouent)</code>
<run>node read.js config.json</run>
<error>(pile d'appels complète)</error>
Attendu : affiche la valeur de "port". Déjà essayé : le fichier
existe, le JSON est validé par jq.
Tâche : donne 3 hypothèses classées par vraisemblance ; pour chacune,
l'expérience qui la confirme ou l'écarte. Ne réécris pas le code.

Pratique (30 min)

1. Prenez un bug récent (ou plantez-en un dans un petit script). Réduisez le code jusqu'à moins de 20 lignes qui échouent encore.
2. Lancez le prompt corrigé. Faites vous-même chaque expérience proposée ; notez l'hypothèse qui a tenu.
3. Si le bug vient d'une modification, retrouvez-la aussi avec git bisect, et comparez avec le classement du modèle.
4. Fiche prompts/dev-debug-hypotheses.md.

Avec votre IA : « Joue un canard en plastique qui pose des questions. Je vais t'expliquer mon bug ; réponds seulement par une question à la fois qui m'oblige à énoncer une supposition, et arrête-toi quand je trouve la cause moi-même. »

Synthèse (10 min)

Trois lignes : reproduction minimale, hypothèses classées, expériences et non corrections. Puis refaites les exercices sans notes.

Jour 32 · 04/12 — Développeur : refactoriser sans changer le comportement

Objectif : obtenir une refactorisation qui garde le comportement, prouvée par les tests d'avant.

Théorie 1/2 : le prompt faible

Nettoie ce code.

Diagnostic : « nettoyer » n'est pas un but. Le modèle renomme, réordonne, « corrige » un comportement qui lui semblait bizarre, et ajoute des fonctions. Martin Fowler définit la refactorisation comme un changement de structure du code sans changement de son comportement observable ; un prompt de refactorisation dit quel problème de structure régler, interdit les changements de comportement, et s'appuie sur des tests qui passent avant et après.

Théorie 2/2 : le prompt corrigé

Refactorise la fonction ci-dessous. But : la découper en une fonction
par étape (analyse, validation, calcul du total), aucun autre changement.
Contraintes : même signature publique ; mêmes valeurs de retour et
exceptions pour toute entrée ; aucune nouvelle dépendance ; garder les
noms existants autant que possible. Si tu vois un bug, signale-le en
commentaire à la fin, ne le corrige pas.
<code>…</code>
<tests>(les tests existants, qui doivent toujours passer)</tests>
Sortie : le nouveau code, puis la liste de chaque changement.

Pratique (30 min)

1. Choisissez une longue fonction à vous qui a des tests (écrivez-en trois d'abord s'il n'y en a pas).
2. Lancez le prompt corrigé ; appliquez le résultat dans une branche ; lancez les tests.
3. Lisez la liste des changements face au diff : y a-t-il dans le diff quelque chose qui n'est pas dans la liste ?
4. Fiche prompts/dev-refactor.md.

Avec votre IA : « Voici un diff qui se dit pure refactorisation [coller]. Liste chaque ligne où le comportement observable a pu changer (valeurs de retour, exceptions, effets de bord, ordre), avec l'entrée qui le montrerait. »

Synthèse (10 min)

Trois lignes : les tests d'abord, un seul but de structure, des bugs signalés et non corrigés. Puis refaites les exercices sans notes.

Jour 33 · 05/12 — Développeur : lire du code inconnu, écrire des messages de commit

Objectif : utiliser un modèle pour comprendre du code plus vite, et pour décrire vos propres changements avec exactitude.

Théorie 1/2 : expliquer du code

Faible :  Que fait ce code ?
Corrigé : Je découvre cette base de code et je connais Python, pas
          asyncio. Explique-moi la fonction ci-dessous : 1) son but en
          une phrase ; 2) le trajet d'une requête à travers elle, étape
          par étape ; 3) les notions asyncio qu'elle utilise, chacune en
          une ligne avec un lien vers la documentation Python. Marque ce
          que tu déduis au lieu de le lire dans le code par (inferred).

La version corrigée dit qui lit, demande un parcours plutôt qu'une paraphrase, et sépare ce qui est dans le code de ce qui est deviné.

Théorie 2/2 : les messages de commit

Un modèle peut proposer un message de commit à partir d'un diff, mais vous seul savez pourquoi le changement a été fait. Donnez-lui le pourquoi ; demandez le format de votre projet, par exemple Conventional Commits ; puis vérifiez que chaque ligne du message correspond au diff.

Propose un message de commit pour le diff indexé ci-dessous, en anglais.
Pourquoi : les utilisateurs au panier vide recevaient une 500 au paiement.
Format : Conventional Commits ; sujet de moins de 60 caractères, à
l'impératif ; corps : ce qui a changé et pourquoi, coupé à 72.
<diff>…</diff>

Pratique (30 min)

1. Prenez un fichier d'un projet libre que vous utilisez. Lancez le prompt d'explication corrigé ; vérifiez chaque « étape » en lisant le code vous-même, et chaque lien de documentation en l'ouvrant.
2. Pour vos trois prochains commits de la semaine, faites proposer le message avec le prompt de commit à partir de git diff --staged, puis corrigez-le à la main.
3. Fiches prompts/dev-explain-code.md et prompts/dev-commit-message.md.

Avec votre IA : « Je viens de lire cette fonction [coller]. Je vais te l'expliquer avec mes mots ; dis-moi ce que j'ai faux ou oublié, sans me donner ta propre explication complète. »

Le faire faire par un agent : les agents de code rédigent les messages de commit à partir du diff indexé dans leur travail. Donnez-leur le pourquoi et le format dans le fichier d'instructions du projet. Vous relisez toujours le message face au diff avant que le commit parte.

Synthèse (10 min)

Trois lignes : un parcours et non une paraphrase, étiqueter les déductions, le pourquoi vient de vous. Puis refaites les exercices sans notes.

Jour 34 · 06/12 — Web design : revue heuristique et accessibilité

Objectif : obtenir une critique de design selon des références nommées, et la vérifier avec des outils.

Théorie 1/2 : le prompt faible

Tu penses quoi du design de mon site ?

Diagnostic : du goût sans référence. Le modèle complimentera et suggérera « plus d'espace blanc ». Un prompt de revue de design nomme les utilisateurs et leur tâche principale, et une référence : les dix heuristiques d'utilisabilité de Jakob Nielsen, ou les critères de succès des WCAG 2.2 pour l'accessibilité.

Théorie 2/2 : le prompt corrigé

Contexte : page d'inscription d'un petit site de réservation ;
utilisateurs surtout de plus de 60 ans, beaucoup sur téléphone.
Tâche principale : créer un compte en moins de 2 minutes.
Entrées : <html>(le HTML de la page)</html> et une description de la
capture : <screen>…</screen>
Tâche : revue selon les 10 heuristiques de Nielsen et ces critères
WCAG 2.2 AA : 1.1.1, 1.4.3, 2.4.7, 3.3.1, 3.3.2.
Sortie : | référence | élément (cité) | problème | correction |, le plus
gênant pour la tâche principale d'abord. Dis quels critères ne peuvent
pas être jugés depuis les entrées (le contraste demande les vraies
couleurs, par exemple).

Pratique (30 min)

1. Prenez une page que vous avez construite (ou un formulaire public simple, copié pour étude). Lancez la revue corrigée.
2. Vérifiez ses constats de contraste avec le vérificateur de contraste WebAIM, et parcourez le formulaire au clavier seulement.
3. Marquez chaque constat confirmé, faux ou non vérifiable.
4. Fiche prompts/design-heuristic-review.md.

Avec votre IA : « Interroge-moi sur les dix heuristiques de Nielsen : décris un problème d'interface à la fois et demande-moi quelle heuristique il enfreint. Dix tours, puis mon score. »

Synthèse (10 min)

Trois lignes : utilisateurs et tâche principale, références nommées, vérifications par outil. Puis refaites les exercices sans notes.

Jour 35 · 07/12 — UX : synthèse de recherche et textes d'interface

Objectif : utiliser un modèle sur de vraies notes de recherche et sur les micro-textes, jamais à la place des utilisateurs.

Théorie 1/2 : pas d'utilisateurs inventés

Faible : Crée 3 personas pour mon appli et dis-moi ce qu'ils veulent.

Diagnostic : des personas sortis de nulle part sont les stéréotypes du modèle, présentés comme de la recherche. Un modèle peut vous aider à organiser ce qu'ont dit de vraies personnes : regrouper des notes d'entretien par thème, compter combien de personnes ont soulevé chaque thème, les citer. Il ne peut pas vous dire ce que veulent vos utilisateurs sans données venant d'eux.

Corrigé : Voici les notes de 6 entretiens utilisateurs, une par balise
          <interview>. Regroupe les problèmes cités par thème. Pour
          chaque thème : un nom, combien d'entretiens le citent, deux
          citations exactes avec le numéro d'entretien. N'ajoute aucun
          thème qu'aucun entretien ne cite.

Théorie 2/2 : les textes d'interface

Pour les micro-textes (libellés de bouton, messages d'erreur), donnez la situation, l'état d'esprit de l'utilisateur, la longueur maximale et la règle : un message d'erreur dit ce qui s'est passé et quoi faire ensuite.

Écris 3 versions du message affiché quand un mot de passe est trop
court (12 caractères minimum). Les utilisateurs sont en pleine
inscription, souvent sur téléphone. 80 caractères max. Dis quoi
faire, pas seulement ce qui a échoué. Sans reproche, sans point
d'exclamation.

Pratique (30 min)

1. Interrogez trois personnes (amis, famille) dix minutes sur un outil qui les agace. Prenez des notes.
2. Lancez le prompt de synthèse sur vos notes. Vérifiez chaque citation dans vos notes et chaque compte à la main.
3. Écrivez trois messages d'erreur pour votre projet avec le prompt de micro-texte ; choisissez-en un et dites pourquoi.
4. Fiches prompts/ux-research-synthesis.md et prompts/ux-microcopy.md.

Avec votre IA : « Je prépare un entretien utilisateur de 10 minutes sur la façon dont les gens gèrent leurs mots de passe. Relis mes cinq questions [coller] et signale celles qui sont orientées ou qui portent sur l'avenir au lieu du comportement passé. »

Synthèse (10 min)

Trois lignes : pas d'utilisateurs inventés, comptes et citations, ce que dit un message d'erreur. Puis refaites les exercices sans notes.

Jour 36 · 08/12 — Data : de la question au SQL

Objectif : obtenir une requête juste en donnant le schéma et une question assez précise pour n'avoir qu'une réponse.

Théorie 1/2 : le prompt faible

Écris une requête SQL pour avoir les meilleurs clients.

Diagnostic : pas de schéma, donc le modèle invente des noms de tables ; pas de dialecte ; et « meilleurs » n'est pas défini (le plus de commandes ? le plus de chiffre d'affaires ? cette année ?). Le passage texte vers SQL marche quand le modèle voit les vraies tables et que la question est sans ambiguïté.

Théorie 2/2 : le prompt corrigé

Dialecte : PostgreSQL 17.
<schema>
CREATE TABLE customers (id int PRIMARY KEY, name text, country text);
CREATE TABLE orders (id int PRIMARY KEY, customer_id int REFERENCES
  customers(id), placed_at timestamptz, total_cents int,
  status text CHECK (status IN ('paid','refunded','cancelled')));
</schema>
Question : les 10 clients au plus fort chiffre d'affaires payé en 2026,
avec leur nom, leur pays et le chiffre en euros. Les commandes
remboursées et annulées ne comptent pas. Égalités : trier par nom.
Sortie : la requête seule, puis une ligne par hypothèse faite.

Pratique (30 min)

1. Créez les deux tables dans un PostgreSQL local (ou SQLite, en ajustant la ligne du dialecte), et insérez 15 lignes à la main aux réponses connues, dont une commande remboursée et une égalité.
2. Écrivez d'abord la requête vous-même. Puis lancez le prompt corrigé et exécutez sa requête.
3. Comparez les deux résultats avec la réponse calculée à la main.
4. Fiche prompts/data-text-to-sql.md, avec vos 15 lignes comme jeu d'essai.

Avec votre IA : « Voici mon schéma [coller]. Donne-moi cinq questions métier de difficulté croissante auxquelles ce schéma peut répondre, une à la fois. J'écris le SQL ; tu me dis s'il répond exactement à la question, et sinon tu donnes un jeu de lignes où il donnerait un autre résultat. »

Synthèse (10 min)

Trois lignes : schéma, dialecte, une question sans ambiguïté. Puis refaites les exercices sans notes.

Jour 37 · 09/12 — Data : relire une requête, nettoyer des données

Objectif : obtenir une revue de performance appuyée sur le plan de requête, et un plan de nettoyage contrôlable.

Théorie 1/2 : la performance demande le plan

Faible :  Pourquoi ma requête est lente ?
Corrigé : PostgreSQL 17. La requête ci-dessous prend 4 s sur 2 millions
          de lignes dans orders. <query>…</query>
          <plan>(sortie de EXPLAIN (ANALYZE, BUFFERS))</plan>
          <indexes>(sortie de \d orders)</indexes>
          Tâche : nomme le nœud le plus coûteux du plan (cité), pourquoi
          il coûte, et un changement à tester. Ne propose pas de
          changement de configuration du serveur.

Sans le plan, le modèle ne peut que réciter des conseils généraux (« ajoute un index »). Avec, le nœud coûteux est dans le texte, et vous vérifiez la citation.

Théorie 2/2 : nettoyer des données

Pour nettoyer des données, demandez un plan de règles avant toute donnée transformée : chaque règle, les lignes qu'elle touche, et ce qu'elle leur fait. Vous appliquez les règles dans du code et vous comptez. Un modèle qui « nettoie » un fichier directement changera en silence des valeurs que vous ne lui avez jamais demandé de toucher.

Pratique (30 min)

1. Chargez 100 000 lignes générées dans orders (generate_series), lancez une requête qui filtre sur placed_at, et capturez EXPLAIN (ANALYZE, BUFFERS).
2. Lancez le prompt corrigé. Appliquez le changement proposé, relancez le plan, comparez les temps.
3. Prenez un petit CSV désordonné (jeu de données public). Demandez des règles de nettoyage ; appliquez-les en Python ou en SQL ; comptez les lignes modifiées par règle.
4. Fiches prompts/data-query-plan-review.md et prompts/data-cleaning-rules.md.

Avec votre IA : « Voici une sortie de EXPLAIN ANALYZE [coller]. Ne me dis pas ce qui est lent. Demande-moi de trouver le nœud au temps réel le plus élevé, puis la raison, en ne donnant des indices que si je bloque. »

Synthèse (10 min)

Trois lignes : le plan en entrée, le nœud cité, des règles et non des modifications. Puis refaites les exercices sans notes.

Jour 38 · 10/12 — ML : plan d'expérience et fuite de données

Objectif : faire relire un plan d'expérience par un modèle, et attraper les erreurs classiques.

Théorie 1/2 : le prompt faible

Comment obtenir 99 % d'exactitude sur mon jeu de données ?

Diagnostic : le but est un chiffre, pas un modèle utile. Une exactitude très haute est souvent un symptôme : un jeu déséquilibré (99 % d'une classe), ou une fuite de données (leakage), quand une information sur la cible se glisse dans les variables ou dans le jeu de test. La page « Common pitfalls » de scikit-learn traite la fuite avec des exemples.

Théorie 2/2 : le prompt corrigé

Relis mon plan d'expérience pour y chercher des fuites et des erreurs
d'évaluation.
Données : 50 000 fiches clients, une ligne par client et par mois,
cible « résilie le mois suivant » (8 % de positifs).
Plan : <plan>(variables, découpage, prétraitement, métrique)</plan>
Sortie : chaque risque avec : l'étape du plan (citée), pourquoi elle
peut fuir ou tromper, comment le tester. Puis la métrique que tu
retiendrais et pourquoi. Ne propose pas d'architecture de modèle.

Pratique (30 min)

1. Écrivez un plan d'une page pour un petit jeu de données public (par exemple un des jeux intégrés à scikit-learn). Mettez-y exprès une fuite (découpage aléatoire de lignes ordonnées dans le temps, ou normalisation avant découpage).
2. Lancez le prompt corrigé. A-t-il trouvé votre fuite ? A-t-il signalé de faux problèmes ?
3. Faites l'expérience des deux façons dans un notebook ; notez l'écart de score.
4. Fiche prompts/ml-experiment-review.md.

Avec votre IA : « Interroge-moi sur la fuite de données : décris une installation d'expérience à la fois, certaines avec une fuite et d'autres saines, et demande-moi si elle fuit et pourquoi. Huit tours. »

Synthèse (10 min)

Trois lignes : les scores suspects, deux sortes de fuite, la métrique pour des données déséquilibrées. Puis refaites les exercices sans notes.

Jour 39 · 11/12 — ML : un modèle de langage comme étiqueteur, mesuré

Objectif : faire étiqueter des données par un modèle, et le mesurer contre des étiquettes posées par vous.

Théorie 1/2 : étiqueter est une classification

Un modèle de langage sait étiqueter du texte (sentiment, sujet, intention) sans entraînement, avec le même prompt qu'au jour 27 : étiquettes fixes, définitions, exemples, sortie structurée, température basse. Avant d'utiliser ses étiquettes, étiquetez un échantillon vous-même (un jeu « de référence ») et mesurez l'accord. Si le modèle est souvent en désaccord avec vous sur une étiquette, sa définition est floue, pour le modèle et peut-être pour vous.

Théorie 2/2 : mesurer

function accuracy(pred, gold) {
}

function accuracy(pred, gold) {
  if (pred.length !== gold.length || gold.length === 0) return null;
  let ok = 0;
  for (let i = 0; i < gold.length; i++) {
    if (pred[i] === gold[i]) ok++;
  }
  return ok / gold.length;
}

Pratique (30 min)

1. Prenez 40 courts textes publics (avis produits d'un jeu de données ouvert). Étiquetez-les vous-même : positif, négatif, mitigé.
2. Faites-les étiqueter par le modèle local avec un prompt d'étiquetage ; calculez l'exactitude et, par étiquette, combien le modèle en a eu justes.
3. Réécrivez la définition de la pire étiquette ; relancez ; comparez.
4. Fiche prompts/ml-labeller.md avec le jeu de référence comme test.

Avec votre IA : « Voici 10 textes où mon étiquette et celle du modèle diffèrent [coller]. Pour chacun, défends brièvement les deux étiquettes, puis dis-moi quelle partie de mes définitions est ambiguë. »

Synthèse (10 min)

Trois lignes : le jeu de référence, l'exactitude par étiquette, corriger les définitions. Puis refaites les exercices sans notes.

Jour 40 · 12/12 — QA : des cas de test depuis l'exigence

Objectif : tirer des cas de test d'une exigence, avec les limites, dans un format qu'une équipe peut exécuter.

Théorie 1/2 : le prompt faible

Écris des cas de test pour la page de connexion.

Diagnostic : pas d'exigence, donc le modèle teste ce que font d'habitude les pages de connexion, pas ce que la vôtre doit faire. La conception de tests part de la règle : donnez le texte de l'exigence, demandez les classes d'entrées (valides, invalides, limites) et le résultat attendu de chacune.

Théorie 2/2 : le prompt corrigé

Exigence : <req>Le compte d'un utilisateur est bloqué 30 minutes après
5 échecs de connexion en 15 minutes. Une connexion réussie remet le
compteur à zéro.</req>
Tâche : écris des scénarios de test en Gherkin (Given/When/Then)
couvrant : le cas nominal, chaque limite (nombre d'essais, fenêtre de
temps, durée du blocage), la remise à zéro. Un scénario par comportement.
Puis liste les questions que l'exigence laisse ouvertes (par exemple :
un échec pendant le blocage le prolonge-t-il ?). N'y réponds pas toi-même.

Pratique (30 min)

1. Écrivez vous-même les scénarios de la règle de blocage : au moins six.
2. Lancez le prompt corrigé ; comparez ses scénarios aux vôtres. Quelles limites chacun a-t-il ratées ?
3. Répondez aux questions ouvertes comme le ferait un product owner, et ajoutez les scénarios qu'elles impliquent.
4. Fiche prompts/qa-scenarios-from-requirement.md.

Avec votre IA : « Voici une exigence [coller]. Joue un responsable QA qui m'interroge : demande-moi, une à la fois, les valeurs limites et le résultat attendu pour chacune, et dis-moi quand j'en oublie une. »

Le faire faire par un agent : une fois des scénarios écrits à la main, un agent peut transformer des scénarios Gherkin validés en tests automatisés dans votre framework et les lancer : « Implémente les scénarios de features/lock.feature en étapes pytest-bdd, lance-les, et dis-moi lesquels échouent. » Vous relisez toujours le code des étapes : une étape qui n'affirme rien rend tous les scénarios verts.

Synthèse (10 min)

Trois lignes : partir de l'exigence, les limites, les questions ouvertes. Puis refaites les exercices sans notes.

Jour 41 · 13/12 — QA : rapports de bug et chartes exploratoires

Objectif : transformer des notes brutes en rapport de bug qu'un développeur reproduit, et préparer une session exploratoire.

Théorie 1/2 : le rapport de bug

Faible :  Écris un rapport de bug : le panier est cassé sur mobile.
Corrigé : Transforme mes notes en rapport de bug avec : titre (ce qui
          échoue, où), environnement, étapes de reproduction (numérotées),
          résultat attendu, résultat obtenu, fréquence, pièces à joindre.
          N'utilise que mes notes ; écris [ASK] là où un champ manque.
          <notes>…</notes>

Le prompt faible invite à inventer des étapes. Le corrigé garde les faits, les structure, et montre quoi collecter avant d'envoyer.

Théorie 2/2 : les chartes exploratoires

Le test exploratoire se prépare avec une courte charte : quoi explorer, avec quelles ressources, pour découvrir quel genre d'information. Un modèle propose bien des chartes à partir d'une description de fonction ; vous les choisissez et les menez.

Fonction : <feature>codes promo au paiement</feature>
Propose 5 chartes exploratoires de la forme « Explorer … avec … pour
découvrir … », chacune pour une session de 30 minutes, visant des
risques différents (calcul, cumul avec d'autres offres, expiration,
abus, affichage).

Pratique (30 min)

1. Trouvez un vrai petit bug dans une appli web que vous utilisez (un défaut d'affichage suffit). Écrivez des notes brutes.
2. Lancez le prompt de rapport ; remplissez vous-même les champs [ASK] ; reproduisez les étapes sur un second appareil.
3. Générez des chartes pour une fonction d'un de vos projets ; menez-en une pendant 20 minutes et notez ce que vous avez trouvé.
4. Fiches prompts/qa-bug-report.md et prompts/qa-charters.md.

Avec votre IA : « Voici mon rapport de bug [coller]. Joue le développeur qui le reçoit : pose-moi les questions dont tu aurais besoin avant de pouvoir reproduire le bug. Arrête-toi quand tu pourrais le reproduire. »

Synthèse (10 min)

Trois lignes : les champs d'un rapport, [ASK] plutôt qu'invention, la forme d'une charte. Puis refaites les exercices sans notes.

Jour 42 · 14/12 — Architecture : décisions et compromis

Objectif : utiliser un modèle pour élargir les options et éprouver une décision, puis la consigner en ADR.

Théorie 1/2 : le prompt faible

Je pars sur des microservices ou un monolithe ?

Diagnostic : sans contexte, la réponse est « ça dépend », suivie d'une comparaison générique. Un prompt d'architecture donne les forces en présence : taille de l'équipe, charge, délais, compétences, contraintes. Il demande des options avec leurs conséquences, et les arguments contre l'option que vous préférez.

Théorie 2/2 : le prompt corrigé et l'ADR

Contexte : appli de réservation, 2 développeurs, 200 utilisateurs par
jour, un VPS, une mise en production par semaine ; il faut ajouter le
paiement en ligne d'ici 3 mois.
Décision à prendre : où vit la logique de paiement.
Tâche : 1) trois options, chacune avec ses conséquences sur le
déploiement, les tests, l'isolation des pannes et le coût ; 2) le
meilleur argument contre mon option préférée (un module dans le
monolithe existant) ; 3) ce qui devrait me faire revoir la décision.
Sortie : un Architecture Decision Record : Title, Status, Context,
Decision, Consequences. Laisse Decision à [TO DECIDE].

Michael Nygard a proposé l'Architecture Decision Record en 2011 : un court fichier par décision, gardé avec le code. Le modèle rédige les options ; la décision et son statut sont à vous.

Pratique (30 min)

1. Choisissez une vraie décision dans un de vos projets (base de données, hébergement, framework).
2. Écrivez le contexte avec les forces en présence. Lancez le prompt corrigé.
3. Vérifiez une conséquence annoncée par option dans la documentation officielle. Écrivez la décision vous-même.
4. Commitez l'ADR dans docs/adr/0001-….md de ce projet ; fiche prompts/archi-adr.md.

Avec votre IA : « Voici mon ADR [coller]. Joue un architecte senior sceptique : pose-moi trois questions qui vérifient si le contexte justifie vraiment la décision, une à la fois. »

Synthèse (10 min)

Trois lignes : les forces, des options avec leurs conséquences, la décision reste à vous. Puis refaites les exercices sans notes.

Jour 43 · 15/12 — Bilan du module 3 : le pack de prompts de construction

Objectif : livrer les prompts testés des métiers de la construction et corriger le plus faible.

Théorie 1/2 : ce qui a changé depuis le module 2

Les prompts de construction ont ajouté deux habitudes : partir de la spécification, pas de l'artefact (les tests depuis la spec et non le code ; les cas de test depuis l'exigence), et laisser décisions et changements de comportement à l'humain (signaler les bugs pendant une refactorisation, [TO DECIDE] dans un ADR, pas d'utilisateurs inventés). Les vérifications extérieures étaient les tests, les mutations, les plans de requête, les outils d'accessibilité et les jeux de référence.

Théorie 2/2 : choisir le meilleur prompt

Pratique (30 min)

1. Relancez chaque fiche du module sur son cas de test ; mettez à jour ## History.
2. Prenez la fiche au score le plus bas ; appliquez deux fois la boucle du jour 8.
3. Écrivez jobs/build.md : un paragraphe par métier du module, avec le prompt que vous réutiliseriez en premier.
4. Livrable du module 3 : le pack de prompts de construction sur votre forge, avec l'avant et l'après du prompt amélioré.

Avec votre IA : « Voici ma fiche de prompt la plus faible et ses échecs [coller]. Ne la réécris pas. Pose-moi des questions jusqu'à ce que je dise moi-même laquelle des sept parties cause les échecs. »

Synthèse (10 min)

Écrivez de mémoire les deux habitudes et cinq vérifications extérieures du module. Puis refaites les exercices que vous aviez ratés.