Avertissement : Ce contenu a été traduit automatiquement. Envoyer un feedback

L'utilisateur headless

16 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

Quand l'utilisateur principal d'un logiciel d'entreprise devient un agent IA, le cadre principal-agent de Jensen et Meckling (1976) cesse d'être une métaphore. La classe des vérificateurs qui émerge en face est la prochaine anomalie de valorisation du marché du travail.

De l’utilisateur-personne à l’utilisateur-agent : la requalification qui redessine le logiciel et le travail

Mi-avril 2026, Salesforce a annoncé Headless 360 à TDX : une restructuration de la plateforme autour d’API, d’outils Model Context Protocol et d’interfaces en ligne de commande (Salesforce; VentureBeat). Ce n’était pas un refresh UX. C’était la reconnaissance d’un fait : l’utilisateur principal du logiciel d’entreprise n’est plus un humain.

Le choix des mots compte. Une décennie d’orthodoxie design a fait de "user" un synonyme de "personne". Les personas avaient des noms, des photos, des objectifs ; les design sprints commençaient par des empathy maps ; les wireframes imaginaient le mouvement des yeux sur un écran. Headless 360 ne raffine pas cette orthodoxie. Il la dissocie. Le navigateur devient une surface legacy. La vue tableur devient l’une des nombreuses sorties, et non plus la sortie. L’écran devient optionnel.

La presse spécialisée a lu le basculement aussi clairement que Salesforce. VentureBeat a décrit le lancement comme une infrastructure pour les agents IA, tandis que PPC.land y voyait une évolution qui retire au navigateur son statut d’interface obligatoire (VentureBeat; PPC.land). Salesforce a expliqué que le lancement incluait plus de soixante outils MCP et plus de trente coding skills, en plus d’un ensemble plus large de surfaces destinées aux agents (Salesforce). C’est l’ampleur d’un pivot de plateforme, pas d’une simple release produit.

Le déplacement est visible ailleurs dans la couche tooling. The New Stack a observé ce mois-ci que Cursor, Claude Code et Codex d’OpenAI sont en train de "fusionner en une AI coding stack que personne n’avait prévue" (The New Stack). Les plateformes voisines ajoutent elles aussi leurs propres couches de construction d’agents, comme le montre clairement la documentation Rovo d’Atlassian (Atlassian). Tous ces produits supposent un opérateur capable de lire, d’éditer et de faire confiance à des artefacts générés sans les inspecter ligne par ligne. L’artefact n’est plus le dashboard. L’artefact, c’est le comportement.

Ce qui est en train de se produire n’est pas un pas de plus dans l’expérience utilisateur. C’est une redésignation de qui est l’utilisateur. Pendant trois décennies, le logiciel d’entreprise a traité l’humain comme le principal : l’entité dont l’attention, l’approbation et l’erreur constituaient la boucle de feedback du système. L’humain cliquait ; le logiciel répondait. La boucle était serrée parce que la latence entre l’intention et l’entrée était faible. Les éditeurs ont optimisé chaque centimètre de cette boucle : formulaires plus rapides, moins de clics, dashboards plus jolis.

Cette boucle se casse. Non pas parce que l’humain disparaît. L’humain reste la source de l’intention, le propriétaire du compte, celui qui paie la facture. Mais l’humain n’est plus l’entité à la console. Quelque chose d’autre l’est. Ça tape. Ça fait des appels API. Ça opère le logiciel.

Appeler cette chose un "user" met le mot sous tension. Plus précisément, c’est un agent qui agit au nom d’un utilisateur. Et la distance entre les deux, entre principal et agent, c’est là que s’ouvre le nouveau terrain.

L’interface qui disparaît

La trajectoire avait été amorcée depuis longtemps. Dans Lenny's Newsletter, Marc Andreessen a décrit le langage naturel comme la prochaine couche d’abstraction au-dessus des langages de plus haut niveau, après que le code machine et l’assembleur ont cédé la place à C et Python (Lenny's Newsletter). Andrej Karpathy, passé par Tesla et OpenAI, a formalisé le mouvement le plus récent avec sa taxonomie Software 1.0, 2.0 et 3.0, dans laquelle les prompts en anglais deviennent une façon de programmer les LLM (Y Combinator podcast). Chaque couche a rendu l’ordinateur accessible à une population plus large, tout en rendant obsolète une population plus étroite.

