Une proposition de loi ferait de votre agent IA un fiduciaire, et casserait le modèle économique que tout le monde présuppose

25 août 2026
12 min de lecture

25 août 2026
12 min de lecture
Une proposition de loi dort à la commission du Commerce du Sénat américain, et elle changerait ce que signifie construire un agent. Presque tout ce qui s'en écrit porte sur la mauvaise moitié.
L'AI AGENT Act — la S.5051, portée par le sénateur Mark Warner et déposée le 21 juillet 2026 — est lue comme un texte d'interopérabilité. C'est la moitié qui fait les titres : les grandes plateformes devraient laisser entrer les agents tiers autorisés et les traiter comme elles traitent un utilisateur humain.
Cette moitié est une bonne nouvelle pour les fondateurs, et j'y reviendrai. Mais ce n'est pas celle qui devrait changer ce que vous construisez ce trimestre.
Le mécanisme repose sur une catégorie juridique nouvelle : l'agent dépositaire de l'utilisateur. C'est l'agent qu'un consommateur désigne pour agir en son nom — acheter, gérer des comptes, modifier des réglages, administrer des contenus — sur une plateforme couverte.
« Plateforme couverte » veut dire grande : plus de 50 millions de clients ou d'abonnés américains sur un mois quelconque des douze précédents. Réseaux sociaux, places de marché, fintech, communications, fournisseurs d'IA.
Deux obligations en découlent, et elles pointent dans des directions opposées.
Le marché, énoncé sans détour
Ce que la plateforme doit à l'agent
L'application revient à la FTC, qui gérerait l'enregistrement et la radiation et engagerait les poursuites, avec des sanctions pouvant être calculées par utilisateur affecté. Le NIST élaborerait les normes d'interopérabilité.
Jusqu'ici, cela se lit comme un texte de concurrence, ce que son titre officiel dit exactement : une loi visant à promouvoir la concurrence et à réduire les coûts de changement pour les consommateurs dans la fourniture de services en ligne. Le mot « IA » ne figure pas dans ce titre.
Voici ce que doit l'opérateur de l'agent, dans le registre du texte lui-même. Un agent dépositaire de l'utilisateur doit protéger les données de l'utilisateur, éviter l'auto-favoritisme, éviter tout dommage prévisible à l'utilisateur, conserver la trace de ce qu'il a fait, et exercer :
le soin, la compétence et la diligence que l'on pourrait raisonnablement attendre d'une personne ordinairement prudente.
Relisez cette phrase avec une oreille de juriste. Devoir de diligence. Devoir de loyauté. Un critère de personne prudente. Ce ne sont pas des exigences de conformité logicielle. C'est un critère fiduciaire, et c'est le vocabulaire qui régit les fiduciaires, les conseillers financiers et les dirigeants de société.
Rien d'autre dans la tech grand public ne fonctionne ainsi. Votre CRM ne doit aucune loyauté à votre client. Votre moteur de recommandation a le droit de préférer vos intérêts. Un agent qui détient une délégation d'un utilisateur, sous ce texte, ne l'aurait pas.
Pourquoi le volet fiduciaire est la partie porteuse
Les règles d'interopérabilité changent ce que vous avez le droit de construire. Un devoir de loyauté change qui vous avez le droit d'être en le construisant. La première question est une affaire d'accès au marché que vos juristes traitent après le lancement ; la seconde est une question d'architecture et de modèle économique, très coûteuse à rattraper, parce qu'elle détermine ce que votre agent a le droit d'optimiser.
Le texte interdit aussi à un agent dépositaire d'utiliser, de partager ou de conserver les données de l'utilisateur à des fins publicitaires, de profilage comportemental ou pour d'autres finalités commerciales secondaires sans rapport.
Mettez cela à côté du devoir de non-auto-favoritisme et regardez quels modèles économiques viennent de mourir :
Le point inconfortable : les deux premiers sont exactement ce que visent la plupart des startups d'agents grand public, parce que c'est ce qui a marché lors du basculement de plateforme précédent. Ce texte les traite comme le conflit d'intérêts qu'ils sont structurellement.
Voilà pourquoi je ne classerais pas ce sujet sous « suivre la politique ».
L'Agent Payments Protocol (AP2) de Google — annoncé en septembre 2025 avec plus de 60 partenaires de lancement, dont Mastercard, PayPal, Coinbase, American Express et Salesforce, et en version v0.2 depuis avril 2026 — résout le même problème par la cryptographie plutôt que par la loi.
L'unité d'AP2 est le mandat, et il y en a trois : Intent, Cart et Payment. Chacun est une attestation vérifiable W3C portant un émetteur, un sujet, une charge utile et une signature. Ensemble, ils donnent au marchand un enregistrement vérifiable de ce que l'utilisateur a autorisé, de ce que l'agent a sélectionné et de ce qui a été facturé. Le protocole se place délibérément entre la couche de raisonnement de l'agent — MCP, A2A — et les réseaux de paiement.
Placez maintenant AP2 à côté de la description que le texte donne de l'agent dépositaire : transparent, documenté, borné, révocable, avec des enregistrements tenus en temps réel.
C'est la même exigence, écrite par des gens différents pour des raisons différentes. Et c'est la troisième fois en deux semaines que la même forme apparaît : la feuille de route 2026 de MCP construit la délégation via ID-JAG et l'échange de jetons de la RFC 8693 précisément pour qu'un sous-agent reçoive une autorité plus étroite que son parent, l'octroi lui-même faisant office d'artefact.
Que trois systèmes indépendants — un consortium de paiement, un groupe de travail de protocole et une commission sénatoriale — convergent sur « l'autorisation doit être un objet signé, borné et révocable » est un signal bien plus fort que l'adoption de l'un d'eux. Cela veut dire que l'exigence est découverte, et non imposée.
Il y a une seconde raison pour laquelle cela compte maintenant, et c'est l'affaire que nous avons traitée au début du mois : la manière dont le Neuvième Circuit a traité un agent agissant avec les identifiants de l'utilisateur lui-même, où ce qui comptait était l'autorisation de l'utilisateur et non celle de l'opérateur.
Rapprochez les deux et une direction se dessine. Les tribunaux s'orientent vers c'est l'autorisation de l'utilisateur qui compte. Ce texte reprendrait ce principe pour le rendre positif — les plateformes doivent l'honorer — en y attachant le devoir qui rend cet honneur sûr.
C'est un règlement cohérent, et c'est à peu près le seul disponible. Si un agent peut agir avec votre autorité, quelqu'un doit répondre de ce qu'il en fait. La réponse du texte : l'opérateur, envers l'utilisateur, en qualité de fiduciaire.
Rien de tout cela n'exige que le texte soit adopté. Tout cela est ce dont vous aurez besoin de toute façon la première fois qu'un client, un prestataire de paiement ou un tribunal demandera ce que votre agent avait le droit de faire.
Le champ du périmètre est celui qu'on saute, et c'est celui qui travaille. « L'utilisateur s'est connecté » n'est pas un périmètre. « L'utilisateur a autorisé des achats jusqu'à 200 dollars dans cette catégorie de marchands jusqu'à vendredi » en est un, et c'est la différence entre un journal qui enregistre ce qui s'est passé et un registre qui établit si c'était permis.
Je veux être prudent ici, car il serait facile de lire ce qui précède comme l'annonce d'une échéance imminente.
Elle ne l'est pas. La S.5051 a été déposée le 21 juillet 2026, lue deux fois puis renvoyée à la commission du Commerce, des Sciences et des Transports, et n'a pas bougé depuis. Elle compte un seul signataire et aucun cosignataire. Elle est issue d'un projet de discussion publié fin juin. La plupart des textes de ce profil ne deviennent jamais des lois, et ceux qui y parviennent arrivent en général des années plus tard sous une forme sensiblement différente.
Donc : ne montez pas un programme de conformité contre la S.5051. Ne dites pas à votre conseil que la réglementation des agents est imminente, car en l'état des faits elle ne l'est pas.
Ce à quoi ce texte sert vraiment, c'est de spécification de la question. Quelqu'un s'est assis pour écrire ce que devrait signifier juridiquement le fait qu'un logiciel agisse au nom d'une personne, et a abouti à transparent, documenté, borné, révocable, avec un devoir de loyauté attaché. C'est une réponse sérieuse, elle rejoint ce que les réseaux de paiement ont construit volontairement, et elle rejoint la direction prise par la couche protocolaire. La convergence est le signal. Le texte n'en est que la formulation écrite la plus claire.
L'AI AGENT Act est discuté comme un bras de fer d'interopérabilité entre startups d'agents et grandes plateformes, et sur cet axe c'est un texte qu'on peut souhaiter : accès aux mêmes conditions qu'un utilisateur, refus à justifier, une FTC à saisir.
La partie qui devrait changer ce que vous construisez, c'est le prix attaché. Un agent dépositaire devrait à son utilisateur un devoir de diligence et un devoir de loyauté, ne pourrait pas monétiser ce qu'il voit, et devrait tenir en temps réel le registre de ce qu'il a fait de l'autorité reçue. C'est un fiduciaire, et c'est incompatible avec les modèles publicitaires et de placement que la plupart des sociétés d'agents grand public présupposent discrètement.
Le texte a un seul signataire et n'a pas bougé depuis cinq semaines. L'exigence qu'il décrit a déjà été mise en œuvre deux fois — une par un consortium de paiement, une par un groupe de travail de protocole — par des gens qui ne l'attendaient pas.
Construisez le registre d'autorisation. Décidez qui vous paie, et sachez le dire à voix haute.
Sources : S.5051, AI AGENT Act de 2026 — état du texte sur Congress.gov · Données d'état de la S.5051, GovInfo · Davis Wright Tremaine, « The Federal AI AGENT Act: Consumer Protection in AI Clothing? » · Le sénateur Warner sur le projet de discussion · Annonce de l'Agent Payments Protocol (AP2), Google Cloud · Documentation du protocole AP2
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.