L’ère de l’interface comme « cache-misère » de la complexité organisationnelle touche à sa fin. Avec l’agentique, le design quitte la surface de l’écran pour la structure du contrat, où seule la clarté sémantique fait foi. Un plaidoyer pour passer du dessin de parcours à l’architecture de modèles métier solides.
L’interface graphique était un pacte de non-agression. Un compromis confortable entre la complexité chaotique de nos processus et le besoin de les rendre vaguement utilisables. Cette ère est terminée. Les interfaces agentiques dissolvent cette façade. Elles agissent comme un test de vérité qui expose trois décennies de dette organisationnelle dissimulée derrière des boutons et des menus déroulants. Reste à savoir si nous avons encore quelque chose de cohérent à dire à la machine.
L’interface graphique (GUI) a été le plus grand mensonge de l’informatique d’entreprise. Un mensonge par omission, un arrangement tacite. Face à des systèmes de gestion (ERP, CRM) dont la complexité interne reflétait des décennies de fusions, d’acquisitions et de compromis politiques, le GUI offrait une trêve. Il promettait de rendre le monstre Liferay ou le labyrinthe SAP navigable, à condition que l’utilisateur renonce à comprendre la logique sous-jacente.
L’accord était simple :
« Ne vous demandez pas pourquoi. Cliquez ici, puis là. »
Cette médiation a transformé des pans entiers de la main-d’œuvre tertiaire en opérateurs de terminaux. La compétence a changé d’objet : de la maîtrise d’un métier à la connaissance d’une séquence de clics.
Cette dynamique a créé les « super-utilisateurs », ces figures ambivalentes, à la fois goulots d’étranglement et piliers indispensables, dont le pouvoir tenait à la maîtrise d’une opacité logicielle plutôt qu’à une expertise métier transférable. L’interface assurait la conformité en anesthésiant la pensée critique.
Ce pacte a sédimenté la dette organisationnelle. Plutôt que de simplifier un processus de facturation alambiqué, on ajoutait un écran, un champ, une validation. Chaque rustine organisationnelle se traduisait par une verrue logicielle, cimentant un peu plus la complexité.
La loi de Conway a joué à l’envers : l’architecture rigide des systèmes imposait des silos organisationnels et des workflows absurdes, là où Conway voyait les structures de communication dicter l’architecture. Le GUI était la carte de cette prison.
L’arrivée des agents conversationnels et des plateformes « low-code » pilotées par LLM met fin à cette trêve. L’annonce récente de Salesforce, qui rend l’ensemble de ses objets et processus accessibles par API, serveur MCP ou ligne de commande, vaut aveu : l’interface graphique est devenue le principal facteur limitant. Le gain de productivité a quitté l’optimisation des clics pour la suppression de l’étape graphique elle-même.
Or, pour dialoguer avec un agent, la monnaie d’échange devient l’intention. Tenter de formuler une requête comme « Sors-moi la liste des clients à risque sur le segment PME en France qui n’ont pas été contactés par un commercial depuis 90 jours » expose immédiatement la fragilité de nos définitions.
Qu’est-ce qu’un « client à risque » ? Le calcul est-il standardisé ou dépend-il de l’interprétation d’un analyste sur un fichier Excel ? Le « segment PME » est-il une propriété stable ou une étiquette volatile ? Le « contact commercial » est-il un appel loggué dans le CRM, un email ou encore une entrée de calendrier ?
L’agent ne peut pas deviner. Il exécute ou échoue. Et son échec est un diagnostic. Il ne dit pas « l’IA ne fonctionne pas », il dit :
Votre définition de « risque client » est inutilisable.
Il révèle que ce que nous pensions être un processus n’était en réalité qu’un rituel, une série d’habitudes tenues ensemble par l’huile de coude de quelques individus. L’accélération individuelle promise par l’IA se heurte de plein fouet à la viscosité d’un système dont personne ne maîtrise plus la grammaire.
La conséquence directe est la nécessité d’interfaces polymorphiques, capables de s’adapter aux préférences cognitives de chacun. Un manager préférera dicter une requête vocale entre deux réunions, un analyste construira un script complexe pour automatiser un rapport, un opérationnel interagira via un chatbot intégré à Teams. L’idée d’une interface unique et standardisée, héritage du taylorisme industriel, devient un non-sens.
La crainte immédiate, notamment chez les DSI et les responsables de la sécurité, est celle de l’anarchie. Si chacun interagit avec le système central à sa manière, la traçabilité, la conformité et la maintenabilité semblent perdues, et débugger une « transaction » devenue conversation en langage naturel paraît impossible.
Cette objection est légitime, mais elle repose sur un postulat erroné : celui selon lequel la liberté de l’interaction implique le chaos dans l’exécution.
Tout se joue sur la solidité de l’objet manipulé, quel que soit le nombre de modes d’interaction autorisés. C’est ici que des concepts issus de l’ingénierie logicielle, comme le Domain-Driven Design (DDD) théorisé par Eric Evans, deviennent centraux pour le management. L’idée fondatrice du DDD est de construire un « langage ubiquitaire » (Ubiquitous Language) partagé par les experts métier et les développeurs, et de le matérialiser dans des objets logiciels clairs (les Domain Models). L’accord doit porter sur la définition et les règles de gestion d’un « Client », d’un « Contrat » ou d’une « Facture ». L’interface vient après. Une fois ce contrat logique établi, les moyens d’y accéder peuvent se multiplier sans risque, car ils attaquent tous le même noyau sémantique, auditable et sécurisé.
Le risque est de remplacer la bureaucratie du clic par la tyrannie du « prompt parfait ». On voit déjà poindre les « experts en prompt engineering » et les managers qui, pour garder le contrôle, voudront imposer la manière exacte de formuler les requêtes, recréant des formulaires et des scripts déguisés en conversation. Ce serait répéter la même erreur, en substituant un carcan par un autre. Le pouvoir passerait de celui qui maîtrise l’interface à celui qui rédige le manuel d’instructions de l’agent.
Cette tentation est un réflexe politique : rien, techniquement, ne l’impose. C’est l’ultime soubresaut de la culture du contrôle a priori. La complexité, hier justifiée par l’opacité du logiciel, se réincarnerait dans l’art supposé de la formulation. Or l’agentique vise à ce que le système comprenne une infinité de variations autour d’une même intention, sans exiger la seule bonne manière de poser une question.
La parade tient à l’auditabilité du système, et la formation au prompt n’y change rien. Le contrôle doit se déplacer vers le résultat en aval (la transaction, la modification de donnée), loin de l’action en amont (le clic, le prompt). Quand les interactions deviennent libres et personnalisées, la seule garantie est la capacité du système à enregistrer chaque opération dans un journal immuable, à expliquer pourquoi une décision a été prise, et à remonter à la source de chaque instruction, qu’elle vienne d’un humain ou d’un autre agent. On passe de la rassurance psychologique du formulaire à l’assurance mathématique du log.
Ce basculement impose de refondre les compétences et les rôles. Le métier de designer UX/UI, focalisé sur l’ergonomie des parcours graphiques, doit muter ou devenir une niche. Le besoin a changé : définir la sémantique du domaine métier plutôt que faciliter un parcours imposé. Le nouveau rôle stratégique est celui d’« architecte de contrats », un profil hybride, à la croisée du métier, du juridique et de la technologie.
Sa mission : animer le travail de clarification conceptuelle, loin du dessin d’écrans. Il doit, avec les équipes, répondre à des questions fondamentales : Quelles sont nos 50 entités métier critiques ? Quelles sont les règles invariantes qui les régissent ? Quels états peuvent-elles prendre ? Qui a le droit d’initier quelle transition d’état ? Ce travail, qui peut sembler fastidieusement philosophique, est en réalité l’acte le plus concret et le plus créateur de valeur dans une économie agentique. C’est la construction du socle de vérité sur lequel toutes les futures interactions reposeront.
Pour les équipes techniques, cela signifie un recentrage sur les fondamentaux de l’ingénierie : des API propres, une modélisation rigoureuse du domaine, et une obsession pour l’observabilité. Pour les managers, cela implique de passer d’un rôle de superviseur de tâches à celui de curateur du sens. Ils doivent s’assurer que tout le monde partage une compréhension univoque des concepts manipulés, plutôt que vérifier que les gens cliquent sur les bons boutons. Le travail est bien plus exigeant.
L’interface nous demandait où cliquer. L’agent nous demande ce que nous voulons vraiment. Peu d’organisations sont prêtes à répondre honnêtement.
Analyse
Quatorze catastrophes logicielles majeures des dix dernières années, et pas une ligne d’IA dedans. Des ports ouverts sans mot de passe, des identifiants par défaut, des sauvegardes que personne n’avait jamais testées. Nous n’avons en réalité jamais fait confiance aux développeurs, mais à une chaîne de revues, de tests et de post-mortems. Toute la question est de savoir ce qu’elle attrape encore, et à quel prix.
Analyse
Le diagnostic est posé : l’IA ne crée pas la dette organisationnelle, elle la rend exigible. Restait à écrire la suite : comment on rembourse. Cet article transpose l’appareil du redressement financier à l’organisation : des covenants plutôt qu’un inventaire, trois régimes de remboursement, un triage entre avalanche et boule de neige, et l’option que personne n’ose, la restructuration. Un plaidoyer pour tenir un registre de dettes organisationnel au même rang que le registre des risques.
Analyse
L’essor des agents IA révèle et amplifie un besoin ancien : savoir manager. La valeur de l’IA se joue dans la capacité à organiser, déléguer et piloter son utilisation.
