s0
BUSL-1.1 · Apache-2.0 au 18 août 2030
Passerelle d'autorisation compatible S3 : chaque requête est désérialisée, soumise à une politique OPA/ABAC, puis réémise vers le stockage sous une identité par locataire.
Ce que nous éditons
Nous éditons Hyperfluid.
Hyperfluid est un nuage interne : 20 services en libre-service dans une seule console, installés dans votre centre de données, votre compte infonuagique ou un réseau air-gap.
Le catalogue service par service, la documentation d'installation, la grille tarifaire et la console d'administration sont publiés sur hyperfluid.cloud.
Écrire cette plateforme nous a obligés à descendre jusqu'au bas de la pile. C'est de là que vient ce que nous savons faire chez nos clients.
Les quatre cibles de déploiement — tenant géré en Europe, votre centre de données, votre compte infonuagique, réseau air-gap — et le droit applicable à chacune sont détaillés colonne par colonne dans le dossier de souveraineté.
Pourquoi nous l'avons écrit
Rendre le contrôle aux entreprises européennes.
Une entreprise européenne doit pouvoir exploiter ses données sans les confier à un opérateur soumis à une loi étrangère.
Les grands clouds sont efficaces, et ils restent soumis au droit de leur pays d'origine. Une injonction étrangère peut atteindre des données hébergées en Europe, sans que l'entreprise qui les a produites en soit informée. Ce n'est pas une hypothèse : c'est le régime juridique sous lequel ces services sont vendus.
La souveraineté ne se délègue pas par contrat, elle se tient par l'architecture. Hyperfluid s'installe dans votre périmètre — votre matériel, ou l'hébergeur que vous avez choisi. Les données, les journaux et les clés y restent, et le contrat d'infrastructure reste à votre nom.
C'est ce qui rend le contrôle vérifiable plutôt que déclaré. Vous ne nous demandez pas de promettre que vos données ne sortent pas : vous le lisez dans la topologie et dans le contrat.
Preuve d'ingénierie
Quand une brique nous manquait, nous l'avons écrite.
Trois briques écrites en Rust, dont le code est publié, en production dans la plateforme que nous éditons.
talos-rust-client
MIT OR Apache-2.0
Client gRPC de l'API Talos Linux, l'OS immuable sur lequel tournent les clusters que nous exploitons. Un OS immuable n'a ni shell ni SSH : tout passe par son API.
trino-rust-client
Apache-2.0
Client Trino pour Rust, avec le protocole spooling : interroger un moteur SQL distribué sans repasser par une JVM et sans plafonner sur les résultats volumineux.
Nous contribuons aussi à Ferris Key, serveur d'authentification en Rust sous Apache-2.0. Écrire le client d'un composant, c'est en connaître le protocole, les erreurs et les limites mieux que sa documentation ne les décrit.
Pour un client de services
L'équipe qui intervient chez vous est celle qui édite la plateforme.
Mêmes ingénieurs, mêmes dépôts, mêmes composants.
Nos ingénieurs interviennent en régie, en audit d'architecture ou en soutien open source sur des piles que nous exploitons déjà pour notre propre compte : Kubernetes et Talos Linux, PostgreSQL, Trino, Ceph, Kafka, Keycloak, la chaîne d'inférence GPU. Quand un incident sort du manuel, l'escalade va vers les gens qui ont écrit le code, pas vers une ligne d'assistance généraliste. ▪
Aucun client n'est tenu de déployer Hyperfluid pour travailler avec nous : la plateforme prouve le niveau, elle n'est pas la condition de la mission.