Construire des plateformes IoT souveraines en Europe

La souveraineté des données signifie que vos données machine relèvent du droit de la juridiction où elles se trouvent physiquement, et que c'est vous, et non un éditeur de plateforme, qui décidez qui peut les lire. Pour une flotte qui circule entre l'Allemagne, la France et les Pays-Bas, ce n'est pas un point de droit abstrait. Cela détermine si l'hyperscaler d'un concurrent, une injonction étrangère ou la faillite d'un fournisseur SaaS peut atteindre vos données de fonctionnement, de défaut et de localisation.

La question que pose un acheteur est précise : si l'éditeur de la plateforme disparaît demain, conservons-nous les données, les clés et un moyen de lire les deux ? La souveraineté est l'architecture qui vous permet de répondre oui. Elle touche trois couches à la fois : où les octets sont stockés, où ils sont traités et qui détient les clés de chiffrement.

Trois textes façonnent la mise en œuvre. Le RGPD s'applique à tout signal télématique rattachable à une personne, et une trace GPS associée à une liste de conducteurs en fait exactement partie : les données de localisation et d'opérateur portent donc des obligations relatives aux données personnelles, même sur du matériel industriel. L'EU Data Act, en vigueur depuis 2024, donne à l'utilisateur d'un produit connecté le droit d'accéder aux données qu'il génère et de les transférer à un tiers de son choix. Une passerelle fermée qui accapare sa propre télémétrie devient ainsi un risque réglementaire, et plus seulement commercial. Schrems II reste la raison pour laquelle les transferts de l'UE vers les États-Unis exigent de véritables garanties plutôt qu'une case à cocher.

La conséquence pour la conception est directe. Construisez de sorte que les données restent dans l'UE par défaut, que le client puisse les extraire à la demande dans un format documenté, et que vous puissiez montrer à un auditeur où réside chaque signal et qui y a touché.

La souveraineté se défend le mieux lorsqu'elle est structurelle, et non un réglage que quelqu'un peut basculer. Ancrez explicitement la couche de stockage dans des régions de l'UE : une instance Postgres ou TimescaleDB à Francfort ou à Paris, un stockage objet verrouillé par région et des sauvegardes qui ne sont jamais répliquées hors du marché intérieur. Faites tourner le broker MQTT (Mosquitto ou EMQX) sur une infrastructure hébergée dans l'UE ou sur le matériel propre du client, afin que le flux de télémétrie lui-même ne transite par aucun pays tiers.

Repoussez vers l'edge autant de traitement que le cas d'usage l'autorise. Une passerelle qui agrège les données moteur J1939 et les relevés capteurs Modbus en résumés à la minute avant la transmission conserve l'essentiel du signal brut sur site. Cela réduit à la fois la facture de bande passante et la surface de souveraineté : des données qui ne quittent jamais la machine ne peuvent être requises par injonction dans une autre juridiction. Pour les données qui circulent, chiffrez-les sur la passerelle avec des clés détenues par le client, de sorte que même un broker hébergé dans l'UE ne voie qu'un texte chiffré qu'il ne peut lire.

Les composants ouverts rendent la résidence et la portabilité vérifiables au lieu de promises. Avec une passerelle Linux ouverte, Mosquitto pour le transport et TimescaleDB pour le stockage, chaque saut est inspectable et chaque réglage de région est sous votre contrôle, et non enfoui dans les conditions d'un éditeur. Une plateforme fermée peut affirmer un hébergement dans l'UE ; une pile ouverte permet à votre auditeur de le confirmer.

La portabilité cesse d'être un projet quand le modèle de données est ouvert dès le départ. Exposez une interface REST ou SQL documentée sur le magasin de séries temporelles, gardez les schémas sous gestion de version, et le droit d'accès du Data Act est satisfait par une fonctionnalité déjà livrée plutôt que par une course contre la montre lorsqu'un client l'invoque. Cette même ouverture vous protège de votre propre fournisseur : lorsque le code source, les schémas et les clés appartiennent au client, le départ d'aucun éditeur ne peut paralyser la plateforme.

La conformité est une question à laquelle vous devez répondre en continu : instrumentez donc le système pour qu'il réponde sans cellule de crise. Journalisez qui a accédé à quel jeu de données et quand, dans une piste d'audit en ajout seul qui survit à l'accès qu'elle enregistre. Étiquetez chaque flux avec sa région de stockage, afin qu'une affirmation de résidence puisse être vérifiée et non simplement énoncée. Documentez la hiérarchie des clés : lesquelles résident sur la passerelle, lesquelles dans le HSM ou le KMS du client, et qui peut les faire tourner.

Les réglementations évoluent, et l'interprétation de l'EU Data Act n'est pas encore stabilisée. Un système fondé sur des formats ouverts et des contrats de données clairs s'adapte à ce mouvement ; un système fermé attend une version de l'éditeur. Anticipez le changement plutôt que de vous figer contre lui.

Une plateforme souveraine est moins un produit qu'un ensemble de garanties rendues concrètes dans le code : stockage résident dans l'UE, brokers dans l'UE ou sur site, chiffrement sur la passerelle avec des clés détenues par le client, et un chemin d'export documenté. Melqart Systems construit ce chemin sur des passerelles Linux ouvertes et une pile de données open core, puis remet le code source, les schémas et les identifiants, de sorte que le système fonctionne sans nous.

Le résultat que veut un opérateur européen, c'est une maîtrise des données qui résiste à l'examen : les données résident là où le droit l'exige, les clés vous reviennent, et les questions d'un auditeur trouvent des réponses qui pointent vers l'architecture plutôt que vers la promesse d'un éditeur.