Si vous avez déjà travaillé sur un projet informatique, vous avez sans doute déjà rencontré cette situation: une implémentation qui avance relativement vite, et pour laquelle on arrive à environ 80% de réalisation en un temps raisonnable, en général 20% du temps. C’est toujours quelque chose de satisfaisant de voir avancer son projet à vitesse grand V et de se dire que l’on prend de l’avance. Puis viennent les 20% restants, les 20% décisifs qui font que le projet sera qualifié de terminé, et sera prêt à être déployé. Ces 20 derniers pourcents, c’est en général ce qui prend environ 80% du temps du projet, car tous les détails sont à caler, toutes les spécificités sont à prendre en compte. On avance beaucoup moins vite, on veut être sûr de ne rien oublier.

Ces 20% restants, c’est ce que l’on appelle le dernier kilomètre. Si je me permets d’utiliser cette image, c’est parce qu’elle s’applique complètement à la réalisation d’un projet IA agentique. Dans un projet agentique, l’effort est très souvent mis sur les points suivants:

• le choix des modèles

• le choix des frameworks de développement

• la mise en place des garde-fous (appelés aussi guardrails)

• la sécurisation des accès

• la construction d’une interface permettant aux utilisateurs d’interagir avec les agents qui seront déployés

Il faut comprendre que ces briques qui composent un système agentique sont en réalité relativement faciles à mettre en place. Quoi que puissent en penser les intégrateurs, avec des outils comme Claude Code, il est possible de mettre en place un workflow agentique en quelques heures, voire quelques jours, avec une solution complètement fonctionnelle et qui répond au besoin. Ces technologies permettent de réduire considérablement le temps production.

bien que cette implémentation réponde au besoin dans les grandes lignes, si l’on regarde dans le détail, inévitablement on se rend compte qu’elle n’est jamais compatible avec les pré-requis et le fonctionnement d’une entreprise. La solution telle que proposée représente 80% de la tâche, achevée fièrement en 20% du temps. Toutefois, il reste maintenant les 20% restants, et ils prendront bien plus que quelques heures et un Claude Code pour être réalisés. J’ai vu des projets déployés à 80%, et qui ont été décommissioné rapidement après leur mise en production. On retrouve en général toujours les mêmes facteurs:

• personne n’utilise la solution

• la solution ne répond pas aux critères de sécurité

• le coût d’exploitation (et en particulier la consommation en tokens) explose

• la latence explose, la solution ne tient pas la charge

• le ROI n’est pas au rendez-vous

Ce qui s’est passé c’est que dans l’empressement, ce qui n’était alors qu’un POC a été passé en production, et même s’il a été réalisé en un temps record, il ne représente que 80% du travail.

Que manquait-il alors que contiennent ces 20% restants, que l’on peut aussi comparer au dernier kilomètre ?

• les règles qui n’ont jamais été documentées mais que tout le monde utilise

• la connaissance des process, détenue par une quantité en général assez restreinte de salariés, acquise au fil des années

• les données éparpillées dans différents endroits de stockage, détenues par différents services

• les usages qui sont propres à chaque utilisateur, qui répondent en réalité à des besoins propres à chaque service, et qui ici aussi ne sont documentés nul part

Ce dernier kilomètre, c’est en réalité le travail pour lequel ne peuvent aider ni un LLM, ni un Claude Code, car ce sont des tâches qui ne s’automatisent pas. Ce dernier kilomètre, c’est le câblage de ces pratiques, de ces connaissances, et de ces contraintes. La raison pour laquelle ce dernier kilomètre est si difficile, c’est parce que chaque fil doit être cablé un par un dans le système, et c’est cela qui permet de garantir que le projet déployé sera intégré à l’entreprise, et utilisé par les collaborateurs.

Ce dernier kilomètre porte également une notion très pragmatique: la réalisation d’un projet commence par l’identification du besoin et des contraintes, pas par la recherche des solutions potentielles.

Quand je regarde le déroulement d’un projet IA, j’entends toujours des positions du style “il faut utiliser langgraph”, “le dernier modèle de Anthropic est meilleur”, “quelle solution de guardrails va-t-on utiliser”, “facile, on va tout faire avec Claude Code”. Ces sujets sont évidemment importants, mais ils orientent le projet vers une vision tournée vers la solution, pas le besoin. Ces solutions sont nécessaires au succès du projet, mais ne seront pas suffisantes. Le maillon manquant qui permet d’accrocher le wagon (si vous me permettez l’expression), c’est le dernier.

