Clairic : l’IA d’extraction de données de Cloudflare
Découvrez Clairic, le modèle de Cloudflare qui extrait, calcule et estime des données structurées. Usages, limites et critères pour l’intégrer à vos workflows.
Clairic : quand l'IA extrait des données sans rédiger de texte
Une facture arrive sous forme de PDF, une réclamation par e-mail, un reçu en photo. Pour automatiser le traitement, il faut en tirer des champs fiables : montant, date, référence, nature du problème. La méthode la plus courante consiste à demander à un grand modèle de langage de lire le document et de renvoyer du JSON. Ça marche souvent... mais il faut ensuite vérifier le format, les calculs et les valeurs parfois mal recopiées, voire carrément inventées.
Et surtout : chaque appel mobilise un modèle conçu pour raisonner et générer du texte, même quand le besoin est plus simple, au fond - extraire quelques champs.
Avec Clairic, Cloudflare propose une autre approche : un modèle d'extraction qui renvoie des valeurs typées, avec des indicateurs de confiance, en un seul passage. Il peut recopier une information, calculer un montant, estimer une valeur ou produire une prévision. L'intérêt est évident pour les équipes qui traitent de gros volumes de données non structurées. Mais ça ne veut pas dire que les contrôles disparaissent. L'important, c'est de tester ce que Clairic fait bien (et ce qu'il rate) avant de l'intégrer à un processus métier.
Pourquoi créer un modèle d'extraction dédié ?
Un grand modèle de langage sait lire une demande en langage naturel, comprendre le contexte et produire une réponse libre. Cette polyvalence a un coût opérationnel : le résultat peut varier, le format demandé n'est pas toujours respecté, et les données produites doivent souvent être relues ou contrôlées avant d'être utilisées par un logiciel métier.
Pour un chatbot, cette liberté est un vrai avantage. Pour un champ de facture, une date d'échéance ou un numéro de référence, c'est une source de travail en plus : on demande au modèle de « générer » alors que le besoin réel, c'est plutôt de produire une valeur exploitable automatiquement, tout en signalant l'incertitude.
Le point n'est pas de dire que les LLM n'ont pas d'intérêt pour l'extraction. C'est plutôt qu'on ne devrait pas leur demander, systématiquement, de mobiliser des capacités de génération et de raisonnement là où une extraction cadrée suffit.
Une autre famille de modèles « System One »
Cloudflare présente Clairic comme un modèle de type « System One », en référence à la pensée rapide décrite par Daniel Kahneman. L'idée n'est pas de prétendre que le modèle reproduit la psychologie humaine : c'est surtout une manière de distinguer deux modes de traitement. Ici, le modèle répond en un passage, sans dérouler de raisonnement textuel et sans générer une réponse token par token.
Clairic s'inscrit dans une catégorie plus spécifique : les modèles d'extraction. Il complète des modèles de décision déjà associés à cette logique (comme Clef et Jev). En simplifiant :
- Clairic extrait ou prédit des valeurs typées à partir d'un contenu.
- Un modèle de décision choisit parmi des options définies, avec des probabilités associées.
- Un LLM génère du texte quand la demande est ouverte (expliquer, rédiger, reformuler).
Cette distinction aide à concevoir un système plus propre : pas besoin de demander à un modèle génératif de « rédiger » une réponse complète si l'étape attendue consiste juste à lire un numéro de commande. Et, à l'inverse, Clairic n'est pas le bon outil quand il faut répondre librement à une question complexe ou arbitrer une situation avec beaucoup de nuance.
Des sorties cadrées, pas une garantie de vérité
Clairic renvoie une valeur conforme au type demandé - texte, nombre, date, durée, liste, estimation ou prévision - ou null si le champ n'est pas trouvé. Sur certaines extractions textuelles, il peut aussi fournir les positions des caractères dans le document source. Les sorties incluent des signaux comme la confiance (ou la probabilité que la valeur soit absente).
C'est utile en aval : une date peut être contrôlée comme une date, un montant comme un nombre, et une valeur absente n'a pas besoin d'être « remplie » avec une phrase plausible. Mais un format valide ne veut pas dire donnée exacte. Le modèle peut mal lire un chiffre, interpréter une consigne de travers, ou pousser une estimation avec trop d'assurance. Le typage réduit des erreurs de forme ; il ne supprime pas les erreurs de fond.
Comment fonctionne Clairic ?
Une requête associe un contenu à analyser - le « state » - et une liste de champs à renseigner. Pour chaque champ, l'application précise un type et peut ajouter une consigne en langage courant. Le modèle traite ces champs en parallèle.
Selon Cloudflare, il n'y a pas de facturation de jetons de sortie, parce que le modèle ne « rédige » pas une réponse texte comme le ferait un LLM classique.
Le service est proposé en préversion sur Workers AI sous le nom @cf/cloudflare/clairic. Cloudflare indique aussi vouloir publier les poids du modèle plus tard. Comme tout service en préversion, il faut vérifier les conditions d'accès, la disponibilité et les caractéristiques dans la documentation de Workers AI.
Extraction, calcul et listes
Les types disponibles couvrent plusieurs besoins courants :
- Texte : extrait une valeur et peut indiquer son emplacement dans l'entrée.
- Nombre : lit un montant ou effectue un calcul simple, avec un nombre de décimales défini.
- Date, heure et date-heure : normalise les informations temporelles.
- Durée : calcule, par exemple, le nombre de jours entre deux dates.
- Liste : repère plusieurs éléments correspondant à une consigne.
L'exemple de Cloudflare porte sur un e-mail de réclamation. À partir du message, Clairic peut extraire une référence de commande et une date de livraison, additionner le prix et la taxe, calculer le délai écoulé et lister les dommages décrits. Si le numéro de suivi n'apparaît pas, le modèle peut renvoyer null plutôt que de présenter une valeur comme certaine.
Les éléments retrouvés peuvent être reliés à leur source via les positions de caractères. C'est pratique pour montrer une preuve à un opérateur ou pour faciliter une vérification. En revanche, dès qu'un processus implique plusieurs opérations arithmétiques dépendantes, ou un agrégat plus complexe, on gagne souvent à faire calculer le résultat par du code après extraction. Clairic lit et interprète ; le logiciel garde la responsabilité des calculs déterministes quand c'est possible.
Estimation et prévision
Clairic peut aussi proposer une estimation quand la valeur n'est pas écrite telle quelle, mais que le contenu donne assez d'indices. L'application fixe alors des bornes et un pas de calcul. Le résultat peut inclure une médiane et un intervalle à 80 %. Dans l'exemple de Cloudflare, des ventes comparables servent à estimer un prix de logement, avec une fourchette plutôt qu'un chiffre isolé.
Cette présentation est souvent plus exploitable qu'une estimation unique sans indication d'incertitude : une fourchette large peut déclencher une vérification humaine, une fourchette plus serrée peut justifier un traitement automatisé si le risque d'erreur est acceptable. Mais l'intervalle n'est pas une promesse : sa qualité peut se dégrader dès qu'on passe à des données différentes de celles sur lesquelles le modèle a été calibré.
Le type « forecast » vise des prévisions à partir d'une série historique. Cloudflare illustre ça avec le nombre quotidien de voyageurs contrôlés dans des aéroports américains. Sur 21 jours de test, l'entreprise rapporte une erreur moyenne de 3,3 % et 17 valeurs réelles comprises dans l'intervalle annoncé à 80 %. Elle observe aussi des écarts pendant un week-end férié, que l'historique seul n'aurait pas forcément permis d'anticiper. Là encore, ce sont des résultats de test, pas une garantie de performance sur vos données.
Quels usages métier envisager ?
Clairic peut être pertinent si trois conditions sont réunies : les données d'entrée sont désordonnées ou hétérogènes, les champs de sortie sont connus à l'avance, et une erreur peut être détectée ou orientée vers une revue. Les équipes de service client, de finance, d'assurance ou d'exploitation peuvent donc tester des cas où la saisie manuelle devient répétitive.
Exemple : traiter une réclamation client
Un workflow logique pourrait suivre ces étapes :
- Clairic lit le message et extrait la commande, la date, le montant et les dommages indiqués.
- Le système vérifie les champs obligatoires, les formats et les niveaux de confiance.
- Du code applique les règles arithmétiques et les contrôles simples.
- Un modèle de décision compare les faits structurés à la politique de remboursement ou de réparation.
- Un LLM rédige une réponse au client à partir des informations validées et de la décision retenue.
Ce découpage a un intérêt pratique : le modèle de rédaction n'a pas besoin de relire tout le message d'origine ni de refaire les calculs. Il reçoit une synthèse plus compacte, ce qui réduit les risques de divergence sur les chiffres. Ça ne supprime ni les erreurs d'extraction ni les enjeux de sécurité, mais ça rend le tout plus simple à auditer.
Cloudflare compare cette chaîne - Clairic, Clef puis GLM-5.3 - à une chaîne utilisant GLM-5.3 à chaque étape. Dans leur test, la première prend 19,3 secondes contre 61,7 secondes, et le coût estimé par million de réclamations est inférieur de 49 %. Attention : ce sont des chiffres issus d'un benchmark publié par l'éditeur. Ils dépendent des modèles, des tarifs, des prompts et du scénario retenu ; ils ne permettent pas de prédire directement le gain pour une entreprise française.
Où tester en France et en Europe ?
Les premiers pilotes doivent idéalement viser des tâches étroites, mesurables et réversibles : classer des pièces entrantes, repérer des dates dans des documents, rapprocher certains champs ou préparer une fiche de dossier. Une banque, un assureur ou un service public peut y voir un moyen de réduire la ressaisie, mais le niveau de contrôle doit suivre le coût d'une erreur.
Une extraction utilisée pour préremplir un formulaire n'a pas le même risque qu'une décision automatique de remboursement ou d'éligibilité.
Dans un contexte européen, il faut aussi regarder les règles de conservation, les transferts de données, les accès et la base juridique du traitement. Le fait que le modèle renvoie des valeurs typées ne suffit pas à répondre aux exigences du RGPD. Pour des données personnelles ou sensibles, l'hébergement, les contrats et la minimisation des données font partie du design du système - pas une vérification de dernière minute.
Pour un premier pilote, constituez un échantillon représentatif : documents faciles, cas incomplets, et exceptions. Mesurez séparément l'exactitude par champ, la capacité à détecter correctement les absences, les faux positifs, le taux de revue humaine, la latence et le coût complet. Un résultat « moyen » peut masquer un champ critique qui s'avère instable.
Limites, risques et méthode d'évaluation
Clairic est annoncé en préversion, et Cloudflare mentionne plusieurs limites. La lecture peut être rapide, tandis que les calculs en plusieurs étapes et les agrégats de nombreuses lignes peuvent être plus difficiles. Les estimations nécessitent des indices dans les données fournies. Les prévisions restent assez généralistes : elles ne remplacent pas forcément un modèle spécialisé quand une décision dépend d'une prévision très détaillée ou à long terme.
Ne pas confondre confiance et validation
La confiance, p_null et les intervalles sont des signaux utiles pour router des cas, pas des certificats de justesse. Une règle simple consiste à définir des seuils par champ et selon la conséquence : au-dessus d'un seuil validé, la valeur continue le workflow ; en dessous, elle est contrôlée par un humain ou par une source indépendante.
Le seuil doit être déterminé à partir de tests, pas choisi « à l'intuition ».
Il faut aussi surveiller les erreurs silencieuses. Un modèle peut renvoyer un montant correctement formé, tout en associant ce montant à la mauvaise facture. Les décalages de période, les devises, la TVA, les dates ambiguës et les scans de faible qualité sont de bons cas à prioriser dans la batterie de test.
Pour les calculs financiers, les règles de gestion et l'arithmétique doivent être exécutées dans du code déterministe dès que les données nécessaires sont disponibles.
Une grille de décision avant intégration
Avant de remplacer une chaîne existante, répondez à ces questions :
- La sortie est-elle connue à l'avance ? Si vous avez besoin d'une rédaction libre ou d'une analyse ouverte, un modèle d'extraction n'est probablement pas suffisant.
- Une erreur est-elle récupérable ? L'automatisation est plus défendable quand une valeur incorrecte peut être détectée avant de produire une conséquence lourde.
- Le modèle apporte-t-il un gain « complet » ? Comparez les coûts d'inférence, de revue, d'intégration, de surveillance et de traitement des exceptions - pas uniquement le prix d'un appel.
- Les données sont-elles représentatives ? Testez sur vos documents : formats atypiques, cas hors du jeu de démo, et scénarios réels.
- Le fonctionnement reste-t-il explicable ? Gardez ce qui compte : entrée utile, valeurs extraites, preuves disponibles, version du modèle et décisions prises, en respectant vos exigences de sécurité et de confidentialité.
La « bonne » architecture n'est pas forcément un assemblage monolithique avec un seul modèle. Une organisation peut très bien utiliser Clairic pour transformer une entrée en données, du code pour valider et calculer, un modèle de décision pour appliquer une politique, et un LLM uniquement pour rédiger l'explication. Chaque composant fait ce pour quoi il est le plus adapté. En pratique, c'est souvent plus robuste qu'un appel unique auquel on demande de tout faire.
Pour suivre l'annonce et les exemples d'origine, voir l'article de Cloudflare sur Clairic. Comme les capacités évoluent avec les versions, vérifiez les informations actuelles avant d'en faire une dépendance en production.
Conclusion
Clairic propose une idée assez pragmatique : éviter de faire « rédiger » par un LLM ce qui peut être extrait et livré directement en données typées. Sur des tâches répétitives, cette spécialisation peut réduire la latence, les coûts et une partie du travail de validation. Elle ajoute aussi des signaux d'incertitude qui aident à traiter les exceptions.
Mais le point crucial reste le même : un résultat structuré n'est pas automatiquement un résultat juste, et les estimations ou prévisions ne remplacent pas un système spécialisé quand l'enjeu l'exige. Commencez par un flux étroit, mesurez l'exactitude par champ sur vos données et gardez une voie de contrôle humain. C'est, en pratique, la façon la plus fiable de savoir si Clairic améliore réellement votre processus.
Pour aller plus loin, consultez la documentation de Workers AI et testez le modèle sur un pilote avant toute mise en production.