Une couche de décision dans vos automatisations

Vos automatisations prennent aujourd'hui deux formes, et aucune des deux ne tient vraiment : des règles fixes qui cassent dès qu'un cas sort du cadre, ou un appel à un grand modèle de langage pour trancher une question simple. Il existe une troisième voie — une couche dédiée à la décision, séparée de celle qui rédige. Voici comment on la câble dans une PME, et ce qu'elle change réellement.

Le problème que tout le monde contourne

Dans une PME industrielle ou de services du Haut-Rhin, le flux est presque toujours le même : un formulaire ou un email arrive, et il faut décider en quelques secondes si c'est une demande de devis, une question technique, une réclamation ou du démarchage — puis évaluer l'urgence et envoyer au bon endroit.

Faute de mieux, deux solutions sont utilisées. La règle fixe d'abord : « si le message contient le mot réclamation, alors… ». Ça tient trois semaines, jusqu'à la première formulation inattendue. Le grand modèle ensuite : on lui demande de classer, il répond — mais chaque tri coûte un appel de génération, prend deux à quatre secondes, et le résultat revient sous forme de texte qu'il faut interpréter, avec le risque qu'il soit formulé autrement que prévu.

Le point commun des deux approches est le même : on demande à un outil inadapté de prendre une décision. L'un est aveugle, l'autre est payé au mot pour répondre « oui ».

Ce qu'est une couche de décision

Le principe tient en une phrase : on envoie l'information à juger — le message, la fiche, le document — accompagnée de questions fermées, et on reçoit une valeur directement exploitable par du code, avec un niveau de confiance. Pas de phrase à interpréter, pas de format à deviner.

Trois formes de questions suffisent à couvrir la quasi-totalité des besoins d'une PME :

• Le choix — une option dans une liste que vous définissez : le pôle concerné, le type de demande, la catégorie de dossier. Une précaution non négociable : prévoyez toujours une option « autre » ou « hors sujet », sinon le système choisira la réponse la moins mauvaise plutôt que d'admettre qu'aucune ne convient.
• La note — une position sur une échelle ordonnée : urgence, niveau d'agacement, maturité du projet, qualité d'une réponse. Tout ce qui est un dégradé se traite ainsi, jamais par un oui/non forcé.
• Le oui/non probabilisé — la probabilité qu'une affirmation soit vraie : « le client demande un remboursement », « ce texte contient un chiffre non vérifié », « cette demande évoque un budget ». La valeur s'utilise directement dans une condition.

Le pattern en trois temps

Ce qui donne sa valeur à cette couche, ce n'est pas l'outil : c'est l'endroit où on le branche dans la chaîne.

• Classer et router à l'entrée. La décision est prise avant que l'information n'entre dans vos outils. Le message est trié, qualifié, orienté vers le bon flux — sans qu'une seule phrase ait été écrite.
• Vérifier à la sortie. Avant qu'une réponse, un devis ou un email ne parte, on contrôle : répond-il à la question posée ? contient-il un engagement de délai intenable ? une donnée confidentielle ? C'est exactement le contrôle que personne ne fait aujourd'hui, parce qu'appeler un grand modèle pour vérifier la réponse d'un grand modèle n'a pas de sens économiquement.
• Laisser la rédaction au modèle payé pour ça. Le modèle de génération n'intervient plus que sur la minorité de cas qui exigent réellement du texte : la réponse client, la synthèse, la proposition commerciale.

« Une automatisation utile n'est pas une automatisation qui décide toujours. C'est une automatisation qui sait quand elle doit se taire. »

Le seuil de confiance, écrit noir sur blanc dans le code

Chaque décision revient avec un indice de confiance, et c'est votre code — pas le modèle — qui décide de ce qu'il en fait. Trois cas, trois comportements :

• Au-dessus du seuil haut (typiquement 85 %) : l'action part automatiquement, personne n'est dérangé.
• Entre les deux seuils : le dossier est préparé, pré-rempli, et présenté pour une validation rapide.
• En dessous du seuil bas (souvent 60 %) : un humain tranche. Toujours.

