Où les grands modèles de langage sont rentables dans l'entreprise

Une entreprise achète des licences d’assistant conversationnel pour chaque salarié. Six mois plus tard, le bilan est mitigé. Certains l’utilisent tous les jours pour leurs e-mails et leurs comptes rendus de réunion. La plupart l’ont essayé quelques fois, puis ont arrêté. Quelqu’un à la finance lui a demandé de rapprocher deux grands livres et a reçu des chiffres sûrs d’eux, bien présentés, et faux. Au moment du renouvellement, personne ne sait dire ce que l’outil a changé, et la décision se prend sur des anecdotes.

Les licences n’étaient pas l’erreur. L’erreur a été de déployer un grand modèle de langage comme un outil généraliste pour tout le monde, au lieu de le placer à des points précis de processus précis, là où ses forces correspondent au travail.

Ces forces sont réelles, et étroites. Un modèle de langage est bon en langage : lire des contenus non structurés, en extraire une structure, rédiger, résumer, classer, et traduire entre la façon dont une personne pose une question et la façon dont un système doit être interrogé. Il est faible en calcul exact, pour restituer des faits qu’on ne lui a pas fournis, pour maintenir un état cohérent tout au long d’un processus long, et pour répondre d’une décision.

Où ils sont rentables

Lire ce qui arrive sans structure. E-mails, factures entrantes, bons de livraison, réclamations, commandes envoyées en pièce jointe. Le modèle les transforme en champs structurés, chacun accompagné du passage dont il est tiré, pour qu’une personne puisse le vérifier en quelques secondes. C’est l’entrée du processus de factures entrantes du module Finance de Hurukan : saisies, imputées, approuvées, exportées.

Rédiger pour qu’une personne envoie. Réponses aux clients, premières versions de devis, synthèses de l’historique d’un dossier avant un appel. La personne corrige et envoie ; le modèle lui épargne la page blanche. Le module Service client est conçu exactement sur cette règle : les agents rédigent, une personne envoie.

Transformer des questions en requêtes. Un responsable demande pourquoi les livraisons vers une région sont en retard. Le modèle en fait une requête sur un modèle métier défini et renvoie la réponse en affichant la requête.

Classer et orienter. Quelle équipe, quelle priorité, quel modèle de réponse. Une tâche étroite, répétitive et facile à vérifier, donc aussi une bonne candidate pour un modèle plus petit.

Expliquer un enregistrement. Pourquoi cette commande est-elle bloquée ? Le modèle lit l’historique de l’enregistrement et écrit trois phrases sur lesquelles une personne peut agir.

Écrire des modifications du système lui-même. Un nouveau champ, une nouvelle règle, un nouveau rapport, rédigés par un agent sous forme de modification soumise à la revue d’une personne. C’est ainsi que Hurukan doit être étendu : décrit, écrit par un agent, approuvé par une personne, enregistré.

Où ils ne le sont pas

Le calcul et les rapprochements. Utilisez du code. Un modèle peut écrire ou appeler le code qui fait l’addition, mais ne doit pas la faire de tête.

Les faits qu’on ne lui a pas fournis. Sans ancrage dans les données de l’entreprise, un modèle produit un texte plausible. Ce sur quoi il s’appuie compte autant que le modèle lui-même, comme le montre rechercher dans l’ontologie, pas dans les documents.

La prévision chiffrée. Les prévisions de demande, de trésorerie et de capacité relèvent des modèles statistiques et d’apprentissage automatique classiques, validés par backtest, comme expliqué dans en prévision, le ML classique bat encore les LLM.

Les décisions finales lourdes de conséquences. Paiements, engagements de prix, clauses contractuelles, tout ce qui touche à l’emploi des personnes. Le modèle prépare ; une personne décide.

Tout ce que vous ne pouvez pas vérifier. Si un résultat ne peut pas être contrôlé à moindre coût, le coût de ses erreurs reste caché jusqu’à ce qu’il soit élevé.

Comment les placer

Pour chaque usage envisagé, posez quatre questions. L’entrée est-elle surtout du texte ? Le résultat peut-il être vérifié rapidement par la personne qui le reçoit ? Une erreur est-elle réversible ? Qui approuve avant que quoi que ce soit ne sorte de l’entreprise ou ne modifie un enregistrement ? Les bons usages ont du texte en entrée, un résultat vite vérifiable et une erreur réversible, avec une approbation partout où cette dernière condition n’est pas remplie.

Confiez ensuite chaque tâche au modèle adapté. La couche Super Intelligence de Hurukan est conçue pour le faire tâche par tâche, entre modèles de pointe et modèles tournant sur le matériel de l’entreprise, selon des règles de qualité, de coût et de destination autorisée des données. Les intégrations avec Microsoft 365 Copilot, Claude et ChatGPT sont prévues, pas encore en service.

Un test à faire dès aujourd’hui

Listez les dix tâches qui prennent le plus de temps chaque semaine dans un service. Pour chacune, cochez trois points :

1. L’entrée est surtout du texte. Oui ou non.
2. Le résultat peut être vérifié en moins d’une minute. Oui ou non.
3. Une erreur peut être annulée. Oui ou non.

Les tâches avec trois oui sont celles où un modèle de langage a le plus de chances d’être rentable. Les tâches avec un non dans la dernière colonne exigent qu’une étape d’approbation soit conçue avant toute autre chose. Les tâches avec un non dans la deuxième colonne ont besoin d’un moyen de vérifier le résultat avant même d’avoir besoin d’un modèle.