Agents IA : qui contrôle le droit d’agir, des super-apps à Hermès Agent ?

« Modifie cette commande et préviens le client. » La phrase tient en une ligne. Pour l’exécuter, un agent doit retrouver la commande, vérifier qui peut la modifier, connaître le stock, puis obtenir le droit d’envoyer un message. Un meilleur modèle peut comprendre la demande sans posséder aucun de ces accès.

Le droit d’agir d’un agent IA est le périmètre d’actions qu’une entreprise et ses fournisseurs l’autorisent réellement à exécuter. Il dépend de l’identité utilisée, des connexions aux outils, des permissions et des validations requises. La qualité du modèle compte ; elle ne remplace pas cette chaîne d’autorisation.

Le contraste entre super-apps chinoises et services plus fragmentés aux États-Unis aide à comprendre cet enjeu. Il éclaire aussi l’intérêt d’Hermès Agent, le framework open source de Nous Research : une couche opératrice que l’on peut organiser autour de ses outils métier, sans confondre indépendance technique et accès illimité.

Super-apps ou outils séparés : où se trouve la friction ?

Sur un parcours fragmenté, le commerce, le paiement, la messagerie et l’identité peuvent dépendre de services distincts. Chaque passage impose une connexion, une règle d’accès ou une vérification. Relier ces étapes crée du travail pour les intégrateurs et les fournisseurs d’infrastructures destinées aux agents.

Une super-app rapproche plusieurs de ces fonctions dans un même environnement. Cela peut faciliter le parcours de ses utilisateurs et celui des partenaires autorisés. Mais la plateforme conserve la décision d’ouvrir telle fonction à tel tiers. Un parcours intégré n’est pas nécessairement un parcours ouvert.

Ce contraste est un modèle de lecture, pas une carte exhaustive de deux pays. Les États-Unis ont aussi des plateformes intégrées ; la Chine compte plusieurs écosystèmes et des agents métier. On ne peut pas en déduire que les agents vont réussir dans un pays et échouer dans l’autre.

Les API existent. Ce sont leurs conditions d’accès qui comptent.

Dire que les super-apps ne proposent pas d’API serait faux. La documentation officielle des Mini Programs Weixin décrit notamment l’authentification avec wx.login et le paiement avec wx.requestPayment. Une API est une interface logicielle permettant à une application d’utiliser une fonction. Sa présence ne donne pas à n’importe quel agent le droit d’en faire usage pour n’importe quel compte.

Le chantier dépasse d’ailleurs cette opposition géographique. Le 30 avril 2025, Visa annonçait Intelligent Commerce, en proposant d’étendre ses infrastructures et standards au commerce par agents. Le 11 septembre 2026, Ant International annonçait le déploiement de son Agentic Mobile Protocol avec des wallets et super-apps, en citant Alipay China parmi les partenaires de première phase.

Ces annonces fournisseurs documentent une direction et un déploiement progressif, pas un paiement autonome universel déjà disponible. Elles montrent surtout que l’action des agents se négocie aussi dans les écosystèmes intégrés. Pour un acheteur, la question utile devient : quels services sont accessibles, à quel acteur et sous quelles garanties ?

Un agent universel et un agent métier n’ont pas le même problème

Un assistant grand public qui doit passer librement d’une application à l’autre dépend de nombreuses plateformes dont il ne maîtrise pas les règles. Un agent métier peut travailler dans un périmètre beaucoup plus précis : les commandes, le CRM et la documentation qu’une entreprise l’autorise à consulter.

Cette distinction change le projet. Une PME n’a pas besoin d’attendre qu’un agent puisse tout faire sur Internet pour lui confier le rapprochement d’un dossier ou la préparation d’une réponse. Elle doit en revanche vérifier que ses logiciels permettent les opérations nécessaires, et qu’elle dispose du droit de les déléguer.

C’est ici qu’un opérateur transverse devient intéressant : il peut coordonner plusieurs outils sans demander à l’entreprise de déplacer tout son travail dans une seule super-app. Chaque connexion reste soumise aux permissions du service concerné.

Ce qu’Hermès Agent apporte concrètement

Connu sous le nom Hermes Agent dans sa documentation officielle, le projet de Nous Research est un framework d’agent, pas un modèle d’IA. Il organise une boucle de travail : recevoir une mission, fournir le contexte au modèle, appeler les outils disponibles, observer leurs résultats et poursuivre ou s’arrêter.

Son intérêt pour une entreprise tient à plusieurs capacités documentées :

