J'ai Écrit le Livre sur les Contrats de Prompts. Le Chapitre 4 a Cassé Mon Propre Framework.

Le contrat stipulait return a JSON array of contacts. Je n'avais défini ni limite, ni pagination. Le code généré par l'IA passait tous les tests. Puis un utilisateur a lancé un rapport sur un gros segment et le navigateur a planté sous 5 000 contacts balancés d'un coup.

Le code était correct. Le contrat était le bug.

J'ai publié un article sur les contrats de prompt. Il a été suffisamment partagé pour qu'en faire un livre ait du sens. Et en l'écrivant, trois trucs ont émergé qu'un seul article ne pouvait pas couvrir. Le contrat qui pète alors que le code est parfait. La frontière entre code fiable et faits fiables. Et l'instinct qui s'atrophie quand on délègue trop longtemps.

5 000 Contacts, Zéro Erreur, Un Navigateur Planté

J'ai construit le truc en un week-end. Petit outil pour synchroniser les contacts distributeurs d'une boutique WooCommerce, backend entièrement généré par IA à partir d'un contrat de prompt. Modèle de données, endpoints API, validation, tout spécifié à l'avance. Y compris cette ligne : "return a JSON array of contacts matching the filter criteria."

Tous les critères d'acceptation validés. J'ai déployé un vendredi après-midi avant d'emmener les gosses faire du snorkeling (parce qu'apparemment j'ai horreur des week-ends paisibles).

Lundi. Un utilisateur avec 5 000 contacts dans son segment distributeur clique sur "Export." Le navigateur devient blanc. L'onglet plante. Pas d'erreur, pas de dégradation gracieuse. Juste un onglet mort et un blob JSON de la taille d'un petit roman qui traîne en mémoire.

L'IA n'avait pas dévié du contrat. Pas d'une seule ligne. Elle a fait exactement ce que j'avais demandé, c'est exactement pour ça que ça a pété.

Le chapitre 4 du livre pose cette question : est-ce que l'IA a cassé le contrat, ou est-ce que j'ai écrit un contrat qui spécifiait le mauvais comportement ?

Trois patterns d'échec de contrat sont sortis de ce chapitre. Cas limites manqués : le contrat disait "return contacts" mais ne précisait jamais ce qui arrive quand il y en a 5 000 (pas de pagination, pas de limite, l'absence de contrainte est elle-même une mauvaise spécification). Mauvaises hypothèses de domaine : je supposais que les contacts seraient des dizaines, peut-être des centaines, mais cette hypothèse vivait dans ma tête, pas dans le document. Et sur-spécification du cosmétique pendant que les limites structurelles étaient absentes : j'avais détaillé l'imbrication JSON exacte, les noms de champs, les types. Mais payload max ? Fallback quand c'est trop gros ? Rien.

La solution n'était pas de mieux prompter. Trois questions. J'ai ajouté trois questions au workflow :

Voici mon contrat pour [feature].
Avant de générer du code :
- Quels cas limites je ne couvre pas ?
- Quelles hypothèses je fais qui ne sont pas écrites ?
- Où est-ce que ça casse à l'échelle ?

Trois questions. C'est tout. L'IA démonte votre spec avant d'écrire une ligne. Vous bouchez les trous, puis vous générez.

C'est la boucle que le livre documente. Pas prompter, générer, corriger le code, re-prompter (le cycle naïf qui garde la spec figée pendant que vous pansez les symptômes). La vraie boucle : spécifier, générer, vérifier, réviser LA SPEC. La spec est le document vivant. Le code est l'output. Quand l'output casse, vous corrigez l'input.

La première version de tout contrat est un brouillon. Toujours. Le test du feeling aide à décider si vous avez besoin d'un contrat (on y revient). Mais une fois que vous décidez qu'il vous en faut un, partez du principe qu'il a des trous. La boucle est le produit, pas le document.

L'article disait : écrivez un contrat. Le livre devait répondre : et quand le contrat lui-même est le bug ?

Un contrat cassé, vous pouvez le réparer (patcher la spec, regénérer). Le problème suivant est plus sournois, parce que le contrat ne peut pas du tout le corriger.

