Longtemps, se servir d’un logiciel, c’était se rendre quelque part. On ouvrait Word. On allait sur Google. On lançait Photoshop. On se connectait à Salesforce. On tapotait une icône. Le geste paraît anodin, parce qu’il a structuré toute une époque. Il porte pourtant l’une des hypothèses les plus lourdes de l’âge numérique :
Qui fournit la capacité tient aussi l’écran par lequel on y entre.
Cet écran a valu cher. C’est là que les éditeurs ont bâti des marques, enseigné des gestes, glissé des fonctions, ramassé des données, vendu des mises à jour et installé des habitudes. C’est là qu’ils tenaient la relation.
L’intelligence artificielle commence peut-être à découdre ces deux fils. La capacité peut rester dans le logiciel. L’interface, elle, peut appartenir à un autre.
L’agent est peut-être déjà là
La question a surgi dans une conversation assez banale : comment ajouter de l’intelligence artificielle à un produit. Deux voies semblaient s’imposer.
La première, on la voit partout. On loge un agent dans le produit. On lui ouvre les données et les fonctions. On laisse poser des questions, créer, modifier, se déplacer dans l’outil par la parole. Le logiciel déjà là reçoit une interface intelligente.
Il y avait une autre voie. Et si l’on ne construisait pas d’agent du tout ?
Non par indifférence. Parce que la personne en a peut-être déjà un. ChatGPT, Claude, Gemini, une Siri encore à venir, un agent fourni par l’employeur, ou un agent souverain qui ne quitte pas une infrastructure qu’elle contrôle.
Si cet agent connaît déjà le travail, les goûts, les projets, les échanges et l’histoire de cette personne, pourquoi chaque nouveau logiciel lui demanderait-il d’entamer encore une relation avec encore une intelligence artificielle ? Le produit a peut-être besoin d’autre chose. Pas d’un agent de plus.
D’un chemin pour que des agents s’en servent.
Bring Your Own Agent
Imaginez, dans quelques années, souscrire à un nouveau service. Aujourd’hui, le rituel est connu : créer un compte, régler l’application, apprendre où cliquer, importer des données, dénicher les fonctions cachées, et finir par greffer encore une interface sur ses habitudes.
Imaginez plutôt une autre option : reliez votre agent. Vous donnez l’accès. L’agent découvre ce que le service sait faire. Et vous continuez à travailler là où vous étiez.
Vous dites par exemple : Prends le document reçu ce matin, ouvre un projet, analyse-le et dis-moi s’il y a quelque chose à regarder. L’agent récupère le document. Il reconnaît le service qui convient. Le système de métier fait l’analyse. L’agent revient avec le résultat. Vous n’avez peut-être jamais ouvert l’application. Et c’est pourtant elle qui a fait le travail le plus précieux de la chaîne.
C’est l’idée de ce qu’on peut appeler Bring Your Own Agent. Les fondations techniques n’ont plus rien d’hypothétique.
Le Model Context Protocol, ou MCP, est une norme ouverte : les applications d’IA s’y branchent sur des données, des outils et des flux externes. La documentation compare cela à une prise USB-C pour l’IA : une interface commune, et des systèmes différents peuvent s’y connecter. D’autres normes se forment autour de la parole entre agents, de la découverte, de l’identité et de l’autorisation.
Les protocoles précis changeront. Certains disparaîtront. D’autres naîtront. Ce qui compte est architectural :
Le logiciel se laisse invoquer par une machine.
De l’application à la capacité
Cela change ce qu’est une application.
Pour un humain, un produit, c’est encore des écrans, des menus, des tableaux, des formulaires, des boutons. Pour un agent, le même produit peut n’être qu’un faisceau de capacités : lire une information, analyser un document, ouvrir un projet, comparer des options, calculer, modifier un enregistrement, produire un rapport, déclencher une action.
L’interface graphique n’est qu’une façon de montrer ces capacités. Elle n’est plus forcément la capacité elle-même.
Pendant des décennies, l’architecture a souvent mis l’humain et son écran au centre. On cliquait. Le bouton lançait une opération. Le résultat s’affichait ailleurs. Une architecture pensée pour les agents inverse une partie de ce schéma. L’opération devient la pièce maîtresse. Plusieurs interfaces peuvent l’appeler : l’écran classique, l’assistant du produit, ChatGPT, un agent d’entreprise, ou une surface qui n’existe pas encore.
Le produit cesse de se demander comment son IA devrait s’en servir. Il commence à se demander :
Comment toute intelligence autorisée doit-elle user de nos capacités ?
L’agent n’est pas forcément celui du produit
Beaucoup de stratégies d’IA s’attaquent peut-être au mauvais problème. On met des copilotes partout. Chaque application se dote d’un champ de saisie. Chaque service veut sa conversation. Chaque entreprise invente un assistant au nom à peine différent.
Les raisons ne manquent pas. Un agent de métier peut connaître son domaine en profondeur. Il peut coller à l’interface graphique. Il peut très bien servir celles et ceux qui passent leur journée dans l’outil. Et tout le monde n’arrivera pas avec un agent extérieur.
Reste une hypothèse étrange : que l’on entretiendra des dizaines de relations distinctes avec des dizaines d’intelligences. On ne tient pas particulièrement à cinquante assistants.
On veut de l’aide.
Dès qu’un agent sait comment je travaille, de quoi je réponds, quels projets comptent, avec qui je collabore, ce que j’ai déjà tranché et ce qui s’est passé hier, passer à l’assistant du produit a un prix. Il faut reconstruire le contexte. Il faut réexpliquer l’intention. La relation repart de zéro.
Un agent personnel ou d’organisation suffisamment capable change le calcul. Le contexte est déjà là. La nouvelle application n’apporte qu’une capacité de plus.
Le logiciel s’efface, pas la valeur
Pour les éditeurs, le tableau a de quoi inquiéter au premier regard. Leurs applications peuvent devenir moins visibles.
Imaginez demander : Qu’est-ce qui demande mon attention, ce matin ? La réponse peut croiser calendrier, courrier, comptabilité, gestion de projet et plusieurs outils de métier. Vous n’en voyez peut-être aucun. Votre agent, lui, les voit.
Plus tard : La proposition révisée est dans mon courrier. Mets à jour le projet, vérifie les chiffres et dis-moi si quelque chose d’important a bougé. Plusieurs produits peuvent intervenir. De votre côté, il n’y a eu qu’une interface : l’agent.
Cela ne rend pas ces produits moins précieux. C’est même souvent l’inverse. Un système de métier peut calculer ce qu’un modèle généraliste ne devrait jamais tenter. Un système financier fait respecter des règles comptables. Un système d’ingénierie mène des simulations déterministes. Une base juridique fournit des sources qui font autorité. Un système scientifique applique des modèles validés.
L’agent orchestre. Les systèmes de métier savent. Cette distinction pourrait marquer l’architecture logicielle qui vient.
Le logiciel sans écran revient
Le web a peu à peu séparé le contenu de la mise en forme. Les API ont ensuite séparé les capacités des interfaces particulières. Le commerce a décroché la vitrine de l’infrastructure. Le cloud a transformé des pans entiers de technique en blocs qu’on programme. Les agents poussent l’idée d’un cran. Ils peuvent séparer l’intention humaine du parcours dans l’application.
Une API permettait à un logiciel d’en appeler un autre. Un agent permet d’énoncer un objectif sans dire, à chaque pas, quel logiciel s’en charge. C’est une délégation d’un autre type. On ne choisit plus forcément l’application pour chaque opération. L’agent peut le faire.
Trouver un logiciel, c’est trouver un service
D’où une autre question : comment trouvera-t-on le logiciel ?
Aujourd’hui, les éditeurs dépensent beaucoup pour devenir des destinations. Référencement, publicité, contenus, pages de vente, boutiques d’applications, visites guidées, essais gratuits, prise en main. Tous ces leviers supposent qu’un humain découvre un outil et décide de s’en servir.
Un monde d’agents introduit un autre client possible : la machine qui agit pour le client.
Imaginez dire : Trouve un service capable de cette analyse. Mes données restent en Suisse, il faut une piste d’audit, et cela doit coûter moins de cinquante francs par mois. Un agent pourrait repérer des services compatibles, inspecter ce qu’ils savent faire, comparer les prix, juger la juridiction et les contraintes de traitement, demander quelles normes ils respectent, peut-être même les tester. Puis proposer : ce service répond à vos critères ; l’autorisez-vous ? Oui. C’est fait.
Trouver un logiciel commence à ressembler à trouver un service. Le site ne disparaît pas. Il n’est peut-être plus la seule porte.
L’interface retient moins
Pendant une bonne part de l’ère SaaS, l’avantage s’est aussi construit en tenant l’écran. Une fois les gens installés dans le produit, partir coûte cher. On a appris les gestes. L’organisation a bâti des procédures autour. Les données s’empilent. Les intégrations s’empilent. Les réflexes s’incrustent. L’interface elle-même devient un rempart.
Les agents pourraient entamer cela. Si je peux dire la même chose à mon agent, quel que soit le service qui exécute la tâche, changer de fournisseur devient plus simple. Au lieu d’apprendre une autre application, j’autorise une autre capacité.
Les coûts de sortie ne disparaissent pas. Les modèles de données comptent. L’historique compte. Les intégrations comptent. La régulation compte. La confiance compte énormément. Mais connaître l’écran retient moins qu’avant. D’autres différences pèsent davantage : justesse, savoir de métier, données uniques, fiabilité, auditabilité, prix, latence, vie privée, juridiction, interopérabilité, confiance.
Dans ce monde, le meilleur éditeur n’est pas forcément celui dont l’interface accroche le plus. C’est peut-être celui dont la capacité, les agents la choisissent avec le plus d’assurance.
La concentration dangereuse au-dessus des applications
Bring Your Own Agent a un air de libération. Cela peut réduire la dépendance à telle ou telle application. Cela peut aussi simplement déplacer la dépendance d’un étage.
Si un seul agent passe par mon courrier, mon calendrier, mes documents, mes achats, mes finances, mes échanges, mes recherches et mes logiciels professionnels, il occupe une place extraordinairement puissante. Il voit mon intention avant les services. Il décide lesquels appeler. Il décide ce qu’il montre. Il peut décider ce qu’il ne montre pas. Il apprend mes goûts. Il se souvient de mon histoire. À terme, il peut peser sur ce que j’achète et sur qui reçoit mon activité.
Le navigateur est devenu une porte vers le web. Les moteurs de recherche, une porte vers l’information. Les systèmes d’exploitation mobiles, une porte vers les applications. L’agent personnel pourrait devenir une porte vers la capacité numérique elle-même.
La grande bataille de plateformes de l’époque des agents ne portera donc peut-être pas sur qui empile le plus de fonctions d’IA. Elle portera sur quelque chose de bien plus précieux :
À qui appartient l’agent ?
La souveraineté suit le levier
La question dépasse largement le confort du consommateur.
Prenez une organisation dont les employés passent par un agent extérieur pour atteindre les systèmes internes. Où s’accumule le contexte de l’organisation ? Qui conserve la mémoire de l’agent ? Qui décide des services qu’il préfère ? Qui peut inspecter ses décisions ? Qui tient son identité ? Qui peut lui retirer l’autorité ? Quelle juridiction encadre l’infrastructure ? Que se passe-t-il si le fournisseur change ses conditions ? Et si quelqu’un veut passer à un autre agent ?
Nous savons déjà à peu près ce qu’est la portabilité des données.
Celle de l’agent peut devenir aussi importante.
Puis-je emporter le contexte de travail accumulé ? Les permissions ? L’historique ? La compréhension de mes goûts ? Les relations avec les services ? Sinon, nous risquons l’un des enfermements numériques les plus forts que nous ayons connus. Le collier applicatif de l’ère SaaS pourrait paraître modeste à côté d’un agent qui a cinq ans de vie numérique dans la mémoire.
L’identité devient de l’infrastructure
Il y a une autre raison pour laquelle la transition durera plus longtemps que les démonstrations. Donner à une IA l’accès à l’information est relativement simple. Lui donner l’autorité ne l’est pas.
Il y a un gouffre entre montre-moi les chiffres du moment et change-les. Il y en a un plus grand encore entre prépare la transaction et exécute-la. Les agents demandent donc autre chose que les permissions classiques d’une application.
Un système utile doit savoir qui est l’humain, quel agent agit, pour qui, ce qui a été autorisé, pour combien de temps, et dans quel cadre. Il doit savoir ce qui peut se faire tout seul, ce qui ne peut qu’être proposé, ce qui exige une confirmation claire, ce qui exige une authentification plus forte, et ce qui s’est passé ensuite.
Une part de l’infrastructure la plus importante de l’époque des agents n’aura donc rien de conversationnel. Elle sera même profondément ennuyeuse : identité, autorisation, périmètres, politique, pistes d’audit, transactions, réversibilité, provenance. Ce sont ces systèmes qui transforment une démonstration brillante en infrastructure à laquelle on peut se fier.
Toutes les interfaces n’ont pas à disparaître
L’arrivée des agents ne signe pas la mort des interfaces graphiques. Les tableurs n’ont pas disparu avec les bases de données. Les sites n’ont pas disparu avec le mobile. Les lignes de commande ont survécu aux systèmes graphiques. Chaque interface est forte à sa manière.
La langue dit très bien une intention. Elle dit souvent très mal un état complexe. Essayez de comprendre des centaines de valeurs liées par la seule conversation. Un tableau fait mieux. Un graphique parfois mieux. Un dessin peut être indispensable. La bonne réponse d’un agent sera donc parfois : voici l’écran qu’il faut.
L’avenir n’est peut-être pas le logiciel conversationnel. C’est peut-être un logiciel qui change de forme. L’intention naît dans la langue. Le système appelle des capacités de métier. Des interfaces visuelles apparaissent quand elles servent. On manipule quelque chose. L’agent voit le changement. La conversation reprend. La frontière entre se servir de l’agent et se servir de l’application commence à se dissoudre.
L’application n’est plus qu’une projection
D’où une autre façon de concevoir le logiciel. Au lieu de bâtir une application puis d’y coller une couche d’IA, on bâtit d’abord un système de métier cohérent. Capacités explicites. Permissions explicites. État lisible par une machine. Opérations déterministes partout où c’est possible. Actions lourdes de conséquences encadrées. Puis on projette des interfaces dessus.
Une projection, c’est l’application web classique. Une autre, le mobile. Une autre, l’assistant du produit. Une autre, un agent extérieur. Une autre encore, un flux automatisé. L’interface devient remplaçable. Le métier demeure.
C’est une architecture qui tient, parce qu’elle n’a pas à parier sur le vainqueur. ChatGPT peut l’emporter. Gemini aussi. Apple peut faire du système d’exploitation le lieu naturel de l’agent personnel. Les entreprises peuvent préférer des agents qu’elles font tourner elles-mêmes. Des systèmes ouverts peuvent dessiner un tout autre écosystème. Il y aura presque certainement des agents que nous n’avons pas encore imaginés.
Un éditeur n’a pas à nommer le vainqueur. Il a à faire en sorte que le vainqueur puisse se servir de son produit en sécurité.
Bâtir une fois. Laisser l’intelligence arriver.
Le principe a une simplicité séduisante. Ne construisez pas votre activité autour de l’agent d’un autre. Ne supposez pas non plus que le vôtre deviendra le centre de la vie numérique de vos clients. Bâtissez la capacité. Dites-la clairement. Ouvrez-la par des normes. Protégez-la par une identité et une politique solides. Rendez les actions lourdes de conséquences auditables. Puis laissez l’intelligence arriver d’où le client la choisit.
Votre propre agent peut être l’un de ces clients. Il n’a pas à être le seul.
Ce n’est pas seulement une stratégie d’intégration. C’est une position sur la souveraineté technique. Le client garde le choix de l’intelligence. L’application garde la maîtrise de ses règles de métier. Ni l’un ni l’autre n’a à se rendre tout entier.
Après l’interface
Pendant quarante ans, nous avons déplacé le lieu où l’humain rencontre la machine. La ligne de commande a cédé au bureau graphique. Le bureau a cédé au web. Le web a été rejoint par le téléphone. Chaque passage a produit des entreprises qui ont pris l’interface d’hier pour la valeur.
La transition suivante peut être plus étrange : cette fois, l’interface elle-même peut comprendre ce que nous voulons. Alors, peut-être cesserons-nous de parcourir un logiciel pour le faire travailler. Nous dirons une intention. Notre agent verra quelles capacités il faut, et négociera avec les systèmes derrière.
Les applications existeront encore. Les interfaces compteront encore. Un bel outil restera précieux. Mais l’idée que chaque service numérique doit tenir la relation humaine pourrait ne pas survivre.
La question décisive, pour un éditeur, n’est donc plus vraiment comment loger un agent dans le produit. C’est :
Comment notre produit existe-t-il dans un monde où l’utilisateur en a déjà un ?
Parce que la fonction d’IA, au bout du compte, ne vivra peut-être pas dans votre logiciel.
Votre logiciel peut vivre dans l’IA de quelqu’un d’autre.
Et s’il en va ainsi, la dernière interface que nous construirons n’appartiendra peut-être à aucune application.
Elle pourra nous appartenir.
Sources
-
Model Context Protocol — Introduction Norme ouverte pour relier des applications d’IA à des données, des outils et des flux externes ; la documentation emploie l’analogie USB-C pour une interface commune. MCP Introduction
-
Model Context Protocol — Specification Exigences du protocole pour les hôtes, clients et serveurs qui exposent outils, ressources et invites. MCP Specification
-
OpenAI — MCP and Connectors Documentation pour relier ChatGPT et des applications associées à des serveurs MCP. OpenAI — MCP
-
OpenAI — Apps in ChatGPT Annonce d’applications qui s’exécutent dans ChatGPT : l’interface appartient à l’agent, les capacités à des tiers. OpenAI — Apps in ChatGPT
-
Anthropic — Introducing the Model Context Protocol Annonce d’Anthropic : MCP comme norme ouverte pour relier les assistants aux systèmes où vivent les données. Anthropic — MCP
-
Google Developers Blog — Agent2Agent Protocol Annonce d’A2A, protocole d’interopérabilité pour la parole entre agents. A2A
-
Google Developers Blog — Agentic Resource Discovery Annonce d’ARD, spécification ouverte pour publier, trouver et vérifier des capacités d’IA d’un domaine à l’autre. ARD
-
Apple Developer — App Intents Cadre pour exposer les capacités d’une application à Siri et à l’intelligence du système, par des intentions et des entités structurées. App Intents
-
Apple Developer — Apple Intelligence Documentation du système d’intelligence personnelle d’Apple, et le cas du système d’exploitation comme foyer de l’agent personnel. Apple Intelligence
-
OWASP — Top 10 for Agentic Applications (2026) Risques propres aux agents autonomes : abus d’identité et de privilèges, empoisonnement de la mémoire et du contexte, communication inter-agents mal sécurisée. OWASP Agentic Top 10
-
OpenClaw Assistant personnel libre qui tourne sur les appareils de l’opérateur, avec un état tenu localement plutôt que dans le nuage d’un fournisseur. OpenClaw