La doctrine déterministe : le modèle propose, le code décide
Posez deux fois la même question à un modèle de langage et vous aurez peut-être deux réponses. C'est un cadeau quand vous voulez des idées, une formulation, un plan. C'est une catastrophe quand vous voulez un verdict : ce test passe-t-il, ce fichier est-il valide, cette commande a-t-elle le droit de tourner. Toute notre pile repose sur une séparation : le modèle propose, le code décide. Tout ce qui n'a qu'une bonne réponse est fait par un programme qui répond pareil à chaque fois.
Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.
Ce que vous y gagnez. De petits modèles locaux qui livrent du vrai travail, parce qu'on ne leur demande jamais ce que le code fait mieux. Des verdicts qu'on peut rejouer, auditer et croire. Et une facture qui baisse, parce qu'un outil déterministe ne coûte aucune réflexion et presque pas de contexte.
1. Deux sortes de questions
| Plusieurs bonnes réponses : un modèle | Une seule bonne réponse : du code |
|---|---|
| découper un projet en stories | ce découpage respecte-t-il le schéma ? |
| écrire la liste des plans d'un film | chaque plan utilise-t-il un cadrage de la liste ? |
| choisir l'outil qui convient à une demande | les arguments de cet appel sont-ils valides ? |
| formuler la réponse à un client | la réponse contient-elle un identifiant secret ? |
| proposer un correctif | les tests passent-ils maintenant ? |
La colonne de gauche est créative : un modèle est le bon outil. Celle de droite est une vérification : un modèle est le mauvais outil, il répondrait « probablement » là où il faut « oui » ou « non ».
2. La doctrine, couche par couche
- Les outils : un outil lit du JSON, écrit du JSON, et son code de sortie porte le sens : 0 succès, 1 un verdict négatif, 2 un refus, 3 et plus une erreur technique, jamais un verdict. Rejoué trois fois, il doit rendre trois fois les mêmes octets (voir fh-tools).
- Les agents : le modèle désigne une fonction dans une table fermée ; le code vérifie les arguments et l'exécute (voir l'assistant de poste).
- Les projets : le modèle propose le découpage, un vérificateur le juge, vous approuvez ; les scénarios tournent comme de simples tests (voir BMAD).
- L'aiguillage : décider quel modèle répond, c'est du code, pas une phrase dans un prompt (voir le juge local).
- L'autorité : le compte qui raisonne ne détient aucun secret ; un démon n'accepte qu'un nom tiré d'une liste fermée (voir agents et autorité).
- La création : le modèle écrit la liste des plans, le code la refuse avant qu'une carte ne s'allume (voir une phrase devient un film).
3. Les chiffres qui nous ont convaincus
- Invité par ses consignes à consulter le juge, un agent l'a fait 0 fois sur 3. Aiguillé par le code : à chaque fois.
- Interrogé sur « pourquoi ça échoue ? », un modèle de 27B a obtenu 2,75/5 en 9 minutes ; muni des faits par un outil, 5/5 en 72 secondes.
- Des listes de plans vérifiées par le code avant le rendu : 4 valides sur 4 du premier coup ; une mauvaise liste découverte après le rendu coûte deux heures.
- Les agents de code livrent des demandes de fusion acceptées avec six outils, 2 182 jetons, là où un catalogue de 58 outils pesait 19 157 jetons à chaque tour.
4. Un bon outil vaut souvent mieux qu'une skill
Une skill apprend une procédure au modèle ; le modèle doit encore la lire, la comprendre et l'appliquer, avec sa variabilité habituelle. Un outil est la procédure : le modèle n'a qu'à l'appeler.
| Skill | Outil | |
|---|---|---|
| coût au repos | sa description | sa description (120 caractères au plus ici) |
| coût à l'usage | toute la procédure, lue dans le contexte | un appel, une réponse JSON |
| résultat | aussi bon que la lecture du modèle | le même à chaque fois, testable de l'extérieur |
| marche avec un petit modèle | parfois | oui : il n'a qu'à choisir et remplir les arguments |
Donc : quand une procédure a un seul bon résultat, écrivez l'outil. Gardez les skills pour ce qui demande du jugement : formulation, conception, découpage, relecture. Plus votre modèle est petit, plus ça compte.
5. Un bug devient du code, jamais une note
Une règle écrite dans un guide le matin a été enfreinte le soir par la personne qui l'avait écrite. Les notes se lisent et s'oublient ; le code s'exécute à chaque fois. Quand quelque chose échoue une fois, le correctif est une vérification, un verrou, un refus, un test, idéalement un test que vous avez vu passer au rouge (voir les tests validés par mutation). Ce qui ne peut pas devenir du code devient une entrée de journal qu'on peut chercher.
Pièges
Un score de confiance mesure à quel point un modèle est sûr de lui, jamais s'il a raison. Deux options à moins de 0,05 l'une de l'autre sont en concurrence : demandez, ne choisissez pas en silence.
Ne pliez pas le contrat par commodité. Un « outil » qui appelle un modèle n'est pas déterministe ; dites-le dans son nom, sinon toutes les autres garanties valent moins.
Utile ? Dites-nous ce qu'il faut mesurer ensuite.