La fin des interfaces, pas la fin du logiciel

Les interfaces, oui. Le logiciel, non. La distinction paraît fine sur le papier et elle décide pourtant de la stratégie produit de tous les éditeurs pour les cinq ans qui viennent.

Le chiffre qui a déclenché le débat vient de Supabase, et il mérite d’être cité dans sa formulation exacte plutôt que dans le raccourci qui a circulé. En juillet 2026, son cofondateur Paul Copplestone déclarait au podcast de Y Combinator : « nous pouvons mesurer que 60 % des bases sont lancées par un agent, mais c’est plus probablement de l’ordre de 90 %, et cela se compte en millions chaque mois. » La plateforme est passée de 6,5 millions de développeurs fin 2025 à 10 millions en juillet 2026, et son plus gros contributeur individuel n’est pas une entreprise mais un agent de codage.

Un produit dont la majorité des utilisateurs ne voient jamais l’écran

Prenez la mesure de ce que cela signifie pour une équipe produit. Vous concevez des parcours, vous soignez un tableau de bord, vous testez des libellés de bouton, et la majorité de vos nouveaux utilisateurs n’ouvriront jamais aucun de ces écrans. Ils liront votre documentation, appelleront votre API et repartiront.

Supabase est un cas favorable, puisqu’il s’agit d’un produit d’infrastructure destiné à des développeurs. Mais la direction est générale et elle est déjà visible chez des éditeurs qui n’ont rien de technique : Salesforce a exposé l’intégralité de sa plateforme en API pour qu’un agent puisse lire les données, déclencher les workflows et mettre à jour les fiches sans jamais passer par l’écran, et des entreprises racontent avoir fondu cinq ou six abonnements distincts dans une seule interface conversationnelle.

Quant à savoir combien d’agents circulent réellement, personne ne le sait. Forbes concluait en juin 2026 que leur nombre se situait quelque part entre 10 % et 100 % de la population humaine, ce qui est une fourchette assez large pour signaler surtout qu’on ne mesure pas encore la bonne chose.

Ce qui meurt n’est pas le logiciel, c’est la tête

La formule qui circule chez les investisseurs est celle du logiciel « sans tête ». Le système de gestion reste exactement où il était, parce qu’il faut toujours un endroit où la donnée vit, où les règles s’appliquent et où l’historique se conserve. Ce qui se détache, c’est l’unique écran par lequel on y accédait, remplacé par autant d’interfaces qu’il existe de façons de formuler une demande.

Ce déplacement a une conséquence brutale pour la conception. Un agent ne s’intéresse pas aux fonctionnalités visibles, il s’intéresse aux capacités atteignables : dix points d’API bien conçus lui sont plus utiles que deux cents écrans de tableau de bord, et cette phrase inverse à peu près tout ce que le métier de product manager a appris depuis quinze ans.

Elle explique aussi pourquoi certains produits très riches à l’écran vont se révéler étonnamment pauvres à l’usage agentique. Une fonctionnalité qui n’existe que sous forme de clic, un état qui ne se lit que visuellement, une action qui suppose trois écrans successifs : rien de tout cela n’est utilisable par un système qui ne regarde pas.

Le mot que tout le monde évite : l’identité

Voici le vrai chantier, et il est ouvert. Si vos utilisateurs deviennent des machines, sous quel nom agissent-elles et qui a accordé ce nom ?

La question paraît administrative et elle est structurante. Un agent qui crée une base de données chez Supabase le fait avec les identifiants de quelqu’un. Un agent qui écrit dans votre ATS engage l’entreprise qui a ouvert l’accès. Or la plupart des systèmes actuels ne savent modéliser que deux situations, l’utilisateur humain et le compte de service partagé, et ni l’une ni l’autre ne décrit correctement ce qui se passe. C’est exactement le problème que le NIST a nommé en février 2026 en observant que les agents en entreprise héritent soit de tous les droits de leur utilisateur, soit d’une identité que personne ne peut auditer, et c’est ce qui rend une injection réussie si difficile à détecter.

