Ce que nous éditons
Hyperfluid est un cloud interne : 20 services en libre-service dans une seule console, installés dans votre datacentre, votre compte cloud 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 managé en Europe, votre datacentre, votre compte cloud, 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
Nous n'avons pas changé de métier. Nous avons industrialisé ce que nos missions répétaient.
Nous avons commencé par exploiter les piles des autres. Un moteur de requête ici, un cluster Kubernetes là, un entrepôt objet, un annuaire d'identités, une supervision recâblée à chaque ajout. D'une mission à la suivante, les mêmes briques revenaient et les mêmes semaines se rejouaient : intégrer, sécuriser, superviser, documenter, transmettre.
Ce qui se répétait, nous l'avons industrialisé. Pas un composant de plus : ce qui les tient ensemble. Une console où les services se trouvent, un annuaire d'identités qui vaut pour tous, une supervision qu'on ne refait pas à chaque ajout, des quotas et des rôles posés une fois au-dessus du catalogue. C'est cela, un cloud interne. La procédure d'installation documentée mène aujourd'hui du serveur nu au premier SELECT en < 1 h (1) .
Écrire cela oblige à comprendre chaque brique jusqu'en bas. On n'empaquette pas un stockage distribué, un moteur SQL ou un plan de contrôle Kubernetes en restant à la surface de sa documentation : il faut lire son code, connaître ses modes de défaillance, savoir ce qu'il fait quand un disque tombe ou qu'un certificat expire. C'est le prix de l'édition, et c'est ce qui rend une équipe capable d'opérer les piles de ses clients. On n'opère pas ce qu'on ne comprend pas.
Preuve d'ingénierie
Deux clients d'infrastructure écrits en Rust, publiés sous licence ouverte, en production dans la plateforme que nous éditons.
8 316 lignes de Rust · 14 fichiers
Client gRPC de l'API Talos Linux, l'OS immuable de SideroLabs sur lequel tournent les clusters que nous exploitons. mTLS par défaut, surface typée générée depuis les fichiers proto officiels.
Un OS immuable n'a ni shell ni SSH : tout passe par son API. Piloter un parc depuis notre propre code supposait d'en écrire le client.
6 374 lignes de Rust · 45 fichiers
Client Trino pour Rust. Le support Presto a été retiré, les fonctionnalités récentes du moteur ajoutées — dont le protocole spooling, qui fait sortir les grands résultats par le stockage objet plutôt que par le canal HTTP.
Interroger un moteur SQL distribué depuis un service Rust, sans repasser par une JVM et sans plafonner sur les résultats volumineux.
Près de quinze mille lignes de Rust publiées, auxquelles s'ajoute notre contribution à 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
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 support 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 hotline 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.
