Les agents multimodaux perdent jusqu’à 53 % de réussite lors de l’assemblage des modules en système

Un classificateur presque infaillible ne suffit pas encore à rendre un agent fiable. C’est sans doute le principal enseignement pratique d’une récente sélection de travaux sur les modèles multimodaux et les robots. Dans l’une de ces études, un module isolé reconnaissait le type de requête attendu avec une précision de 99,84 %, mais le système assemblé ne respectait intégralement les exigences que dans 47,08 % des scénarios complexes.

Le problème est familier à quiconque a construit un produit à partir de plusieurs composants d’IA. La reconnaissance a fonctionné, la recherche a trouvé le document, le modèle a sélectionné l’outil — et pourtant, l’utilisateur a obtenu un résultat incorrect. L’erreur ne se situe pas nécessairement à l’intérieur d’un module. Elle apparaît aux interfaces : l’agent interprète mal l’intention, appelle un outil inadapté, omet une vérification ou exécute les bonnes étapes dans le mauvais ordre.

La précision des composants ne garantit pas la fiabilité du système

SkinAgent AI en offre un bon exemple. Cet assistant de soins de la peau analyse une photo, précise la demande et sélectionne des produits. Ses auteurs l’ont délibérément limité à des recommandations non médicales : le système ne doit pas établir de diagnostic et doit respecter des règles de sécurité.

Pris séparément, ses composants semblaient convaincants. Le classificateur des requêtes thématiques affichait une précision de 99,84 %. Mais sur un jeu interne de 240 tâches complexes, l’agent identifiait correctement l’intention de l’utilisateur dans 80 % des cas, sélectionnait l’ensemble exact d’outils dans 62,92 % des cas et n’achevait intégralement le scénario sans enfreindre les exigences que dans 47,08 % des cas.

Imaginez un service d’assistance dont l’opérateur identifie presque toujours correctement le sujet de la demande, puis, dans la moitié des cas, ouvre le mauvais formulaire, oublie de vérifier les données ou clôt prématurément le ticket. La grande précision de la première étape est alors peu rassurante.

Pour une équipe produit, la conclusion est simple : il ne suffit pas de mesurer la qualité de la reconnaissance, de la recherche ou de la génération. Il faut une métrique de bout en bout — la proportion de tâches achevées correctement, en toute sécurité et sans étape omise. Les tests doivent en outre inclure des requêtes ambiguës, des défaillances d’outils et des données absentes des démonstrations des développeurs.

Les métriques internes peuvent elles aussi être trompeuses

Une autre étude a testé une idée répandue : si les représentations internes du texte et de l’image sont similaires, cela signifie que le modèle utilise réellement l’image. Les chercheurs ont remplacé l’image par du bruit aléatoire. La qualité des réponses chutait fortement, mais certains indicateurs d’« alignement » continuaient d’afficher une forte similarité.

Autrement dit, l’instrument indiquait une situation normale même après la disparition du signal utile. Pour les développeurs, c’est un avertissement : de beaux graphiques issus des couches cachées ne prouvent pas que le modèle comprend l’image. Ces indicateurs doivent être vérifiés conjointement avec les résultats obtenus sur une tâche réelle. Un test minimal utile consiste à retirer l’image, à la remplacer par du bruit ou à fournir une image contradictoire, puis à vérifier si la réponse évolue comme prévu.

Le simulateur est un terrain d’essai, pas une recette

Dans les travaux de robotique, des agents de programmation écrivaient eux-mêmes des programmes de planification des mouvements et atteignaient, dans plusieurs environnements, entre 56 et 95 % d’exécutions réussies, contre 47 % pour un planificateur classique. C’est un signal important : l’agent peut expérimenter, préciser les règles de l’environnement et transférer le programme obtenu à de nouvelles dispositions d’objets.

Mais les essais se déroulaient principalement en simulation, où l’agent connaissait l’état exact des objets. Une véritable caméra commet des erreurs de profondeur, masque certains objets et modifie l’estimation des coordonnées lorsque l’éclairage change. Il est donc impossible de transposer directement ce résultat à un entrepôt ou à une ligne de production.

La même prudence s’impose pour évaluer la vérification vocale des faits. Un système a atteint une précision de 86,1 %, mais il a été testé sur une parole synthétisée avec une seule voix, sans bruit de fond réel. Pour les podcasts, les interviews et les directs, il s’agit encore d’un prototype, et non d’une garantie de qualité prête à l’emploi.

La conclusion pratique est unique : construisez l’évaluation autour du parcours utilisateur complet. Testez les connexions entre les modules, dégradez volontairement les données d’entrée et identifiez séparément les résultats issus de simulations. C’est précisément dans cet espace, entre une démonstration impressionnante et un produit opérationnel, qu’une grande partie de la fiabilité des systèmes d’IA se perd aujourd’hui.