Notre conviction est que ce point deviendra le principal critère de choix d’un logiciel professionnel avant deux ans, bien avant la richesse fonctionnelle. Un éditeur capable de dire précisément quelle identité a fait quoi, avec quels droits et sur quelle demande, vaudra plus qu’un éditeur dont l’interface est plus jolie.

Ce que l’écran garde, et qu’on oublie de dire

Il serait malhonnête de prédire la disparition complète des interfaces, parce que trois usages y résistent et qu’aucun des trois n’est marginal.

Le premier est l’exploration. Une conversation est excellente pour obtenir ce que l’on sait demander et très mauvaise pour découvrir ce que l’on ignore. Personne n’a jamais trouvé une anomalie dans ses chiffres en posant une question : on la trouve en regardant un tableau et en remarquant que quelque chose cloche. Tant qu’un agent ne sait pas ce qui va vous surprendre, l’écran reste le seul endroit où la surprise peut se produire.

Le deuxième est la vérification avant engagement, et c’est celui qui nous concerne le plus directement. La file d’attente où un humain relit ce qu’un agent s’apprête à envoyer est une interface, tout ce qu’il y a de plus classique, et elle ne peut pas être remplacée par une conversation : valider suppose de voir. C’est d’ailleurs le seul écran que nous considérons comme non négociable dans Balt.

Le troisième est la confiance dans la durée. Un système dont on ne voit jamais l’état finit par inquiéter, même quand il fonctionne, et l’inquiétude coûte plus cher que l’écran qu’elle aurait évité.

La bonne façon de formuler la transition n’est donc pas que les interfaces disparaissent, mais qu’elles cessent d’être le point de passage obligé. Elles deviennent un mode d’accès parmi d’autres, réservé à ce qu’il fait le mieux, et c’est déjà un changement considérable pour qui a construit son produit autour d’elles.

Ce que ça change concrètement pour une ESN

Trois choses, et elles se vérifient sans attendre que le marché ait fini de bouger.

Votre ATS cesse d’être jugé sur son ergonomie, ce qui est une bonne nouvelle pour tout le monde. La question devient de savoir si ses capacités sont atteignables autrement que par un clic, parce qu’un outil qui ne s’ouvre pas devient un îlot où votre donnée reste prisonnière pendant que le reste de votre système d’information communique. C’est aussi ce qui remet la réversibilité au centre du choix d’un éditeur.

Le prix par utilisateur devient une anomalie que vos fournisseurs vont défendre de moins en moins bien. Facturer un siège à une machine n’a aucun sens, et le modèle glisse déjà vers ce qui est réellement consommé ou accompli, exactement comme le tarif au siège se retourne contre un éditeur d’agents.

Enfin, vos propres écrans internes perdent de leur importance relative. L’endroit où le travail se demande devient la messagerie, et ce déplacement vaut aussi bien pour vos consultants que pour vos clients.

Notre pari, et ce qu’il nous coûte

Nous avons construit Balt en supposant que l’interface n’était pas le produit, ce qui est facile à dire et coûteux à assumer. Concrètement, cela veut dire que nous investissons peu dans des écrans et beaucoup dans ce qui se passe derrière : la qualité du contexte, la précision des droits, la trace de ce qui a été fait.

Le coût commercial est immédiat et nous le constatons à chaque démonstration. Un produit dont l’essentiel est invisible se vend moins bien qu’un tableau de bord impressionnant, et il faut plus longtemps pour convaincre quelqu’un que l’absence d’écran est une décision plutôt qu’un manque.

Nous pensons malgré tout que c’est le bon pari, pour une raison simple. Quand l’intelligence tend vers zéro et que la rareté se déplace vers le contexte et le droit d’agir, le logiciel qui garde de la valeur n’est pas celui qui affiche le mieux, c’est celui à qui l’on accepte de confier quelque chose. Une interface se refait en six mois. Une permission se gagne une fois et se perd définitivement.