Il ne remplace pas le prompt, il le rend fiable. Le vrai sujet, c’est de passer d’une bonne formulation à une tâche correctement définie, vérifiable et exploitable par un modèle, un agent ou un workflow IA.
Pourquoi le prompt ne suffit plus ?
Le prompt engineering reste utile, mais il ne suffit plus dès qu’on confie à l’IA des tâches complexes comme coder, analyser des données ou prendre des décisions en plusieurs étapes.
Bien demander, c’est savoir formuler une consigne claire. Définir ce que veut dire bien fait, c’est autre chose. C’est préciser le résultat attendu, les contraintes, les exceptions, les critères de validation, le format de sortie, et parfois même ce que l’IA n’a pas le droit de faire.
Peut-on faire confiance à un LLM comme juge ?
C’est là que beaucoup de projets se plantent. Un modèle peut produire une réponse très convaincante. Propre, fluide, bien structurée, presque rassurante. Et pourtant, il peut avoir raté l’exigence réelle. Il répond bien à la surface, mais pas au besoin.
Avec un prompt vague, l’IA optimise souvent ce qui est visible. Elle améliore la formulation, donne une impression de maîtrise, remplit les trous avec des hypothèses plausibles. Le problème, c’est que vos vraies règles métier ne sont pas dans sa tête.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le specification gaming, c’est exactement ça. Le système respecte la consigne apparente, mais contourne l’intention réelle. Pas forcément par mauvaise volonté, juste parce qu’on ne lui a pas donné de cadre assez précis.
- Un résumé peut être excellent à lire, mais oublier une métrique clé qui change toute l’analyse.
- Un nettoyage de données peut supprimer des lignes “anormales”, alors que ces lignes étaient justement celles à investiguer.
- Un patch de code peut faire passer le test visible, tout en cassant une hypothèse cachée dans le reste de l’application.
La bonne question n’est donc plus seulement est-ce que la réponse a l’air bonne ? La vraie question devient est-ce qu’elle respecte l’objectif, les contraintes, les cas limites, le format attendu et les critères d’évaluation ?
Je le vois souvent sur des projets data ou automatisation. Le prompt est propre, la sortie est jolie, mais elle est inutilisable. Personne n’avait défini les règles de validation, le format exact attendu, les champs obligatoires, ou les limites à ne pas franchir. Résultat, on passe plus de temps à corriger qu’à gagner du temps.
À partir du moment où une sortie IA doit être relue, testée, intégrée dans un outil ou consommée par un autre système, le prompt seul devient fragile. Il faut passer à une logique de spécification.
C’est quoi une bonne spécification IA ?
Quels serveurs MCP choisir pour vos agents IA ?
La specification engineering, c’est simplement transformer une demande floue en instructions exécutables, testables et relisibles.
Une bonne spécification IA ne cherche pas à faire joli. Elle décrit l’objectif, le contexte, les entrées disponibles, le format de sortie attendu, les contraintes, les critères d’évaluation, les cas limites et les étapes de vérification. Ce n’est pas juste un prompt plus long. C’est une manière de rendre le travail vérifiable, surtout quand le résultat peut influencer une analyse, une décision ou une automatisation.
Prenez une demande data classique : Analyse ce dataset de churn. C’est trop vague. L’IA peut faire un graphique, entraîner un modèle au hasard, oublier les valeurs manquantes, mélanger les données d’entraînement et de test, puis annoncer un score flatteur mais inutilisable. Je l’ai vu chez un client, avec un modèle qui “prédisait” très bien parce qu’une colonne contenait déjà une information post-résiliation. C’est ce qu’on appelle une fuite de données.
Une spécification plus solide dirait plutôt : Analyse le dataset de churn. Contrôle les valeurs manquantes, l’équilibre des classes et les risques de fuite de données. Fais le split train/test avant tout prétraitement. Compare logistic regression, random forest et XGBoost. Reporte accuracy, precision, recall, F1, ROC-AUC, PR-AUC et matrice de confusion. Ne présente pas les résultats comme une preuve de causalité.
Chaque élément change la qualité du résultat. Les contraintes empêchent l’IA de prendre des raccourcis. Les interdictions évitent les conclusions abusives. Les métriques forcent une comparaison propre, pas juste un score qui arrange. Le format de sortie évite de recevoir un pavé inutilisable quand vous aviez besoin d’un tableau clair. L’intérêt n’est pas d’écrire plus. L’intérêt, c’est d’enlever l’ambiguïté là où elle coûte cher.
| Élément de spécification | Pourquoi ça compte |
| Objectif | Ça dit clairement ce qu’on cherche à obtenir, pas juste le sujet général. |
| Contexte | Ça aide l’IA à comprendre le métier, les enjeux et les pièges possibles. |
| Entrées | Ça précise les données, fichiers, colonnes ou sources à utiliser. |
| Sortie attendue | Ça rend le résultat exploitable directement, sans retraitement inutile. |
| Contraintes | Ça limite les mauvaises méthodes, les hypothèses fragiles et les raccourcis. |
| Critères d’évaluation | Ça permet de juger si le résultat est bon, pas seulement convaincant. |
| Cas limites | Ça force à traiter les situations bizarres, rares ou risquées. |
| Vérifications | Ça réduit les erreurs silencieuses avant de faire confiance au résultat. |
Cette logique devient encore plus importante quand l’IA ne produit pas seulement du texte, mais déclenche du code, une analyse, une décision ou une automatisation. À ce moment-là, une consigne floue ne crée pas juste une réponse moyenne. Elle peut créer une action mauvaise, répétée vite, à grande échelle.
Comment vérifier qu’une sortie IA est correcte ?
Vérifier une sortie IA, ce n’est pas demander si elle paraît intelligente, c’est vérifier si elle satisfait les exigences définies avant l’exécution. C’est là que beaucoup de projets IA se plantent. On juge la réponse au feeling, alors qu’on devrait la juger comme un livrable.
Après chaque sortie, je me pose toujours les mêmes questions simples. Est-ce que l’objectif est atteint ? Est-ce que les contraintes sont respectées ? Est-ce que les cas limites sont traités ? Est-ce que le résultat est consommable par un autre système ? Est-ce qu’on peut le tester ? Est-ce que le modèle a optimisé une mauvaise métrique ? Cette dernière question est souvent la plus dangereuse. Le modèle peut produire une réponse très propre, très convaincante, mais alignée sur le mauvais objectif.
Le format de sortie joue un rôle énorme dans les workflows IA. Dans un outil low code, un agent ou une automatisation, une réponse en texte libre est vite pénible à exploiter. Il faut parser, deviner, nettoyer, gérer les exceptions. Et franchement, c’est souvent là que les automatisations deviennent fragiles.
Les réponses structurées changent la donne. Avec les Structured Outputs d’OpenAI, par exemple, on peut contraindre la sortie avec un schéma JSON. Un schéma JSON, c’est une description précise des champs attendus, de leurs types et parfois de leurs valeurs possibles. Ça permet de connecter une réponse IA à un CRM, un outil métier, une base de données ou un scénario Make/Zapier sans devoir deviner la structure à chaque exécution.
Mais le format ne suffit pas. Un JSON peut être parfaitement formé et raconter n’importe quoi. J’ai déjà vu un cas client où l’IA renvoyait une recommandation commerciale très bien structurée, avec un score, une justification et une action proposée. Techniquement, c’était nickel. Sauf que la recommandation ignorait la marge, qui était la métrique principale du business. Résultat propre, décision absurde.
- Valider le format attendu.
- Contrôler les contraintes définies au départ.
- Tester les cas limites.
- Revoir les hypothèses utilisées par le modèle.
- Comparer la sortie avec les métriques attendues.
- Prévoir une vérification humaine sur les décisions sensibles.
On voit aussi cette logique à un niveau plus large avec le Model Spec d’OpenAI et la Constitution d’Anthropic. Ce sont des signaux clairs. On ne se contente plus de demander au modèle de répondre. On définit aussi comment il doit se comporter dans certains cadres, avec des règles, des priorités et des limites. C’est exactement l’esprit du specification engineering.
Pourquoi la recherche va dans ce sens ?
La recherche et les produits IA convergent vers la même idée : la qualité des exigences influence directement la qualité des réponses. Pas seulement la qualité de la phrase. Pas seulement le ton. Ce qui change vraiment le résultat, c’est la clarté de ce qu’on demande au modèle de respecter.
Les travaux 2024 autour du Requirement-Oriented Prompt Engineering, qu’on peut traduire simplement par “conception de prompts orientée exigences”, vont exactement dans ce sens. L’idée n’est pas d’apprendre aux utilisateurs à écrire des prompts plus jolis. L’idée est de les entraîner à formuler des exigences exploitables : ce que le modèle doit produire, ce qu’il doit éviter, les contraintes à suivre, les critères qui permettent de dire que la réponse est bonne.
Et ça montre un écart assez net entre un prompt bien tourné et une vraie demande utilisable. Un prompt peut être élégant, poli, détaillé en apparence, et rester flou. À l’inverse, une demande un peu sèche mais bien cadrée donne souvent de meilleurs résultats. Je le vois souvent chez des clients : ils cherchent “le bon prompt”, alors que le vrai problème, c’est qu’on n’a jamais défini la sortie attendue.
Dans un projet IA, ce qui manque le plus souvent, ce n’est pas une phrase magique. C’est plutôt ça :
- Ce qui est attendu exactement.
- Ce qui est interdit ou hors périmètre.
- Ce qui doit être vérifié avant de répondre.
- Ce qui compte comme une réponse réussie.
On a déjà appris cette leçon dans la data, l’analytics engineering et l’automatisation. Une pipeline data sans contrat clair casse vite. Un tracking sans plan de marquage devient inexploitable. Une automatisation sans règles d’erreur finit par faire n’importe quoi, mais plus vite. L’IA ne fait pas exception. Elle rend juste le problème plus visible.
Les signaux industriels vont dans la même direction. Structured Outputs pousse les modèles à répondre dans des formats contrôlés. Le Model Spec formalise ce qu’un modèle doit faire ou refuser dans certains cas. La Constitution d’Anthropic encadre le comportement du modèle avec des principes explicites. Ce sont des approches différentes, mais le mouvement est le même : moins d’incantation, plus de spécification.
Et c’est encore plus flagrant quand on passe au développement assisté par IA. Là, la différence entre un prompt vague et une spécification claire ne se voit pas seulement dans la qualité du texte. Elle se voit dans le code, les bugs, les tests, et le temps perdu à corriger derrière.
Comment coder avec une spécification ?
Coder avec une spécification, c’est arrêter de faire du vibe coding au hasard et donner à l’IA un cahier des charges assez clair pour produire, tester et corriger correctement.
Quand vous écrivez Build me a simple expense tracker app, vous laissez trop de trous. Simple pour qui ? Avec quelles règles ? Quelle interface ? Quelle persistance ? L’IA va deviner, et parfois elle devine bien, parfois elle vous sort un truc joli mais inutilisable.
| Prompt vague | Build me a simple expense tracker app. |
| Spécification utile | Créer une application React de suivi de dépenses avec ajout, modification, suppression, filtre par catégorie, total mensuel et sauvegarde dans le local storage. |
Une bonne demande précise aussi le comportement attendu. Les champs sont obligatoires. Le montant doit être positif. La catégorie est requise. Les erreurs doivent être visibles près des champs concernés. Si aucune dépense n’existe, l’application affiche un état vide clair, pas juste une page blanche.
Pour du code, je mets généralement ces éléments dans la spécification :
- Stack technique : React, TypeScript ou JavaScript, CSS simple, local storage.
- Composants attendus : Formulaire de dépense, liste, filtre, résumé mensuel.
- Modèle de données : Id, libellé, montant, catégorie, date.
- Règles de validation : Champs obligatoires, montant supérieur à zéro, catégorie obligatoire.
- Cas limites : Aucune dépense, local storage vide, suppression du dernier élément.
- Tests à prévoir : Ajout valide, erreur sur montant négatif, filtre par catégorie, calcul du total.
- Format de réponse : Fichiers à créer, explication courte, commandes pour lancer le projet.
- Critères d’acceptation : L’app fonctionne sans backend, les données restent après rechargement, les erreurs sont compréhensibles.
Ça peut ressembler à ça dans une demande envoyée à l’IA :
<strong>Objectif</strong>
Créer une application React de suivi de dépenses.
<strong>Fonctionnalités</strong>
<ul>
<li>Ajouter, modifier et supprimer une dépense.</li>
<li>Filtrer les dépenses par catégorie.</li>
<li>Afficher le total des dépenses du mois.</li>
<li>Sauvegarder les données dans le local storage.</li>
</ul>
<strong>Contraintes</strong>
<ul>
<li>Le montant doit être positif.</li>
<li>Le libellé, la catégorie et la date sont obligatoires.</li>
<li>Afficher un message clair si aucune dépense n'existe.</li>
</ul>Ce n’est pas réservé aux développeurs seniors. Même une spécification simple évite déjà beaucoup d’allers-retours, surtout quand on ne veut pas passer son temps à dire “non, pas comme ça”.
Sur des projets d’automatisation ou de data, j’ai souvent vu des équipes perdre du temps parce qu’elles essayaient de corriger la sortie IA au lieu de corriger la spécification de départ. C’est humain, on regarde le résultat, on râle, puis on patch. Mais souvent, le vrai bug était dans la demande.
La specification engineering ne rend pas l’IA parfaite. Elle rend ses erreurs plus visibles, plus testables et plus faciles à corriger. C’est exactement ce qu’on cherche quand on veut l’utiliser sérieusement dans un business.
Et si le vrai levier était de mieux définir le travail ?
Le prompt engineering garde sa place, mais il ne suffit plus dès qu’on attend de l’IA un résultat fiable, testable et réutilisable. La specification engineering ajoute ce qui manque souvent : l’objectif, les contraintes, les formats, les cas limites, les critères de réussite et les vérifications. C’est moins magique, mais beaucoup plus solide. Je le vois surtout dans la data, le code et l’automatisation : une IA mal cadrée produit vite du plausible inutilisable. Une IA bien spécifiée devient un vrai levier opérationnel. Le bénéfice pour vous, c’est simple : moins d’allers-retours, moins d’erreurs cachées, plus de résultats exploitables.
FAQ
- Qu’est-ce que la specification engineering ?
La specification engineering consiste à transformer une demande vague en exigences claires, testables et relisibles. On définit l’objectif, les contraintes, le format de sortie, les critères d’évaluation, les cas limites et les étapes de vérification pour que l’IA sache ce qu’elle doit vraiment produire. - Quelle est la différence avec le prompt engineering ?
Le prompt engineering aide à mieux formuler une demande. La specification engineering va plus loin : elle précise ce que veut dire un résultat correct. Le premier améliore la question, le second cadre l’exécution, la validation et l’intégration du résultat. - Pourquoi les prompts vagues posent problème avec l’IA ?
Un prompt vague peut produire une réponse qui semble bonne mais qui ne respecte pas les contraintes réelles. L’IA peut oublier une métrique importante, supprimer des données à investiguer, ou générer un correctif de code qui passe un test visible mais casse une règle implicite. - Comment écrire une bonne spécification pour une tâche IA ?
Je commence par l’objectif, puis j’ajoute le contexte, les données d’entrée, le format de sortie attendu, les contraintes, les interdictions, les métriques de succès, les cas limites et les contrôles à effectuer. L’idée n’est pas d’écrire long, mais d’écrire vérifiable. - La specification engineering est-elle utile pour le code IA ?
Oui, surtout pour éviter le vibe coding. Au lieu de demander une application vague, on décrit les fonctionnalités, les règles de validation, les composants, les cas limites et les critères d’acceptation. L’IA produit alors un résultat plus facile à tester, corriger et maintenir.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent utiliser l’IA proprement, avec des systèmes fiables, mesurables et connectés au business. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos usages IA, vos automatisations ou vos projets data, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.