Résultats métier
Sept cas distincts : support sous garantie, planification d’intervention, achat approuvé, résolution d’incident, préférences client, rapprochement de factures et comparaison de prix.
Benchmarks
Évaluer les résultats et les frontières de responsabilité
Une tâche réussie et une autorité respectée répondent à deux questions complémentaires. Nous évaluons séparément les résultats métier, les contrats de gouvernance et leur représentation.
Conditions communes
Mêmes demandes métier, opérations de service et données synthétiques isolées. Les instructions, demandes et données contrôlées sont en anglais. Les opérations autorisées peuvent être réutilisées.
Orchestration multi-agent
Les cas d’incident et de facturation mobilisent chacun trois agents séquentiels, avec responsabilités et périmètres d’opérations correspondants dans chaque système.
17 octobre 2026 · 7 modèles · 7 cas · 5 répétitions
Réussite des cas métier
La campagne réunit 1 225 exécutions. Chaque barre indique le nombre de réussites sur 35 essais : sept cas métier, répétés cinq fois. Les cinq méthodes apparaissent dans le même ordre sur chaque figure.
OpenAI
réussites sur 35GPT-4o miniGPT-4.1 miniGPT-6 AstraAnthropic
réussites sur 35Claude Haiku 5.5Claude Sonnet 5.5Réussites sur 35 observations par modèle et méthode. Même échelle de 0 à 35 pour les trois figures.
Touba natif atteint 35/35 avec six modèles et 30/35 avec GPT-4o mini. Il rejoint le meilleur compte observé pour chacun des sept modèles. Astra, Sonnet et Argon donnent 35/35 aux cinq méthodes.
Sur l’ensemble des cinq méthodes, 1 158 exécutions réussissent et 67 échouent : 31 produisent un résultat métier incorrect ou incomplet, et 36 atteignent la limite de 12 opérations de service avant de terminer la tâche.
Consulter tous les comptes exacts
| Modèle | Touba structuré | Agents SDK | LangChain | LangGraph | Touba natif |
|---|---|---|---|---|---|
| GPT-4o minigpt-4o-mini-2024-07-18 | 21/35 | 21/35 | 25/35 | 30/35 | 30/35 |
| GPT-4.1 minigpt-4.1-mini-2025-04-14 | 34/35 | 35/35 | 35/35 | 31/35 | 35/35 |
| GPT-6 Astragpt-6-astra | 35/35 | 35/35 | 35/35 | 35/35 | 35/35 |
| Claude Haiku 5.5claude-haiku-5-5 | 31/35 | 34/35 | 33/35 | 35/35 | 35/35 |
| Claude Sonnet 5.5claude-sonnet-5-5 | 35/35 | 35/35 | 35/35 | 35/35 | 35/35 |
| Gemini 3.8 Flashgemini-3.8-flash | 35/35 | 33/35 | 30/35 | 35/35 | 35/35 |
| Gemini 4 Argongemini-4-argon | 35/35 | 35/35 | 35/35 | 35/35 | 35/35 |
Écarts appariés entre les deux interfaces Touba
Écart = taux de réussite natif − taux de réussite structuré, en points de pourcentage. Un écart positif favorise le natif ; un écart négatif favorise le structuré ; zéro indique une égalité des taux observés.
Pour estimer la variation liée au choix des cas, l’analyse recalcule l’écart sur 10 000 tirages avec remise parmi les sept cas. Chaque cas tiré conserve ses cinq répétitions. Ces calculs donnent les intervalles descriptifs à 95 % ci-dessous. Ils incluent tous zéro : les données restent compatibles avec un écart nul.
| Modèle | Écart (points) | En faveur de | Intervalle à 95 % |
|---|---|---|---|
| GPT-4o mini | +25,7 | Natif | [0; 57,1] |
| GPT-4.1 mini | +2,9 | Natif | [0; 8,6] |
| GPT-6 Astra | 0 | Égalité | [0; 0] |
| Claude Haiku 5.5 | +11,4 | Natif | [0; 28,6] |
| Claude Sonnet 5.5 | 0 | Égalité | [0; 0] |
| Gemini 3.8 Flash | 0 | Égalité | [0; 0] |
| Gemini 4 Argon | 0 | Égalité | [0; 0] |
Conditions et interprétation
- Organisation des essais
Chaque modèle exécute les sept cas avec chacune des cinq méthodes, à cinq reprises : 7 × 5 × 7 × 5 = 1 225 exécutions. L’ordre des méthodes varie selon le cas et la répétition. Les identifiants API des modèles figurent dans le tableau des résultats.
- Limites par exécution
Chaque exécution dispose de 24 appels au modèle et de 12 opérations de service, partagés entre ses agents. Les lectures comptent aussi parmi ces opérations. Ces compteurs repartent à zéro à chaque nouvel essai. Chaque requête au fournisseur dispose de 120 secondes ; les relances automatiques sont désactivées.
Pour un modèle donné, les réglages restent identiques entre les cinq méthodes. Les deux modèles mini d’OpenAI utilisent une température de 0 et un maximum de 1 000 tokens en sortie. Les autres utilisent un effort de raisonnement bas et un plafond de sortie adapté à chaque modèle.
- Vérification du résultat
Un vérificateur automatique contrôle les données enregistrées, les opérations réalisées et le résultat demandé. Pour la comparaison de prix, il contrôle la réponse finale et le format attendu. L’approbation d’achat est simulée et les préférences client sont stockées dans un service commun aux cinq méthodes. Les mécanismes propres à Touba pour l’approbation et la mémoire font l’objet de tests dédiés.
Exemple observé : quatre articles à 189 € coûtent 756 €. Un agent a utilisé le plafond d’achat de 1 000 € comme montant de commande. L’approbateur simulé a accepté ce montant ; le vérificateur a relevé le montant incorrect. La règle métier à contrôler est ici : montant = quantité × prix unitaire.
- Historique et contexte
Pour chaque invocation d’agent, Touba conserve en mémoire les messages originaux et les informations du fournisseur nécessaires à la suite des échanges. L’historique a une taille limitée et reste propre à cette invocation. Le résumé automatique est désactivé dans cette étude. Les deux modes Touba permettent de terminer par une réponse au format défini par le programme.
Les cinq méthodes contrôlent la taille de l’entrée avant chaque appel au modèle. Le nombre de tokens est majoré de 20 %, puis de 512 tokens, et comparé à un plafond de 100 000 tokens. Le budget financier réserve aussi le coût maximal de la réponse.
- Lecture des résultats
Les cinq répétitions montrent la régularité de chaque méthode sur les sept cas étudiés. Pour comparer les interfaces Touba, l’analyse regroupe les répétitions d’un même cas. La portée de ces résultats est celle des sept cas ; l’étude d’autres familles de tâches permettrait de l’élargir.
Deux façons de communiquer avec le modèle
En mode structuré, le modèle décrit son choix et ses paramètres dans une réponse au format défini par Touba. C’est le mode par défaut. En mode natif, il utilise le format d’appel d’outils du fournisseur, activé dans la configuration du SDK. Touba applique les mêmes autorisations et conserve l’historique des échanges dans les deux modes.
Sur les cas étudiés, le mode natif réussit davantage d’exécutions avec trois modèles. Les quatre autres obtiennent le même nombre de réussites dans les deux modes.
Structuré : par défaut
import { createAiSdkDecisionProvider } from "@touba/sdk";
export const decideAgentCapability =
createAiSdkDecisionProvider({
model,
decisionInterface: "structured",
instructions: "Use observed data and authorized capabilities.",
});
Natif : choix explicite
import { createAiSdkDecisionProvider } from "@touba/sdk";
export const decideAgentCapability =
createAiSdkDecisionProvider({
model,
decisionInterface: "native",
instructions: "Use observed data and authorized capabilities.",
});
Couverture des invariants d’implémentation
Chaque contrôle associe une proposition refusée à un chemin autorisé. La preuve combine le contrat, la décision d’admission et les effets observés : une opération bloquée au bon endroit démontre l’application de la règle.
Audit des tracesRetrouver le dispatch, le refus et la pause humaine à partir des événements.
Identité des triggersAccepter un événement valide et refuser son rejeu ou une source incohérente.
Provenance mémoireConserver les métadonnées sans exposer contenu brut ou secret dans la preuve.
Contamination mémoireGarder le contenu injecté hors des traces publiques lors des lectures et écritures.
BudgetsRefuser les appels ou invocations en excès et le dispatch après timeout.
Intégrité des dépendancesRefuser un lock manquant ou des artefacts handler et manifest modifiés.
Arrêt contrôléAppliquer l’annulation et le kill switch aux frontières de dispatch testées.
Délégation et revueVérifier l’autorité de l’appelant et préserver les continuations pendant les pauses humaines.
Tests du langage et du SDK
Compilation, métadonnées déclarées, types, imports, boucles, sérialisation et finalisation typée sont vérifiés séparément des contrats d’autorisation. La couverture des constructions de V1 est documentée avec le langage et évoluera avec ses versions.
Ce que les preuves formelles établissent
Probabilistic Agentic Programming (PAP) fixe les obligations de responsabilité. Le kernel choisi démontre des propriétés sous ses hypothèses de médiation, de confiance et d’exécution séquentielle. Un théorème distinct relie un fragment Touba défini à son graphe d’exécution. Les tests compilés examinent les correspondances avec l’implémentation.
L’exploration finie couvre 4 608 configurations du kernel : huit choix booléens, un mode humain à deux valeurs et deux limites à trois valeurs, soit 2⁸ × 2 × 3 × 3. Les 203 712 états et 314 904 transitions sont les situations atteignables et leurs changements, comptés par configuration.