Il y a quelques jours, j’ai lu un billet de Mircha Emanuel D’Angelo sur la mort de l’interface utilisateur. De ces textes qui te restent collés. Je l’ai lu, relu, puis j’ai commencé à le remarquer dans la vie réelle : combien d’énergie mentale on dépense juste à se rappeler où on fait quelque chose, dans quel onglet, dans quel menu, dans quel produit.
Et alors que j’essayais de m’endormir, la question est devenue plus gênante et plus intéressante : si l’UI cesse vraiment d’être le centre du logiciel, qu’arrive-t-il au reste ? Parce que peut-être ce n’est pas seulement l’écran qui meurt. C’est peut-être l’application telle qu’on l’a connue.
Si l’UI meurt, elle ne tombe pas seule
Quand on dit « app », on entend en général un objet assez clair. Il a un nom, une icône, une place dans le dock, un abonnement mensuel, une personnalité. Et surtout une frontière. Dedans, il y a le monde de Notion. Dedans, il y a Jira. Dedans, il y a Salesforce. Dehors, tout le reste.
Je me suis aperçu que cette frontière, souvent, n’est pas là parce que le problème l’exige. Elle est là parce que le modèle économique l’exige.
Une grande partie du logiciel moderne est construite comme un enclos. Pas par méchanceté, peut-être. C’est juste que pendant des années, la façon la plus simple de monétiser a été celle-ci : prends un ensemble de fonctionnalités, empaquette-les, construis autour une interface qui devient familière, mets-y les données de l’utilisateur, et fais en sorte que la sortie soit douloureuse.
Mircha trace un parallèle qui m’a paru éclairant : les serveurs MCP comme « nouveaux programmes Unix ». Et si c’est vrai, alors la conséquence naturelle est une autre, un peu plus inconfortable. Les SaaS, vus de là, ressemblent à des mainframes. Grands monolithes nés à une époque où distribuer du logiciel coûtait cher et où la seule façon de le faire payer était de bâtir des murs.
Dans un monde où un agent peut composer au vol de petites capabilities précises, ce mur devient plus un encombrement qu’une protection.
L’interface générative : non conçue, invoquée
Il y a un passage du billet de Mircha qui m’a fait m’arrêter. L’idée que la GUI passe de control panel à display. Et je me suis demandé : et si elle n’était ni l’un ni l’autre ?
Peut-être l’interface, dans le tour suivant, devient éphémère.
Aujourd’hui, quand un designer conçoit un écran, il fait un compromis. Il cherche un layout qui marche « assez bien » pour beaucoup de personnes, dans beaucoup de contextes. Le résultat est souvent une interface solide, cohérente, testée, mais inévitablement générique. Elle doit servir tout le monde, donc elle ne sert parfaitement personne.
Avec un agent au milieu, ce compromis pourrait sauter.
Je n’entends pas « tout faire en chat », ce qui est une caricature confortable. J’entends un système qui, à partir de ton intention, génère l’interface adaptée à ce moment précis. Un formulaire non générique, mais avec ces champs, dans cet ordre, avec les valeurs par défaut qui ont du sens pour ton cas. Un dashboard non standard, mais la visualisation qui répond à une question précise, avec les données nécessaires et zéro bruit.
Ces UI ne sont pas maintenues. Ne sont pas versionnées. N’ont pas besoin de roadmap.
Elles sont invoquées, puis disparaissent.
Et l’inquiétant, c’est que ce n’est plus de la science-fiction. On voit déjà des modèles qui génèrent des composants, des pages, de petits artefacts en React en temps réel. C’est encore brut, oui. Mais la direction est difficile à ignorer.
À ce moment-là, le rôle du designer ne disparaît pas, il change de peau. De concepteur d’écrans, il devient concepteur de systèmes génératifs. Design system, contraintes, patterns, règles. Un travail plus proche de bâtir une grammaire que de dessiner des phrases.
L’agent comme système d’exploitation
Une autre conséquence me revient : peut-être la bonne métaphore pour l’agent n’est pas « assistant ». C’est « système d’exploitation ».
Un OS fait des choses qu’on tient pour acquises : il abstrait le matériel, gère les ressources, offre une interface unifiée, permet à des programmes différents de cohabiter et de se parler.
L’agent fait quelque chose de similaire, un cran au-dessus. Il abstrait les services, gère les contextes, offre une interface unifiée (le langage naturel), orchestre des capabilities différentes.
Si cette métaphore tient, alors quelque chose de presque inévitable se produit : l’agent devient la plateforme. Pas parce que tout « vit dans » l’agent, mais parce que tout passe par l’agent. Comme aujourd’hui aucun logiciel ne tourne sans OS, demain aucun service ne sera utilisé sans agent.
Et là entre la partie politique, ou économique, qui est peut-être la plus délicate. Qui contrôle l’agent contrôle le point d’accès au logiciel. Une position que l’on a déjà vue dans l’histoire, sous d’autres noms.
Et je me demande si on saura éviter la trajectoire habituelle. Celle que Cory Doctorow appelle l’enshittification. D’abord tout est utile et ouvert, ensuite ça devient une rente, ensuite ça devient un péage.
De l’app à la capability
Si l’application perd son sens, que reste-t-il ?
Reste la capability.
Une capability est une fonction atomique exposée via protocole, décrite de manière humaine, invocable par un agent. « Crée une facture ». « Cherche ce contact ». « Résume ces tickets et dis-moi les risques ». Ce n’est pas un produit avec une marque et un layout. C’est une brique.
Et dès que tu penses en briques, l’économie change aussi.
Aujourd’hui, tu paies un abonnement pour un bundle : cent fonctions, tu en utilises vingt, mais le prix est pour toutes. Demain tu pourrais payer à la consommation, capability par capability, au moment où tu en as besoin. Des fractions de centime pour une seule action bien faite.
Cela met en crise trois avantages historiques du SaaS :
Premièrement, l’interface comme lock-in. Si l’interface appartient à l’agent, elle n’est plus à toi.
Deuxièmement, les données comme prison. Si les données sont dans des coffres personnels avec des permissions granulaires, l’enclos perd son pouvoir.
Troisièmement, le bundle. Si l’agent peut composer le meilleur pour chaque pièce, le paquet monolithique devient moins attractif.
À ce stade, il ne reste qu’une chose : la qualité de la capability. Fais une seule chose, fais-la mieux que tous. C’est Unix comme philosophie technique, mais aussi comme modèle économique. Élégant, et un peu impitoyable.
Le nouvel alphabétisme
Une autre idée du billet de Mircha me semble sous-évaluée : « ne pas savoir parler à l’IA » comme nouvelle forme d’analphabétisme.
Pendant des décennies, on a appelé « alphabétisation numérique » une chose très précise : savoir utiliser des interfaces. Cliquer, glisser, naviguer dans les menus, remplir des formulaires. On a bâti des cours, des certifications, des métiers.
Si l’agent devient l’interface principale, tout cela se dégonfle.
La compétence centrale devient autre, et peut-être plus humaine que technique. Savoir exprimer une intention avec clarté. Savoir donner du contexte. Savoir décomposer un problème. Savoir juger un résultat et itérer.
Et là, un paradoxe me fascine. Il y a des gens qui n’ont jamais vraiment appris Excel mais qui savent dire ce qu’ils veulent avec une précision chirurgicale. Et il y a des power users qui, mis devant un agent, ne savent pas quoi demander.
La carte des compétences se redessine.
Et oui, le risque d’un nouveau digital divide est réel. Mais il y a aussi une opportunité rare : pour la première fois, l’avantage n’est pas « savoir parler le langage machine ». C’est savoir penser et communiquer correctement.
La surprise européenne : la compliance comme capability
Il y a un morceau de cette histoire qu’à mon avis, en Europe, on ne peut pas ignorer.
Tandis que le récit américain tend à voir la régulation comme un frein, ici on construit un cadre normatif qui touche précisément les nerfs à vif d’un monde de capabilities composables : AI Act, Cyber Resilience Act, Product Liability Directive, EAA.
Dans un système où un agent combine trois capabilities de trois fournisseurs différents, la question « qui est responsable si quelque chose tourne mal ? » devient explosive.
Si la loi exige traçabilité, sécurité, audit trail, explicabilité, alors la compliance cesse d’être un simple coût. Elle devient une capability différenciante.
Le SBOM comme passeport du composant. Le journal des actions de l’agent comme exigence. La transparence comme avantage concurrentiel.
Et il y a là un retournement presque ironique : beaucoup de revendications historiques de la culture hacker — ouverture, accountability, vérifiabilité — sont en train de devenir loi. Peut-être l’Europe, plutôt que ralentir, est en train de bâtir l’infrastructure de confiance sans laquelle le monde des agents ne tient pas dans les entreprises sérieuses.
2030, un jour comme un autre (peut-être)
J’essaie d’imaginer une journée normale, sans verser dans la science-fiction.
Tu n’as plus d’« apps » sur le téléphone. Tu as un agent. Tu lui parles, tu lui écris, tu fais peut-être un geste. Il orchestre des services différents et tu ne vois presque jamais les coulisses. Un peu comme aujourd’hui tu ne penses pas aux microservices quand une page s’ouvre.
L’interface que tu vois a été générée pour toi, à ce moment précis. Dans cinq minutes, elle n’existera plus.
Le commerce devient conversation. « Il me faut des chaussures de trail, budget 150 euros, terrain mixte, je préfère les semelles Vibram. » L’agent connaît ta taille, ton historique, tes préférences, tes sources fiables. Il te propose trois options avec une comparaison sur mesure. Tu choisis, fin.
Au bureau, quelque chose de similaire. Le PM n’ouvre pas Jira, il demande « où en est-on sur Alpha ? » et obtient l’état, les risques, les prochaines étapes. Le commercial ne navigue pas le CRM, il demande « quels deals sont à risque cette semaine ? » et reçoit un briefing. Le développeur décrit un comportement, et le système génère, teste, déploie.
Les données vivent dans un coffre personnel, chiffré et portable. Les capabilities demandent des permissions granulaires, révocables, et tout est journalisé. Chaque action produit un audit trail.
Dans ce monde, la valeur tient à deux choses : de bonnes capabilities et de la confiance.
Un réalisme nécessaire
Est-ce inévitable ? Je ne sais pas.
Les transitions ne sont jamais linéaires. Il y aura des résistances économiques énormes. L’enterprise se déplace avec une lenteur presque géologique. Les habitudes changent plus lentement que les communiqués de presse. Et il y a de vrais problèmes techniques : fiabilité sur tâches complexes, gestion des erreurs dans les chaînes de composition, sécurité, coûts.
Mais la direction que Mircha met au point me semble difficile à ignorer, parce qu’elle est portée par deux forces concrètes.
D’un côté, le coût cognitif des interfaces traditionnelles, qui croît avec chaque nouveau SaaS.
De l’autre, la capacité des agents à réduire ce coût, qui croît à chaque itération des modèles.
Quand l’écart entre les deux dépasse un seuil, la transition devient pratique, pas idéologique. Et pour certains cas d’usage, ce seuil est peut-être déjà franchi.
Mircha clôt en demandant qui construira ce futur et avec quelles valeurs. J’emporte une autre question, un peu plus personnelle et un peu plus cynique : qui aura le courage de construire pour ce futur, en sachant que cela signifie démonter le modèle qui paie aujourd’hui les salaires ?
Parce que le dilemme, au bout, n’est pas technique. C’est la volonté de cannibaliser le présent.
Et le temps pour décider de quel côté se ranger n’est probablement pas infini.
Ce billet naît de la lecture de « La morte dell’interfaccia utente come la conosciamo » de Mircha Emanuel D’Angelo. Si vous ne l’avez pas lu, à mon avis ça vaut la peine de partir de là.
Ce qu'il faut retenir
Les SaaS, vus depuis les MCP, ressemblent à des mainframes : monolithes nés pour monétiser à une époque où distribuer était cher.
L’agent n’est pas un assistant, c’est un système d’exploitation : qui le contrôle contrôle le point d’accès au logiciel.
La valeur migre de l’app vers la capability : fais une seule chose, fais-la mieux que tous.
En Europe, la compliance cesse d’être un coût et devient une capability différenciante : traçabilité et audit trail comme avantage concurrentiel.
Le dilemme n’est pas technique : c’est la volonté de cannibaliser le modèle qui paie aujourd’hui les salaires.
Questions & réponses
Pourquoi la mort de l'UI entraîne-t-elle la mort de l'idée d'app ?
Parce que l’app comme objet (nom, icône, dock, abonnement, personnalité) n’a de sens que tant qu’il existe une interface qui la délimite. Si l’interface disparaît — remplacée par des agents IA qui parlent à plusieurs services en même temps — la frontière de l’app cesse d’être exigée par le problème. Elle ne reste que parce que le modèle économique la réclame : prendre des fonctionnalités, les empaqueter, rendre la sortie douloureuse. Cet enclos, sans UI, ne tient pas.
Que sont les serveurs MCP dans ce contexte ?
Selon Mircha Emanuel D’Angelo, les nouveaux « programmes Unix » : de petits services spécialisés que les agents IA composent au besoin. Ils remplacent les grands SaaS — qui, vus de là, ressemblent à des mainframes des années 70 — par des architectures modulaires. Chaque MCP fait une chose bien, les agents composent des flux multiples en langage naturel.
Qu'est-ce qui change pour les SaaS qui vivent aujourd'hui d'abonnements ?
Le problème est structurel : si l’utilisateur interagit avec un agent IA qui compose des fonctionnalités issues de dix MCP différents, la valeur perçue n’est plus celle de l’app mais celle de l’agent. L’app devient une commodity API-based, facilement remplacée par le concurrent qui expose un meilleur MCP. Le pricing devra passer de l’accès à l’interface à l’accès aux données ou aux fonctions atomiques. Le modèle seat-based est l’un des premiers à sauter.
Que devrait faire un produit SaaS aujourd'hui pour ne pas être désintermédié ?
Trois mouvements : (1) exposer ses fonctionnalités via MCP avant que les clients le demandent, pas après ; (2) séparer clairement ce qui est infrastructure remplaçable de ce qui est valeur défendable (relations contractuelles, données exclusives, expertise verticale) ; (3) cesser d’investir dans le polish d’UI quand cette UI est sur le point de ne plus être le point d’entrée. Chaque sprint qui ajoute un bouton à la place d’un endpoint MCP est un sprint perdu en 2026.
L'auteur
