Le GUI comme pacte de non-agression
L'interface graphique (GUI) a été le plus grand mensonge de l'informatique d'entreprise. Non pas un mensonge malveillant, mais 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 eu pour effet de transformer des pans entiers de la main-d'œuvre tertiaire en opérateurs de terminaux. La compétence n'était plus la maîtrise d'un métier, mais la connaissance quasi-ésotérique 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 ne reposait pas sur une expertise métier transférable, mais sur la maîtrise d'une opacité logicielle. L'interface n'était pas un outil d'émancipation, c'était un mécanisme de contrôle qui 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 inversée a joué à plein : ce ne sont plus les structures de communication qui dictaient l'architecture des systèmes, mais l'architecture rigide des systèmes qui imposait des silos organisationnels et des workflows absurdes. Le GUI était la carte de cette prison.
L'agentique ne pardonne pas le flou conceptuel
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, rendant l'ensemble de ses objets et processus accessibles via des API et des commandes en langage naturel, n'est pas une simple mise à jour. C'est l'aveu que l'interface graphique est devenue le principal facteur limitant. Le gain de productivité ne se situe plus dans l'optimisation des clics, mais dans la dissolution pure et simple de l'étape de la médiation graphique.
Or, pour dialoguer avec un agent, la monnaie d'échange n'est plus le clic, mais 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.
Le polymorphisme n'est pas l'anarchie
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 pour les DSI et les responsables de la sécurité, est celle de l'anarchie.
Si chacun peut interagir avec le système central à sa manière, comment garantir la traçabilité, la conformité ainsi que la maintenabilité ?
Comment débugger un problème quand la "transaction" est une conversation en langage naturel ?
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.
La solution ne réside pas dans la restriction des modes d'interaction, mais dans la robustesse de l'objet manipulé.
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'enjeu n'est plus de s'accorder sur une interface, mais de s'accorder sur la définition et les règles de gestion d'un « Client », d'un « Contrat » ou d'une « Facture ». 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é.
La tyrannie du « prompt parfait » remplacera-t-elle la bureaucratie du clic ?
Un nouveau risque émerge. Celui 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 ne serait plus détenu par celui qui maîtrise l'interface, mais par celui qui rédige le manuel d'instructions de l'agent.
Cette tentation est un réflexe politique, pas une nécessité technique. 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'objectif de l'agentique n'est pas de trouver la seule bonne manière de poser une question, mais de permettre au système de comprendre une infinité de variations autour d'une même intention.
La parade à cette tyrannie n'est pas la formation au prompt, mais l'investissement dans l'auditabilité systémique. Le contrôle ne doit plus porter sur l'action en amont (le clic, le prompt), mais sur le résultat en aval (la transaction, la modification de donnée). Dans un monde où les interactions sont fluides 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.
Des designers d'interfaces aux architectes de contrats
Ce basculement impose une refonte radicale des compétences et des rôles. Le métier de designer UX/UI, focalisé sur l'ergonomie des parcours graphiques, doit muter ou devenir une niche. Le besoin critique n'est plus de faciliter un parcours imposé, mais de définir la sémantique du domaine métier. 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 : non pas dessiner des écrans, mais animer le travail de clarification conceptuelle. 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. Leur responsabilité n'est plus de vérifier que les gens cliquent sur les bons boutons, mais de s'assurer que tout le monde partage une compréhension univoque des concepts qu'ils manipulent. C'est un travail infiniment plus exigeant, et éminemment humain.
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.