Les agents IA tiennent-ils enfin leurs promesses ? Cas d’usages concrets, performances et limites actuelles.

À l’inverse, les agents IA ne sont pas adaptés aux environnements à forte exigence de fiabilité, notamment dans les contextes industriels critiques. 

La production automatisée, la supervision d’équipements sensibles, la logistique temps réel, ou la maintenance prédictive sont autant de domaines où la tolérance à l’erreur est extrêmement faible. Dans ces cadres, toute décision prise par un système automatisé doit être traçable, reproductible, et validable a priori. Ce sont des conditions que les agents IA actuels, basés sur des modèles probabilistes, peinent à satisfaire. En effet, leur autonomie décisionnelle, si elle est un atout dans les fonctions exploratoires ou les contextes changeants, devient un risque lorsqu’il s’agit de respecter un protocole industriel strict.

Les erreurs de planification, les interprétations approximatives ou les hallucinations textuelles peuvent avoir des conséquences graves, tant en termes de sécurité que de continuité d’activité. Le non-déterminisme des LLM, leur sensibilité au contexte, et leur dépendance aux formulations linguistiques en font des outils trop peu robustes pour des chaînes critiques. Dans ces cas, la solution la plus fiable reste l’usage de pipelines LLM contrôlés. Ces architectures reposent sur des enchaînements de tâches définis à l’avance, dans lesquels les appels aux modèles de langage sont strictement encadrés.

Chaque étape est conçue pour produire un résultat prédictible, traçable, et vérifiable. Cette approche permet de bénéficier de la puissance des LLM pour certaines opérations spécifiques (extraction d’information, reformulation, classification), tout en gardant un contrôle total sur le comportement global du système.

Pipeline LLM vs agents : comment choisir la bonne approche ?

Le choix entre pipeline LLM et agent autonome ne doit donc jamais être dicté par la tendance technologique ou la promesse marketing, mais par une évaluation contextuelle rigoureuse. Trois questions doivent structurer cette réflexion :

• L’environnement est-il stable ou changeant ?
• Les données sont-elles structurées ou non ?
• La tâche tolère-t-elle l’erreur, ou exige-t-elle une exactitude absolue ?

Lorsque les réponses plaident pour le contrôle et la stabilité, le pipeline est clairement la meilleure option.

Dans la pratique, les cas où un agent IA autonome est réellement justifié restent aujourd’hui marginaux. Ce n’est pas une faiblesse, c’est une bonne nouvelle : cela signifie que la majorité des besoins peuvent être adressés par des architectures plus simples, plus économes, et plus faciles à maintenir. Il faut surtout garder à l’esprit que l’intelligence de l’utilisateur de ces solutions et sa valeur ajoutée repose sur sa prise de décision : choisir vous-mêmes de tourner à droite ou à gauche en fonction de la réponse de l’agent.

Retour d’expérience chez Cross Data

Chez Cross Data, l’expérimentation des agents IA ne se limite pas à une analyse théorique ou documentaire. Nous avons initié plusieurs projets internes pour tester de manière concrète leur efficacité, leur robustesse et leur maintenabilité. Deux agents sont actuellement en phase active d’évaluation, chacun avec des objectifs distincts.

Le premier agent est dédié à la veille technique. Son rôle est d’explorer de manière autonome les actualités et publications dans le domaine des modèles de langage, d’en extraire les éléments les plus pertinents, puis de les organiser sous forme de synthèses exploitables. Il ne s’agit pas uniquement de collecter des articles, mais bien de raisonner sur leur contenu, de filtrer les sources pertinentes, de détecter les signaux faibles et de formuler des analyses adaptées au contexte de nos travaux R&D. Cet agent fonctionne selon une logique de boucle : il effectue une recherche, analyse les résultats, produit une synthèse, et adapte sa stratégie de collecte en fonction des lacunes détectées.

Le second agent vise à maintenir à jour un catalogue interne de solutions LLM disponibles sur le marché. Ce catalogue est un outil stratégique pour nos équipes de conseil et de prototypage : il regroupe des informations essentielles sur les modèles (licences, modalités d’hébergement, compatibilité avec notre infrastructure, coûts, disponibilité des API…). Le rôle de l’agent est de détecter les évolutions, d’identifier les nouvelles versions, d’analyser les modifications de licence, et de proposer des mises à jour structurées des fiches outils.

Ces deux agents partagent le même constat : leur grande variabilité de performance. Sur certaines itérations, les résultats sont impressionnants de pertinence, de cohérence et d’autonomie. Mais d’autres exécutions, pourtant lancées dans un contexte similaire, produisent des sorties incomplètes, incohérentes, voire erronées. Cette dispersion rend tout déploiement en production risqué. 

Pour le moment, leur intérêt est indéniable dans une logique exploratoire : ils permettent de gagner du temps dans les phases amont, de stimuler la réflexion, et de générer des contenus préliminaires. Mais ils ne remplissent pas les critères de robustesse exigés pour une livraison industrielle. Le passage à l’échelle impliquerait un effort de fiabilisation important, voire une refonte vers une architecture plus déterministe.

Cas client pour une organisation internationale : un assistant fiable capable de répondre à des requêtes spécifiques

Le client, après formation, pouvait assembler ces blocs selon ses besoins spécifiques, définissant ainsi des assistants personnalisés à ses cas d’usage.

Bien que ce système soit parfois qualifié d’”agent”, notamment dans certains discours non techniques, il reste fondamentalement déterministe. Le chemin d’exécution est prévu à l’avance. Aucune autonomie de planification n’est confiée au LLM. La supervision humaine est présente à chaque étape, ne serait-ce que pour valider le mapping entre la question et la requête SQL, ou pour affiner les filtres sémantiques. Ce projet illustre parfaitement la pertinence des approches hybrides : tirer parti de la puissance d’interprétation des LLM, sans renoncer à la traçabilité et à la sécurité des traitements.

Pour évaluer objectivement les performances de ces systèmes, qu’ils soient agents ou assistants enrichis, nous avons mis en place un cadre d’analyse basé sur plusieurs niveaux d’indicateurs. D’abord, nous définissons des indicateurs métier, propres au contexte d’usage. Dans le cadre de la génération de contenus marketing, par exemple, ces indicateurs peuvent inclure le respect du ton de marque, la conformité à une terminologie spécifique, ou la cohérence avec un positionnement stratégique. Il ne s’agit pas simplement d’évaluer la justesse grammaticale ou syntaxique, mais bien de mesurer l’alignement du contenu généré avec les objectifs de communication du client.

Ensuite, nous utilisons des indicateurs génériques, applicables à tous les projets. Le premier d’entre eux est le taux de réussite : l’agent a-t-il ou non atteint l’objectif assigné ? 

Nous mesurons également la présence ou l’absence d’hallucinations, c’est-à-dire d’informations inventées ou non vérifiables. La pertinence du contexte fourni au modèle, et la capacité du système à respecter les consignes précises, font également partie de notre grille d’évaluation.

Enfin, nous cherchons à quantifier le retour sur investissement, non pas en valeur absolue, mais en pourcentage d’optimisation. Sur des cas concrets comme la génération de code, les gains observés sont réels mais modestes.

Les études internes et les benchmarks que nous avons réalisés convergent vers des gains de productivité compris entre 10 % et 20 %, ce qui reste significatif à l’échelle d’une équipe, mais très en deçà des annonces commerciales qui évoquent parfois des multiplications par cinq ou dix. Il convient par ailleurs de prendre en compte les coûts de relecture et de correction, souvent sous-estimés, ainsi que les frais liés à l’infrastructure (temps machine, consommation de tokens, monitoring des performances).