Ne sous-estimez donc pas ce dernier kilomètre, c’est en réalité lui qui va assurer la réussite de votre projet. Vous pouvez choisir le mauvais model, vous pouvez aussi prendre le mauvais framework. Vous pourrez toujours le changer à postériori, et rien ne sera plus facile avec l’IA générative. Par contre, l’intégration des mauvaises règles, ou leur oubli façonneront un système qui ne donnera pas satisfaction bien qu’il soit entièrement fonctionnel.

En 2026, l’important ce n’est donc pas le choix du framework ou du LLM, c’est le dernier kilomètre.

La scène se reproduit entre toutes les deux semaines, et tous les mois, et le scénario est toujours le même. L’annonce impromptue de la sortie du dernier modèle frontière, par Anthropic, OpenAI, Google, ou Meta (au choix). S’ensuit alors la même réaction en cascade. C’est l’affolement général sur la toile. Déjà LinkedIn grouille de posts partageant fièrement “je fais partie des rares privilégiés qui a pu le tester, et je vous le dis, c’est ce modèle le meilleur”. Youtube n’est pas en reste, et rapidement des centaines de vidéos sont postées, chacune portant haut un titre toujours plus putaclic, tel que “Cette IA va nous détruire”, “C’est la fin”, “La course aux LLMs est terminée”.

Voilà de quoi nous faire réfléchir, voire même nous effrayer. Et surtout, comment passer à côté d’une telle avancée technologique ? C’est la réaction naturelle, ce que l’on appelle le FOMO, et de mon humble avis, c’est véritablement ça le piège dans lequel il est dangereux de tomber aujourd’hui.

Il n’est pas évident de savoir quelles métriques utiliser aujourd’hui pour comparer des IA. A la question “qui est le plus fort ? Anthropic ou OpenAI ?”, nous sommes bien démunis. Alors on compare le nombre de paramètres, on fait passer les LLMs sur des bench toujours plus pointus, pour savoir lequel des modèles passera devant l’autre.

Mais tout ceci a-t-il un sens ?

Si l’on fait une comparaison avec le monde de l’automobile, on comprend aisément que la formule 1 qui gagne un grand prix n’est pas celle qui a le moteur le plus puissant. Le moteur a son importance, certes, mais c’est aussi l’aérodynamisme de la voiture, les pneus, la course de l’embrayage, et (accessoirement) la sagacité du pilote.

Ce qui fait la performance d’une F1, c’est donc la qualité et l’assemblage de tous ses composants, plus que uniquement son moteur.

Il en est exactement de même avec un système agentique. Un système IA, c’est évidemment un (ou plusieurs) LLMs, mais la performance d’un système IA, c’est aussi (et surtout) la gestion du contexte, de la mémoire, les outils, l’orchestration, l’expérience produit, les garde-fous, la sécurité, etc. Ainsi, donner tout le crédit au LLM se révèle bien injuste. Ce qui confère à un système agentique sa performance, c’est tout ce qu’il y a autour. Cette nébuleuse de technologies qui entoure les agents, c’est ce que l’on appelle le harnais.

Une fois que le harnais a été mis en place, l’enjeu pour les équipes pour construire le meilleur produit, ce n’est pas de choisir le modèle le plus puissant (ce serait trop simple), mais plus précisément de trouver le modèle qui offrira le meilleur compromis entre la performance, le coût, la latence. Voilà qui revient en réalité à trouver le modèle qui répond le mieux à une tâche précise.

Ainsi, l’enjeu pour les équipes de développement, c’est de mettre en place un système qui exploite au mieux les performances des LLMs, en passant de l’un à l’autre pour chaque tâche donnée. Comme pour une formule 1, la performance de la machine ne se trouve pas dans son moteur, mais dans le système qui exploite ses capacités avec le meilleur rendement.

Prenons un autre exemple un peu caricatural. Considérons un agent dont le rôle est de router une demande vers 3 autres agents au choix. Quelle sera la meilleure stratégie ? Utiliser un modèle généraliste haut de gamme qui va coûter 10$/MTokens, qui est capable de tout faire mais qui ne sera sollicité que pour faire du routage de demande ? Face à une demande aussi simple, il serait sans doute plus judicieux de confier la tâche à un modèle plus petit, qui va coûter 0.01$/MToken, qui certes ne sera pas capable de réciter du Shakespeare, mais dont les capacités seront déjà bien suffisantes pour orienter une demande entre 2 agents.

Faire passer les modèles au second rang dans un système agentique, et se permettre de switcher d’un modèle à un autre de façon purement arbitraire, c’est ce que l’on appelle la commoditisation des modèles. La commoditisation des LLMs, cela revient à placer les LLMs au second rang, à leur enlever ce sacré qui fait que l’on les place en général au coeur des systèmes, et à les considérer comme des outils interchangeables, en concédant que le LLM n’est pas LA performance, mais qu’il y contribue.

