Une hypothèse née des usages des assistants de développement
Dans son billet du 21 janvier 2026, « B2CC — Claude Code is your customer », Caleb R. John défend l’idée que les éditeurs devraient penser leurs services pour des assistants capables de les découvrir et de les utiliser. Son raisonnement porte notamment sur les API, la documentation et les obstacles rencontrés lorsqu’un agent doit passer par un parcours conçu pour une personne.
Il s’agit d’une proposition stratégique issue d’un billet d’opinion, pas d’une étude mesurant la part des achats déjà réalisés par des agents. Sa reprise sur Moltbook ne constitue pas une confirmation indépendante. L’idée reste néanmoins intéressante pour un éditeur : si le logiciel qui assiste un utilisateur participe au choix d’un service, la facilité d’intégration pourrait peser davantage dans ce choix.
Le mot « client » demande ici une précaution. L’agent peut devenir un intermédiaire dans la découverte ou l’utilisation de l’offre. Cela ne suffit pas à lui attribuer un besoin économique propre, un budget indépendant ou le pouvoir d’engager une organisation sans mandat.
Une API utilisable ne remplace pas les conditions d’un achat
Le Model Context Protocol facilite le raccordement d’applications d’IA à des outils et à des données. Cette possibilité technique ne règle pas, par elle-même, la sélection commerciale, le paiement ou les conditions contractuelles. Exposer une fonction n’équivaut pas à autoriser n’importe quel agent à l’acheter.
Pour un service de traitement documentaire, par exemple, la décision ne porterait pas seulement sur la présence d’une API. Il faudrait connaître les formats acceptés, le prix, les limites d’utilisation, la conservation des données et les modalités d’arrêt. Une réponse techniquement correcte peut rester incompatible avec les contraintes du client qui a mandaté l’agent.
La découvrabilité ne devrait donc pas reposer sur une description séduisante que le modèle serait invité à croire. Elle suppose des informations vérifiables et des conditions lisibles. Côté acheteur, un plafond de dépense, une liste de fournisseurs autorisés et une validation des engagements importants peuvent délimiter la délégation. Côté vendeur, l’identification du compte, la facturation et le traitement des litiges restent à organiser.
Les intermédiaires pourraient changer de place plutôt que disparaître
Un agent capable de comparer directement plusieurs offres pourrait éviter certaines étapes d’un parcours web. On ne peut pas en déduire que les plateformes deviendraient inutiles. Elles peuvent aussi apporter de la confiance, agréger des services, traiter les paiements ou simplifier la gestion d’un ensemble de fournisseurs.
Une autre dépendance est même possible : si l’assistant privilégie un catalogue, un protocole ou un prestataire, l’entreprise peut perdre de la visibilité sur les critères qui ont orienté le choix. Une interface supprimée n’est pas nécessairement un intermédiaire supprimé. Il faut alors pouvoir retrouver les offres examinées, les contraintes appliquées et l’autorisation donnée.
Pour un éditeur, rendre un service plus facile à évaluer et à intégrer constitue une piste raisonnable, même sans parier sur un marché entièrement agentique. Une documentation précise, des tarifs compréhensibles et des données exportables servent aussi les clients humains et leurs équipes techniques.
Les agents peuvent ainsi participer à un parcours d’achat sans en changer la nature. La technique ouvre des accès ; l’organisation du mandat, du paiement et de la vérification reste à concevoir. C’est cette conception, et non la présence d’une API, qui détermine si l’intermédiaire change de place ou disparaît.