La retrieval est la nouvelle intelligence.

La personne la plus douée, avec la mauvaise boîte à outils.

Vous appelez une artisane pour réparer un robinet qui fuit. Elle arrive avec 500 outils dans son utilitaire. Elle sait se servir de chacun. Mais elle attrape une scie au lieu d’une clé à molette. Le robinet n’est pas réparé. Pas par manque de compétence. Parce qu’elle a choisi le mauvais outil.

C’est exactement ce qui se passe à l’intérieur des agents IA tous les jours. Un agent prend votre demande, choisit un outil dans sa panoplie et l’exécute. Quand ça marche, l’effet est magique. Quand ça rate, l’échec est précis : il a pris le mauvais outil. Ou il n’a pas su que le bon existait.

L’industrie a passé des années à rendre les modèles plus intelligents. Meilleurs en raisonnement, en code, en compréhension du langage. Mais un problème plus discret a grossi en arrière-plan. À mesure que les agents accèdent à plus d’outils, trouver le bon devient plus difficile. Ce problème porte un nom : la retrieval, c’est-à-dire la sélection du bon outil pour la tâche.

Qu’est-ce que la retrieval ?

La retrieval, c’est le processus qui consiste à trouver et sélectionner le bon outil pour une tâche donnée. Quand vous demandez à un assistant IA de « me préparer une présentation », l’agent doit déterminer quel outil traite les slides. Quand vous dites « résume ce document », il attrape un outil différent. Quand vous dites « nettoie ça », il doit interpréter votre intention puis la rapprocher d’une capacité précise.

L’IA ne vous renvoie pas dix options à choisir. Elle prend un outil et l’exécute. Si elle se trompe, vous obtenez un mauvais résultat sans forcément comprendre pourquoi.

Ce problème prend de l’ampleur dans la recherche. Des chercheurs de Stanford et Harvard ont récemment publié un cadre d’analyse expliquant pourquoi les systèmes d’IA agentique s’effondrent en production, et la retrieval des outils y est identifiée comme un point de défaillance central. Le projet ToolBench, mis en avant à ICLR 2024, a construit un benchmark de plus de 16 000 API réelles et constaté que même les modèles avancés peinent à maintenir leur précision de retrieval à mesure que le catalogue d’outils grossit. Plus récemment, MCP-Bench a testé des agents sur 250 outils et confirmé que retrouver le bon outil à partir d’instructions floues reste l’un des défis non résolus les plus durs du design d’agents IA.

Pourquoi ça casse.

L’échec de retrieval le plus dangereux est celui que vous ne voyez jamais. L’agent ne choisit pas le mauvais outil. Il ne choisit aucun outil, parce qu’il ne sait pas que le bon existe. Vous lui demandez de « vérifier ce contrat pour repérer les clauses risquées ». Il possède un outil spécialisé de revue juridique, mais le système de retrieval ne le fait pas remonter. L’agent utilise donc un outil texte générique à la place. Vous obtenez une réponse moyenne et concluez que l’IA n’en est pas capable. En réalité, l’outil parfait restait inutilisé dans la boîte. C’est l’échec invisible, et il érode la confiance plus vite que n’importe quelle erreur visible.

Plusieurs forces rendent la retrieval difficile. Chaque outil est livré avec une description. Pensez-y comme à l’étiquette d’un bocal. L’agent lit ces étiquettes pour décider lequel attraper. Mais les étiquettes sont écrites par des humains. Les humains sont incohérents. Un outil annonce « générer des fichiers DOCX ». Un autre « créer des documents professionnels ». Un troisième « rédiger des rapports formatés ». Tous les trois font à peu près la même chose avec des mots différents. L’agent doit comprendre que votre demande de « note soignée » correspond à n’importe lequel des trois.

L’échelle amplifie le problème. Un agent avec cinq outils décide vite. Un agent avec 200 outils affronte des recouvrements, des ambiguïtés et une context window saturée. Chaque description prend de la place en traitement. Certains systèmes ne montrent à l’agent qu’un sous-ensemble d’outils. Mais si le bon ne figurait pas dans le sous-ensemble ?

Reste la partie humaine. Les gens parlent d’une façon qui ne colle pas proprement aux descriptions d’outils. « Répare mes données » peut vouloir dire supprimer des doublons, corriger un format, combler des trous, ou restructurer le fichier. Chaque cas demande une opération différente. Le système de retrieval porte tout le poids de cette traduction entre la façon dont on parle et la façon dont les outils sont étiquetés.

Le casse-tête multi-outils.

Tout ce qui précède concerne des tâches qui n’ont besoin que d’un outil. Beaucoup de tâches réelles en demandent plusieurs, qui s’enchaînent. Vous voulez lire un PDF, en extraire un tableau, nettoyer les données, et exporter le tout vers un tableur. Cela fait quatre outils, l’un après l’autre.

L’agent doit planifier la chaîne complète avant de démarrer. Il doit sélectionner des outils qu’il n’a pas encore utilisés, pour des étapes qu’il n’a pas encore franchies. Le mode de défaillance classique : l’agent termine l’étape 1 puis peine à trouver le bon outil pour l’étape 2. Chaque transition est un nouveau problème de retrieval. Les erreurs s’accumulent d’étape en étape.

Vers quoi on se dirige.

L’industrie commence à prendre la retrieval au sérieux. Quelques directions se dessinent.

Première piste : les compétences composables. Au lieu de traiter chaque outil comme une brique isolée, les systèmes permettent de les combiner comme des plugins. Une compétence « lire PDF » se branche à une compétence « nettoyer les données » qui se branche à une compétence « exporter vers un tableur ». L’agent ne fait pas la retrieval de chaque pièce depuis zéro. Il récupère un workflow déjà composé. Des unités petites, ciblées, qui s’emboîtent selon ce que la tâche demande.

Deuxième piste : une meilleure organisation, ce que certains appellent un graphe de savoir-faire vivant. Au lieu d’une liste plate de 200 outils, les compétences et les outils sont cartographiés dans un graphe structuré et évolutif de relations. Le graphe capture quels outils sont apparentés, lesquels se composent bien, lesquels couvrent un terrain proche, et comment ils ont performé sur les tâches passées. Le mot-clé est « vivant » : quand une nouvelle compétence est ajoutée, le graphe l’intègre. Quand un outil existant sous-performe ou devient redondant, le graphe se restructure. Il apprend des usages et s’adapte dans le temps.

C’est la couche d’infrastructure qui manque à la plupart des plateformes d’agents IA aujourd’hui. Le modèle est le cerveau. Les outils sont les mains. Sans système de retrieval qui joue le rôle d’index intelligent et évolutif, le cerveau continue à attraper les mauvaises mains.

Un graphe de savoir-faire bien tenu devient le tissu conjonctif entre ce dont l’utilisateur a besoin et ce que l’agent sait faire. Des plateformes comme skilder construisent cette infrastructure : un système où les compétences sont structurées, composables et gouvernées via un graphe vivant que les agents interrogent en temps réel. L’objectif est de transformer la retrieval en couche pilotée et évolutive, plutôt qu’en élément ajouté après coup. Chez skilder, ces compétences sont regroupées en casquettes (nos Hat, au sens technique du produit) : des assemblages propres à un rôle qui réunissent compétences, contexte et permissions, et qu’un agent enfile pour une mission donnée.

La prochaine frontière des agents IA n’est pas de les rendre plus intelligents. C’est de leur donner la bonne infrastructure pour trouver, composer et déployer les bonnes compétences au bon moment.

La retrieval est la nouvelle intelligence.