Ceci pose donc la question de savoir quel outil va se placer au centre de l’échiquier. C’est précisément la “réponse” qu’apporte la notion de harnais. En parlant de harnais, on met en avant non pas un outil (ce serait ici aussi trop simple), mais la composition des outils qui tous indépendamment occupent un rôle précis, mais qui assemblés créent le produit et apportent de la valeur. Et c’est véritablement sur ce point que doivent aussi se concentrer les entreprises aujourd’hui.

Comment le système est sécurisé, comment les utilisateurs sont authentifiés, comment le workflow est monitoré, comment le budget est suivi, comment les décisions sont-elles prises ? La réponse à ces questions, ce sont tous les outils et les méthodes qui ensemble forment le harnais, et qui permettent de proposer un produit qui est compatible avec le SI de l’entreprise, aligné avec la stratégie des dirigeants, et qui répond aux besoins des utilisateurs.

J’aurai évidemment l’occasion de revenir sur cette question de harnais, mais pour l’heure, si vous ne deviez retenir qu’un message de mon article, c’est celui-ci:

L’important, ce n’est pas le modèle. Celui-ci est en train de se commoditiser. L’important, c’est la harnais. C’est à cet endroit que se trouve la vraie valeur d’un système agentique, et c’est ici que doivent se concentrer les entreprises pour créer les meilleurs produits augmentés avec l’IA.

En 2000, le psychologue Barry Schwartz a écrit un livre intitulé “The paradox of Choice”, livre dans lequel il explique que contre intuitivement, plus de choix ne mène pas à la liberté, mais au contraire à l’aliénation.

Son ouvrage est en lien avec une expérience sociale assez connue. Dans un supermarché, des chercheurs installent un stand de pots de confiture. Un jour, le stand propose 24 parfums. Un autre jour, il n’en propose que 6. Les résultats ont conclu que c’est le jour où il y avait moins de parfums disponibles que les ventes ont été les plus élevées (significativement).

Ce que ces études montrent, c’est que face à un trop grand choix, le cerveau se bloque et se retrouve incapable de choisir. Peur de se tromper, envie d’un choix encore meilleur (puisqu’il y a 24 parfums disponibles, peut-être que c’est le 25e qui sera le meilleur). Au final, soit aucun choix n’est fait, soit il est regretté immédiatement, et ces situations sont vécues comme très stressantes par le cerveau, pouvant même conduire à des crises d’angoisse.

Le paradoxe du choix appliqué à l’IA

25 ans plus tard, nous utilisons l’IA avec des modèles LLM de plus en plus puissants, des capacités de plus en plus grandes, et des cas d’usage toujours plus exigeants. On voudrait que nos agents puissent tout faire, et en même temps, on a à notre disposition pléthore de Tools et d’API. Comme si ce n’était pas suffisant, on a désormais le fameux protocole MCP qui rend la connexion entre un agent et un Tool encore plus facile.

Il est donc normal et tentant de se dire que puisqu’un agent est capable de tout faire, alors autant lui donner toutes les capacités possibles. Pourquoi ne pas lui brancher 100 Tools, ou même mieux 1000 Tools ? C’est évidemment ce qui a été fait, et les résultats sont... intéressants.

Avec une quantité importante de Tools (plus de 10) branchés sur un agent, au niveau macroscopique, ce qui est observé, c’est une dégradation de la précision de l’agent, des contraintes à gérer sur l’utilisation de certains LLM, et surtout une explosion des coûts d’infrastructure.

Au niveau microscopique, l’agent a à sa disposition 10 Tools. Chaque Tool a sa description et son scope fonctionnel. L’orchestrateur présente donc au LLM les 10 Tools en utilisant le contexte. Le LLM est bien “embêté”, ne sachant lequel choisir. Il va donc utiliser celui qui a priori répond le mieux au besoin. Le Tool est appelé, et la réponse est renvoyée avec toute le contexte. Cette dernière n’étant pas satisfaisante, un autre Tool va être utilisé, et ainsi de suite jusqu’à affiner la réponse qui permettra à l’agent d’accomplir sa mission (et au fur et à mesure, augmenter le contexte avec tous les échanges des précédents tours de LLM).

Le résultat obtenu est le suivant :

• un workflow de l’agent qui devient très compliqué (trop compliqué) ;

• une dégradation significative de la précision des actions qui sont prises et des réponses qui sont renvoyées ;

• une latence accrue, avec des temps de traitement de la demande qui empêchent un passage à l’échelle ;

• un contexte de plus en plus gros, qui contraint à utiliser d’autres modèles, plus récents, plus gros et accessoirement plus chers ;

