Les evals avant les fonctionnalités : la suite de tests avant le prompt
Les evals avant les fonctionnalités, c'est écrire la suite de tests qui définit « fonctionne » avant de construire l'IA qui doit la réussir. C'est le principe qui rend possibles un prix fixe et une garantie post-lancement : sans mesure convenue du « terminé », ni le client ni le constructeur ne peuvent dire si le système a réussi.
Dans le logiciel classique, les tests vérifient que le code fait ce qu'il doit. En IA, l'équivalent — les evals — fait quelque chose de plus fondamental : il définit ce que « doit » signifie pour un système probabiliste. PRIONATION les écrit en premier, avant de choisir le moindre prompt ou modèle.
Ce n'est pas une préférence de processus. C'est le mécanisme qui permet à une mission à périmètre et prix fixes d'être honnête, parce que la définition du succès est convenue et mesurable avant le début du build.
Ce que signifie ce principe
Une eval est un test reproductible qui note la sortie d'un système d'IA selon une norme définie : un ensemble d'entrées représentatives, un comportement attendu et une méthode de notation. Une suite d'evals transforme la question vague « l'IA est-elle assez bonne ? » en un chiffre convenu à l'avance par tous.
Les écrire d'abord inverse l'ordre habituel. Au lieu de construire une fonctionnalité puis de se demander si elle marche, PRIONATION précise ce que « marche » veut dire — le jeu de données de référence, les seuils de réussite, les cas d'échec — et ne construit qu'ensuite le système pour y répondre.
L'anti-modèle
Le mode d'échec courant est le développement piloté par la démo : un prototype impressionne sur quelques entrées triées sur le volet, tout le monde s'enthousiasme, et on déploie. En production, il rencontre des entrées que personne n'a testées, échoue en silence, et le débat devient subjectif — « le modèle se trompe » contre « le prompt est bon » — sans norme commune pour trancher.
Sans evals, il n'y a pas non plus de garantie honnête. Si le « terminé » n'a jamais été défini, impossible de dire si une régression ultérieure est un bug à corriger gratuitement ou un nouveau travail à chiffrer. L'absence d'evals est ce qui rend la plupart des missions d'IA discrètement sans fin.
Comment cela se relie aux trois autres principes
Les evals alimentent la télémétrie : la même logique de notation qui valide le build s'exécute sur le trafic de production, de sorte que la performance en direct est mesurée à la même aune que le build. Elles dépendent de l'infrastructure possédée, car le jeu de données de référence et le harnais d'evals sont des actifs du client livrés avec le code.
Et elles rendent les pods réduits possibles. Une petite équipe peut avancer vite précisément parce que la suite d'evals détecte automatiquement les régressions, supprimant le contrôle qualité manuel qui ralentirait sinon un pod de deux à trois personnes.
Pourquoi c'est le socle structurel de la livraison à prix fixe
Un prix fixe n'est honnête que si le « terminé » est défini avant que le chiffre soit convenu. Les evals sont cette définition. Elles transforment un problème de recherche ouvert en un problème d'ingénierie borné : construire le système qui dépasse le seuil sur la suite convenue.
C'est pourquoi PRIONATION considère la spécification des evals comme le véritable livrable du Diagnostic. Une fois qu'elle existe, le Build est dérisqué des deux côtés — le périmètre ne peut pas s'étendre en silence, et le résultat ne peut pas être contesté.
Là où les équipes se trompent
L'erreur la plus courante est de traiter les evals comme une étape de QA à la fin plutôt que comme la spécification au départ. Écrites en dernier, elles ne font que confirmer ce qui a déjà été construit ; écrites en premier, elles contraignent ce qui sera construit. L'ordre est tout l'enjeu.
La deuxième erreur est de juger au feeling — une poignée d'exemples triés sur le volet qui font bonne figure en démo. Une vraie suite inclut les entrées qui cassent le système : les cas limites, les formulations adverses, les formats que personne n'avait prévus. Ce sont ces cas qui décident si un système survit au contact de la production.
Questions fréquentes
Qu'est-ce qu'une eval en IA ?
Un test reproductible qui note la sortie d'un système d'IA selon une norme définie — un ensemble d'entrées représentatives, un comportement attendu et une méthode de notation. Les evals transforment « l'IA est-elle assez bonne ? » en un chiffre convenu.
Pourquoi écrire les evals avant le prompt ?
Parce que l'eval définit ce que « fonctionne » signifie. L'écrire d'abord rend le succès mesurable et convenu avant le build, ce qui permet un prix fixe et une vraie garantie. Construire d'abord et tester ensuite laisse le « terminé » indéfini.
En quoi cela rend-il un prix fixe possible ?
Un prix fixe n'est honnête que si la ligne d'arrivée est définie à l'avance. La suite d'evals est cette ligne d'arrivée : le Build est chiffré et garanti sur sa réussite, donc le périmètre ne peut pas s'étendre en silence.
Les evals ralentissent-elles le build ?
Elles l'accélèrent. Les contrôles d'evals automatisés en CI détectent les régressions instantanément, supprimant les cycles de QA manuels. C'est ce qui permet à un pod de deux à trois personnes d'avancer vite sans rien casser.
À qui appartient la suite d'evals ?
Au client. Le jeu de données de référence et le harnais d'evals sont livrés avec le code dans le cadre de l'infrastructure possédée, de sorte que la même norme continue de tourner après la fin de la mission.
Que contient réellement une suite d'evals ?
Trois choses : un jeu de données de référence d'entrées représentatives, le comportement attendu ou les critères d'acceptation pour chacune, et une méthode de notation qui transforme les sorties brutes en réussite, échec ou chiffre. Le plus difficile est rarement l'outillage — c'est de s'accorder sur ce qu'est une bonne réponse.
Peut-on écrire des evals quand les besoins sont encore flous ?
Écrire les evals est la façon dont des besoins flous deviennent concrets. Spécifier les entrées, les sorties attendues et les seuils met l'ambiguïté au grand jour tant qu'elle est encore peu coûteuse à lever — bien avant qu'elle ne surgisse comme un incident de production.
Commencez par un Diagnostic
Deux semaines. 5 000 €. Un goulot d'étranglement cartographié et un plan prêt pour la production — sans obligation de poursuivre vers un Build.
Démarrer un Diagnostic →
Comment PRIONATION l'applique
Chaque Build commence par construire un jeu de données de référence à partir d'entrées réelles et représentatives, et par définir la grille de notation de chacune — correspondance exacte lorsque c'est pertinent, notation par modèle lorsque le jugement est nécessaire, avec des seuils explicites. Celles-ci deviennent des contrôles de non-régression automatisés exécutés en CI à chaque changement.
La suite d'evals est spécifiée pendant le Diagnostic de deux semaines, avant que le Build soit chiffré. C'est délibéré : la suite est le contrat. C'est ce sur quoi le prix fixe est calculé et ce sur quoi la garantie post-lancement de quatre semaines est mesurée.