Technique
Un binaire, une base, et rien à administrer de plus
Ce que votre équipe devra tenir : un binaire et un PostgreSQL. Pas d'extension à compiler, pas de courtier de messages, pas de grappe. Vous gardez la main sur l'endroit où le hub vit, sur sa disponibilité et sur les données de votre parc : aucune plateforme extérieure n'est nécessaire pour ouvrir un accès. Et un agent qui refuse ce qu'il ne doit pas faire, même quand l'ordre vient du serveur.
Les agents vont avec, et c'est le hub qui les distribue à votre parc. Chacun sert de porte vers son réseau local : un automate, une IHM ou une caméra s'atteignent à travers lui, sans rien avoir à y installer et sans qu'aucun port ne s'ouvre. Le portail est chez nous : votre licence y vit, avec les binaires signés. Le hub ne s'y connecte que si vous le lui demandez - c'est un réglage, désactivé au départ - et il prouve alors qu'il porte une licence valide sans jamais la transmettre. Sur un réseau coupé d'Internet, cette liaison n'existe pas et les binaires se déposent à la main.
Le hub, les agents, le portail
Un serveur que vous installez, des agents posés sur vos machines, et un portail que nous tenons pour vos licences et vos binaires - c'est tout. Aucune de vos données ne passe par les nôtres, et un agent atteint aussi ce qui vit derrière lui : les équipements de son réseau local, qui n'ont eux-mêmes rien d'installé.
Un binaire et une base de données, rien d'autre
C'est tout ce qu'est PipeLinker Hub côté serveur : un exécutable natif qui porte le serveur et sa console web, et une base PostgreSQL. Pas de cluster à dimensionner, pas de file de messages, pas de cache distribué, pas de moteur à installer autour.
Cela le rend déployable à peu près partout : une machine virtuelle, un serveur physique dans votre salle, un service systemd, votre orchestrateur habituel, ou un réseau totalement coupé d'Internet. Une même instance sépare vos parcs les uns des autres, sans qu'il faille en installer une par client ou par site.
Le hub sert son TLS lui-même : il lit un certificat et une clé dans un dossier, et ce qui les y dépose ne le regarde pas - certbot, une PKI d'entreprise, ou un mandataire inverse (reverse proxy) devant lui si vous en avez déjà un.
Ce que le schéma montre
Le portail, lui, est chez nous : il porte votre licence et les binaires signés. Le hub ne s'y connecte que si vous le lui demandez - le réglage part désactivé - et il prouve alors qu'il porte une licence valide sans jamais la transmettre. Sur un réseau coupé d'Internet, cette liaison n'existe pas et les mises à jour se déposent à la main.
Le serveur orchestre ; l'agent exécute. Les deux partagent les mêmes briques de code, donc les mêmes règles de validation : les deux bouts de la chaîne ne se désynchronisent pas quand une version évolue.
Une base de données que votre équipe connaît déjà
PipeLinker Hub s'installe chez vous. Votre inventaire de parc, vos métriques, vos positions et vos enregistrements de sessions ne transitent par aucun service tiers - et surtout, ils sont stockés dans PostgreSQL, pas dans une technologie propriétaire qu'il vous faudrait apprendre à exploiter.
Ce que votre exploitant y gagne
Vos procédures existantes s'appliquent
Sauvegarde, restauration, supervision, réplication : votre équipe utilise les mêmes outils que pour ses autres bases. Pas de runbook spécifique à écrire, pas de formation, pas d'astreinte sur une technologie que personne ne connaît en interne.
Un seul composant à exploiter
PipeLinker Hub, c'est un service et une base. Pas de cluster à dimensionner, pas de file de messages, pas de cache distribué à surveiller. Un déploiement de 1 000 appareils tient sur une machine modeste.
Vos données vous appartiennent vraiment
PostgreSQL est sous licence permissive, et nous n'utilisons aucune extension qui restreindrait ce que vous pouvez en faire. Vous interrogez votre base directement avec vos outils décisionnels, vous créez vos propres vues, vous exportez ce que vous voulez, quand vous voulez. Certaines solutions du marché s'appuient sur des composants dont la licence leur impose de vous interdire de modifier votre propre schéma - ce n'est pas notre cas, et c'était un critère de conception.
Aucune surprise juridique
Pas de licence à faire valider par votre service achats, pas de clause à répercuter, pas de composant au statut ambigu dans votre inventaire logiciel.
Pourquoi pas TimescaleDB
La question revient souvent, puisque nous stockons des séries temporelles. L'extension est techniquement solide, mais ce qui justifierait de l'adopter n'est pas sous licence libre : la Timescale License encadre la redistribution et l'usage commercial.
Pour un produit livré chez vous, ce serait vous imposer ces conditions - et une extension à installer, absente d'une bonne partie des PostgreSQL managés.
Nous gérons donc nous-mêmes l'agrégation et la purge des séries temporelles, sur PostgreSQL nu. Un peu plus de travail de notre côté, aucune contrainte juridique du vôtre.
Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.
Ce que ça consomme, chez vous
PipeLinker Hub gère de 1 000 à 40 000 appareils par déploiement. La fréquence de collecte est réglable par agent : quelques minutes pour du suivi de flotte, plus rapprochée pour les équipements critiques. La connexion aux appareils, elle, reste ouverte en continu : commandes et accès distant ne dépendent pas de la fréquence de collecte, et restent donc possibles même sur un parc suivi toutes les dix minutes.
Les données brutes sont agrégées puis purgées selon la rétention que vous choisissez : l'historique long sans une base qui croît indéfiniment.
Nous fournissons un tableau de dimensionnement (processeur, mémoire, stockage) par volume d'appareils et par durée de rétention, pour que vous puissiez provisionner avant de vous engager.
Et aucune confiance implicite, y compris envers nos propres composants
Ce qui précède décrit ce qui tourne et où. Ce qui suit décrit ce que chaque maillon refuse de croire sur parole : c'est là que se joue la différence entre un outil d'administration et un produit qu'on laisse toucher à une machine en production.
Une identité par appareil, jamais une clé partagée
Chaque agent porte son propre certificat client. Pas une clé d'API que dix mille appareils se partagent, et dont la fuite d'un seul compromettrait le parc entier. La révocation est individuelle et immédiate.
La clé privée est engendrée sur l'appareil et n'en sort pas ; le certificat est de courte durée et se renouvelle seul. Aucun jeton durable à voler dans un fichier de configuration.
Une conséquence à connaître avant de déployer
Un certificat client n'existe que dans la poignée de main TLS. Un mandataire inverse qui termine le TLS l'efface, et plus aucun agent ne se connecte. Le nom de la console, lui, se met derrière un mandataire comme n'importe quel site. C'est la principale chose à savoir au moment de placer le hub dans une infrastructure existante.
Votre hub signe ces certificats lui-même, par une autorité propre à chaque parc, ou se raccorde à la chaîne de confiance que votre organisation tient déjà. Dans les deux cas l'autorité est la vôtre : le hub tourne chez vous, et ce qu'il engendre ne sort pas plus que ce que vous lui fournissez. Une identité par équipement, compatible avec votre PKI
Un binaire ne s'installe pas sans être signé
Une mise à jour à distance est, littéralement, l'exécution de code arbitraire sur tout un parc. Ce qui protège n'est donc pas le canal - il est déjà authentifié et chiffré - mais la preuve que le binaire vient bien de qui prétend l'avoir produit.
Deux contrôles, et ils ne servent pas à la même chose. L'empreinte protège de l'accident : un téléchargement tronqué, un disque qui ment, un miroir périmé. Elle ne protège de rien d'autre, puisqu'elle voyage par le même chemin que le binaire - qui tient ce chemin tient les deux.
La signature protège de la malveillance. Elle ne peut être produite que par le détenteur de la clé privée, qui n'est ni sur le portail, ni sur le hub, ni sur l'agent. Un hub compromis peut mentir sur tout, il ne peut pas signer.
La clé de vérification est dans le binaire, pas dans un réglage
La clé publique est compilée dans l'agent, et dans le hub pour sa propre mise à jour. Une clé qu'on poserait dans un fichier de configuration se remplacerait par celle de qui veut signer ce qu'il veut, et la vérification ne prouverait plus rien : la contourner demande alors de refaire le binaire, ce qui est le niveau où l'on a décidé de s'arrêter.
Sans clé compilée, toute mise à jour est refusée. Le défaut est fermé : un binaire qu'on ne peut pas vérifier est un binaire qu'on n'installe pas. Ni un agent ni un hub ne se met à jour tout seul sur un binaire dont la signature ne correspond pas.
Trois vérifications, et une seule qui décide
Le portail refuse un dépôt dont il ne reconnaît pas la signature, et le hub fait de même avec le binaire qu'on lui remet : l'erreur est attrapée devant celui qui la commet, et non des semaines plus tard sur une machine lointaine.
Mais ni l'un ni l'autre n'est l'autorité : ils ne détiennent aucune clé qui signe. Seule décide la vérification faite au bout, sur la machine, avec une clé que rien de ce qui précède ne peut influencer.
Comment une personne se connecte
Un mot de passe, puis un second facteur par code à usage unique - celui des applications d'authentification usuelles. Dix codes de secours accompagnent l'enrôlement : assez pour tenir jusqu'au remplacement d'un téléphone.
L'ordre compte, et il est vérifié. Le code est demandé avant que la session ne soit ouverte : l'ordre inverse laisserait une session ouverte à qui ne connaît que le mot de passe.
Les agents ne sont pas concernés : ils s'authentifient par certificat, sans personne devant l'écran. Une identité par équipement, compatible avec votre PKI
Moindre privilège
Les droits se règlent par parc, par groupe et par action, et distribuer des droits est lui-même un droit - c'est ce qui permet de confier un parc à un administrateur sans lui confier le reste de l'installation. Le compte d'administration initial en est exempté : sans cette exception, retirer par mégarde la dernière autorisation fermerait la porte pour de bon.
Le shell interactif est traité comme ce qu'il est, une capacité puissante, et reste réservé aux rôles qui la justifient.
Le cloisonnement entre organisations est strict, avec expiration des sessions, rotation des clés, limitation de débit et stockage maîtrisé des secrets.
Rust, pour ce que cela retire
Le serveur et les agents manipulent du réseau, de la cryptographie et des données venues de l'extérieur - exactement le terrain des débordements mémoire et des corruptions. Rust élimine cette famille de failles par construction, sans imposer le surcoût d'un ramasse-miettes : l'empreinte reste faible et prévisible, y compris sur un boîtier ARM modeste.
Le hub se défend, et le dit
Un hub est une porte sur un parc, et une porte se fait sonder. Le hub tient deux journaux distincts : celui des accès - qui s'est connecté à la console, quand, d'où, et qui a échoué - et celui de la sécurité, qui compte les refus par origine, garde les changements de clé d'hôte et les décisions d'un administrateur, et survit à la purge des données d'exploitation. Une vue d'ensemble sur fenêtre glissante donne les totaux par nature et les origines qui insistent.
Prise 10
La force brute se compte, et se coupe. Tout ce qui prend un code tapé à la main - un mot de passe, un code d'inscription, un second facteur - est limité à cinq essais par adresse et par minute. Au-delà, cinquante refus en cinq minutes depuis une même origine ne sont plus du bruit : la gravité monte, et l'adresse est écartée d'elle-même, pour une durée qui s'allonge si elle recommence. Un administrateur peut aussi écarter une adresse par décision, ou en mettre une en liste blanche que le seuil ne touchera jamais ; les réseaux privés y sont d'office, et le hub refuse d'écarter l'adresse depuis laquelle on lui parle - on ne s'enferme pas dehors.
Prise 11
Ce qui est critique remonte. Un changement de clé d'hôte qui fait échouer une session, une origine qui insiste, un événement de sécurité critique : chacun produit une notification, envoyée par courriel si un relais est configuré, et la ligne du journal reste même si la notification se perd. Ce que quelqu'un a tapé dans un champ de mot de passe n'est jamais écrit : c'est souvent le vrai mot de passe d'un autre.
Ce que la sécurité du parc permet de démontrer
Savoir ce qui tourne, pouvoir corriger vite et le prouver n'est plus seulement une bonne pratique : c'est ce que le Cyber Resilience Act exigera des fabricants. Ce que le règlement demande
Page mise à jour le 22 septembre 2026. Page technique, tenue par l'équipe PipeLinker de LOOTUS SECURITY, éditeur du produit. La date vient du dépôt, pas d'une saisie.