Mode Agent : comment PWR communique avec le Collector, en toute sécurité
6 min de lecture
Une explication simple de ce qui se passe quand vous choisissez la connexion via Collector local : pourquoi un jeton dédié (X-Collector-Token) plutôt que votre identifiant de connexion habituel, et comment PWR distingue toujours qui lui parle — vous, ou l'agent installé chez vous.
Ce qu'il faut retenir en une phrase
Quand vous choisissez le mode Agent (Collector local) plutôt que la connexion directe, PWR ne parle jamais à votre base de données lui-même : il envoie sa demande à l'agent Collector installé chez vous, et c'est ce dernier qui interroge réellement PostgreSQL avant de renvoyer le résultat.
Pour que cet échange reste fiable et sécurisé, PWR utilise deux identités complètement séparées : votre identifiant de connexion (celui qui prouve que c'est bien vous, l'utilisateur, qui consultez un rapport) et un jeton technique propre au Collector (celui qui prouve que c'est bien votre agent, et pas un tiers, qui répond). Ces deux identités ne se mélangent jamais.
Pourquoi le Collector a besoin de son propre jeton
Le Collector n'est pas une personne : il n'a ni compte, ni mot de passe, ni session de connexion comme un utilisateur qui se connecte à PWR. C'est un petit programme installé sur une machine de votre infrastructure, dont le seul rôle est d'exécuter des requêtes de lecture seule pour le compte de PWR et de renvoyer le résultat.
PWR doit pourtant être certain de deux choses avant d'envoyer la moindre demande : qu'il s'adresse bien à VOTRE agent (et pas à une machine tierce qui se ferait passer pour lui), et que cet agent est toujours autorisé à répondre (le jeton peut être révoqué ou régénéré à tout moment depuis votre espace "Connexions"). C'est exactement le rôle du jeton dédié transmis à chaque appel.
Deux jetons, deux rôles, jamais confondus
Quand vous consultez un rapport dans votre navigateur, votre session PWR (créée à la connexion) prouve au SaaS que c'est bien vous. Ce jeton-là ne quitte jamais les serveurs de PWR : il n'est ni transmis, ni connu du Collector.
Quand PWR a besoin d'une donnée qui vit chez vous (le tableau de bord "Live", l'historique des snapshots, un rapport de comparaison...), il envoie une seconde demande, séparée, vers votre agent Collector — accompagnée cette fois du jeton propre à cet agent, différent pour chaque client et régénérable à volonté.
Résultat : votre session personnelle et l'identité de votre Collector ne se croisent jamais dans le même échange. Un problème sur l'un (session expirée, jeton Collector révoqué) n'affecte jamais la validité de l'autre.
Exemple concret : ouvrir le tableau de bord "Live"
Voici ce qui se passe concrètement, en trois étapes, quand vous ouvrez le tableau de bord temps réel avec une connexion en mode Agent :
1. Votre navigateur demande les données au SaaS PWR, en utilisant votre session personnelle habituelle — exactement comme pour n'importe quelle autre page de l'application.
2. Le SaaS PWR relaie cette demande à votre Collector, en y joignant le jeton dédié à cette connexion précise — jamais votre session personnelle, que le Collector n'a de toute façon aucun moyen de vérifier.
3. Le Collector vérifie ce jeton, interroge votre base PostgreSQL en lecture seule, et renvoie immédiatement le résultat au SaaS, qui l'affiche dans votre tableau de bord.
À aucun moment votre mot de passe, votre session ou vos identifiants personnels ne transitent vers l'agent installé chez vous : celui-ci ne connaît que son propre jeton, généré et affiché une seule fois lors de sa configuration.
Pourquoi ne pas simplement réutiliser le même jeton partout ?
On pourrait imaginer plus simple : un seul jeton pour tout. Ce serait pourtant plus risqué, pour deux raisons.
D'abord, un jeton de session utilisateur est personnel et temporaire (il expire, il peut être renouvelé à chaque connexion) — mal adapté à un agent qui doit rester joignable en continu, parfois pendant des mois, sans qu'un utilisateur ne se reconnecte. À l'inverse, le jeton du Collector est fait pour durer, mais reste révocable indépendamment à tout moment, sans jamais déconnecter les utilisateurs de votre équipe.
Ensuite, séparer les deux limite strictement ce qu'un jeton compromis pourrait faire : si le jeton du Collector fuitait, il ne donnerait accès qu'aux données en lecture seule de cette connexion précise — jamais à votre compte, vos autres connexions, ou aux réglages de votre espace de travail.
Comment PWR sait quel Collector appeler
Chaque connexion en mode Agent enregistre, côté PWR, l'adresse à laquelle joindre votre Collector ainsi que son jeton propre — visibles et modifiables à tout moment depuis "Connexions" > "Configurer l'agent". Régénérer le jeton depuis cet écran invalide immédiatement l'ancien : l'agent déjà installé devra être reconfiguré avec la nouvelle valeur avant de pouvoir répondre à nouveau.
C'est cette association (une connexion = une adresse + un jeton, propres à ce client) qui permet à PWR de gérer plusieurs clients en mode Agent en parallèle, chacun avec son propre Collector, sans jamais risquer de mélanger leurs données.
En résumé
Votre session utilisateur prouve qui vous êtes auprès de PWR. Le jeton du Collector prouve à PWR que c'est bien votre agent qui répond. Les deux vivent dans des mondes séparés, ne se croisent jamais dans le même échange, et peuvent être révoqués indépendamment — c'est ce qui permet au mode Agent de rester aussi sûr que la connexion directe, tout en gardant votre base PostgreSQL hors de portée d'Internet.