• Choisir le modèle séparément de l’opérateur. Plusieurs fournisseurs et des endpoints personnalisés sont pris en charge. Changer de modèle n’impose pas de changer toute l’interface de travail, mais la qualité des missions doit être retestée.
• Travailler depuis plusieurs surfaces. Le terminal et des messageries comme Telegram, Slack ou WhatsApp peuvent servir d’accès à l’agent, selon la configuration. La messagerie reçoit la consigne ; les outils connectés réalisent les opérations.
• Conserver du contexte. La mémoire persistante et la recherche dans les sessions peuvent éviter de repartir de zéro. Elles ne constituent pas, à elles seules, une base documentaire officielle validée par l’entreprise.
• Réutiliser des procédures. Les « skills » sont des instructions réutilisables que l’agent peut créer et améliorer à partir du travail effectué. En entreprise, leurs changements doivent être relus, testés et approuvés selon leur impact.

Le dépôt public de Nous Research décrit ces mécanismes, les outils et les extensions. La boucle d’amélioration concerne notamment les procédures et le contexte de travail ; elle ne signifie pas que le modèle se réentraîne tout seul, ni que l’agent doit modifier librement ses règles d’autorisation.

Pour évaluer ce choix sur une mission complète, notre guide d’Hermès Agent en entreprise explique comment les appels d’outils s’enchaînent et à quel moment garder une validation humaine.

Exemple : traiter un changement de commande sans donner tous les pouvoirs

Prenons un scénario illustratif, pas un résultat client mesuré. Une entreprise veut traiter les demandes de changement d’adresse avant expédition. Avec les connexions nécessaires, Hermès pourrait consulter la demande, retrouver la commande, vérifier son statut et préparer la modification ainsi que la réponse au client.

Si le colis est déjà remis au transporteur, la procédure prévoit une escalade. Si l’adresse paraît incohérente, l’agent demande une vérification. L’envoi du message ou la modification effective restent derrière une validation humaine tant que l’entreprise n’a pas explicitement autorisé ces actions dans un périmètre testé.

Le bénéfice recherché est précis : réduire les consultations et ressaisies entre outils. Il ne vient ni du contournement d’une identité client, ni d’un accès obtenu malgré le refus d’une plateforme. Sans connecteur utilisable et sans permission, l’agent doit signaler la limite plutôt que prétendre avoir exécuté l’action.

Pour passer de la proposition à l’exécution, le principe du moindre privilège aide à séparer consultation, modification et envoi. La preuve attendue doit venir de l’outil métier : statut modifié, identifiant d’opération ou confirmation exploitable, pas seulement « c’est fait » dans le chat.

Héberger son agent ne suffit pas à rendre toutes les données locales

Hermès peut fonctionner dans un environnement choisi par l’entreprise. Cela permet de reprendre la main sur une partie de l’exploitation. Mais héberger l’agent sur son serveur ne signifie pas héberger le modèle. Les informations envoyées à un fournisseur de modèle, un service de recherche ou un autre outil distant suivent le circuit de ce prestataire, selon la configuration et les contrats.

Il reste aussi à maintenir les connexions, protéger les accès, installer les correctifs, vérifier les journaux et désigner un responsable des incidents. Un framework ouvert facilite l’inspection et l’adaptation ; il ne garantit ni conformité automatique ni absence de dépendances.

Enfin, une mémoire utile à l’agent peut contenir des hypothèses ou des habitudes périmées. Lorsque plusieurs agents doivent appliquer les mêmes règles commerciales, un Company Brain avec des connaissances d’entreprise gouvernées permet de distinguer la règle approuvée de ce qu’un agent a retenu pendant une conversation.

Les cinq questions à poser avant de déléguer

1. Quelle mission bornée ? Nommer l’opération et les exceptions, pas seulement un rôle vague d’« assistant autonome ».
2. Quels accès réels ? Vérifier les logiciels, les comptes, les données accessibles et les opérations autorisées.
3. Qui valide quoi ? Conserver une approbation sur les paiements, engagements externes et changements sensibles ; fixer les limites avant le test.
4. Quelle preuve et quel arrêt ? Contrôler le résultat dans le système cible et prévoir la révocation des accès si le comportement dérive.
5. Qui entretient le système ? Attribuer la responsabilité des connecteurs, des procédures, des modèles et de la reprise manuelle.

Chez Say Digital, ce cadrage précède le prototype : une mission, des droits limités, des cas d’échec testés et une preuve de résultat. Le déploiement contrôlé vient ensuite, avec mesure des erreurs, du temps de reprise et du gain réellement observé. Les procédures peuvent alors évoluer sans élargir les permissions par défaut.

Vous envisagez Hermès Agent sur vos outils métier ? Échangeons avec Say Digital pour cadrer une première mission testable, ses connexions et ses validations. Le premier objectif n’est pas de donner tous les pouvoirs à l’agent, mais de prouver qu’il peut terminer une tâche utile avec les bons droits.

Sources : documentation officielle Nous Research / Hermes Agent, Weixin, Visa et Ant International, citées dans le texte et consultées pour cette publication. Les capacités décrites dépendent de la configuration ; les annonces fournisseurs ne constituent pas des résultats clients audités.