• un coût d’utilisation qui explose car un grand contexte revient à avoir beaucoup de tokens consommés en input du LLM. Comme les tarifications des LLM (en SaaS du moins) sont exprimées en dollars par million de tokens, plus on sollicite un LLM, plus la facture sera élevée. De plus, on se trouve contraint d’utiliser des modèles permettant de prendre en entrée de gros contextes, et souvent ils sont plus chers. Ne sous-estimez pas la facilité avec laquelle on peut remplir un contexte avec 1M tokens.

Combien de Tools par agent IA ? Les règles à appliquer

Ce qu’on constate au niveau de l’agent, c’est qu’il est victime de ce que l’on appelle le paradoxe du choix. Si ses capacités sont trop élevées, comme un humain, il se trouve paralysé et ne “sait” plus quelle option choisir. Un humain va hésiter, et sans doute ne rien choisir de peur de se tromper, alors que le LLM va se résoudre à demander à l’orchestrateur de tester les Tools (car quel que soit le scénario, un LLM doit toujours répondre...).

Le paradoxe du choix est un problème réel et difficile à éviter car contre-intuitif. Voyant que les LLM peuvent faire toujours plus, beaucoup y voient à tort une opportunité de se simplifier la vie en jetant tous leurs œufs dans le même panier, pensant (aussi à tort) que le LLM saura démêler le vrai du faux.

Pour rester concis, voici les règles que je m’applique lorsque je mets en place un agent :

• Entre 1 et 3 Tools : c’est OK ;

• Entre 4 et 6 Tools : ça se tend, et il faut s’attendre à une baisse de la précision de l’agent. Il est donc important de monitorer le workflow des agents qui tournent avec des outils comme LangFuse pour mesurer l’impact sur la performance ;

• Au delà de 6 Tools : red flag, c’est la conception même du système agentique qu’il faut revoir.

Un changement de paradigme : des agents aux systèmes multi-agents

Dire qu’il ne faut pas utiliser plus de 3 Tools en même temps, c’est bien, mais il existe tout de même des cas d’usage exigeant de plus grandes capacités. C’est ici qu’il faut changer de paradigme.

Plutôt que de considérer un agent qui peut tout faire, pourquoi ne pas considérer une équipe d’agents, chacun ayant sa spécialité. C’est bien comme cela que nous nous organisons au quotidien, non ? Dans un projet IA on a un ingénieur, un PO, un scrum master, un data scientist, un devops, etc. Chaque membre de l’équipe joue un rôle et a une spécialité. Pourquoi n’en serait-il pas de même pour les agents ?

Une façon intuitive de gérer le paradoxe du choix est de considérer un système multi-agents, et donner à chacun d’entre eux un rôle précis, avec des capacités qui le représentent.

Par exemple, on peut imaginer un agent “knowledge”, qui sera capable de récupérer de l’information dans JIRA et dans Confluence. Un autre agent “developer” quant à lui pourra générer du code, se connecter à Git. Enfin, un troisième agent “devops” aura accès à Git et à l’infrastructure Cloud. En utilisant ces 3 agents ensemble, on a alors un système multi-agent qui sait gérer de bout en bout (ou presque) la chaîne de production d’un programme : assistant de code, écriture des tests, rédaction de la documentation, revue de code, CICD, déploiement, mise à jour des tickets. C’est évidemment plus complexe que ça, mais vous voyez l’idée.

Les systèmes multi-agents permettent de s’affranchir de cette barrière que représente le paradoxe du choix. Evidemment, les systèmes multi-agents sont plus complexes à mettre en place qu’un agent seul sur lequel on aurait branché plein de Tools. Des frameworks comme CrewAI, Google ADK permettent néanmoins de construire relativement simplement et rapidement des architectures multi-agents.

Les LLM, un peu trop à l’image de l’Homme ?

Il reste tout de même fascinant de constater autant de similarités entre le fonctionnement d’un LLM et celui d’un cerveau humain (toutes proportions gardées). Comprenez bien que le paradoxe du choix n’a pas été encodé dans le LLM, c’est un effet qui a émergé de l’utilisation de ce dernier avec des Tools. Je ne vois pas non plus de relation de cause à effet avec l’entraînement du modèle, ni même les données qui ont servi à son entrainement.

Le paradoxe du choix serait alors un phénomène émergent de la construction d’un LLM, avec les mêmes effets que ceux observés sur un cerveau humain. En outre, les LLM sont construits sur des architectures de réseaux de neurones, et la notion même de “réseau de neurones” a été inspirée aux scientifiques par le fonctionnement du cerveau humain.

Il se dit que l’Homme aurait créé la machine à son image. Du coup, peut-on imaginer que le paradoxe du choix soit un signe que la réalité est en train de rattraper la fiction ?