Modèle de décision ou IA/LLM : comment choisir

Automatiser une tâche : un LLM ou un modèle de décision plus simple ?

Le dilemme se pose dès la première automatisation. Un grand modèle de langage (LLM) semble tout savoir faire : trier, classer, extraire, rédiger. Un modèle de décision ne fait qu’une chose : renvoyer une valeur choisie dans un cadre fixé à l’avance. La tentation est de tout confier au LLM. Elle coûte cher quand la tâche n’avait pas besoin de texte.

Le tableau ci-dessous donne la grille de lecture. Quatre critères suffisent pour une première orientation. La nature de la tâche, d’abord. La variabilité des entrées, ensuite. Puis la tolérance à l’erreur et le coût acceptable par exécution. Une cinquième ligne, la traçabilité, compte dès qu’une décision doit être expliquée à un client ou à un contrôleur. Gardez cette grille en tête, le reste de l’article la détaille.

Une précision de vocabulaire avant de continuer. « Modèle de décision » désigne ici toute brique qui renvoie une décision typée sans rédiger. Cela recouvre un moteur de règles écrit à la main, un arbre de décision ou un classifieur entraîné sur vos données. Cela recouvre aussi un modèle calibré récent comme Jev. Leur point commun : la sortie est une valeur, jamais une phrase.

Même entrée, deux sorties : du texte ou une valeur typée

Prenez un message reçu par le service client : « Mes paiements échouent depuis trois jours ». Un LLM produit un texte : une réponse rédigée, un résumé, parfois un JSON qu’il a écrit lui-même. Un modèle de décision produit une valeur : urgence 0,95, service « facturation », niveau de frustration « frustré ». Même entrée, deux natures de sortie.

Cette différence commande tout le reste. Un texte doit être lu par une personne, ou reparsé par du code avec un risque sur la forme. Une valeur typée s’insère directement dans un test : au-dessus d’un seuil, on agit ; en dessous, on transmet à un humain. L’exemple du message de paiement vient de la fiche Cloudflare de Jev. Il est détaillé dans notre présentation du modèle de décision Jev.

Le schéma résume ce partage. En haut, l’entrée ; en dessous, deux chemins qui ne se remplacent pas. Le choix ne porte pas sur la « puissance » du modèle, mais sur ce que votre processus doit consommer ensuite. La flèche en pointillés montre le cas fréquent où un modèle de décision contrôle ce qu’un LLM a rédigé. Ce contrôle en série est souvent la meilleure façon de rendre une génération exploitable sans relire chaque texte.

Quatre briques qui renvoient une décision sans rédiger

Avant de comparer avec un LLM, il faut savoir de quoi la famille « modèle de décision » est faite. Quatre briques la composent, du plus simple au plus récent. Elles diffèrent par ce qu’elles demandent pour démarrer : du métier, des données historiques ou des questions bien formulées. Elles partagent la même promesse : une valeur exploitable par du code.

Le moteur de règles

Une liste de conditions écrites par le métier : « si le montant dépasse le plafond, alors validation manuelle ». Le coût de calcul est négligeable et la sortie est déterministe. La décision reste lisible par n’importe qui dans l’équipe. Sa limite : chaque cas doit être prévu. Dès que les entrées sont du texte libre, les règles se multiplient puis se contredisent.

L’arbre de décision et le classifieur

L’arbre de décision enchaîne des tests sur des critères mesurables. On peut le lire de haut en bas et expliquer chaque branche à un collègue. Le classifieur apprend sur vos exemples étiquetés, par exemple des tickets déjà triés, et renvoie une catégorie avec un score. Tous deux exigent des données historiques et un réentraînement quand le métier change.

Le modèle de décision calibré

Une famille récente, dont Jev est le premier représentant public selon son éditeur TypeSafe AI (annonce du 15 septembre 2026). Vous décrivez des questions typées, choix, score ou oui/non, avec leurs critères en langue naturelle. Le modèle renvoie une réponse et une probabilité, sans entraînement préalable. Il ne rédige pas et ne sort pas du cadre déclaré. La mise en œuvre est décrite dans notre guide Jev sur Cloudflare Workers AI.

Et le grand modèle de langage ?

Le LLM reste à part. Sa fonction est de générer du texte, et il peut imiter une sortie typée en écrivant du JSON. Mais cette imitation reste une génération : la forme peut dévier, une valeur peut être inventée. La capture ci-dessous montre à quoi ressemble une sortie typée réelle. Le tableau qui suit compare ensuite les deux approches critère par critère, sans chiffre inventé.

Quand un modèle de décision classique bat un LLM sur le terrain

Sur le terrain, la victoire du modèle de décision tient à quatre propriétés. Le coût de calcul, la prévisibilité de la sortie, l’absence d’hallucination et la traçabilité. Elles comptent surtout quand la tâche se répète des centaines de fois par jour et que personne ne relit chaque résultat. Trois tâches d’entreprise le montrent.

Tri de tickets. Une demande arrive, il faut la router vers le bon service. Un classifieur entraîné sur vos tickets passés, ou une question typée, renvoie le service et l’urgence avec un score. Le LLM peut le faire, mais vous payez une génération de texte pour obtenir un mot. Et ce mot varie avec la consigne.

Extraction de champs. Un numéro de commande, une date, un montant. Si le format est stable, une facture fournisseur récurrente par exemple, une règle ou une expression régulière est imbattable. Si le format varie ou si l’information est noyée dans un texte libre, le LLM devient utile. À une condition : valider chaque champ extrait par une règle avant de l’enregistrer.

Scoring. Donner une note de complétude à un dossier ou une priorité à un lead. La note doit rester comparable d’un dossier à l’autre. Un arbre de décision ou un score calibré le garantit. Un LLM qui « donne une note sur dix » change d’avis selon la formulation de la demande.

