Le prochain utilisateur d'ERP pourrait ne pas être humain

Chaque écran est une supposition sur qui regarde.

Considérez ce qu'est un ERP du point de vue de son utilisateur. Derrière la marque, c'est un ensemble de tables et de règles : clients, articles, commandes, factures, mouvements de stock, et les contraintes qui les maintiennent cohérents. Devant cela se trouve la partie sur laquelle la plupart de l'argent a été dépensé : plusieurs milliers d'écrans qui présentent ces tables à une personne quelques champs à la fois, dans un ordre qu'une personne peut suivre, avec des étiquettes qu'une personne peut lire et des boutons qu'une personne peut trouver.

Chacun de ces écrans encode une supposition sur qui se trouve de l'autre côté. La supposition est celle d'une personne avec une mémoire de travail limitée, donc le formulaire est divisé en onglets. Une personne qui lit de gauche à droite, donc le champ important est en haut à gauche. Une personne qui peut garder environ sept choses en tête, donc le tableau de bord a six tuiles. Une personne qui fera des erreurs de frappe, donc il y a une validation à la soumission. Une personne qui se fatigue, donc le chemin commun a moins de clics. Tout cela est un bon design pour l'utilisateur que le designer avait, et pendant quatre décennies, cet utilisateur était le seul qui existait.

La conséquence est que l'interface est une représentation dégradée du modèle de données pour un type de lecteur. Le modèle sait qu'une facture a des lignes, un client, une date d'échéance et un statut ; l'écran montre les lignes sur un onglet, le client sur un autre, et le statut sous forme de couleur. Un travail qui touche cinq enregistrements signifie cinq écrans, et la personne porte le fil entre eux dans sa tête. Ce fil est la majeure partie de ce qu'une entreprise paie son personnel administratif pour maintenir.

Le nouvel utilisateur a des outils, pas des mains

Un agent IA opérant un système d'entreprise ne reçoit rien de cela. Ce qu'il reçoit, lorsqu'il se connecte via le Model Context Protocol, est le résultat d'une demande pour lister des outils : pour chacun, un nom, une description écrite pour un modèle à lire, un schéma pour ses entrées, et éventuellement une annotation indiquant si l'outil ne fait que lire, s'il peut détruire quoi que ce soit, et si l'appel à deux reprises est sûr. L'agent choisit un outil, l'appelle avec des arguments tapés, lit le résultat et choisit à nouveau. Le résumé du protocole lui-même est qu'il s'agit d'un moyen standardisé de connecter des applications IA à des systèmes externes, de la même manière qu'un port commun connecte des appareils, et les principaux clients le parlent maintenant : Claude, ChatGPT, Cursor et VS Code parmi eux.

Regardez ce dont cet utilisateur n'a pas besoin. Il n'a pas besoin que la facture soit divisée en onglets, car il peut tenir l'ensemble de l'enregistrement à la fois. Il n'a pas besoin que le champ important soit en haut à gauche, car il n'y a pas de gauche. Il n'a pas besoin de six tuiles, car il peut demander le nombre qu'il veut. Il ne se fatigue pas, et il n'y a pas de clics. Chaque concession qui a rendu l'écran bon pour une personne est, pour cet utilisateur, soit sans pertinence, soit un obstacle.

Et regardez ce dont il a besoin à la place, que l'écran n'a jamais fourni. Il a besoin que la description de chaque action soit précise, car la description est l'ensemble de sa compréhension. Il a besoin que le schéma soit complet, car il ne peut pas voir un exemple. Il a besoin de savoir quelles actions sont sûres à réessayer. Il a besoin que le résultat indique ce qui s'est passé et ce qu'il peut faire ensuite. Pour cet utilisateur, la documentation est l'interface, et le nommage est un design : un outil général avec une description de deux lignes est un produit moins bon que la même capacité sous la forme de trois outils avec des noms simples et des descriptions honnêtes, peu importe à quoi ressemblent les écrans au-dessus d'eux.

Le détour par l'écran ne durera pas

La première réponse à un nouvel utilisateur est toujours de l'habiller comme l'ancien. L'automatisation des processus robotiques a fait cela pendant une décennie : un bot se connecte avec un compte de service et pilote les écrans comme s'il avait des mains, trouvant le bouton par son sélecteur ou ses coordonnées. La version actuelle donne à un modèle de langage une capture d'écran et un curseur. L'utilisation de l'ordinateur par Anthropic fait exactement cela, et sa documentation précise soigneusement où elle se situe : elle existe pour les cas où aucune interface plus étroite n'est disponible, elle vous dirige vers un outil de navigateur lorsque le travail reste sur une page, et elle demande à une personne de confirmer quoi que ce soit ayant des conséquences réelles significatives, y compris les transactions financières.

Le costume est coûteux à porter. Un écran ne fait aucune promesse à une machine, donc chaque changement effectué pour la personne casse l'automatisation qui prétend en être une. Chaque couche entre l'agent et l'action, la capture d'écran, la supposition de quel pixel est le bouton, le texte tapé qui peut ou non avoir atterri dans le bon champ, est un endroit où se tromper, et un modèle est déjà un endroit où se tromper. La conduite par écran est le pont que vous construisez pendant que le système en dessous n'a rien de mieux, et les fournisseurs des bots le disent eux-mêmes : ils décrivent maintenant le robot comme une couche d'exécution qu'un agent appelle pour les systèmes qui en ont encore besoin.

