Conception IA : pourquoi les LLM choisissent mal

Le piège de la formalisation excessive

Prenons un outil de mémoire qui doit signaler des contradictions entre des informations enregistrées. Deux entrées peuvent dire, par exemple, qu'une personne travaille à Paris puis qu'elle travaille à Lyon. Une réponse raisonnable consiste à demander à un modèle de comparer les entrées (une à une ou par lots), puis d'indiquer les cas ambigus.

Un agent peut pourtant partir sur une autre idée : transformer chaque phrase en faits structurés, définir des règles logiques et utiliser un moteur de résolution pour repérer les incompatibilités. Le résultat a l'air rigoureux. Le hic, c'est que le nœud du problème arrive plus tôt : déterminer si deux phrases en langage naturel expriment la même proposition, avec les mêmes conditions et le même contexte. Une représentation symbolique ne « fait » pas cette interprétation toute seule.

Ce n'est pas que les règles soient forcément mauvaises. Elles marchent bien quand les données sont déjà propres, et quand le domaine est bien borné. Mais dès que les formulations varient, que des sous-entendus apparaissent, ou que le contexte fait partie de la vérité, l'approche finit par accumuler des exceptions. On transforme alors une tâche d'interprétation en chantier de formalisation... qui ne couvre pas tout le réel.

Le bon code peut servir une mauvaise idée

Ensuite, l'agent peut livrer un ensemble cohérent : modules propres, tests unitaires, documentation détaillée. Tout ça ne prouve pas que l'architecture est pertinente. Ça prouve surtout que l'agent sait bien travailler à l'intérieur du cadre choisi.

On parle ici d'une erreur de conception, pas forcément d'une erreur d'implémentation. Le code peut respecter sa spécification et, quand même, rater le besoin métier. Pour une équipe, la conséquence est très concrète : au lieu de réduire le risque principal, on consacre du temps à améliorer des règles qui reposent sur un mauvais pari.

Le même phénomène existe dans les systèmes distribués. Un agent peut proposer un mécanisme de consensus très sophistiqué pour éviter des données momentanément obsolètes, alors qu'accepter quelques secondes de décalage serait plus fiable et moins cher. Il peut aussi ajouter des vérifications synchrones dans un traitement pensé autour d'événements, ce qui crée des dépendances et ralentit toute la chaîne.

Le signal à surveiller, ce n'est pas juste un code défectueux : c'est une solution qui empile de la complexité avant d'avoir montré qu'elle était nécessaire.

Les habitudes héritées du code existant

Une piste, ce sont les exemples sur lesquels les modèles ont été entraînés. Une grande partie du code disponible a été écrite avant l'arrivée massive des modèles génératifs dans les applications. Les « recettes classiques » - expressions régulières, règles métier, recherche par mots-clés - sont donc fréquentes dans les données de programmation.

Mais cette explication n'explique pas tout. Les modèles savent aussi recommander des technologies plus récentes plutôt que des bibliothèques anciennes, ce qui suggère qu'ils peuvent mettre à jour leurs choix quand c'est pertinent. Là où ça se complique, c'est quand on conçoit un système où un LLM devient une dépendance : il faut arbitrer entre qualité sémantique, coût, latence, confidentialité et besoin de contrôle. Ce n'est pas seulement « connaître une API » : c'est accepter que le cœur du problème est probabiliste.

Des évaluations qui favorisent le code vérifiable

Autre piste : la façon dont on entraîne et évalue certains systèmes, notamment via du renforcement et des environnements de programmation automatisés. Quand un évaluateur peut exécuter un programme et comparer une sortie attendue, une solution déterministe se mesure facilement. En revanche, évaluer une architecture qui appelle un autre modèle est plus difficile : il faut tenir compte des accès, des coûts, des variations de réponse et de la qualité « au sens » (pas seulement au sens syntaxique).

Dans certains cas, les environnements d'entraînement peuvent donc avantager des solutions directement testables. Ce n'est pas une preuve que les modèles « évitent » les appels à des LLM pour cette raison. C'est une piste plausible, pas un diagnostic certain. Mais ça rappelle un point utile : un système optimisé pour réussir des exercices de code n'a peut-être pas été assez évalué sur la qualité de ses choix d'architecture.

Une faiblesse plus générale de conception logicielle

La lecture la plus utile pour les équipes est aussi la plus simple : les agents font, comme tout le monde, des erreurs ordinaires de conception. Ils peuvent choisir un outil mal adapté, sous-estimer les coûts d'exploitation, ou ajouter de la complexité simplement parce que « ça ressemble à une réponse complète ».

Un agent peut être très bon pour générer des fonctions et médiocre pour décider si cette fonction doit exister. Il peut aussi défendre une approche avec aplomb sans qu'elle ait été validée. Le fait qu'il explique bien son idée n'est pas une preuve que l'architecture est la bonne.

Du coup, la règle pratique est de lire prudemment les recommandations : qu'est-ce que la solution suppose ? Quel risque réduit-elle ? Et quel nouveau risque introduit-elle ? Une architecture n'est pas meilleure parce qu'elle utilise plus de composants, plus de règles ou davantage d'agents. Elle est meilleure si elle répond au besoin avec un niveau de fiabilité, de coût et de maintenance acceptable.

