Quand utiliser un LLM plutôt qu’un programme classique ?

Un client écrit « je voudrais décaler ma livraison à la semaine prochaine ». Un modèle de langage peut aider à comprendre cette demande. Calculer les dates disponibles et vérifier les règles de livraison relève ensuite du logiciel métier. Pour décider où utiliser un LLM, séparez ce qui demande une interprétation de ce qui peut être exécuté avec des règles explicites.

Un LLM, ou grand modèle de langage, produit du texte à partir d'un contexte : instructions, documents ou conversation. Il peut résumer, reformuler, classer des demandes et proposer des actions. La qualité de cette interprétation dépend de la tâche et doit être évaluée.

Le modèle peut aussi se tromper ou donner des réponses différentes à des demandes proches. Il faut donc déterminer ce que l'application fera d'une erreur, avant de choisir comment l'intégrer.

Commencer par le résultat attendu

Pour la demande de livraison, plusieurs problèmes se succèdent. Le texte du client est libre ; « la semaine prochaine » dépend de la date de référence. Le calendrier des créneaux est structuré. Les règles de changement de livraison peuvent être explicites.

Vous pouvez demander au modèle d'extraire une intention de report et une période souhaitée. Un programme consulte ensuite les créneaux, applique les restrictions et présente les choix au client. La validation finale ne repose pas sur la seule interprétation du message.

Je privilégie ce partage lorsque les règles sont connues : confier au modèle le passage du texte libre à une proposition structurée, puis vérifier cette proposition avant d'agir. Il limite la partie du traitement dont le résultat dépend du modèle.

Le code explicite facilite certaines garanties

Un calcul de total, l'application d'un barème ou la validation d'un format se décrivent généralement avec des règles précises. Du code classique permet de tester directement ces règles et de retrouver comment un résultat a été obtenu.

Un traitement déterministe donne le même résultat pour les mêmes entrées et le même état de référence. Cela ne rend pas tout programme automatiquement correct : il peut contenir un bug, lire une donnée ancienne ou dépendre d'un service indisponible. Mais la logique explicite facilite la vérification de ce qu'il est censé faire.

Un LLM construit une réponse à partir des régularités apprises pendant son entraînement et du contexte fourni. Certains réglages réduisent la variation entre exécutions ; ils ne garantissent pas l'exactitude du résultat. Pour calculer un prix contractuel, il reste préférable de vérifier le calcul avec les règles de tarification.

Le modèle est utile lorsque les entrées se prêtent mal à des règles simples

Des demandes rédigées librement peuvent exprimer la même intention avec des mots très différents. Un modèle peut aider à les classer, à extraire des informations ou à préparer une réponse, là où une liste de mots-clés deviendrait fragile.

Il peut également rapprocher des documents, proposer du code ou préparer un brouillon. La question utile est alors de savoir si ses résultats sont assez bons, et assez faciles à vérifier, pour améliorer le travail demandé.

La présence de texte libre ne suffit toutefois pas à justifier un modèle. Quelques formats connus peuvent être traités par un analyseur simple. Inversement, une tâche sur des données structurées peut demander une interprétation ou une explication. Le choix dépend du travail réel, pas seulement du format d'entrée.

Choisir le niveau d'autonomie nécessaire

Un appel ponctuel et un agent n'impliquent pas la même organisation. Dans un appel ponctuel, le programme sait quand interroger le modèle et quoi faire du résultat. Un agent choisit une partie de ses étapes et de ses outils au cours de la tâche.

Ces organisations se combinent. Un workflow peut inclure un appel à un modèle tout en conservant un enchaînement fixé par le programme. Vous n'avez pas besoin de déléguer le choix de toutes les étapes pour bénéficier de l'interprétation du langage.

Anthropic recommande de commencer par la solution la plus simple et de n'ajouter un fonctionnement agentique que lorsque la tâche le justifie. La souplesse supplémentaire se paie notamment par davantage d'appels et un parcours plus difficile à prévoir.

Comparer les solutions sur des tâches représentatives

Constituez des exemples qui ressemblent aux demandes réelles, y compris les cas ambigus. Comparez le modèle à la solution plus simple que vous pourriez utiliser. Mesurez la réussite, mais aussi les corrections humaines, le délai et le coût complet du traitement.

Si le modèle extrait une mauvaise date, le client peut-il la corriger avant validation ? S'il sélectionne un mauvais compte, l'application peut-elle empêcher l'envoi d'informations à ce compte ? Ces questions déterminent les contrôles nécessaires.

Des vérifications nombreuses ne prouvent pas à elles seules que le modèle est mal choisi. Elles peuvent être justifiées par une tâche difficile. En revanche, si tout ce dispositif reproduit péniblement une règle déjà connue, revenez à un traitement explicite.

L'autonomie d'un agent devient intéressante lorsque le parcours varie réellement et que cette adaptation apporte un bénéfice mesuré. Elle reste à encadrer par des droits et des outils adaptés à la mission, même si le modèle réussit les premiers essais.

Sources

• Anthropic, Building effective agents, décembre 2024.
• B. Subramaniam et M. Fowler, Emerging Patterns in Building GenAI Products, février 2025.