Les agents
Un agent sur vos machines : il relie, il supervise, il ouvre l'accès
Posé au plus près d'un équipement ou d'un réseau, l'agent remonte l'état et les métriques de la machine, puis ouvre le canal sortant par lequel on y accède : aucun port entrant. Linux, Windows et Android, x64 et ARM64, le même binaire natif et le même protocole. Et quand votre parc contient autre chose - un automate, une carte à microcontrôleur, un temps réel - nous écrivons l'agent qui manque.
Prise 1
Choisissez l'agent qui va avec votre environnement, IT, OT ou IoT. Le rôle ne change pas : relier la machine au hub, remonter son état et ses métriques, et n'ouvrir l'accès qu'aux personnes autorisées.
Linux et Windows
Le même agent natif, en x64 et en ARM64, sur les deux systèmes : quatre binaires, du serveur à la passerelle industrielle. Il établit une connexion sortante vers le hub et la maintient : aucun port entrant n'est ouvert sur la machine.
Windows sur ARM a son propre binaire, alors qu'il émule très bien le x64. La raison vous concerne : un processus émulé annonce « x86_64 », et la machine mentirait donc sur sa propre architecture dans votre nomenclature logicielle - celle dont vous vous servez le jour où un avis de sécurité paraît et qu'il faut dire, sans y passer la semaine, quelles machines sont concernées.
Une simple connexion internet sortante suffit : un lien 4G ou 5G, la box d'un prestataire, une liaison de chantier - un réseau que vous ne maîtrisez pas. Un parc entier se reconnecte sans faire tomber le hub après une coupure.
Ils portent tout : télémétrie, commandes, mises à jour signées, terminal, transfert de fichiers, tunnels, écran et bureau distants, inventaire des paquets installés.
| Ce que l'agent fait | Linux | Windows | Android |
|---|---|---|---|
| Architectures | x64, ARM64 | x64, ARM64 | ARM 32 et 64, x86 et x64 |
| Télémétrie et inventaire | oui | oui | oui |
| Commandes | oui | oui | oui |
| Mises à jour signées | oui | oui | oui |
| Shell interactif | oui | oui | oui, dans le bac à sable de l'application |
| Fichiers de la machine | oui | oui | oui, les dossiers que l'appareil a accordés |
| Tunnels vers les équipements derrière l'agent | oui | oui | oui |
| Écran et bureau d'un équipement atteint à travers l'agent | oui | oui | oui |
| Écran de la machine qui porte l'agent | si elle sert VNC ou RDP | si elle sert VNC ou RDP | non |
Sur Android, le shell et les fichiers sont ceux que le système laisse à une application non rootée : un vrai terminal, sous l'identité de l'agent et dans son bac à sable, et les dossiers que l'appareil a accordés - jamais le disque entier. L'écran, lui, se lit en deux lignes et non en une : un écran s'atteint parce qu'un service VNC ou RDP tourne quelque part et qu'un agent y mène. Sur un serveur Linux ou un poste Windows, ce service peut tourner sur la machine elle-même ; sur les trois systèmes, il peut tourner sur un équipement derrière l'agent, et le tunnel l'atteint de la même façon. Ce que le téléphone ne fait pas, c'est servir son propre écran : c'est une autorisation qu'on ne lui demande pas.
Android : un parc d'appareils, pas une flotte de téléphones
L'agent Android vise des appareils professionnels à fonction dédiée : terminaux durcis, boîtiers métier, tablettes de véhicule, bornes. Pas les téléphones personnels de vos salariés, dont la gestion pose des questions de tout autre nature.
Ce que vous voyez sans le demander
- Batterie : niveau, charge, tension, courant, santé, température.
- Position : latitude, altitude, vitesse, précision, à cadence adaptative.
- Réseau : type, puissance du signal, opérateur, itinérance, SSID.
- Écran : état, verrouillage, luminosité, temps d'écran, déverrouillages.
- Mouvement : accéléromètre, orientation, détection de déplacement.
- Système : mémoire, stockage, temps de fonctionnement.
- Applications : inventaire, dates, stockage occupé, temps au premier plan.
La cadence de position est adaptative, et ce n'est pas un détail de confort : un relevé à intervalle fixe vide la batterie d'un appareil qui ne bouge pas, ce qui est l'essentiel du temps pour un terminal posé sur un poste.
L'origine d'installation, qui porte l'essentiel du signal
Chaque application inventoriée dit par quoi elle a été installée : un
magasin, votre solution de gestion, ou adb. Cette dernière valeur désigne une
pose manuelle, hors procédure, sur un appareil qui n'aurait pas dû en recevoir.
C'est ce qui permet de répondre à deux questions distinctes : qu'a-t-on installé en dehors du cadre, et ce qu'on a déployé sert-il réellement - la seconde se lisant dans le temps passé au premier plan.
Les commandes disponibles
Prise 6
Faire sonner l'appareil, verrouiller son écran, régler sa luminosité, demander une position ponctuelle, réclamer un inventaire ou un relevé d'usage.
Les scans WiFi et Bluetooth ont été retirés du produit
Ils étaient présents, ils ne le sont plus. Ils captaient les identifiants d'équipements appartenant à des tiers qui n'y avaient pas consenti - les points d'accès du voisinage, les appareils des personnes autour. Ni le hachage des identifiants ni une rétention courte ne suffisaient à le justifier.
Leur place reste réservée et vide dans le protocole, pour qu'aucune version future ne la réutilise par accident.
L'identité de l'appareil
La clé privée est engendrée dans le Keystore Android, adossée au matériel quand l'appareil en dispose. L'application n'en reçoit qu'une poignée : elle peut signer avec, elle ne peut pas la lire. Une sauvegarde applicative restaurée sur un autre appareil ne transporte donc aucune identité.
L'enrôlement se fait par un code à usage unique ; le certificat qui en sort vaut quatre-vingt-dix jours et se renouvelle seul. C'est le hub qui nomme l'appareil, jamais l'appareil lui-même.
Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.
Ce que l'agent Android fait dans les limites du système, et ce qu'il ne fait pas
Un shell, des fichiers, des tunnels - dans le bac à sable. Le terminal est un vrai pseudo-terminal, avec l'édition de ligne et le contrôle de tâches, mais il tourne sous l'identité de l'application : ni root, ni les commandes d'administration du système. Les fichiers sont ceux que l'appareil a accordés - les dossiers propres de l'agent toujours, le stockage partagé ou des dossiers désignés un par un si on les lui a ouverts -, jamais le disque entier. Les tunnels vers les équipements du réseau local sont les mêmes que sur Linux et Windows. Ce n'est pas nous qui posons ces limites, c'est Android, qui n'accorde rien de plus à une application non rootée.
Le téléphone ne sert pas son propre écran. Voir et reprendre l'écran d'un appareil Android suppose une autorisation que l'agent ne demande pas, et il vaut mieux le savoir avant de bâtir une procédure dessus. Ce n'est pas la même chose que l'écran d'un équipement derrière lui : celui-là s'atteint par le tunnel, depuis un téléphone comme depuis ailleurs.
Sur mesure : quand le parc n'entre dans aucune des trois cases
Les trois agents ci-dessus répondent à la majorité des cas. Mais un parc industriel contient toujours autre chose : une carte à microcontrôleur qui pilote un capteur, un calculateur sous un système temps réel, un automate avec son propre environnement, un boîtier dont le fabricant a figé la chaîne de compilation il y a huit ans.
Ces équipements-là sont souvent les plus importants du parc, et ce sont précisément ceux qu'aucun outil générique ne sait atteindre. Nous écrivons l'agent qui manque.
Avant de nous engager, nous regardons avec vous le système, les protocoles qu'il parle et la façon dont on déploierait dessus. C'est cette étude qui dit si c'est faisable, et à quel prix : il y a du matériel sur lequel on ne pose rien, et le dire en premier vaut mieux que de le découvrir en cours de route.
Pourquoi un agent de plus ne se paie pas en mois
Un agent PipeLinker n'est pas un logiciel compliqué. Il ouvre une connexion sortante, parle un protocole défini une fois pour toutes, et fait ce qu'on lui demande. Tout le reste - la base, l'interface, les droits, l'audit, le déploiement progressif - vit dans le hub et ne bouge pas.
Le protocole est un contrat écrit, pas un usage
Les échanges sont décrits dans un fichier Protobuf partagé, depuis lequel le code est engendré dans chaque langage : une divergence devient une erreur de compilation, pas une trame mal décodée en production. Écrire un agent, c'est partir d'un contrat qui existe, pas d'une page blanche.
La cible dicte le langage, pas nos préférences
Nous écrivons nos agents en Rust quand on peut choisir. Quand le fabricant impose sa chaîne, ou que seul un C existe, c'est cette contrainte qui décide.
Un agent minimal - annoncer son identité, remonter quelques mesures, recevoir des ordres - tient dans très peu de code. C'est ce qui rend l'exercice raisonnable là où embarquer un environnement complet ne l'est pas.
Ce que l'agent remonte est le vôtre
Un débit, une pression, un compteur de cycles, un code défaut constructeur, l'état d'une vanne : ce sont ces valeurs-là qui ont un sens pour votre métier, pas l'occupation mémoire. L'agent que nous écrivons remonte ce que votre équipement sait dire, et le hub l'affiche, l'historise et le seuille comme le reste.
Ce qui ne se transporte pas partout, et qu'il vaut mieux savoir
Toutes les capacités ne descendent pas jusqu'au microcontrôleur
Le shell et les tunnels supposent un système d'exploitation. Une carte sans système n'a ni processus à lancer ni pile réseau à multiplexer : elle remonte des mesures et reçoit des ordres, et c'est déjà l'essentiel de ce qu'on lui demande.
TLS a un coût qui n'est pas toujours payable. Sur une cible très contrainte, on règle la question au cas par cas - pile légère, lien déjà chiffré, ou une passerelle locale qui porte l'agent pour un groupe d'équipements muets.
L'agent Android en est déjà un exemple assumé : un shell et des fichiers dans les limites du système, et pas d'écran distant.
Comment ça se passe, de la première prise de contact
Nous regardons d'abord la cible : processeur, mémoire, pile réseau, chaîne de compilation, et ce qu'elle sait déjà dire d'elle-même. Cette étape est courte et tranche la moitié des questions.
Vient ensuite un agent minimal qui se connecte et remonte quelques valeurs, sur un exemplaire de votre matériel. C'est le moment où l'on sait vraiment si la cible tient, et il arrive tôt plutôt que tard.
Le reste - les mesures qui comptent, les commandes, la mise à jour à distance - s'ajoute ensuite, par itérations, sur une base qui fonctionne.
À qui cela appartient
L'agent écrit pour votre matériel est développé pour vous et vous est livré. Les conditions - propriété du code, droit de le reprendre, maintenance dans le temps - se posent dans le contrat plutôt que sur cette page, parce qu'elles ne se règlent pas de la même façon selon que l'équipement est le vôtre ou celui que vous vendez à vos clients.