Brancher Jev sur Cloudflare :
ce qu’une PME prépare avant

Avant de brancher Jev sur Cloudflare, une question précède toutes les autres : quelle décision votre entreprise veut-elle confier au modèle. Un prestataire ou un développeur construit le circuit technique très vite. Ce qu’il ne peut pas deviner à votre place, c’est la décision elle-même.

Écrire le cas d’usage sur une page, avant le premier appel technique, évite le retour en arrière une fois le code commencé. Cette page décrit la décision, les catégories de réponse possibles et la donnée qui alimente le modèle.

Prenons un exemple : trier les demandes reçues par un formulaire. La décision est « quel service doit traiter ce message ». Les catégories possibles sont facturation, technique et commercial. La donnée d’entrée est le texte du message, complété au besoin par le nom du client.

1. Quelle décision répétitive voulez-vous confier au modèle ?
2. Quelles catégories ou options doit couvrir cette décision ?
3. Quelle donnée d’entrée (message, formulaire, document) alimente la décision ?
4. Quel est le coût d’une erreur sur cette décision ?
5. Qui reprend la main quand le cas est ambigu ?

Le compte Cloudflare qui portera le Worker doit être créé avant le premier test. Décidez qui le détient dans votre entreprise : le prestataire pour la durée du projet, ou vous-même avec un accès donné au prestataire.

Le modèle a besoin d’accéder aux données qu’il doit évaluer : messages, dossiers, commandes. Identifiez où elles vivent aujourd’hui et qui en détient l’accès. C’est souvent le point qui retarde un projet, plus que le code.

Si les données évaluées contiennent des informations personnelles (nom, e-mail, contenu d’un message client), le traitement relève du RGPD. Vérifiez avec votre prestataire ce qui transite vers Cloudflare et vers TypeSafe AI, l’éditeur du modèle, et ce qui peut être anonymisé avant l’appel.

Le prestataire ou le développeur construit le Worker, déclare le binding Cloudflare, formule les questions typées et met en place le seuil de confiance. C’est un travail technique, détaillé dans le guide d’implémentation de référence.

L’entreprise fournit le cas d’usage, l’accès aux données et la connaissance du métier : quelles réponses sont correctes, quelles situations restent ambiguës. Sans cette matière, le prestataire cadre à votre place, avec le risque de se tromper.

DodoIA accompagne ce cadrage à La Réunion : cerner la décision, formuler les catégories avec les personnes qui la prennent aujourd’hui, et vérifier que le projet reste proportionné avant de lancer le développement.

Trois postes composent le coût d’usage d’une décision automatisée sur Cloudflare. Le premier est l’appel au modèle lui-même, facturé par la plateforme au volume de tokens traités : il apparaît dans le tableau de bord Cloudflare.

Le deuxième est le développement du Worker, des questions typées et du seuil : un travail ponctuel, dont la durée dépend du nombre de questions et de la complexité du cas d’usage cadré à l’étape précédente.

Le troisième est la maintenance : surveiller le seuil, ajuster les catégories si elles dérivent, tenir le journal des décisions. Aucun chiffre n’est avancé ici tant qu’il n’est pas vérifié pour votre cas : les postes de coût d’un projet d’automatisation sont détaillés sur la page suivante.

Tous les postes de coût d’un projet d’automatisation

Au démarrage, relisez une part large des décisions automatiques, pas seulement celles sous le seuil. C’est la seule façon de savoir si le seuil choisi est le bon, avant de réduire progressivement ce qui est relu.

Une décision part seule quand deux conditions sont réunies : la confiance renvoyée par le modèle dépasse le seuil fixé avec l’équipe, et l’erreur possible reste réparable rapidement si elle survient malgré tout.

Les cas limites, eux, ne se règlent pas par un chiffre. Désignez une personne dans l’équipe qui tranche ces cas et ajuste le seuil si les erreurs se répètent sur un même type de situation.

Techniquement, le Worker appelle le modèle Jev depuis Cloudflare avec l’état à évaluer et les questions typées. La réponse revient sous forme de données, avec une probabilité par question, jamais sous forme de phrase rédigée. Le code applique ensuite le seuil de confiance décidé à l’étape précédente.

Le guide d’implémentation complet de Jev sur Cloudflare Workers AI

Avant de mesurer depuis votre propre Worker, une intégration publique donne un ordre de grandeur réel. La démo askjev.ai (Convex + API TypeSafe, non affiliée à l’éditeur) pose six questions typées à Jev à chaque message et affiche, pour chaque appel, le coût et la latence rapportés par son serveur. Nous avons relevé 172 appels du mur public le 19 septembre 2026 et soumis deux questions.

Latence : 117 ms au minimum, 188 ms en médiane, 395 ms au 95e centile, 622 ms au pire, pour six questions par appel. Coût : 0,8191 $ pour 18 442 messages, soit 0,0000444 $ par appel et environ 1 057 tokens en entrée par message. Ces chiffres sont ceux d’une application tierce en production ; ils ne viennent pas d’un test DodoIA depuis un Worker.

Sur nos deux questions, le comportement est instructif. « Is a parcel ten days late an urgent request » obtient « it depends » à 58 % : formulée sans contexte, la question est réellement ambiguë et le modèle le dit par sa probabilité. « Is a quote request for next month urgent » obtient « it depends » à 85 %, avec un sujet « work » à 98 %. C’est exactement le cas d’usage du seuil : sous 0,85, une personne tranche.

Deux limites de cette observation. Les questions sont celles de la démo, pas votre schéma service / urgence / ton. Et la démo n’accepte que des mots anglais, un filtre de l’application, pas une limite du modèle. Ce relevé date du 19 septembre 2026 : les chiffres d’une application tierce peuvent avoir changé depuis.

Ce que Jev fait et ne fait pas : le pilier

Le cadrage compte plus que l’outil. Une décision bien écrite, avec ses catégories et sa donnée d’entrée, se code aussi bien avec Jev qu’avec un autre modèle si le besoin change demain.

DodoIA vous aide à écrire ce cadrage avant de lancer le développement, en s’appuyant sur votre flux réel plutôt que sur une liste de fonctionnalités.

1. La décision, ses catégories et sa donnée d’entrée : écrites sur une page.
2. Le compte Cloudflare et l’accès aux données : décidés avant le développement.
3. Le seuil et la relecture humaine : fixés avec l’équipe, avant la mise en production.

Faire cadrer votre projet avec dodoIA à La Réunion

Comment fonctionne un modèle de décision, le pilier conceptuel

Automatisation IA entreprise : quelles décisions déléguer

Par quoi commencer pour automatiser une étape de votre activité