Séparer interprétation et exécution

Commencez par découper le processus. Les tâches de compréhension - résumer une demande, comparer deux formulations, classer un document ambigu - peuvent justifier un appel à un LLM. À l'inverse, une opération exacte - calculer une TVA, vérifier un format, appliquer une règle réglementaire explicitement définie - doit généralement rester déterministe.

Dans beaucoup de cas, une architecture hybride rend le système plus robuste : le modèle interprète l'entrée et produit une proposition structurée ; du code classique valide les champs, applique les règles de sécurité et déclenche l'action. Le modèle apporte la souplesse quand le langage varie. Le code garantit la répétabilité quand une réponse doit être exacte.

Par exemple, pour trier des demandes adressées à un service client : le LLM peut proposer une catégorie et extraire les informations utiles. Ensuite, une règle vérifie que le numéro de dossier respecte le format attendu. Si la catégorie implique une action à fort impact, le système peut demander une validation humaine plutôt que d'exécuter automatiquement.

Comparer les options sur des cas représentatifs

Avant de choisir une architecture, préparez un petit jeu d'exemples qui ressemble vraiment aux cas du terrain : formulations habituelles, exceptions, entrées incomplètes, cas ambigus. Comparez au moins trois options : règles seules, LLM seul, approche hybride.

Évaluez chaque option avec des critères concrets :

• Qualité : proportion de résultats corrects, et coût des erreurs les plus graves ?
• Coût : coût par demande, y compris les reprises et la supervision ?
• Latence : le temps de réponse colle-t-il au processus métier ?
• Confidentialité : les données peuvent-elles être transmises au fournisseur, en tenant compte des engagements de l'entreprise et du RGPD ?
• Maintenance : qui mettra à jour les règles, les exemples et les consignes quand le besoin bougera ?

Une comparaison sérieuse ne s'arrête pas à une démo « qui marche ». Il faut regarder aussi les faux positifs, les cas limites, et ce qui se passe quand le modèle n'est pas sûr. Pour une tâche à faible risque, une réponse imparfaite mais révisable peut suffire. Pour une décision financière, médicale ou liée aux droits d'une personne, il faut un niveau de contrôle bien plus élevé.

Traiter l'incertitude comme une propriété du produit

Les sorties d'un LLM ne sont pas des faits garantis. Le produit doit donc prévoir ce qu'il fait quand le modèle hésite, répond hors format, ou manque d'information. Selon le contexte, la bonne réponse peut être de demander une précision, d'envoyer le dossier à un opérateur, ou simplement de ne rien faire.

Ce mécanisme évite de transformer une incertitude du modèle en incident opérationnel silencieux. Il rend aussi les coûts visibles : un contrôle humain peut ralentir le traitement, mais il coûte souvent moins cher qu'une erreur qu'on ne saura plus corriger. Le bon arbitrage dépend du volume, du niveau de risque, et de la capacité réelle de l'organisation à surveiller le système.

Demander plusieurs options avant le code

Commencez par demander à l'agent de reformuler le problème, puis de proposer plusieurs approches. Pour chaque option, demandez les hypothèses, les avantages, les limites, les dépendances et les risques de maintenance. Et demandez aussi pourquoi une solution plus simple ne suffit pas.

Un format utile tient en quelques lignes :

• problème à résoudre et utilisateurs concernés ;
• approches possibles, dont une option sans LLM ;
• hypothèses de volume, de latence et de qualité ;
• risques principaux et stratégie de repli ;
• test minimal pour comparer les options.

Cette étape ne garantit pas une bonne réponse. Mais elle rend les choix visibles avant que l'agent ne consacre du temps à tout implémenter. Elle permet aussi à quelqu'un qui connaît le produit de corriger une hypothèse fausse - par exemple un besoin de réponse immédiate qui ne correspond pas à la réalité.

Construire une preuve limitée, pas un système complet

Une fois l'option retenue, demandez un prototype sur un échantillon de données représentatif. Mesurez ses résultats et comparez-les à une référence simple. Si une approche basée sur des mots-clés suffit pour 95 % des cas et que le reste est traité manuellement, un modèle plus coûteux n'est peut-être pas justifié. À l'inverse, si les formulations varient énormément, les règles peuvent devenir plus difficiles à maintenir qu'un appel à un modèle.

Le prototype doit aussi inclure les conditions d'échec : sortie invalide, absence de réponse, délai dépassé, décision incertaine. En production, ce ne sont pas des détails. Ce sont ces cas qui déterminent si le service continue, se dégrade proprement, ou bloque un processus métier.

Évaluer le coût total et garder une porte de sortie

Le coût d'un système IA ne se résume pas au prix des requêtes. Il inclut l'évaluation, la supervision, les reprises, le suivi des changements de modèles et le traitement des erreurs. Pour une entreprise française, il faut aussi vérifier les flux de données, les contrats du fournisseur, les durées de conservation et les obligations liées au RGPD.

Prévoyez enfin un plan de repli : règles déterministes, traitement manuel, ancien parcours ou mise en attente. Un agent ne doit pas être autorisé à élargir tout seul le périmètre d'une automatisation qui touche des utilisateurs ou des données sensibles. La conception, c'est aussi définir les limites opérationnelles, pas seulement dérouler le chemin nominal.