Le Framework a une Frontière que l'Article n'a Jamais Tracée

Les contrats de prompt produisent du code fiable. Ils ne produisent pas des faits fiables.

Cette phrase n'apparaît nulle part dans l'article original. Elle ne pouvait pas y être. Dans un seul article vous montrez le framework qui marche, vous n'allez pas cartographier où il s'arrête. Un livre ne vous laisse pas vous en tirer comme ça.

Un webhook Stripe valide la signature ou ne la valide pas. Un schéma de base de données respecte l'index ou ne le respecte pas. Pour la logique de code, le contrat élimine l'hallucination. L'IA génère ce que vous avez spécifié, les tests le confirment, terminé.

Mais mon outil WooCommerce génère aussi des rapports avec de vraies données distributeur. URLs de contact, nombres d'audience, noms de partenaires. Des trucs qui existent dans le monde, pas dans le contrat. Et là le contrat a fait baisser l'hallucination de 30% à environ 15%. Baisser, pas disparaître.

15% ça sonne petit jusqu'à ce que vous rencontriez Karen de la Compta. Chaque pipeline en a une. C'est la personne à l'autre bout qui se fiche de votre architecture propre. Karen se soucie que la ligne 47 du rapport trimestriel liste un distributeur qui n'existe pas. Vous pouvez expliquer que le code est techniquement correct. Karen vous expliquera que le client a appelé, et que votre rapport techniquement correct a fait passer l'entreprise pour des amateurs. Karen gagne toujours ces disputes. 🤷

L'étude METR a trouvé un écart de 39-44% entre la productivité que les développeurs pensent avoir avec l'IA et leur productivité réelle. Ox Security est allé plus loin : 10 anti-patterns récurrents dans 80-100% du code généré par IA, ce qu'ils ont appelé "une armée de juniors talentueux sans supervision." Le contrat est la supervision pour le code. Pour les faits que l'IA tire de ses données d'entraînement ou invente de nulle part, le contrat n'a aucune juridiction.

Pour les produits où la valeur est dans le code (la plupart des SaaS), le framework suffit. Pour les produits où la valeur dépend de faits générés par l'IA, vous avez besoin d'une couche de vérification par-dessus. Le livre documente les deux côtés. L'article n'avait de place que pour un.

Et cette semaine rend la frontière plus visible. 1 234 skills communautaires pour Claude Code. Neuf catégories, du déploiement aux tests à la documentation. Chacune automatise la génération. Combien automatisent la vérification des outputs factuels ? J'ai scrollé dans le top 10. Zéro.

1 234 skills pour générer du code. Celle pour vérifier les faits n'existe pas encore.

Ce qui suit n'est ni technique ni factuel. C'est personnel, et c'était le chapitre le plus dur à écrire.

La Compétence que le Livre m'a Apprise qu'Aucune Slash Command ne Peut Remplacer

J'ai écrit ce contrat il y a trois mois pour un import CSV de partenaires :

feature: partner-csv-import
acceptance_criteria:
  - Parse CSV with headers: name, url, category, audience_size
  - Validate each row: name non-empty, url valid format,
    audience_size integer > 0
  - Skip malformed rows, log them to stderr
  - Output clean JSON array to stdout
edge_cases:
  - Empty CSV → exit 0, empty array
  - CSV > 50,000 rows → stream processing, never load full file
  - Duplicate URLs → keep first occurrence, log duplicates

Et voici ce que j'ai généré la semaine dernière pour un script jetable pour renommer des fichiers image :

rename all .png files in /uploads to kebab-case, lowercase

Pas de contrat. Pas de critères d'acceptation. Pas de cas limites. Une ligne.

La différence c'est le test du feeling. L'import CSV touche des données partenaire qui alimentent des rapports de production. Si le parser fait tomber des lignes silencieusement ou corrompt une URL, de vraies personnes prennent de vraies décisions sur de mauvaises données. Ça me serre le ventre. Contrat. Le renommage d'images ? Si ça foire un nom de fichier je le relance juste. Haussement d'épaules. Vibe code.