Sans ce garde-fou, une automatisation finit par prendre des décisions hasardeuses avec assurance — et c'est précisément ce qui fait retirer un agent de production au bout de trois semaines. Un mot sur les seuils, d'ailleurs : ils ne se recopient pas. Ils se règlent sur vos propres données, en regardant les faux positifs et les faux négatifs sur quelques centaines de cas réels. C'est une demi-journée de travail, pas un réglage magique.

Cinq automatisations à câbler, dans cet ordre

• Le tri du formulaire de contact. Demande réelle, démarchage, candidature, question technique ? Et pour quel pôle ? Le dirigeant cesse de lire ce qui ne le concerne pas, et les demandes sérieuses n'attendent plus.
• La vérification avant envoi. Un garde-fou sur les réponses générées : promesse commerciale, engagement de délai, information confidentielle. Le contrôle tourne sur chaque message sortant, ce qui était impensable quand chaque vérification coûtait le prix d'une rédaction.
• La qualification des prospects. Taille de l'entreprise, maturité du projet, douleur exprimée, intention, urgence : cinq signaux séparés que vous pondérez vous-même, plutôt qu'un score unique et opaque que personne ne sait interpréter.
• Le routage du support. Question récurrente (réponse type envoyée immédiatement), cas technique (transmis à la bonne personne, déjà contextualisé), réclamation sensible (traitée en priorité, avec le ton qui convient).
• Le tri de gros volumes. Vos anciens articles, vos avis clients, vos historiques de support ou de devis : des jugements constants appliqués à des milliers de lignes, à un coût qui rend enfin l'exercice possible.

Ce que ça change vraiment pour votre budget

Soyons précis, parce que le sujet prête à l'exagération. Pour une PME, l'économie annuelle sur les tokens est faible : vos volumes sont modestes, et personne ne se ruine à classer trois cents messages par mois.

Le gain réel est ailleurs, et il est plus intéressant : il est dans ce que vous ne faisiez pas du tout. Contrôler chaque réponse avant envoi. Trier chaque demande à l'entrée. Qualifier chaque prospect sur des critères constants. Ces tâches étaient exclues non par manque d'intérêt, mais parce qu'un appel de modèle de génération pour les réaliser, multiplié par le nombre d'événements, devenait absurde.

Quand un jugement coûte une fraction de centime et prend quelques centaines de millisecondes, la question change de nature. On ne se demande plus « est-ce que ça vaut le coup ? », mais « où est-ce que je le branche ? ». C'est cette bascule qui compte, pas la facture.

Ce que ça ne remplace pas

Aucune de ces couches ne rédige : tout ce qui s'écrit — devis, email, synthèse, contenu — reste produit par un modèle de génération, sous votre contrôle. Elle ne connaît pas votre marché : elle ne juge que ce que vous lui donnez, et un contexte pauvre donne un jugement propre sur un mauvais contexte. Les dates et les calculs restent du ressort du code. Enfin, garantir un format n'est pas garantir une décision juste : la mauvaise catégorie choisie dans la bonne liste reste possible — d'où le seuil de confiance et la relecture humaine.

Par où commencer à Mulhouse

La bonne entrée n'est jamais « on va mettre de l'IA partout ». C'est une décision répétée, coûteuse, et qui se prend aujourd'hui soit trop tard, soit à la main. On l'isole, on écrit les critères de chaque réponse possible, on mesure sur vos propres données, puis on règle le seuil. Une fois la première décision fiabilisée, les suivantes coûtent beaucoup moins cher à brancher : seuls les critères changent.

Si vous voulez d'abord la vue d'ensemble — pourquoi séparer celui qui décide de celui qui rédige change l'économie d'un projet, et ce que cette séparation ne remplace pas — nous avons écrit l'analyse côté métier : la couche de décision qui manque à votre IA.

Questions fréquentes