Dans un agent IA, tout ne demande pas de raisonner. Router un ticket, décider si une action exige une validation humaine, classer un incident, choisir un outil parmi cinq : ce sont des choix parmi des options connues à l'avance. Pourtant, ces embranchements sont souvent confiés au même gros modèle de langage que celui qui rédige les réponses.
Le 1er octobre 2026, Cloudflare a publié Clef, une famille de modèles de décision ouverts. L'annonce est l'occasion de poser une question d'architecture utile à toute PME qui construit un agent : faut-il vraiment un modèle génératif à chaque bifurcation ? Cet article résume ce que Cloudflare a annoncé, ce qu'on peut en retenir sans changer de plateforme, et comment tester l'idée sur vos propres cas.
Ce que Cloudflare a annoncé
D'après l'annonce du 1er octobre 2026 :
- deux modèles, Clef et Clef-flash, sont publiés sur Hugging Face sous licence Apache 2.0 et disponibles sur Workers AI ;
- Clef s'appuie sur le modèle Qwen3.8-27B, Clef-flash sur Qwen3.5-9B, auxquels Cloudflare ajoute des composants d'adaptation entraînés pour la décision ;
- Cloudflare les décrit comme des « decision models » : au lieu de générer du texte libre puis de le convertir en sortie structurée, ils évaluent directement des choix valides et renvoient des probabilités dans un schéma défini ;
- Cloudflare lance aussi un service de fine-tuning par apprentissage par renforcement, d'abord opéré avec ses équipes d'ingénieurs, avec l'objectif de proposer ensuite une plateforme en libre-service.
L'annonce ne mentionne ni tarif ni date de disponibilité pour le service de fine-tuning. Elle présente par ailleurs des résultats chiffrés sur un benchmark que Cloudflare a lui-même publié, le Jev Decision Index, où Clef est présenté comme en tête. Ce sont des résultats du fournisseur, pas une évaluation indépendante, et l'annonce montre elle-même des sous-tests où d'autres modèles font mieux. Nous ne reprenons donc aucun classement ici.
L'idée utile : séparer raisonner, décider, exécuter
Indépendamment de Clef, le schéma d'architecture mérite d'être retenu. Dans un agent, on peut distinguer trois types de tâches :
| Type de tâche | Exemple | Ce qu'il faut |
|---|---|---|
| Raisonnement ouvert | Comprendre une demande client ambiguë, rédiger une réponse | Un modèle généraliste |
| Décision bornée | Choisir la file de traitement, juger si une validation humaine s'impose | Une sortie contrainte à une liste d'options |
| Exécution | Créer le ticket, appeler l'API, envoyer l'e-mail | Du code déterministe |
Le guide d'Anthropic Building effective agents rappelle déjà que les systèmes agentiques échangent de la latence et du coût contre de meilleures performances, et qu'il faut les employer là où cet échange se justifie. Les modèles de décision prolongent cette logique : ne pas payer la liberté d'un modèle génératif là où la réponse tient dans une liste fermée.
Pourquoi un gros LLM à chaque décision peut coûter cher
Utiliser un modèle généraliste pour un choix borné pose trois problèmes concrets :
- La latence. Chaque embranchement ajoute un appel. Dans un agent qui en enchaîne plusieurs, les délais s'additionnent.
- Le coût. Chaque appel consomme des tokens, y compris pour une décision qui tient en un mot. Notre article sur le coût par tâche réussie montre comment mesurer ce que coûte réellement un agent, au-delà du prix du token.
- La liberté de sortie. Un modèle génératif peut répondre à côté du format attendu. On y remédie avec des sorties structurées et des validations, ce qui ajoute de la complexité. Un modèle qui ne peut produire que l'une des options valides supprime une partie du problème par construction.
Ces points sont des raisons de tester, pas des gains démontrés. Aucun chiffre de l'annonce ne permet de dire ce que vous gagneriez sur vos données.
Le bénéfice moins évident : des probabilités exploitables
Un modèle de décision qui renvoie une probabilité par option offre un levier que le texte libre donne mal : un seuil de confiance. Vous pouvez décider qu'en dessous d'un certain score, la décision part vers un humain plutôt que d'être appliquée automatiquement.
C'est exactement le type de garde-fou qu'on recommande pour un premier agent, comme détaillé dans cadrer son premier agent IA en entreprise. Une précision toutefois : une probabilité n'est utile que si elle est calibrée, c'est-à-dire si les cas annoncés à 90 % sont réellement justes environ neuf fois sur dix. Cela se vérifie sur vos propres exemples, pas sur ceux d'un benchmark.
Ce que cela ne remplace pas
- Le raisonnement ouvert reste le terrain des modèles généralistes. Un modèle de décision ne rédige pas une réponse nuancée.
- Les règles métier fixes n'ont pas besoin de modèle. Si la décision se calcule avec une condition (montant supérieur à un seuil, pays, type de client), du code ou un workflow suffit et reste plus simple à auditer. C'est le même arbitrage que celui évoqué avec n8n Agents : le déterministe pour ce qui est connu, le modèle pour ce qui ne l'est pas.
- Votre jeu d'essai. Un modèle entraîné pour des décisions génériques peut se comporter très différemment sur le vocabulaire de votre métier. Cloudflare reconnaît lui-même, à propos du fine-tuning, qu'on peut perdre en performance générale en gagnant en précision sur un domaine.
- Vos contraintes de données. Si vous envisagez un hébergement tiers, vérifiez où transitent les données avant d'y envoyer des cas réels. Cloudflare indique ne pas lire, stocker ni entraîner sur les requêtes et réponses, sauf usage de son produit de fine-tuning : à confirmer contractuellement pour vos données.
Tester l'idée sur vos décisions : méthode en cinq étapes
- Recensez les décisions de votre agent. Listez chaque point où l'agent choisit parmi des options fermées : routage, priorité, validation requise, choix d'outil.
- Constituez un jeu d'essai. Rassemblez 50 à 100 cas réels par décision, avec la bonne réponse validée par la personne qui connaît le métier. Anonymisez-les.
- Définissez ce que vous mesurez. Taux d'erreur, délai de réponse, coût par décision et, si le modèle donne des probabilités, qualité de la calibration.
- Comparez à une référence. Le point de départ honnête est votre modèle généraliste actuel avec une sortie structurée. Comparez-y un modèle de décision, sur les mêmes cas.
- Décidez avec un seuil. N'automatisez que les décisions où l'écart est net et où une erreur est peu coûteuse. Gardez un humain dans la boucle pour les autres.
Si le gain ne se voit pas sur vos cas, vous avez évité une complexité inutile. S'il se voit, vous savez où il se situe.
Questions fréquentes
Qu'est-ce qu'un modèle de décision ?
D'après la définition de Cloudflare, c'est un modèle qui évalue directement des choix valides dans un schéma défini et renvoie des probabilités, au lieu de produire du texte libre qu'il faudrait ensuite convertir en sortie structurée.
Clef remplace-t-il un LLM dans un agent IA ?
Non. Il vise les décisions bornées. Le raisonnement ouvert et la rédaction restent du ressort d'un modèle généraliste, et l'exécution se fait en code.
Les résultats publiés par Cloudflare sont-ils fiables ?
Ils sont publiés par le fournisseur, sur un benchmark qu'il a lui-même présenté, et n'ont pas été validés ici de façon indépendante. Ils indiquent une direction, pas ce que vous obtiendrez sur vos données.
Faut-il attendre le service de fine-tuning ?
Pas pour tester l'idée. L'annonce ne précise ni tarif ni calendrier de disponibilité en libre-service. Vous pouvez comparer les modèles ouverts à votre référence actuelle sans fine-tuning.
Sources
- Cloudflare — Introducing Clef: our open-source decision models, and new RL fine-tuning platform (1er octobre 2026)
- Anthropic — Building effective agents
Pour aller plus loin
Vous construisez un agent et vous voulez savoir quelles décisions méritent un modèle, du code ou un humain ? Décrivez-nous votre cas : nous définissons ensemble le jeu d'essai et la mesure avant tout choix technique. Notre approche part toujours d'un processus précis, et nos offres détaillent les formats d'accompagnement.