// plateforme de confiance iiot · souveraine · air-gap

La plateforme de confiance pour l'IIoT souverain.

Identité matérielle, décision locale, action autonome, air-gap. Quatre couches ouvertes et auditables — prenez une brique, plusieurs, ou la stack complète.

Voir la console démo → Ce que la plateforme sait faire Documentation technique

// platform telemetry

devices.enrolled412 policy.evals.local12 847 attestations.signed1 976 audit.entries8 402 satellites.online99.4 % stackEU / open

// demo data — banc de démonstration

// snapshot · banc Île-de-France

▸Ops-Devices est la plateforme de confiance souveraine pour l'IIoT.

Trust-Buster est le premier système construit dessus : contrôle d'accès ABAC avec satellites de coupure, déployé et opéré sur site. trust-buster.com ↗

// ce que la plateforme sait faire

Capacités

Capacités démontrées sur banc.

Percevoir: Détection RF passive (BLE / WiFi), corrélation de présence, cartographie, signatures de consommation électrique (NILM — corroboration seulement, jamais preuve d'identité).
Identifier: Identité matérielle ancrée (enclave, IoT SAFE), attestation mTLS signée par l'enclave, enrôlement d'équipements legacy sans les modifier.
Décider: Politiques évaluées localement, hors ligne, sur manifest signé ; anti-rollback par compteurs monotones ; aucun appel serveur sur le chemin critique.
Agir: Coupure d'alimentation, filtrage de flux, proxy de confiance par interface (BLE, USB, Ethernet, série, RS-485 / Modbus).
Prouver: Journal d'audit signé, append-only, non-répudiation, export SIEM (syslog / CEF).
Interopérer: MQTT 5.0 standard, REST / OpenAPI, webhooks, adaptateurs de frontière (CoT pour la défense).
Déployer: On-premise, air-gap total, ou souverain hébergé ; 3 form factors.

// 4 couches indépendantes

Briques techniques

Chaque couche est documentée, versionnée, et utilisable indépendamment. Vous achetez ce qui manque dans votre stack actuel — pas une solution monolithique.

L1

Hardware

3 form factors (Cube, rail DIN, durci IP68) · ESP32-S3 + composant sécurisé

Firmware par défaut prêt à l'emploi, datasheets publiques, schémas électroniques sur demande NDA. La chaîne de confiance est ancrée dans un composant sécurisé certifié Critères Communs EAL5+ (enclave héritée Tiempo Secure, via Sequans Monarch 2) : la clé privée y est générée et n'en sort jamais. La certification porte sur le composant, pas sur Ops-Devices.

MCU: ESP32-S3 / ESP32-C6
Cellulaire: Walter (Sequans Monarch 2, FR/BE)
Radio: BLE 5.0 + WiFi 6
Charge: Qi 5V + USB-C
Boîtier: 12 cm cube, IP non spécifié v1
Composant sécurisé: Certifié CC EAL5+ (Tiempo Secure)
Protocole: IoT SAFE (GSMA RP.25)
Clé privée: Générée en enclave, jamais en RAM
Attestation: mTLS X.509 signé enclave, pas firmware

L2

Firmware

Firmware ESP32 open-source, SDK, OTA signé via hawkBit

Apache 2.0, développé en Europe, auditable, build reproductible. Profils configurables (alerte, passerelle, contrôle). Adaptez les payloads MQTT à vos contraintes, ajoutez vos heuristiques de détection.

Licence: Apache 2.0
Framework: ESP-IDF v5.1+
MQTT: 5.0 + mTLS X.509 (TLS 1.3)
OTA: Signé Ed25519, hawkBit
Sécurité: AES-256-GCM, ECDH/HKDF
Anti-rollback: Compteurs monotones en enclave

L3

Backend & API

Ingestion MQTT, politiques, journal signé, REST + webhooks

Python asyncio + PostgreSQL/TimescaleDB. API REST documentée OpenAPI, webhooks MQTT, ingestion ProtoBuf. Auto-hébergeable on-premise (air-gap possible) ou souverain hébergé. La plateforme distribue les politiques ; elle ne participe jamais à la décision.

Stack: Python 3.12 + asyncio
DB: PostgreSQL + TimescaleDB
Broker: EMQX 5 (MQTT 5.0) — démo
Broker souverain: HiveMQ / VerneMQ / Mosquitto
API: REST OpenAPI + webhooks
Export: SIEM syslog / CEF
Déploiement: Podman / Docker / on-prem / air-gap

L4

Console de supervision

Frontend SvelteKit + cube 3D Three.js — supervision temps réel

Open-source, customisable (logo, couleurs, faces, libellés). Dashboards admin, inbox messages, multi-cubes, cartographie RF. Déployable à votre marque (option OEM / white-label).

Stack: SvelteKit 2 + Tailwind 3
3D: Three.js
Auth: OIDC (LemonLDAP, Keycloak…)
i18n: FR / DE / IT inclus
Licence: Apache 2.0 + accord OEM

// architecture

Une ancre, des satellites.

L'ancre est distante des équipements qu'elle protège, et elle en protège plusieurs : elle ne se câble jamais directement sur l'un d'eux. Le Cube est l'ancre de confiance et le point de décision d'une zone. Les satellites appliquent, un par interface. Le Cube ne délègue jamais d'autorité : il émet des capacités éphémères signées, à durée de vie limitée et liées au contexte. Il ne fait jamais confiance à un satellite — il vérifie.

Interface contrôlée	Satellite	Rôle	Statut
Alimentation 230 V	Shelly (stock durci, detached input)	Coupure / autorisation d'un équipement	● Démonstrateur
Périphériques BLE	Proxy BLE	Clavier, souris, périphérique sans fil	● Roadmap
Bus USB	Filtre USB-HID — STM32H7 (deux cœurs USB)	Clavier USB — cas de référence du flux complet	● Roadmap
Réseau filaire	Gate Ethernet	Segment OT	● Roadmap
Interface série	Passerelle série — STM32 + ST3485E isolé	Automate Modbus RTU legacy (RS-485 / RS-232)	● Roadmap

Le satellite d'alimentation, en détail

C'est le seul satellite en fonctionnement. Le Cube ne lui délègue aucune autorité : il lui adresse une capacité éphémère signée, à TTL court, et vérifie son état.

Matériel: Shelly (Allterco, Bulgarie — ISO 27001)
Firmware: Stock durci, aucun reflash
Entrée: Detached input — le bouton signale, le relais n'obéit qu'au Cube
Désactivé: Cloud, BLE, schedules, webhooks
Au démarrage: État power-on OFF (fail-closed)
Liaison: MQTT over mTLS, interface web authentifiée
Interlock: Mesure amont (Pro 1PM, rail DIN) vs aval (Plug S)
Banc: 2× Plug S Gen3, 1× Pro 1PM, 1× EM Gen3, 1× Plus i4 DC
Portabilité: Plug S Gen3 = ESP32-C3 : le firmware du Cube n'y est pas portable

Sur les satellites, la souveraineté est réelle

Les satellites n'ont pas besoin de radio : le compromis ESP32 du Cube y disparaît. Ils sont bâtis sur STMicroelectronics (franco-italien) — MCU STM32 et élément sécurisé STSAFE-A120, certifié Critères Communs EAL5+. Les points d'enforcement, au contact de l'équipement critique, ont donc une racine de confiance matérielle européenne — ce que le Cube v1 n'a pas, son enclave étant passée sous contrôle Qualcomm. Le STSAFE-A120 validé sur les satellites est le candidat du Cube v2.

Boucle tamper / auto-réparation

Détection de reset d'un satellite (réapparition de l'AP par défaut, LWT MQTT) → lockdown fail-closed de la zone → ré-enrôlement authentifié avec protection evil-twin. Un interlock différentiel de courant (mesure amont vs aval) signale un contournement physique.

