No. 03 · Étude de cas
Praxis
Un outil qui transforme une question business en note d’analyse (un briefing) écrite par des modèles d’IA, dont les sources sont contrôlées par du code et la rédaction relue par un modèle chargé d’y chercher la faille.
En bref
- Ce que ça fait
- À partir d’une question business, il cherche sur le web, vérifie en code que chaque fait a une source acceptable, puis rédige une note d’analyse qui dit elle-même ce qu’elle n’a pas pu sourcer.
- Ce qui est mesuré
- Combien d’exécutions réelles, payées, aboutissent à une note, ce que coûte une note, et combien de notes passent le contrôle des sources.
- Défaut principal
- Aucune note réelle ne passe le contrôle des sources. Ce que j’en ai fait : la note est livrée quand même, avec une section écrite par le code qui liste chaque élément non sourcé ; le défaut est publié, pas caché.
6/13Preuve : praxis/docs/SYSTEM_CARD.md
exécutions réelles arrivées au bout, sur les tentatives
3,29–4,75 $Preuve : praxis/README.md
coût d’une note terminée, de la moins chère à la plus chère
notes terminées signalées comme insuffisamment sourcées
Le problème
En deux phrases, pourquoi ce projet existe.
Une note d’analyse écrite par un modèle d’IA a l’air sourcée même quand elle ne l’est pas. Praxis écrit une note dans un format choisi (note de préparation, mémo, prise de position) et dit au lecteur, dans le texte même, ce qui repose sur une source vérifiable et ce qui n’y repose pas.
Ce que j’ai construit
Les étapes d’une note, de la question au fichier livré, et les deux issues possibles.
Les consignes données aux modèles sont des fichiers .prompt lus par PromptLang. La section des éléments sans source est écrite par le code à partir du rapport du contrôle : aucun modèle ne peut l’adoucir.
Mesures
Ce que donnent les exécutions réelles, payées, et ce qui n’est pas mesuré du tout.
Sur les exécutions réelles, 6/13Preuve : praxis/docs/SYSTEM_CARD.md sont arrivées au bout ; une note terminée a coûté 3,29–4,75 $Preuve : praxis/README.md. Toutes les notes terminées sont signalées comme insuffisamment sourcées : 6/6Preuve : praxis/README.md. Le signal se lève dès qu’un seul élément bloque.
Pas de point de comparaison
Rien dans le dépôt ne compare Praxis à une approche plus simple, un seul appel au modèle ou une rédaction sans recherche. Le seul score publié auparavant notait des notes simulées, écrites à la main pour les tests : il mesurait ces exemples, pas un modèle, et il a été retiré (journal des modifications). La qualité des notes elles-mêmes n’est relue pour aucune question ; seules les sources de première main d’une question ont été relues par un humain (exécutions réelles).
Détail des mesures
Une proportion porte son intervalle de confiance à 95 % (IC) : la plage où se trouve probablement la vraie valeur, large quand l’échantillon est petit.
Exécutions réelles, payées
| Mesure | Valeur | IC 95 % | Lecture |
|---|---|---|---|
| Notes terminées, sur les tentatives | 6/13Preuve : praxis/docs/SYSTEM_CARD.md | 23 % – 71 % | Les autres tentatives ont échoué : contrôle des sources trop strict, texte avant la réponse structurée, délai dépassé, réponse tronquée, section refusée. |
| Notes signalées insuffisamment sourcées | 6/6Preuve : praxis/README.md | Le dépôt ne publie pas d’intervalle pour ce décompte. | Le défaut principal : chaque note terminée est signalée. Le signal se lève dès qu’un seul élément bloque. |
| Coût d’une note terminée | 3,29–4,75 $Preuve : praxis/README.md | L’étendue des exécutions terminées, de la moins chère à la plus chère : pas une estimation. | Coût enregistré avec chaque exécution terminée. |
Ce qui n’a pas marché, et ce que j’ai fait
Trois échecs réels, leur cause quand elle est connue, et ce que chacun a changé.
Déclaré terminé sans une seule note réelle
Toutes les étapes et tous les formats ont été construits et testés sur des exemples écrits à la main avant la première exécution réelle. Les tests ne pouvaient prouver que l’assemblage des étapes, le banc d’essai mesurait ces exemples, et les premières exécutions réelles ont toutes échoué. Ce que j’ai fait : un audit indépendant, puis des corrections sans appel payant (consigne générale à sa place, modèle choisi par étape, lecture tolérante de la réponse structurée, délais par étape, reprise là où l’exécution s’était arrêtée, mesure du coût), puis des exécutions réelles publiées, échecs compris (plan de correction).
Le contrôle strict jetait tout le travail
En mode strict, un seul élément sans source annulait toutes les étapes déjà faites. Aucune trace de ces exécutions n’a été gardée : la cause est lue dans la consigne et le code, pas observée. La consigne de recherche exigeait une date de consultation que le modèle ne peut pas connaître, ce qui ne laissait qu’une réponse conforme : « source manquante ». Praxis date maintenant lui-même ses consultations, ce qui retire la cause probable sans garantir une source à chaque élément, et la note est livrée avec ses manques écrits dedans (ADR 0002).
Une section refusée pour une adresse web dans son texte
Une section de synthèse a été refusée, puis refusée à nouveau à la relance, cette fois pour une adresse www. dans le texte, que les lecteurs de documents transforment en lien. La correction (#44) remplace cette consigne par des renvois numérotés aux sources, vérifiés par le code. Aucune relance payante n’a été faite pour « vérifier » : la correction n’est pas prouvée sur une exécution réelle.
Trois décisions
Trois choix d’architecture, chacun écrit dans une note de décision (ADR) avec ses raisons et ses conséquences : de quoi juger le raisonnement, pas seulement le résultat.
Lire la réponse structurée en code, sans rien réparer
L’interface d’Anthropic refuse les réponses au format imposé quand la recherche web cite ses sources, et refuse de forcer l’appel d’un outil sur les modèles utilisés. Pour les étapes avec recherche, le code garde le texte qui suit le dernier appel d’outil et en extrait la plus grande réponse structurée (un objet JSON) complète et lisible, sans rien réparer ; les étapes sans recherche imposent leur format. Dans tous les cas, le code valide chaque champ.
Livrer en signalant plutôt qu’abandonner
En ligne de commande et dans le banc d’essai, un échec du contrôle des sources est enregistré, l’exécution continue, le rapport est signalé et le code ajoute une section qui liste chaque élément bloquant. La note est complète, mais dit dans son propre texte ce qu’elle n’a pas pu sourcer. Utilisé comme bibliothèque, Praxis abandonne toujours par défaut : changer les erreurs qu’une fonction publique peut lever casserait le code de ceux qui l’appellent.
À quelles sources faire confiance
Le site d’une entreprise est accepté pour les faits de cette entreprise seulement, à condition que la correspondance entre organisations et sites soit explicite, relue et versionnée. Après une relecture humaine, la règle n’accepte plus jamais une source de première main pour la probabilité ou l’impact d’un risque. Le second volet, la presse spécialisée, n’est pas implémenté.
Comment c’est construit
Pour un lecteur technique : la pile, les modèles utilisés et les outils de test.
TypeScript sur Bun. L’interface de programmation (API) Messages d’Anthropic, avec son outil de recherche web : claude-opus-5-5 pour le cadrage, les options et la relecture contradictoire, claude-sonnet-5-5 pour la recherche, les acteurs, les risques et la rédaction. @promptlang/core depuis npm, épinglé par son empreinte ; pdfkit pour le PDF, le fichier Word écrit à la main. Testsbun test, fast-check, Stryker. Architecture : docs/architecture.md.
La suite
Ce qui manque, d’après la feuille de route du projet.
- Une exécution réelle qui aboutit de façon fiable, et mesurée : coût, volume de texte traité, durée, échantillon noté.
- La qualité des notes réelles notée par un modèle juge, validé contre des notes humaines, avec sa marge d’erreur.
- L’ancienneté d’une source mesurée sur la date de la page elle-même.
- Une recherche web qui filtre ses résultats en cours de route, évaluée contre l’outil de base.