Donner à un agent Hermes l’accès à HubSpot

Pourquoi le jeton ne doit pas vivre dans l’agent

Hermes Agent, l’agent open source de Nous Research, sait très bien dialoguer avec HubSpot. La question est de savoir où va l’identifiant. Dans une installation auto-hébergée, le jeton HubSpot finit dans un fichier .env ou dans config.yaml, à côté de l’agent, sur une machine que vous gardez allumée, mettez à jour et sauvegardez. Quiconque, ou quoi que ce soit, qui peut lire cette configuration, y compris l’agent lui-même sous un prompt malveillant, peut lire le jeton.

Sur Atako, l’identifiant reste hors de ce tableau. Vous connectez HubSpot une fois, au niveau de l’entreprise. Le jeton est stocké côté serveur et injecté au moment où l’appel part. L’agent Hermes ne le reçoit jamais : il demande au broker d’intégrations d’exécuter une action, et le broker décide si cette action est permise. Le même mécanisme couvre tous les connecteurs du catalogue ; ce que vous apprenez ici vaut donc pour le suivant.

Ce qu’il vous faut avant de commencer

Il vous faut un compte HubSpot où vous pouvez créer une private app, ce qui demande en général les droits de super admin, et un agent Atako qui tourne sur le harnais Hermes. Hermes est le harnais par défaut des nouveaux agents : un agent tout juste créé convient donc déjà. Si vous hésitez encore sur le harnais, la page pilier sur les agents autonomes explique comment un agent fonctionne sur la plateforme.

Créer le jeton avec les scopes les plus étroits

Une private app HubSpot émet un jeton lié à une liste fixe de scopes. Cette liste est votre premier plafond : même si vous accordez plus tard davantage dans Atako, HubSpot refusera ce que le jeton ne couvre pas. Partez de ce que l’agent fera réellement. Un agent qui qualifie des leads doit lire les contacts et écrire des notes et des tâches. Un agent de reporting n’a besoin que de lire les deals et les pipelines. N’ajoutez le scope de création de propriétés que si vous voulez que l’agent crée des propriétés personnalisées, et le scope content que s’il doit préparer des e-mails marketing.

Traitez le jeton comme un mot de passe. Collez-le dans Atako et nulle part ailleurs : ni dans une conversation avec l’agent, ni dans un document que l’agent peut lire. Une fois connecté, vous n’avez plus besoin de le revoir.

Connecter une fois, accorder par agent

Connecter HubSpot dans Atako est une action au niveau de l’entreprise, faite depuis le catalogue d’intégrations. Elle rend HubSpot disponible, mais ne donne aucun droit à aucun agent. Les droits viennent de l’accès que vous créez sur chaque agent.

Cet accès fonctionne en deux couches. Vous choisissez d’abord un niveau avec les puces Lecture et Écriture. Vous cochez ensuite les endpoints un par un. Un agent qui résume le pipeline reçoit search_deals et list_pipelines, rien d’autre. Un agent qui consigne l’issue des appels reçoit update_deal et create_note. C’est plus proche du moindre privilège qu’une clé d’API unique du tout ou rien, et c’est facile à relire : la liste des endpoints cochés est la liste de ce que l’agent peut faire.

Parler à l’agent

Une fois l’accès créé, vous n’écrivez aucune configuration d’outil. Vous décrivez le travail en langage courant : trouve les contacts créés depuis lundi, vérifie lesquels appartiennent à une entreprise existante et ajoute une note sur ceux qui correspondent à notre profil idéal. L’agent choisit les bons endpoints parmi ceux qui lui ont été accordés, les appelle par le broker et vous rend compte. Un endpoint non accordé ne peut simplement pas être appelé, et c’est à vous de décider d’élargir l’accès.

Comme un agent Hermes tourne aussi sur planning, le même accès sert les tâches récurrentes. Un résumé hebdomadaire du pipeline ou une vérification quotidienne des deals qui stagnent utilise exactement les droits que vous avez déjà définis.

Garder un œil sur ce qui se passe

Chaque appel qui passe par le broker est enregistré : quel outil, quel statut, quel code HTTP, combien de temps. L’enregistrement est visible sur l’agent et dans le dashboard de l’entreprise, dans la vue d’usage des intégrations et dans le journal des intégrations. C’est votre piste d’audit. Quand un commercial demande pourquoi un deal a changé d’étape, vous ouvrez le journal et vous voyez l’appel, au lieu de deviner à partir du seul historique du CRM.

Le journal aide aussi à ajuster les droits. Si un agent tente à répétition un endpoint qui ne lui a pas été accordé, c’est un signal : soit la tâche en a besoin et vous l’ajoutez en connaissance de cause, soit l’agent dérive et c’est le prompt qu’il faut retravailler.

Ce que cette configuration ne fait pas

L’accès sélectionne des endpoints. Il ne restreint pas les enregistrements qu’un endpoint peut toucher : un agent autorisé à appeler update_deal peut modifier n’importe quel deal que le jeton atteint. Si vous voulez une frontière plus serrée, créez la Private App avec moins de scopes, ou gardez les écritures sensibles derrière une étape humaine. Demandez par exemple à l’agent de proposer d’abord le changement dans la conversation, puis de l’appliquer après votre confirmation.

Pour le côté HubSpot du connecteur, avec toutes les actions qu’il expose, consultez la page de l’intégration HubSpot. Pour des workflows commerciaux concrets, le cas d’usage RevOps montre ce que fait un agent une fois l’accès en place, et le cas d’usage opérations marketing couvre le versant campagnes.