Le premier système construit sur ce patron

Nous avons commencé par le contrôle d'accès ABAC avec satellite de coupure d'alimentation — c'est le système Trust-Buster, déployé et opéré sur site. Le même patron s'étend au BLE, à l'USB, à l'Ethernet et au série.

→ trust-buster.com ↗

// autorisation

Le modèle ABAC — trois questions jamais fusionnées

Autorisation contextuelle : sujet × ressource × lieu × créneau, sur manifest signé.

Facteur	Question	Mécanisme	Statut sécurité
Présence	Où — qui est probablement là ?	Co-présence RSSI de devices enrôlés	Gate — nécessaire, jamais suffisant
Identité	Qui — est-ce vraiment lui ?	Challenge-response cryptographique (élément sécurisé du smartphone ↔ enclave du Cube)	Preuve
Habilitation	Quoi — a-t-il le droit, ici, maintenant ?	Manifest signé par l'autorité : activité prévue (jour, lieu, ressource), TTL	Droit

Règle d'or

Le RSSI dit « il est là » ; la crypto dit « c'est bien lui ». Une actuation physique ne se conditionne jamais sur le seul tiers passif. Le badge NFC est un pointeur de proximité — il désigne qui challenger — pas une preuve d'identité.

Machine d'autorisation

1 · DEMANDE Entrée satellite détachée (appui bouton) → requête vers le Cube. Le bouton n'actionne jamais le relais directement.
2 · GATE Présence RSSI co-localisée d'au moins un utilisateur enrôlé candidat → sinon rejet : personne de plausible dans la zone.
3 · PREUVE Challenge du Cube → réponse signée par l'élément sécurisé du smartphone (nonce lié au contexte : ressource, zone, fenêtre).
4 · DROIT Manifest signé vérifié : activité prévue, ce jour, ce lieu, cette ressource ; TTL non expiré ; compteur monotone (anti-rollback).
5 · CAPACITÉ Émission d'une capacité éphémère signée vers le satellite concerné.
6 · EXÉCUTION Le satellite exécute ; le Cube journalise (log signé, append-only). Toute étape en échec → rejet journalisé avec motif.

