- ▸ Une question simple, quarante-sept étapes
- ▸ La thèse : le goulot n'est plus le modèle, c'est l'API
- ▸ Du connecteur ETL au Context Store : la généalogie d'un retournement
- ▸ L'analyse technique : pourquoi 90 % de tokens en moins
Réduire de 75 à 90 % la consommation de tokens d’un agent IA face à une base CRM ou ticketing : voilà la promesse mesurée par Airbyte sur Zendesk, Linear et Gong, en comparaison directe avec les serveurs MCP de chaque éditeur. La société a soumis le 5 mai 2026 son projet Airbyte Agents au crible de Hacker News. Trois constats techniques, trois implications produit, trois questions ouvertes pour les directions data.
Points clés 1. Airbyte Agents réduit jusqu’à 90 % la consommation de tokens face au MCP Zendesk, 80 % face au MCP Gong, 75 % face au MCP Linear, 16 % face à Salesforce, selon les mesures publiées par Airbyte le 5 mai 2026. 2. L’écart sur Salesforce s’explique par l’efficacité native du langage SOQL, qui rapproche déjà Salesforce d’un index agent-friendly. 3. Le pivot d’Airbyte : transformer un service de réplication de données en index optimisé pour la recherche agente, plutôt que de laisser l’agent dialoguer directement avec chaque API métier. 4. Un cas remonté par l’équipe Airbyte illustre la dérive des agents câblés sur MCP brut : 47 étapes pour répondre à une requête métier simple. 5. Le débat se déplace de l’API publique vers la couche de découverte : avant d’agir, l’agent doit savoir quoi chercher, où le chercher et selon quel schéma.
Une question simple, quarante-sept étapes
L’exemple que met en avant l’équipe Airbyte sur Hacker News est devenu une vignette de référence dans la discussion : un agent confronté à une requête métier quelconque finit par enchaîner quarante-sept appels distincts pour livrer sa réponse. Quarante-sept allers-retours, quarante-sept jetons d’authentification, quarante-sept interprétations partielles. La requête typique qui déclenche ce ballet ressemble à celle-ci : « Show me all enterprise deals closing this month with open support tickets. » Une formulation que n’importe quel responsable commercial pourrait poser à un humain, et qui requiert pourtant, côté machine, de cartographier le CRM, le système de ticketing, la liste des comptes prioritaires et le calendrier de clôture. Chaque API parle son dialecte. Chaque réponse alourdit la fenêtre de contexte. Le coût final n’est plus seulement monétaire ; il est aussi cognitif pour l’agent, qui voit son raisonnement dilué à mesure que les jetons s’accumulent.
La thèse : le goulot n’est plus le modèle, c’est l’API
Airbyte ne propose pas un nouveau modèle, ni une nouvelle technique d’inférence. La société, connue pour ses connecteurs de réplication de données, soutient que la productivité d’un agent dépend désormais moins de son LLM sous-jacent que de la couche qui le sépare des données métier. Sa proposition : un Context Store, index unifié et préparé pour la recherche agente, peuplé par les mêmes connecteurs que ceux utilisés pour la réplication classique. Si la mesure de 75 à 90 % d’économie de tokens se confirme à grande échelle, l’arbitrage entre payer le modèle et payer l’orchestration vient de basculer.
Du connecteur ETL au Context Store : la généalogie d’un retournement
Pour mesurer l’enjeu, il faut revenir à 2024. Anthropic publie alors le Model Context Protocol, conçu comme un standard ouvert pour connecter un agent à des sources de données externes. Le succès est rapide. En quelques mois, des centaines de serveurs MCP voient le jour, chacun encapsulant une API existante : Zendesk, Linear, Gong, Notion, Stripe, GitHub. Le pari est lisible — si chaque éditeur expose son API métier sous forme MCP, n’importe quel agent peut s’y brancher sans glue code.
L’architecture est élégante sur le papier. Sur le terrain, elle hérite d’un défaut historique des API REST : elles ont été conçues pour des développeurs humains, qui connaissent le schéma de données, comprennent la documentation et savent quels endpoints appeler. Un agent, lui, démarre une étape plus tôt. Il doit d’abord découvrir ce qui existe, puis raisonner. Comme le formule l’équipe Airbyte, les API supposent que l’on sait déjà quoi requêter, alors que les agents commencent par avoir besoin de découvrir ce qui compte avant même de pouvoir raisonner.
Cette inversion explique pourquoi un MCP brut, même bien spécifié, peut conduire à la spirale des quarante-sept étapes. L’agent essaie. Il échoue sur un nom de champ. Il consulte le schéma. Il essaie un autre filtre. Il rate un identifiant d’objet. Il liste, il filtre, il croise. Chaque opération coûte des tokens — d’entrée pour passer le contexte, de sortie pour produire la requête, d’entrée à nouveau pour ingérer la réponse.
Airbyte arrive avec un avantage de sédimentation. Depuis sa fondation, la société a accumulé plusieurs centaines de connecteurs de réplication. Chaque connecteur normalise déjà le schéma source vers une structure tabulaire. La transition vers un index agent-ready consiste à pré-mâcher ce travail, à exposer les entités sous forme de catalogue interrogeable, à pré-calculer les jointures probables. Le Context Store n’est pas un produit nouveau ex nihilo : c’est l’extension d’un actif existant à un nouveau cas d’usage. Cette filiation explique pourquoi Airbyte peut prétendre couvrir un large spectre de sources sans repartir de zéro pour chacune.
L’analyse technique : pourquoi 90 % de tokens en moins
Le chiffre central — jusqu’à 90 % de tokens en moins sur Zendesk — mérite qu’on le décompose. Airbyte publie le 5 mai 2026 quatre mesures comparatives, chacune mettant en regard l’utilisation de son Context Store et l’utilisation du MCP officiel de l’éditeur concerné.
| Source de données | Économie de tokens vs MCP éditeur | Lecture |
|---|---|---|
| Zendesk | jusqu’à 90 % en moins | Cas où le MCP officiel multiplie les appels pour reconstituer l’arborescence ticket-utilisateur-organisation. |
| Gong | jusqu’à 80 % en moins | Volumétrie d’appels et de transcripts d’entretiens commerciaux qui fait gonfler la fenêtre. |
| Linear | jusqu’à 75 % en moins | Suivi de tâches : graphes de dépendances entre issues coûteux à parcourir via API. |
| Salesforce | jusqu’à 16 % en moins | « Salesforce’s own SOQL does a good job here », commente Airbyte. |
Le chiffre Salesforce mérite une mention particulière. Avec seulement 16 % d’écart, le verdict est presque inversé : Salesforce, par son langage déclaratif SOQL, propose déjà une couche de requête proche d’un Context Store. SOQL permet à l’agent d’exprimer la jointure dont il a besoin, en une seule passe, plutôt que de l’orchestrer à coups d’appels REST. Salesforce, premier client historique du modèle CRM, est devenu sans le vouloir une référence d’API agent-friendly.
L’écart entre 90 % (Zendesk) et 16 % (Salesforce) trace un axe d’analyse. Plus une API force l’agent à orchestrer manuellement la découverte du schéma et la composition des requêtes, plus le Context Store crée de valeur. À l’inverse, dès qu’une API expose un langage de requête déclaratif, le différentiel s’effondre. Le ratio d’économie est, pour ainsi dire, un thermomètre de la friction agentique de chaque API.
D’un point de vue architectural, le Context Store joue trois rôles distincts. Premier rôle, l’indexation : les entités — tickets, deals, issues, transcripts — sont matérialisées dans une structure interrogeable, avec leurs relations explicites. Deuxième rôle, la résolution de schéma : l’agent reçoit une vue normalisée plutôt qu’un patchwork d’identifiants opaques. Troisième rôle, la recherche : l’agent peut combiner critères structurés et recherche sémantique, ce qui réduit les itérations de raffinage.
À volume constant, le coût d’inférence d’un agent se décompose schématiquement entre le coût du modèle (par million de tokens), le coût d’orchestration (latence par étape) et le coût de contexte (la fenêtre qui grossit). Réduire la consommation par 4 ou par 10 sur la composante donnée, c’est aussi remonter d’un cran la profondeur de raisonnement possible avant saturation. L’effet est cumulatif : moins de tokens consommés pour la découverte, plus de marge pour la planification.
Cette mécanique a une conséquence directe sur la structure de coût. Lorsque la facture d’un agent en production se répartit entre plusieurs sources d’API, économiser 75 à 90 % sur chaque source n’est pas additif au sens strict — il faut tenir compte des appels résiduels — mais l’effet de cumul reste substantiel. Une plateforme qui croise CRM, ticketing et outils de revenue intelligence peut voir sa facture mensuelle d’inférence divisée par un facteur significatif, à condition que le Context Store soit alimenté assez fréquemment pour rester pertinent.
Impact terrain : trois exemples de requêtes, trois métiers
Pour les directions data, la question pratique est de savoir ce qu’on gagne au quotidien. Les trois requêtes données en exemple par l’équipe Airbyte permettent d’esquisser trois usages.
Premier exemple, prospection commerciale : « Show me all enterprise deals closing this month with open support tickets. » La requête croise CRM (segment enterprise, date de clôture) et système de ticketing (statut ouvert, mapping compte). Sans Context Store, l’agent doit interroger séparément les deux sources, joindre côté agent, gérer la cohérence des identifiants. Avec un index unifié, la jointure est précalculée ou exprimable en une seule passe.
Deuxième exemple, qualité de delivery : « Find every support ticket that doesn’t have a Github issue opened. » Là encore, la requête croise deux sources distinctes — un système client-facing et un dépôt code. La logique d’anti-jointure (« doesn’t have ») est notoirement coûteuse à exprimer via API REST sans curseurs ni filtres adaptés.
Troisième exemple, fidélisation : « which customers are at risk of leaving this quarter? » Cette question, plus floue, demande à l’agent d’agréger des signaux disparates — historique de support, usage produit, sentiment dans les conversations, fenêtre de renouvellement. La valeur du Context Store y est moins dans la jointure brute que dans la capacité à faire émerger les bons axes d’analyse à partir d’un index sémantiquement riche.
Pour une direction data, le calcul de retour sur investissement n’est pas seulement « combien de dollars de tokens en moins ». Il intègre aussi la latence — un agent qui répond en huit secondes au lieu d’une minute change le rapport d’usage —, la fiabilité — moins d’étapes signifie statistiquement moins d’occasions d’erreur — et la profondeur — la fenêtre libérée peut accueillir davantage de raisonnement métier. C’est cette combinaison qui rend la promesse difficile à évaluer sur un seul chiffre.
Perspectives contradictoires : ce qui plaide contre
L’enthousiasme méthodologique appelle plusieurs contre-arguments sérieux. Le premier tient à la nature du benchmark publié. Les mesures portent sur des cas où l’agent doit interroger plusieurs entités liées, ce qui pénalise mécaniquement les MCP qui multiplient les appels. Sur des requêtes plates — récupérer un seul ticket, créer une issue — l’écart est probablement moindre. Le chiffre « jusqu’à 90 % » est un plafond, pas une moyenne.
Le deuxième contre-argument est l’effet Salesforce. Avec 16 % d’économie seulement, le Context Store n’apporte qu’un gain marginal lorsque l’API source est déjà bien conçue pour la requête déclarative. On peut anticiper que les éditeurs concurrents — Zendesk, Linear, Gong en tête — réagiront en proposant à leur tour des langages de requête plus expressifs, soit nativement, soit via une nouvelle génération de MCP serveurs. La différence de 75 ou 90 % observée aujourd’hui pourrait se compresser à moyen terme.
Troisième angle : le verrouillage. Adopter un Context Store unique, c’est concentrer la dépendance sur un fournisseur intermédiaire entre l’agent et les sources. Le bénéfice est immédiat, le coût de sortie l’est moins. Pour une direction data attentive aux risques d’adhérence, l’arbitrage entre commodité et indépendance reste à instruire au cas par cas.
Quatrième point, plus structurel : la question de la fraîcheur. Un index optimisé pour la recherche agente, peuplé par réplication, n’est jamais aussi à jour qu’un appel direct à l’API source. Pour les usages temps réel — alerte fraude, dispatching, opérations de marché — l’arbitrage peut s’inverser au profit du MCP brut.
Prospective : où va la couche de contexte
Trois trajectoires se dessinent à douze mois. Première trajectoire : standardisation. Si le pattern Context Store fait ses preuves, les éditeurs SaaS auront intérêt à exposer leurs propres index agent-ready. Salesforce a déjà un pied dans ce camp grâce à SOQL. Les autres suivront, par contrainte concurrentielle.
Deuxième trajectoire : convergence avec MCP. Le Model Context Protocol n’est pas en concurrence frontale avec un Context Store — il pourrait en devenir le moyen d’exposition. Un MCP de seconde génération, branché sur un index pré-mâché, combinerait standard ouvert côté agent et performance côté infrastructure.
Troisième trajectoire : la concurrence directe sur la couche elle-même. Airbyte n’a pas le monopole des connecteurs, et son avance se mesurera à la qualité du modèle de données qu’il expose, à la fraîcheur de l’index et au coût d’opération. La question pour les directions data n’est plus de choisir un agent, mais de choisir le câble entre l’agent et les données.
FAQ
Quels sont les gains en tokens annoncés par Airbyte ?
Selon les mesures publiées le 5 mai 2026, Airbyte Agents consomme jusqu’à 90 % de tokens en moins que le MCP Zendesk, 80 % de moins que le MCP Gong, 75 % de moins que le MCP Linear, et 16 % de moins que Salesforce. Les chiffres sont des plafonds observés sur des requêtes croisant plusieurs entités liées, pas une moyenne globale.
Qu’est-ce que le Context Store ?
Le Context Store est un index de données optimisé pour la recherche agente, peuplé par les connecteurs de réplication d’Airbyte. Il expose les entités métier — tickets, deals, issues, transcripts — avec leurs relations précalculées, permettant à un agent de découvrir ce qui existe avant de raisonner, sans multiplier les appels d’API ni saturer sa fenêtre de contexte.
Pourquoi Salesforce se comporte-t-il différemment ?
Salesforce dispose nativement de SOQL, un langage déclaratif qui permet à un agent d’exprimer une jointure complète en une seule requête. L’écart avec le Context Store tombe à 16 %. Cela suggère qu’une API offrant une couche déclarative riche se rapproche déjà d’un index agent-friendly, et réduit le différentiel apporté par une couche de contextualisation externe.
Quel rapport avec le Model Context Protocol ?
MCP est le standard de connexion agent-source publié par Anthropic en 2024. Le Context Store ne s’y oppose pas frontalement : il pourrait s’exposer demain via MCP, en jouant le rôle de moteur derrière le protocole. Le débat se déplace alors de la spécification du protocole vers la qualité de l’index qui l’alimente.
Sources
- Show HN: Airbyte Agents – context for agents across multiple data sources, Hacker News, 5 mai 2026 — https://news.ycombinator.com/item?id=48023496
