Pourquoi les agents ont besoin d'index, pas d'applications

Il existe aujourd'hui deux façons de donner à un agent IA accès à une donnée métier. La première : lui faire piloter un navigateur pour qu'il utilise vos applications comme un humain — cliquer, scroller, lire des pages. La seconde : lui donner accès à un index structuré qu'il interroge directement. La première approche fascine, parce qu'elle promet de tout automatiser sans rien changer. Notre conviction, après l'avoir mesurée, est qu'elle ne tient pas la comparaison — et que l'écart n'est pas marginal, il est de deux ordres de grandeur.

Le coût : lire des pixels est un gaspillage structurel

Quand un agent « navigue », chaque page consultée doit être capturée, convertie en texte ou en image, puis ingérée par le modèle. Une page de résultats d'un site d'emploi représente facilement 30 000 à 50 000 tokens une fois sérialisée, dont l'écrasante majorité est du bruit : menus, bannières, scripts, mises en page. La donnée utile — dix offres avec leur intitulé, leur entreprise et leur localisation — tiendrait en 1 500 tokens de JSON.

À l'échelle d'une tâche réelle de sourcing (disons 200 pages consultées), l'écart se chiffre : plusieurs millions de tokens ingérés côté navigation, contre quelques dizaines de milliers côté index. Le rapport de coût d'inférence est de l'ordre de 50 à 100 pour 1, avant même de compter l'infrastructure de navigateurs headless à maintenir.

La latence : des minutes contre des secondes

Une interaction de navigation — charger la page, attendre le rendu, laisser le modèle interpréter, décider du clic suivant — prend rarement moins de 5 à 10 secondes. Les tâches réelles en enchaînent des dizaines, en série, car chaque étape dépend de la précédente. Une recherche multicritère qui traverse trois sites peut ainsi durer 10 à 15 minutes.

La même intention exprimée contre un index structuré est une requête unique avec filtres, qui répond en quelques centaines de millisecondes. Ce n'est pas seulement plus confortable : cela change la nature des usages possibles. Un enrichissement de CRM en temps réel, une veille qui tourne toutes les heures sur 1,4 million d'offres, un agent conversationnel qui répond pendant que l'utilisateur lit sa question — aucun de ces usages n'existe à 10 minutes par requête.

La fiabilité : le vrai point de rupture

Le coût et la latence se négocient ; la fiabilité, non. Un agent qui navigue est exposé à tout ce qui fait la fragilité du web : refontes d'interfaces qui cassent silencieusement les parcours, contenus chargés dynamiquement, CAPTCHA et murs de connexion, tests A/B qui font qu'une page n'est jamais deux fois la même. Les taux de complétion observés sur des tâches web multi-étapes plafonnent, selon les benchmarks publics, bien en dessous de ce qu'exige un processus métier — et surtout, l'échec y est souvent silencieux : l'agent croit avoir lu la bonne valeur.

Un index expose un contrat : un schéma versionné, des champs typés, des codes d'erreur explicites. Quand quelque chose échoue, l'échec est détectable et traitable. Quand quelque chose répond, la provenance et la fraîcheur de la donnée sont connues. Pour un processus de recrutement ou de vente, cette différence sépare l'outil de production du prototype de démonstration.

La navigation reste utile — en amont, pas en aval

Soyons précis : faire lire le web à des agents a un sens. C'est même ainsi qu'un index se construit et se maintient — des agents de collecte qui parcourent les sources partenaires, détectent les changements et alimentent la base en continu. Mais ce travail doit être fait une fois, industriellement, en amont, puis mutualisé. Le refaire à chaque requête, chez chaque client, dans chaque conversation, revient à faire recompiler le programme à chaque exécution. La navigation est un moyen de production de l'index ; elle est un très mauvais mode de consommation.

Conclusion

La question n'est donc pas de savoir si les agents remplaceront les utilisateurs dans les applications, mais où placer la frontière : le désordre du web d'un côté, un contrat de données propre de l'autre. C'est précisément la fonction de sourcing.sh — encaisser une fois la complexité de la collecte sur les entreprises, les profils, les écoles et les offres, et exposer aux agents ce dont ils ont réellement besoin : non pas des pages à déchiffrer, mais un index à interroger, via API ou MCP, au forfait et sans compteur.