Air-gap : compenser l'absence de révocation temps réel

TTL courts sur les manifests (l'expiration remplace la révocation), compteurs monotones en enclave (anti-rollback des politiques), nonces liés au contexte dans le challenge-response.

// notre approche souveraineté

Pourquoi de l'ESP32 dans une stack qui se dit souveraine ?

[01] L'ESP32 (Espressif) n'est pas un MCU européen — pourquoi le retenir ? ▶

Parce que c'est aujourd'hui le seul écosystème open-source mature avec BLE 5 + WiFi 6 + coexistence radio à ce prix. Imposer un MCU EU sur la v1 reviendrait à doubler le coût matériel et retarder le produit de 18 mois. Nous l'assumons et nous le documentons : le risque de supply chain est sur la couche silicium uniquement, pas sur le firmware (open-source EU) ni la plateforme (auto-hébergeable on-prem).

[02] Quelle alternative européenne travaillez-vous ? ▶

Variante STM32WB (STMicroelectronics, FR/IT) + module RF européen, prévue v2.0 (Q4 2027). Pour les clients exigeant une supply chain 100 % EU sans concession, cette variante sera disponible avec une dégradation acceptable de coexistence radio (BLE 5 sans WiFi simultané).

[03] Et le module Walter (LTE-M) ? ▶

Walter est conçu et fabriqué en Belgique par DPTechnics, basé sur un modem Sequans Monarch 2 (FR). Supply chain EU sur la couche cellulaire — utile pour démontrer la souveraineté sur l'uplink critique.

[04] Et la plateforme cloud / les données ? ▶

OVHcloud France (datacenter Roubaix). PostgreSQL + TimescaleDB, Mosquitto, LemonLDAP::NG (FR), Garage S3 (Deuxfleurs FR). Aucune dépendance hyperscaler US. Toutes les données restent en UE, le KMS est sous votre contrôle on-prem si vous le souhaitez. En air-gap, aucune donnée ne sort du site.

[05] Le firmware peut-il être audité avant déploiement ? ▶

Oui. Le firmware est open-source (Apache 2.0), build reproductible, releases signées. Vous pouvez auditer chaque ligne, ou faire auditer par un tiers. C'est un argument décisif vs les firmwares propriétaires des grands constructeurs.

[06] Votre composant sécurisé EAL5+ — qu'est-ce que ça change concrètement ? ▶

La clé privée du device est générée directement dans l'enclave (IP Tiempo Secure, via Sequans Monarch 2). Elle ne sort jamais en RAM ni en flash ESP32. Un attaquant qui compromet le firmware ne peut pas l'extraire. Tout handshake mTLS est signé par l'enclave — pas par le SoC hôte. C'est ce que le standard GSMA IoT SAFE formalise. Deux précisions honnêtes : la certification Critères Communs EAL5+ porte sur le composant, pas sur Ops-Devices ; et EAL5+ n'est pas le plus haut niveau de l'échelle (elle va jusqu'à EAL7). À notre connaissance, aucun acteur européen ne propose cette combinaison sur ce segment.

[07] Pourquoi EMQX alors que l'éditeur est chinois ? ▶

EMQX est utilisé sur le banc de démonstration pour sa maturité et ses performances en clustering. Pour les contextes défense ou nécessitant une souveraineté maximale (conformité ANSSI, périmètres classifiés), nous déployons HiveMQ (DE), VerneMQ ou Mosquitto (Eclipse Foundation, open source). Nous n'utilisons que du MQTT 5.0 standard, sans extension propriétaire, précisément pour rester portables. Le choix du broker est documenté dans le HBOM de chaque déploiement et ne touche pas la chaîne de confiance cryptographique.

[08] Fournissez-vous un SBOM et un HBOM ? ▶

Oui. Notre SBOM (Software Bill of Materials) est généré en format CycloneDX 1.6 et couvre toutes les dépendances firmware (ESP-IDF, mbedTLS, esp-mqtt) et backend (Python, PostgreSQL, broker). Notre HBOM (Hardware Bill of Materials) documente chaque composant physique avec son fabricant, pays de conception, pays de fonderie et niveau de souveraineté, selon IPC-1752A et NIST SP 800-161. Ces documents sont disponibles sur demande NDA, et inclus dans le dossier de conformité CRA livré avec chaque déploiement.

[09] Tiempo Secure a été racheté par Qualcomm — que devient votre souveraineté ? ▶

Qualcomm a acquis Tiempo Secure et les actifs 4G IoT de Sequans : l'IP de l'enclave est désormais sous contrôle américain. Notre souveraineté est donc opérationnelle et de conception : aucun cloud étranger, aucun kill-switch distant, air-gap complet, conception et intégration européennes. Nous ne revendiquons pas une IP 100 % européenne. La roadmap Cube v2 vise un élément sécurisé discret certifié européen (ST, Infineon, NXP). Ce n'est pas qu'une intention : nos satellites — les points d'enforcement au contact de l'équipement — sont spécifiés autour du STSAFE-A120 (STMicroelectronics, CC EAL5+), une racine de confiance matérielle réellement européenne. Nous la validons là d'abord, puis nous la portons au Cube.

[10] Que ne savez-vous pas faire ? ▶

Nous ne mesurons pas la distance physique : pas de distance bounding, le Channel Sounding BLE 6.0 n'est pas disponible sur notre matériel actuel. Une attaque par relais (wormhole) reste donc possible. Nous la détectons et la traçons — journal signé, corrélations, interlock différentiel de courant — mais nous ne prétendons pas la bloquer. Le seul levier préventif dur reste la coupure d'alimentation. C'est documenté dans notre modèle de menace, avec les autres risques résiduels.

// conformité

La conformité en version preuve

Conçu selon l'IEC 62443-4-2, avec une architecture alignée sur les exigences fondamentales FR1 à FR7. Cible de conception : SL-C 2 (industriel).

⚠ Évaluation par tierce partie non encore réalisée. Aucun niveau SL n'est affiché comme acquis : un SL-C exige une évaluation tierce que nous n'avons pas.

Mapping IEC 62443 — exigences fondamentales

Exigence	Comment l'architecture y répond
FR1 Identification & authentification	Identité matérielle en enclave, challenge-response élément sécurisé smartphone ↔ Cube, attestation mTLS X.509 signée par l'enclave.
FR2 Contrôle d'usage	Autorisation ABAC sur manifest signé (sujet × ressource × lieu × créneau), TTL courts, capacités éphémères par satellite.
FR3 Intégrité du système	OTA signé Ed25519, anti-rollback par compteurs monotones en enclave, firmware open-source à build reproductible.
FR4 Confidentialité des données	mTLS (TLS 1.3), AES-256-GCM, ECDH/HKDF. Clé privée générée et conservée en enclave, jamais exposée en RAM.
FR5 Flux de données restreints	Décision locale, aucun appel serveur sur le chemin critique, air-gap total possible. Les satellites ne détiennent aucune autorité permanente.
FR6 Réponse aux événements	Journal d'audit signé append-only, détection de tamper/reset satellite, lockdown fail-closed de zone, export SIEM (syslog / CEF).
FR7 Disponibilité des ressources	Fonctionnement hors ligne par conception, état power-on OFF, ré-enrôlement authentifié après incident.

Registre des risques résiduels — publié

Risque	Posture assumée
Relais / wormhole (BLE)	Irrésoluble sur le matériel actuel (nécessiterait le Channel Sounding BLE 6.0). Posture détective : détection + attribution, pas de prévention revendiquée. Seul levier préventif dur : la coupure d'alimentation.
Accès physique / teardown	Un accès physique prolongé permet de détruire le matériel. Le teardown est détectable — il détruit la preuve d'inviolabilité — mais il n'est pas empêchable.
Déni de service par fail-closed	La posture fail-closed peut être exploitée pour provoquer un arrêt. Choix assumé : en cas de doute, l'équipement s'arrête.
Supply chain silicium	ESP32 (Espressif) et IP d'enclave désormais sous contrôle Qualcomm. Documenté publiquement (SBOM / HBOM), jamais dissimulé.

Positionnement CRA

SBOM CycloneDX 1.6, HBOM IPC-1752A / NIST SP 800-161, modèle de menace documenté (STRIDE), registre de risque résiduel publié. Dossier de conformité livré avec chaque déploiement.

// journal r&d

Les alternatives que nous avons écartées

Chaque décision structurante est consignée avec l'alternative rejetée et son motif.

Écarté	Retenu	Motif
Sonoff	Shelly (Allterco, BG, ISO 27001)	Local-first natif, detached input, variantes rail DIN, origine UE, MQTT over TLS.
Reflasher les satellites	Firmware stock durci + profil de verrouillage	L'OTA Shelly est signé ECDSA ; le teardown UART serait destructif et détruirait la preuve d'inviolabilité.
Mongoose OS	Firmware stock Shelly durci	Obsolète, antérieur au support ESP32-C3.
Le RSSI seul comme autorisation	Triptyque présence + identité + habilitation	Spoofable par relais, inopérant sous randomisation MAC. Le RSSI reste un gate, jamais une preuve.
Le badge NFC comme preuve d'identité	Badge = pointeur de proximité	Clonable, aucun secret challengeable.
NILM comme preuve d'identité d'équipement	NILM = corroboration seulement	Les signatures de charge ne sont pas probantes.
Autorité permanente déléguée aux satellites	Capacités éphémères signées émises par le Cube	Zero-trust interne : vérifier, jamais croire.
Revendiquer la prévention anti-relais	Posture détective + attribution	Le wormhole est irrésoluble sans BLE 6.0 Channel Sounding. Réévaluable au passage BLE 6.0.
Présenter EAL5+ comme une certification Ops-Devices	Toujours « héritée du composant »	Honnêteté technique : le surclaim se paie en due diligence.
Le scan RF comme barrière à l'entrée	La couche d'intégration IoT SAFE	Le scan passif est reproductible en quelques semaines. L'avance réelle est dans l'intégration de la chaîne de confiance.
ESP32 pour les satellites	STM32 (ST, FR/IT)	Un satellite n'a pas besoin de radio : le compromis qui impose l'ESP32 au Cube n'a plus lieu d'être. Une chaîne 100 % européenne devient possible.
Un élément sécurisé non européen (Microchip ATECC)	STSAFE-A120 (ST, CC EAL5+)	Racine de confiance matérielle réellement européenne sur les points d'enforcement — et candidat du Cube v2.
Un seul contrôleur USB (OTG) pour le proxy HID	STM32H7 — deux cœurs USB indépendants	L'OTG bascule de rôle : il ne peut pas être hôte et device simultanément. Un proxy clavier l'exige.
Un satellite série non isolé	Isolation galvanique des données et de l'alimentation	Un bus OT est bruité (mode commun de plusieurs centaines de volts) : sans isolation, pannes intermittentes et risque matériel.

Catalogue produit

Nous sommes au stade démonstrateur.

Niveau 1 — Form Factors (hardware)

Réf.	Désignation	Statut
OPS-FF-CUBE	Cube lumineux interactif — 12 cm, NFC, LEDs RGB, Qi+USB-C	● Démonstrateur
OPS-FF-DIN	Boîtier rail DIN 35 mm — 24V DC, RS-485, IP20, industrie	● Roadmap
OPS-FF-HARD	Boîtier durci étanche — IP68, terrain / extérieur	● Roadmap

Niveau 2 — Profils logiciels (par Cube)

Réf.	Désignation	Statut
PROFILE-ALERT	Mode alerte seule — non-intrusif, zéro modification infra	● Démonstrateur
PROFILE-GW	Mode passerelle réseau — coupure active des flux non autorisés	● Roadmap
PROFILE-CTRL	Mode contrôle direct — ABAC + satellite d'actuation	● Démonstrateur

Niveau 3 — Plateforme (abonnement)

Réf.	Désignation	Statut
OPS-PLATFORM-EDGE	Licence on-prem / air-gap — aucune connexion cloud requise	● Roadmap
OPS-PLATFORM-SAAS	Souverain hébergé — OVH France, multi-sites, API REST	● Démonstrateur
OPS-PLATFORM-OEM	White-label — console rebrandable, royalty, support dédié	● Roadmap

Niveau 4 — Satellites (points d’enforcement)

Réf.	Désignation	Statut
OPS-SAT-PWR	Coupure 230 V — Shelly stock durci, detached input	● Démonstrateur
OPS-SAT-485	Passerelle série RS-485 / RS-232 — STM32 + ST3485E isolé + STSAFE-A120	● Roadmap
OPS-SAT-HID	Filtre USB-HID — STM32H7 (deux cœurs USB) + STSAFE-A120	● Roadmap

Références historiques (OPS-CUBE-S3, OPS-WLT-*, OPS-RF-CORE, OPS-MAP-SAAS…) : reclassées dans cette architecture. Table de correspondance dans la documentation technique, sur demande NDA.

Principes d'ingénierie

Open-source: Stack ouvert (Apache 2.0), auditable, build reproductible. Pas de boîte noire.
Souveraineté: Hébergement EU, conception et intégration européennes. Supply chain documentée (SBOM / HBOM) — limites comprises.
Décision locale: La politique s'évalue sur le Cube, hors ligne. Aucun appel serveur sur le chemin critique, air-gap total possible.

// règle de segment

Quel canal pour quel besoin ?

Les situations critiques — équipement dangereux, périmètre sensible, conformité contraignante, traçabilité opposable — sont traitées en service opéré par Trust-Buster : matériel déployé et exploité sur site. → trust-buster.com ↗

Les besoins d'automatisation et les déploiements standard passent par la plateforme et son réseau d'intégrateurs et de revendeurs.

// distribution & oem

Distribution, revendeurs, OEM

Vous construisez votre stack sur nos briques, vous déployez chez vos clients, ou vous proposez la plateforme sous votre propre marque.

Découverte

Gratuit

Évaluer la stack avant engagement

▸ Accès à la documentation technique complète
▸ 1 sonde de démo prêtée 30 jours
▸ Console démo avec compte de test
▸ Support email (réponse 5 jours ouvrés)

Revendeur agréé

Contrat-cadre

Déployer nos briques chez vos clients

▸ Tarifs volume hardware dégressifs
▸ Formation technique 2 jours (Paris ou distant)
▸ Roadmap produit partagée trimestriellement
▸ Support prioritaire (SLA 1 jour ouvré)
▸ Logo "Revendeur agréé" sur votre site

OEM / White-label

Sur mesure

Proposer nos briques sous votre marque

▸ Plateforme à votre marque (front + console)
▸ Co-branding hardware (sticker, packaging)
▸ Comité technique trimestriel
▸ Engagement de SLA contractuel
▸ Royalty fixe ou pourcentage selon volume

Discuter de votre cas Voir la documentation technique

// contact technique

Évaluer la plateforme, ou devenir partenaire.

Décrivez votre besoin technique : quelles briques, quelle intégration, quel volume cible. Documentation technique, datasheets, SBOM / HBOM et modèle de menace disponibles sous NDA. Nous revenons sous 5 jours ouvrés.

Email contact@ops-devices.eu

Plateforme ops-devices.eu

Système opéré trust-buster.com ↗

Hébergement OVH France