Guillermo Rauch, fondateur de Vercel, a formulé l’implication de façon directe dans le même podcast : beaucoup de jobs de programmation autrefois spécialisés deviennent des tâches de traduction, surtout de l’intention ou du design vers l’implémentation (Lenny's Newsletter). La traduction, du design vers le code, de la policy vers la configuration, de la spécification vers le schéma, a constitué la couche intermédiaire du travail logiciel white-collar pendant deux générations. Ce que dit Rauch, ce n’est pas que la programmation disparaît. C’est que les traducteurs disparaissent.

Headless 360 est la version enterprise du même mouvement, et ce n’est pas un cas isolé. Sur la même période, Oracle, SAP, Workday, et ServiceNow ont chacun lancé un virage parallèle vers des plateformes agentiques. Le navigateur était une couche de traduction : l’intention humaine exprimée via des clics sur des formulaires qui écrivaient dans des tables via du middleware qui appelait des API. Supprime le navigateur, et la chaîne se contracte : l’intention se mappe directement à l’appel API, l’agent faisant la traduction. L’administrateur qui savait cliquer à travers dix-sept écrans pour configurer une règle de conformité perd le moat que ces écrans lui offraient. Le spécialiste des opérations qui avait mémorisé l’ordre des cases à cocher le perd aussi. Tout comme le formateur qui apprenait aux nouvelles recrues le chemin de clic.

Qu’est-ce qui remplace ces moats ? Pas de nouveaux moats au même étage. L’étage lui-même est en train de se dissoudre. À sa place s’installent un autre ensemble d’artefacts (le system prompt, le schéma d’outil, l’evaluation harness) et un autre ensemble de praticiens capables de les produire. Anthropic, OpenAI et Salesforce livrent chacun, à leur manière, les primitives de cette couche de remplacement (Anthropic MCP docs; OpenAI function calling; Salesforce).

La chose contre-intuitive, avec une interface qui disparaît, c’est que le travail ne disparaît pas avec elle. Il se déplace. Il faut toujours quelqu’un pour décider ce que signifie la règle de conformité, quelles exceptions sont acceptables, et ce qui doit se passer quand la proposition de l’agent arrive à la frontière de la policy. Cette personne ne clique plus. Elle relit, de plus en plus.

La question, c’est comment l’appeler.

Le problème principal-agent, version machine

La littérature économique a un cadre vieux de cinquante ans pour décrire exactement cette situation. En 1973, Stephen Ross a publié un article introduisant ce qu’il appelait le problème du principal : une situation dans laquelle une partie délègue une action à une autre et où l’agent détient une information privée que le principal ne peut pas observer complètement (Ross 1973). Trois ans plus tard, Michael Jensen et William Meckling ont formalisé ce cadre dans Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, en définissant les agency costs comme la somme des dépenses de monitoring du principal, des dépenses de bonding de l’agent et de la residual loss (Jensen and Meckling 1976). L’écart entre ce que voulait le principal et ce que livrait l’agent est toute la logique du cadre.

Pendant un demi-siècle, ce cadre a été appliqué à des agents humains. Les actionnaires déléguaient aux dirigeants. Les clients déléguaient aux avocats. Les patients déléguaient aux médecins. Chaque raffinement de la théorie (rémunération liée à la performance, droit fiduciaire, comités d’audit, règles d’indépendance des conseils) visait à réduire la residual loss en remodelant le monitoring.

En 2026, le cadre s’applique avec une franchise inhabituelle. Le logiciel n’a ni intérêt propre ni devoir fiduciaire, donc l’analogie n’est pas parfaite, mais les hypothèses structurelles se transposent suffisamment bien pour que les catégories de coûts s’alignent presque sans effort. Deux articles récents en management, Humberd and Latham (2026) dans le Journal of Management Studies et Jarrahi and Ritala (2025) dans le California Management Review, font le même déplacement indépendamment l’un de l’autre : traiter l’IA comme un nouveau type d’agent dans l’entreprise et demander à quoi ressemblent monitoring et bonding quand l’agent est du software.

L’information privée, dans le cadre original, c’était la connaissance supérieure de l’agent sur des conditions que le principal ne pouvait pas observer. Dans la version machine, l’information privée, c’est le raisonnement interne du modèle : la chaîne d’activations qui a produit la sortie, impossible à inspecter depuis la surface API. La divergence d’intérêts, dans l’original, c’était l’agent poursuivant son propre gain au détriment du principal. Dans la version machine, c’est l’objectif d’entraînement qui diverge de l’intention de l’utilisateur : le modèle optimise une sortie plausible plutôt qu’une sortie correcte, l’apparence d’utilité plutôt que la substance. Le coût de monitoring, dans l’original, c’était le prix de l’audit des actions de l’agent. Dans la version machine, c’est le coût de vérification des sorties du modèle à l’échelle de la production, un coût qui scale avec le volume de sorties plutôt qu’avec l’importance de la tâche. La residual loss, dans l’original, était l’écart entre le résultat voulu et le résultat obtenu. Dans la version machine, c’est l’hallucination, le scope drift, l’échec silencieux : toute la taxonomie d’erreurs qu’un principal peut ne jamais détecter.

La théorie anticipait déjà chacune des dynamiques que les équipes qui déploient des agents sont en train de redécouvrir. Ce qu’elle n’anticipait pas, c’était l’échelle. Un avocat humain produit un document à la fois. Un dirigeant humain prend une décision à la fois. Monitorer ce volume est coûteux mais borné. Un agent logiciel produit des documents, des décisions et des effets de bord à un rythme qu’aucun principal ne peut auditer par défaut. Le coût de monitoring, dans le cadre classique, relevait de la diligence. Dans l’édition machine, il relève de la capacité.

Or cette capacité, là où elle existe, est concentrée entre les mains d’un petit groupe encore sans nom. Ce sont eux le bottleneck. Ce sont eux, même si personne ne l’a encore formulé ainsi, une classe.

La classe des vérificateurs

Alexander Embiricos, de l’équipe Codex d’OpenAI, a décrit le bottleneck actuel comme relevant davantage de la validation humaine et de la code review que de la génération brute de code (Lenny's Newsletter). Embiricos parlait d’un workflow précis (des agents de code asynchrones qui se lancent, produisent des changements puis reviennent pour validation), mais le diagnostic se généralise. D’un domaine à l’autre, l’étape qui décide si la sortie d’un agent entre en production est le passage humain qui vient juste après.

Ce passage est plus difficile qu’il n’en a l’air. Hamel Husain et Shreya Shankar, chercheurs en AI evals, soutiennent que les critères d’évaluation changent à mesure qu’on inspecte davantage de sorties, ce qui signifie que la grille ne peut pas être entièrement figée à l’avance (Lenny's Newsletter). Le vérificateur ne compare pas seulement le travail de l’agent à une spécification ; il construit la spécification en temps réel, en réponse à la distribution de sorties que l’agent produit effectivement. Dans ce régime, l’évaluation n’est pas l’application d’une simple suite de tests. C’est l’invention d’une suite de tests sous contrainte.

Concrètement, cela ressemble à un plancher de défauts que le générateur introduit de manière fiable et à un plafond de capacité de review que le vérificateur peut fournir de manière fiable, avec un écart qui se creuse à mesure que l’usage scale. Le plancher est mesurable : la mise à jour Spring 2026 de Veracode a trouvé que 55 % des tâches de génération de code IA testées étaient sûres, ce qui implique un taux d’environ 45 % de failles de sécurité connues sur l’ensemble benchmarké (Veracode). Une discussion Y Combinator sur sa cohorte W25, rapportée par TechCrunch, indiquait qu’environ un quart de la batch avait des codebases générées à 95 % par l’IA (TechCrunch). Une génération à haut volume qui finit en production avec une review légère n’est pas une prédiction. C’est déjà courant.

Rien de tout cela n’est propre au code. Le schéma se répète dans la review juridique, dans la prise de notes médicales, dans l’analyse financière, dans le copy marketing. Dans chaque domaine, l’agent produit en volume ; un humain contrôle ; le contrôleur est la contrainte. Le détail métier change. La forme du rôle, non.

Ce rôle n’a pas de titre. Il n’a pas de carrière type. Il n’apparaît sur aucun organigramme. Pour l’instant, il est rempli par les personnes qui se trouvent à proximité : l’ingénieur senior censé écrire des features, l’avocat staff censé conseiller des clients, le lead designer censé créer. Leur job explicite est autre chose. Leur vrai job consiste à relire ce qu’un agent a produit et à décider si cela part en prod.

Ils forment la classe des vérificateurs. Le nom est nouveau ; la fonction ne l’est pas. Mais les conditions, si.

Ce qui distingue un vérificateur d’un reviewer, d’un éditeur, d’un auditeur ou d’un approbateur, ce n’est pas l’acte de review. C’est la coïncidence de trois conditions.

La file amont n’a pas de plafond : la sortie est produite par un système dont le débit scale avec la dépense API, pas avec les heures de travail d’un autre humain. Le débit du vérificateur, lui, ne scale pas : il reste borné par la bande passante cognitive humaine. Et la grille est émergente : comme l’expliquent Husain et Shankar, elle doit se former en réponse à la distribution de sorties que le système produit réellement, pas être définie à l’avance.

Les éditeurs et les auditeurs remplissent une ou deux de ces conditions. Le vérificateur remplit les trois en même temps. Voilà le cœur économique du rôle.

La question de la distribution

Le récit dominant sur l’effet de l’IA sur le travail s’est concentré sur la substitution : les systèmes génératifs comprimeraient le milieu de la distribution des compétences, rendraient redondants les knowledge workers intermédiaires et concentreraient les gains chez les détenteurs du capital et les talents de frontière. Ce récit suppose un cas sans friction : un agent qui shippe sa propre sortie sans review.

La vérification change la forme du problème. Contrairement à la génération, la vérification est très dépendante du domaine. Un agent généraliste peut rédiger une demande de brevet, un compte rendu de radiologie, un communiqué de résultats trimestriels et une approbation de prêt. Le vérificateur de chacun doit posséder respectivement la connaissance d’un avocat en brevets, d’un radiologue, d’un contrôleur financier et d’un chargé de crédit. Cette connaissance n’est pas transférable. Elle ne se synthétise pas rapidement. Elle s’acquiert par des années de formation spécifique dans un contexte spécifique, et c’est la chose la plus difficile à externaliser.

La conséquence contre-intuitive, c’est que la vérification peut re-localiser certaines formes d’expertise. L’offshoring, dans les décennies précédentes, reposait sur le fait que l’exécution pouvait être découplée du contexte : la spécification était écrite une fois, dans le pays source, puis exécutée de nombreuses fois ailleurs. La vérification, elle, ne peut pas être découplée. Chaque sortie appelle un jugement neuf. Et chaque jugement exige le contexte que l’agent n’a pas fourni.

Le rapport State of the Designer 2026 de Figma, une enquête menée auprès de 906 designers digitaux avec NewtonX, documente un remodelage brutal du rôle lui-même (Figma report; Figma blog). Le travail d’exécution (produire des mockups, des wireframes, des prototypes) a vu son coût s’effondrer, tandis que le travail de jugement (sélectionner, curer, diriger éditorialement les options générées) est devenu la contrainte déterminante dans la description qu’en donnent les répondants. Dans un autre post centré sur le recrutement, Figma soutient que l’IA augmente la demande de designers, en particulier les seniors dotés de plus d’expérience et de meilleur jugement (Figma hiring post). Ces deux affirmations sont à des niveaux différents. L’une décrit ce que les designers racontent de leur propre travail ; l’autre la manière dont Figma l’interprète pour ses clients enterprise. Elles pointent pourtant dans la même direction. Le titre du poste n’a pas changé. Le job, lui, oui.

Dans son interview de février 2026 chez Lenny Rachitsky, Lazar Jovanovic de Lovable a décrit la compétence de remplacement comme étant la clarté, le goût, le jugement et une meilleure prise de décision plutôt que la vitesse brute de coding (Lenny's Newsletter). La clarté, ici, c’est la capacité à spécifier une intention que l’agent ne pourra pas mal interpréter, et à reconnaître quand il l’a fait. C’est exactement le même mouvement cognitif que demande la vérification, formulé depuis l’autre côté.

Ces observations pointent dans une seule direction. Le marché du travail ne s’aplatit pas vers une petite élite de frontière. Il se stratifie selon un nouvel axe (générateur contre vérificateur) qui traverse les rôles existants. La position à plus fort levier est celle du vérificateur dans un domaine important, avec le contexte qu’on ne peut pas facilement scripter et le jugement qu’on ne peut pas facilement automatiser. La rémunération suivra. La friction au recrutement aussi : le nombre de personnes capables de générer à l’échelle explose ; le nombre de personnes capables de vérifier à l’échelle n’explose pas.

Cette asymétrie est la prochaine anomalie de valorisation du marché du travail.

Les deux interfaces

Tous les produits logiciels construits dans les cinq prochaines années porteront deux interfaces, que leurs designers les nomment ou non.

La première est l’interface protocolaire : la surface par laquelle les agents opèrent le système. Ses primitives sont l’endpoint API, la définition d’outil MCP, la commande CLI, le périmètre d’autorisation, la rate limit. Sa discipline de design est la lisibilité pour un modèle : un naming qui résiste à l’ambiguïté, des schémas qui fail closed, une documentation suffisamment dense pour être récupérée mais suffisamment structurée pour permettre la sélection d’outils. Headless 360 de Salesforce est une première déclaration publique de ce à quoi ressemble cette interface à l’échelle enterprise, tandis que le Model Context Protocol d’Anthropic et les spécifications de tool use d’OpenAI font partie de l’infrastructure de l’écosystème qui l’entoure (Salesforce; Anthropic MCP docs; OpenAI function calling).

La seconde est l’interface de jugement : la surface par laquelle un vérificateur relit, approuve, amende ou rejette ce que l’agent a fait. Ses primitives sont le diff, le rollback, la trace, la chaîne d’attribution, la file d’approbation. Sa discipline de design n’est pas la lisibilité pour un modèle, mais la lisibilité pour un expert métier qui travaille sous pression temporelle. Que s’est-il passé ? Pourquoi ? Qu’est-ce qui change si on le laisse passer ? Qu’est-ce qui casse si on l’inverse ? Une interface de jugement bien conçue permet à un expert métier de confirmer rapidement une sortie assistée par IA ; une mauvaise l’oblige à refaire le travail à la main et efface le gain d’efficacité que l’agent était censé apporter.

Aujourd’hui, la plupart des entreprises construisent agressivement la première interface et presque pas du tout la seconde. La surface protocolaire a une roadmap, une équipe dédiée et l’attention du board. La surface de jugement hérite d’un admin panel bricolé, d’un export CSV ou, de plus en plus, de rien du tout, au motif que l’agent serait "assez bon" pour shipper sans review. Chaque vérificateur qui travaille aujourd’hui depuis un ticketing system démontre le contraire.

Voici une prévision falsifiable : d’ici fin 2028, je m’attends à ce que la plupart des grands éditeurs enterprise livrent une interface de jugement nommée et traitée comme une primitive de premier rang. La force qui les y contraindra ne sera pas la théorie de l’agence, mais la procurement. Quand les premiers contrats de l’ère agentique arriveront à renouvellement, la question de l’épuisement des vérificateurs sera difficile à traiter sans surface dédiée.

Le déplacement plus profond est plus ancien que n’importe laquelle de ces technologies. Le cadre de 1976 de Jensen et Meckling quitte les départements d’économie pour entrer dans les roadmaps produit. Les monitoring costs qu’ils avaient modélisés deviennent des lignes budgétaires UX. La residual loss qu’ils avaient nommée devient une métrique trimestrielle. La théorie de l’agence, pendant cinq décennies langage de la gouvernance d’entreprise, devient langage du design logiciel.

Quand l’utilisateur est un agent, le client est un vérificateur. La distinction n’est pas rhétorique. C’est la forme que prendra la prochaine décennie du logiciel enterprise, et du marché du travail qui le fait tourner. Les produits et les carrières qui comprennent cela vont composer. Les autres continueront d’optimiser pour un principal qui a déjà quitté l’écran.

Sources