L'article original avait un pitch simple : écrivez un contrat, laissez l'IA coder. Le livre devait ajouter la deuxième partie inconfortable : mais gardez votre instinct vivant.

J'ai travaillé dans une banque française au début de ma carrière. Ils avaient des jobs batch COBOL qui tournaient en production depuis 25 ans. Personne n'y touchait. Personne n'en avait besoin. Toute la mise en place marchait si bien que comprendre le système était devenu optionnel. Jusqu'à ce qu'un changement réglementaire force une modification, et les développeurs qui comprenaient le système étaient à la retraite. Partis. Pas parce que quelqu'un avait fait une erreur. Parce que le système était trop fiable trop longtemps.

Luciano Nooijen a dit au MIT Technology Review que ses instincts de codage se sont dégradés après des mois d'usage intensif d'IA. Même mécanisme, juste compressé de décennies à mois. Craig Weiss l'a dit différemment cette semaine (et la communauté dev a approuvé assez fort pour qu'on le remarque) : le vrai fossé c'est la conception système et la réflexion produit, pas la syntaxe. La syntaxe est déléguée. Le jugement ne peut pas l'être.

Le truc marrant (ou terrifiant, ça dépend quel jour vous me demandez).

On est passé de lire chaque ligne de code à ne plus la lire du tout. Et le remplacement de "j'ai vérifié ça ligne par ligne" n'est pas un système de vérification automatisé supérieur. Aucune suite de tests n'attrape tout. On tourne au feeling maintenant. Ce truc va exploser. Celui-là c'est bon. Celui-ci, attention. On a échangé la revue de code contre le gut check. Le workflow de développement le plus avancé de l'histoire tourne à l'estomac. 🫠

Le test du feeling en fait une méthode au lieu d'une supposition. Imaginez le pire output possible pour la tâche que vous allez déléguer. Base de données corrompue. Paiement débité deux fois. Données utilisateur exposées dans les logs. Ventre serré : contrat. Haussement d'épaules : vibe code librement.

J'ai construit le framework original des contrats de prompt après assez de désastres comme le crash des 5 000 contacts. L'article a capturé la direction. Le livre cartographie le terrain, impasses incluses.

L'article a enseigné un framework. Le livre m'a appris quand ne pas l'utiliser.

Ce que l'Article ne Pouvait pas Couvrir

Une lecture de 10 minutes prouve une direction. "La spécification bat l'improvisation." Cette partie est réglée.

Mais une lecture de 10 minutes ne vous laisse pas vous poser avec les modes d'échec. Le contrat qui est le bug. La frontière où les faits commencent et le framework s'arrête. L'érosion lente de votre propre jugement. J'ai écrit le livre pour creuser tout ça, pour les devs qui tapent les mêmes murs et veulent plus qu'un cap au compas.

Le livre s'appelle Prompt Contracts: How I Stopped Vibe Coding and Started Shipping Real Software With AI. Il est sur Amazon maintenant.

---

L'industrie va empiler des skills, des couches, des abstractions. Cette semaine c'est 1 234. Le mois prochain ce sera 50 000. Chaque nouvelle couche rend plus confortable de ne jamais regarder ce qui se passe en dessous.

Le livre ne dit pas "arrêtez d'empiler." Il dit : sachez où sont les fissures dans les fondations. L'homme sage ne construit pas sa maison sur le sable. Le contrat peut être le bug. Le contrat a une frontière. Et votre instinct a une date d'expiration si vous ne l'utilisez pas.

Feeling + méthode. Shippez.

---

Sources

Étude METR sur la productivité du développement assisté par IA (écart de perception 39-44%). Ox Security, "Top 10 AI Code Generation Risks" (anti-patterns dans 80-100% du code IA). MIT Technology Review, Luciano Nooijen sur l'atrophie de l'instinct de codage.

Si vous construisez avec l'IA et voulez la version honnête (trous inclus, pas juste le highlight reel), suivez. Le prochain atterrit dans votre inbox.

(*) La couverture est générée par IA. Les trois trous dans l'article sont certifiés bio, erreurs humaines de la ferme à la table.