Spécification
Des specs précises en entrée. Du code livré en sortie.
Un LLM ne sait pas ce que vous voulez vraiment. Il sait ce que vous avez dit. L'écart entre les deux est là où meurent la plupart des projets IA. Le travail consiste à fermer cet écart avant de générer le moindre code : en resserrant le brief, en faisant remonter les inconnues, et en mettant des mots sur ce qui serait autrement supposé.
La boucle du stagiaire
Le prompt d'un junior, c'est la description de la fonctionnalité : 'ajoute une page de facturation.' Le modèle produit une page de facturation plausible, avec la mauvaise devise, la mauvaise logique de TVA, pas de proratisation, des appels vers un service qui n'existe pas. Le prompt suivant : 'corrige la devise.' Puis 'corrige la TVA.' Trois jours plus tard, la codebase a six pages de facturation et aucune ne fonctionne. La vitesse sans intention, c'est juste générer des bugs plus vite.
Le travail d'avant
Avant tout code : le LLM joue le rôle de gardien. Quel problème résolvez-vous vraiment ? Quelle est la forme des données ? Qu'est-ce qui casse aux limites ? Quelle est la version la plus simple qui se livre ? Le brief est challengé avant de demander au modèle de l'exécuter. C'est une conversation, pas un exercice d'écriture. Un ou deux prompts de plus, main dans la main avec le modèle, jusqu'à ce que les inconnues deviennent des décisions. Pour les travaux à fort enjeu, la conversation atterrit dans un spec.md que l'équipe peut consulter. Pour les plus petits, dans un prompt plus précis. Dans les deux cas, les suppositions se traitent avant la génération, pas après.
Une intention décidée, pas supposée
Les specs à fort enjeu vivent dans le repo et versionnent avec le code, visibles pour le prochain ingénieur, la prochaine équipe, le prochain modèle. Les décisions plus petites n'ont pas toujours besoin d'un fichier, mais elles ont été prises délibérément, en conversation, avant la génération. L'intention se retrouve, elle ne se reconstruit pas.
- 01Avant de générer du code, quelque chose challenge-t-il le brief : un collègue, une checklist, un modèle ?
- 02L'intention de la dernière fonctionnalité livrée pourrait-elle être reproduite par un inconnu sans demander à personne ?
- 03Quand le périmètre change, qu'est-ce qui change en premier : le brief ou le code ?
- 04Pour vos travaux les plus critiques, la spec est-elle écrite quelque part où l'équipe (et le modèle) peut la trouver ?