Quand utiliser un LLM — et quand s'en passer

« Mettez de l'IA. » L'injonction est partout, et c'est précisément pourquoi la première décision d'architecture n'est pas comment brancher un modèle de langage, mais s'il faut en brancher un.

Un grand modèle de langage (LLM) est une couche d'adaptabilité : il comprend, reformule, classe et synthétise du langage naturel même quand les entrées ne sont pas entièrement prévisibles. C'est une capacité réelle. Mais c'est aussi une capacité probabiliste, coûteuse en calcul et difficile à auditer — l'inverse de ce qu'on attend d'une logique métier. Le savoir-faire d'ingénieur consiste moins à brancher un LLM qu'à délimiter le périmètre où il apporte vraiment quelque chose, et à l'en sortir partout ailleurs.

Déterministe contre probabiliste

Deux mots structurent toute la décision. Un traitement déterministe produit, pour une même entrée, toujours la même sortie : une requête SQL, une machine à états, une fonction pure. On peut le tester, le rejouer, raisonner sur son comportement. Un traitement probabiliste — un appel à un LLM — produit une sortie plausible, pas garantie : la même question peut donner deux réponses différentes, et rien n'assure que la réponse soit exacte.

Ce n'est pas un défaut à corriger, c'est la nature de l'outil. Un LLM échantillonne une réponse dans une distribution ; il n'exécute pas un programme. D'où la règle qui guide tout le reste : on accepte le probabiliste là où la valeur naît de l'interprétation, et on exige le déterministe partout où l'on attend une garantie.

Le critère : l'ambiguïté du langage

Un LLM se justifie quand la valeur d'un traitement réside dans la gestion de l'ambiguïté ou de la variabilité du langage naturel : comprendre une demande formulée librement, résumer des contenus hétérogènes, extraire une intention d'un texte mal structuré, reformuler, cadrer. Là, aucune expression régulière ni aucun parseur ne suffit : il faut « comprendre », et c'est exactement ce que le modèle apporte.

Le critère inverse est tout aussi net. Si la donnée est structurée de bout en bout — sérialisable en JSON ou en table, traitable par des règles explicites — l'introduction d'un LLM n'ajoute que de l'instabilité et un coût d'inférence. Calculer un total, appliquer un barème, synchroniser deux bases, valider un format : ce sont des problèmes d'ingénierie classique, pas des problèmes de langage. Les confier à un modèle, c'est rendre incertain ce qui était sûr.

Le syndrome du marteau d'or

L'erreur la plus fréquente n'est pas de mal utiliser un LLM, c'est de l'utiliser là où il n'avait rien à faire. Une fois qu'on tient un modèle qui « sait tout faire », tout problème ressemble à un clou. On déploie alors un agent probabiliste, coûteux et lent, pour une tâche d'intégration triviale qu'une requête et trois lignes de code auraient réglée — avec, en prime, une fiabilité absolue que l'agent ne donnera jamais.

Le symptôme est reconnaissable : on se met à fiabiliser le modèle (réessais, vérifications, garde-fous, second modèle qui contrôle le premier) pour rattraper une garantie qu'un programme déterministe offrait gratuitement. Quand on en est là, le diagnostic est posé : ce n'était pas un problème pour un LLM.

Quatre options, un seul arbitrage

Avant d'écrire la moindre ligne, l'arbitrage se pose entre quatre formes, de la plus déterministe à la plus souple :

• Service classique (API, batch) — entrées structurées, règles figées, résultat strictement déterministe. La forme par défaut : on ne la quitte que pour une bonne raison.
• Workflow déterministe (orchestrateur de tâches, machine à états) — plusieurs étapes séquencées, des embranchements connus, mais aucune interprétation sémantique requise.
• Appel LLM unitaire — la valeur tient entièrement dans un acte de langage isolé : générer une réponse, extraire des métadonnées d'un texte, catégoriser un message. Pas d'enchaînement d'actions, pas d'état.
• Agent — et seulement alors — quand la résolution exige de l'adaptation en temps réel : enchaîner des actions conditionnées par les retours d'outils, s'ajuster à des situations imprévues, évaluer soi-même si la tâche est finie.

La progression n'est pas neutre : chaque cran vers la droite gagne en souplesse mais perd en latence, en coût et en prévisibilité. On choisit la forme la plus à gauche qui résout le problème, pas la plus impressionnante.

Ce parti pris de sobriété n'a rien d'isolé. Anthropic, dans son retour d'expérience sur les agents, le formule presque à l'identique : chercher la solution la plus simple possible et n'ajouter de la complexité que lorsqu'elle se justifie — quitte à ne pas construire de système agentique du tout. Un agent échange en effet de la latence, du coût et de la prévisibilité contre de la souplesse ; on ne paie ce prix que si la souplesse est la valeur réellement recherchée.

Le test pratique

Pour trancher sans se raconter d'histoires, une question suffit : confierait-on cette tâche à un stagiaire muni d'un manuel ? Si la tâche se décrit par une procédure stable que n'importe qui suivrait à l'identique, elle relève du code — un humain n'y apporterait aucun jugement, un modèle non plus. Si elle demande au contraire de comprendre une demande floue, d'arbitrer un cas non prévu, d'improviser un chemin, alors elle demande un opérateur — humain ou agent.

Un agent est un opérateur métier à qui l'on délègue un mandat, pas une brique d'intégration. C'est la bonne raison de l'employer, et la seule. Reste à savoir, une fois cette décision prise, comment l'insérer dans le système sans lui ouvrir toutes les portes : c'est l'objet de l'article suivant.