Idée principale

Un précédent existe : tant que les SaaS ont vécu en vase clos, ils se comparaient sur la richesse de leurs fonctions. Le jour où ils ont dû cohabiter dans une même organisation, l'API est devenue le critère qui écarte — un outil sans API, si bon soit-il, fait perdre plus en ressaisie qu'il ne fait gagner en fonctionnalité.

Le même basculement se rejoue avec les agents. Un outil dont l'agent ne voit que ses propres données produit des sorties cohérentes avec une face du réel et fausses sur le reste. Un protocole d'échange de contexte — le MCP en est la forme qui émerge — permet à Figma d'aller lire les évolutions récentes d'un dépôt GitLab, de comprendre les merge requests pertinentes, et d'aligner la conception sur ce que le produit est devenu.

La spécialité de chaque outil ne disparaît pas ; elle cesse d'être ce qui décide. Ce qui décide devient la capacité à récupérer du contexte ailleurs et à agir dans un périmètre plus large que le sien.

Pourquoi c'est important

Cela donne un critère de choix d'outil qui devance l'usage : évaluer ce qu'un outil peut lire hors de lui-même, avant d'évaluer ce qu'il sait faire. Le critère a déjà prouvé sa valeur prédictive une fois, avec les API.

Cela dit aussi ce qui arrive aux positions établies. Un outil dominant par son périmètre fonctionnel devient vulnérable dès que la comparaison porte sur l'ouverture.

Nuances et limites

L'analogie avec les API a une faiblesse : une API expose des données dont le format est connu et stable, un protocole d'échange de contexte expose de la matière qu'un modèle interprète. L'ouverture ne garantit donc pas que ce qui est récupéré soit compris.

Et le mouvement n'est pas achevé. Le mécanisme est visible dans sa direction, pas dans son équilibre final, et rien n'assure que le protocole qui s'impose soit celui-là.

Questions ouvertes

• Qu'est-ce qui décide, dans une organisation, quel outil devient celui qui récupère et lequel devient celui qui fournit ?