Ce que le logiciel doit devenir

Si l'argument jusqu'à présent est valide, la forme du logiciel agent-native en découle, et ce n'est pas qu'une API secondaire. Cinq propriétés doivent être vraies en même temps.

• Chaque action est un outil. Pas la douzaine que le fournisseur pensait être sûre, mais toute la surface qu'une personne peut atteindre à travers les écrans : créer, lire, déplacer, approuver, envoyer, rapprocher. Tout moins, et l'agent doit se rabattre sur l'écran pour le reste.
• Chaque appel porte une identité. L'agent agit en tant que personne spécifique, via une connexion normale, et les outils qui lui sont proposés sont filtrés par le rôle de cette personne avant qu'il ne les voie et vérifiés à nouveau lorsqu'ils sont exécutés. Un agent ayant accès à l'ensemble du système est un échec de conception, pas une fonctionnalité.
• Il demande par conception. Certaines actions s'exécutent ; certaines sont suspendues pour une personne ; certaines sont refusées outright. Le protocole lui-même stipule qu'il doit toujours y avoir un humain dans la boucle capable de refuser un appel d'outil, et les principaux clients demandent avant une écriture par défaut. Le logiciel doit rendre les catégories explicites plutôt que d'espérer que le modèle soit poli.
• Les dépenses ont un plafond. Lorsque le raisonnement du système coûte de l'argent, ou lorsqu'un outil engage de l'argent, il y a un plafond par connexion que le système impose et que le modèle ne peut pas contourner.
• Le journal est le produit. Chaque appel, ses entrées et son résultat, sous l'identité qui l'a effectué, est révisable de la même manière que les actions d'une personne. Pour un agent, la piste de vérification est comment la confiance se construit, une semaine à la fois.

Une sixième propriété est moins une exigence qu'une conséquence. Lorsque le travail est effectué à l'aide d'outils, l'enregistrement est conservé comme un sous-produit : l'agent qui facture, relance et rapproche laisse derrière lui exactement la facture, la relance et le rapprochement qu'une personne aurait tapés, sans la saisie. Les écrans survivent, pour regarder, réviser et décider. Ils cessent d'être le seul endroit où le travail peut se faire.

L'objection qui mérite d'être prise au sérieux

La plus forte objection admet que les agents peuvent effectuer le travail et souligne qu'ils le font parfois mal, avec confiance, lors d'une écriture. C'est vrai, et la documentation honnête le dit : ChatGPT considère tout outil sans annotation en lecture seule comme une écriture et exige une confirmation par défaut ; Claude demande une approbation avant d'invoquer un outil d'un connecteur personnalisé et avertit qu'un serveur malveillant peut contenir des instructions cachées. Les clients ont raison d'être prudents, et une entreprise devrait l'être aussi.

Mais remarquez où la prudence doit résider. Elle ne peut pas résider dans le modèle, qui est la partie qui pourrait se tromper. Elle doit résider dans le logiciel, qui est exactement là où un bon logiciel l'a déjà mise pour les utilisateurs humains. Validation, autorisations, seuils d'approbation, annulation, audit : chacun de ces éléments existe parce que l'utilisateur précédent a également fait des erreurs, avec confiance, lors d'une écriture. Le logiciel natif agent prend cette ancienne discipline au sérieux à chaque action plutôt qu'à celles que le concepteur d'écran a retenues, et l'applique à un utilisateur qui appellera une centaine d'outils avant le déjeuner.

Une deuxième objection est le déterminisme. Certains travaux doivent produire la même sortie pour la même entrée, de manière prouvable, à chaque fois. Ce travail doit rester un flux de travail fixe, et l'agent doit appeler le flux de travail comme un outil plutôt que de l'improviser. Le jugement ne remplace pas les règles ici ; le système a besoin des deux, exposés à un utilisateur capable de les distinguer.

Qui le construit, et pour qui

La dernière conséquence est celle que l'entrepreneur devrait remarquer. Si l'utilisateur du logiciel peut être un agent, le constructeur le peut aussi. Un développeur décrit l'application qu'il souhaite à un agent qu'il a déjà, l'agent la construit à l'aide d'un ensemble d'outils de construction, le développeur la valide localement et la publie, et dès le premier jour, chaque outil que l'application expédie est disponible pour chaque autre agent sur la plateforme. L'entreprise qui l'installe n'apprend pas ses écrans ; son personnel apporte l'agent qu'il utilise déjà et décrit le résultat. C'est l'arrangement autour duquel Sois est construit, proposé ici comme une mise en œuvre de l'argument plutôt que comme sa conclusion.

La conclusion est plus simple. Pendant quarante ans, la question qu'un concepteur de logiciels posait était ce que la personne de l'autre côté avait besoin de voir. Le prochain utilisateur ne voit pas. Il lit un contrat et appelle ce qu'il est autorisé à appeler, et il le fera au nom des mêmes personnes pour qui les écrans ont été conçus. Un logiciel qui traite cet utilisateur comme un citoyen de première classe sera utilisé de manière fluide. Un logiciel qui garde l'écran comme sa seule porte sera toujours utilisé, à travers un trou de serrure, par un agent portant un costume, jusqu'à ce que ses propriétaires se lassent du costume et passent à autre chose.

Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.