La traçabilité pèse aussi sur le plan réglementaire. L’AI Act classe à haut risque des usages comme le tri de CV ou la notation de crédit. Pour ces systèmes, les obligations de journalisation et de surveillance humaine s’appliquent à compter du 2 décembre 2027. La date est celle affichée par la page officielle de la Commission européenne. Une décision typée se journalise ; un texte se relit. Notre guide AI Act pour les entreprises détaille ce calendrier.

Quand utiliser un LLM en entreprise, et le piège dans les deux sens

Un grand modèle de langage s’impose dès que la sortie est destinée à une personne. Réponse client, compte rendu, résumé d’un document, reformulation d’une demande floue : autant de textes qu’aucune règle ne produira correctement. Il est aussi le seul à interpréter une entrée imprévue, comme une référence citée au milieu d’un message. Ces usages justifient son coût et sa relecture.

Le cadrage d’un LLM passe par la consigne. Rôle, matière fournie, format attendu, critère de refus : la méthode est décrite dans notre trame de prompt IA pour l’entreprise. Elle réduit les dérives sans les supprimer. C’est pourquoi une relecture, humaine ou par une règle, reste nécessaire après chaque génération.

Le premier piège : un LLM là où il faut une sortie contrainte

Demander à un LLM une catégorie qu’un modèle de décision aurait renvoyée directement coûte cher à l’usage. Vous ajoutez un prompt à maintenir, une latence, un coût par appel et une sortie à valider. Le symptôme est connu : un parseur JSON qui échoue de temps en temps. Et une équipe qui passe ses semaines à « corriger le prompt » au lieu d’améliorer le processus.

Le piège inverse : des règles pour produire une phrase

Un moteur de règles qui assemble des bouts de texte donne des réponses rigides et difficiles à maintenir. Il est incapable d’interpréter le contexte d’une demande. Quand la tâche exige une phrase adaptée à la situation, le LLM est le bon outil, à condition d’organiser sa relecture.

La combinaison est souvent la bonne réponse. Le modèle de décision trie et route. Le LLM prépare un brouillon. Un second modèle de décision vérifie une règle avant l’envoi. Cette chaîne est celle d’un agent IA en entreprise bien cadré : des décisions typées autour d’une génération contrôlée.

Tester chez soi en une demi-journée

Les tableaux précédents orientent, ils ne tranchent pas à votre place. Deux entreprises qui trient des demandes n’ont ni les mêmes messages, ni la même tolérance à l’erreur. Le seul arbitre fiable est un essai sur vos propres cas, avec une référence écrite avant de lancer les outils.

Le choix ne se fait pas sur une fiche technique, mais sur vos données. Une demi-journée suffit pour une première comparaison honnête, sans développement lourd. L’objectif n’est pas de mesurer une précision absolue. Il est de voir où chaque approche se trompe, et si elle le signale.

Choisissez une tâche étroite : router des demandes entre trois services, ou décider si un avis peut être publié. Rassemblez une trentaine de cas réels, anonymisés, en incluant des cas ambigus. Écrivez la réponse attendue à la main avant de lancer quoi que ce soit. C’est votre référence, et elle vaut plus que n’importe quel score affiché par un outil.

Comparez ensuite trois approches sur les mêmes cas. Des règles simples, écrites en une heure. Un LLM avec une consigne contrainte. Un modèle de décision calibré, si vous disposez d’un compte Cloudflare. La mise en place de Jev sur Workers AI tient dans quelques lignes de configuration. Notez les désaccords avec votre référence, pas seulement le taux de réussite.

Le résultat qui compte : où sont les erreurs, et sont-elles signalées ? Une approche qui se trompe en annonçant une probabilité faible vaut mieux qu’une approche qui se trompe avec assurance. C’est la base d’une automatisation des tâches où la relecture humaine se concentre sur les cas douteux. Les étapes ci-dessous détaillent le déroulé.

La question finale : la sortie est-elle lue par du code ou par une personne ?

Tout l’article tient dans cette question. Si la sortie est consommée par du code, il faut une valeur typée, donc un modèle de décision. Un test, un routage ou un seuil ne savent rien faire d’une phrase. Des règles quand les cas sont connus et peu nombreux. Un classifieur ou un arbre de décision quand vous disposez d’un historique étiqueté. Un modèle calibré quand les entrées sont du texte libre et que vous n’avez ni données ni temps d’entraînement.

Si la sortie est lue par une personne, il faut un texte, donc un LLM. Il est cadré par une consigne et suivi d’une relecture. Et si le processus mêle les deux, découpez-le : chaque étape reçoit sa brique. Le LLM, plus coûteux et plus lent, n’intervient que là où une phrase est réellement utile.

Ce critère évite l’opposition artificielle entre « IA générative » et « alternative aux LLM ». Automatiser une tâche sans intelligence artificielle générative est possible, et souvent préférable, quand la réponse tient dans une liste. Recourir à un LLM est justifié quand il faut écrire. La bonne question n’est pas « quel modèle est le plus fort », mais « qui lit la sortie ». L’arbre ci-dessous et la grille qui suit résument la décision.

Prolonger la réflexion

Le découpage par étape est un travail de métier autant que de technique. Formuler les questions, choisir les seuils, organiser la relecture : ces choix appartiennent à l’équipe qui traite les dossiers. C’est l’un des sujets du parcours IA de La Refonte. Deux jours pour travailler le prompting, les automatisations no-code et les garde-fous à partir de vos cas réels.

Pour comparer les différents modèles d’IA entre eux, notre panorama complet des modèles IA prolonge cette lecture. Il situe les grandes familles de modèles et leurs usages. Une fois la question « qui lit la sortie » tranchée pour votre tâche, ce panorama aide à choisir le modèle lui-même.