Missions

Quatre missions, décrites par ce qu'elles ont laissé en place.

On ne peut pas opérer ce qu'on ne comprend pas. Chaque mission descend jusqu'au système qui tient les nœuds.

Quatre systèmes, quatre secteurs, quatre façons d'être critique : une plateforme data bancaire, un centre de calcul pour la recherche publique, un cloud d'inférence sous maîtrise publique, un fonds documentaire industriel. Dans chaque cas : l'état de départ, la pile construite, et ce que les équipes du client exploitent aujourd'hui.⁽¹⁾

Nous descendons jusqu'en bas de la pile parce qu'il n'y a pas d'autre façon d'en répondre : le système qui tient les nœuds, le stockage, le plan de contrôle. Quand le client d'un composant que nous exploitons ne suffit pas, nous l'écrivons — deux d'entre eux sont publiés en Rust, sous licence libre.

Voir ce que nous publions

Les quatre missions, par secteur et par mode.
Nº	Secteur	Mode	Durée
01	Groupe bancaire national	Régie	en cours, plus de 12 mois
02	Centre de calcul de Montpellier	Conseil et mise en œuvre	en cours
03	Montpellier Métropole	Cloud souverain	en cours
04	Groupe industriel	Data & IA	mission ponctuelle

Comptes rendus

Ce que les clients exploitent aujourd'hui.

01 · Régie · en cours, plus de 12 mois

Groupe bancaire national

Une plateforme data interne remise en code, en flux GitOps et en libre-service.

Point de départ: Une plateforme data interne partagée par plusieurs équipes métier. Les déploiements se faisaient à la main, environnement par environnement. Deux installations censées être identiques ne l'étaient pas, et personne ne pouvait dire en quoi elles différaient. Ouvrir un environnement de travail à une équipe passait par une demande, puis par une attente.
Construit: Des ingénieurs embarqués dans les équipes du client, sur leur dépôt et leur chaîne de production. Ce qui se faisait à la main est décrit, versionné et relu.
Socle décrit en code : OpenTofu pour ce qui est une ressource, Ansible pour ce qui n'en est pas une.
Déploiements en flux GitOps, sous Argo CD : le dépôt fait foi, l'écart avec le cluster se lit et se corrige au même endroit.
Environnements de travail issus d'un gabarit unique, ouverts par les équipes elles-mêmes.
Métriques, journaux et traces sur la même horloge, du service applicatif jusqu'au nœud.
Chaque changement laisse une trace nominative : qui l'a proposé, qui l'a relu, quand il a été appliqué.
Déroulé: Régie ouverte pour douze mois, reconduite depuis. Nos ingénieurs travaillent sur le dépôt du client, dans ses rituels et à son rythme. Chaque chantier est mené à deux, un ingénieur du client et un des nôtres ; la fusion reste au client. Le transfert de compétences n'est pas un atelier de fin de mission, c'est la façon dont le travail se fait.
Produit: Deux environnements censés être identiques le sont ; l'écart, quand il existe, se lit dans un diff.
Une équipe ouvre son environnement sans passer par nous.
Un incident se rejoue : l'état de la plateforme au moment des faits est dans l'historique du dépôt.
Réversibilité : tout ce que nous écrivons vit dans les dépôts du client.
Mesure: 34 %
de temps d'ingénierie data récupéré
Une seule mission, après passage aux environnements self-service. Mesure déclarative de l'équipe cliente, avant/après. Non généralisable.Arrêté au mars 2026.
Stack: KubernetesArgo CDOpenTofuAnsibleGrafanaOpenTelemetry

Le groupe n'est pas nommé, et sa topologie réseau ne sera pas décrite.

02 · Conseil et mise en œuvre · en cours

Centre de calcul de Montpellier

Un socle Kubernetes sur système immuable, et une chaîne d'inférence GPU pour la recherche publique.

Point de départ: Un centre de calcul au service de la recherche publique. Les moyens de calcul existaient ; ce qui manquait, c'était une couche d'exploitation commune. Chaque service arrivait avec sa méthode d'installation, et rien ne garantissait qu'on saurait le remonter à l'identique après un incident. La demande des équipes portait déjà sur l'inférence de modèles, donc sur du GPU partagé.
Construit: Un socle Kubernetes sur système immuable, décrit intégralement dans un dépôt GitOps qui porte quatorze applications. Ce dépôt est le seul point d'entrée : il tient l'infrastructure comme les services qui tournent dessus.
Talos Linux sur les nœuds : ni shell, ni gestionnaire de paquets. Une API, et une configuration versionnée.
Un dépôt GitOps unique qui décrit quatorze applications. Ce qui n'y figure pas ne tourne pas.
Infrastructure découpée en modules : bastion, configuration de cluster, calcul, réseau, sécurité, socle Talos.
Stockage réparti Rook-Ceph, bases PostgreSQL sous CloudNativePG, secrets dans OpenBao.
Entrée réseau par Envoy Gateway, certificats délivrés et renouvelés par cert-manager, supervision livrée avec le reste.
Chaîne d'inférence GPU : NVIDIA GPU Operator pour l'accès aux cartes, KServe pour le service des modèles, LeaderWorkerSet pour répartir un modèle trop grand pour un seul nœud.
Au-dessus, ce que les équipes utilisent vraiment : une interface de conversation, et un environnement d'exécution cloisonné pour les agents.
Déroulé: Le dépôt s'est monté application par application : chacune entre avec sa description complète avant d'être mise en service. Il reste chez le centre et se lit sans nous — c'est la condition pour que la plateforme survive à la fin de la mission.
Produit: Une plateforme réinstallable : sa description tient dans un dépôt, pas dans la mémoire d'un administrateur.
De l'inférence servie aux équipes de recherche sur les cartes du centre, sans que les données quittent l'établissement.
Quatorze applications mises à jour par le même chemin, sous le même contrôle.
Moins de surface d'administration : sur un système immuable, il n'y a pas de configuration locale à réconcilier.
Stack: Talos LinuxKubernetesRook-CephCloudNativePGOpenBaoEnvoy Gatewaycert-managerKServeNVIDIA GPU Operator

La forme de la plateforme est publiable ; son plan ne l'est pas — ni hôte, ni adressage, ni dimensionnement.

03 · Cloud souverain · en cours

Montpellier Métropole

Un cloud de données et d'inférence exploité sous maîtrise publique.

Point de départ: Une collectivité qui veut instruire des cas d'usage d'intelligence artificielle sur ses propres données. Les offres disponibles supposaient toutes l'un ou l'autre : confier ces données à un opérateur soumis à une loi extraterritoriale, ou renoncer à l'ergonomie qui rend ces outils utilisables par des agents non techniciens.
Construit: Un cloud interne de données et d'inférence, déployé sous maîtrise publique : les modèles tournent sur l'infrastructure de la collectivité, et les journaux restent de son côté.
Inférence exécutée sur l'infrastructure de la collectivité : les requêtes ne sortent pas du périmètre.
Une identité unique pour tous les services : qui accède à quoi se décide au même endroit.
Journal d'accès conservé et lisible par la collectivité, sans passer par nous.
Stockage objet et base relationnelle sous son contrôle, clés comprises.
Composants open source de bout en bout : l'exploitation est reprenable par un tiers.
Produit: Des cas d'usage instruits sans que les données quittent le périmètre public.
Les clés et les journaux du côté de la collectivité, pas du nôtre.
Une dépendance bornée : aucun composant du socle n'est propriétaire.
Stack: KubernetesvLLMKeycloakPostgreSQLMinIO

Ni les usages métier, ni les jeux de données, ni les délibérations en cours.

04 · Data & IA · mission ponctuelle

Groupe industriel

Un fonds documentaire hétérogène rendu interrogeable, chaque réponse citant son document.

Point de départ: Un fonds documentaire accumulé sur des années : PDF numérisés, courriels, exports de bases métier. L'information existait. La retrouver supposait de savoir d'avance où elle avait été rangée, donc d'avoir été là quand on l'a rangée.
Construit: Une chaîne d'ingestion qui accepte les documents tels qu'ils arrivent, un socle de tables ouvertes interrogeable en SQL, une indexation sémantique — et une règle côté restitution : une réponse sans document source n'est pas une réponse.
Ingestion des formats tels qu'ils arrivent, OCR compris pour ce qui n'est qu'une image.
Tables au format ouvert Iceberg sur stockage objet : le moteur qui lit n'est pas tenu d'être celui qui a écrit.
Interrogation SQL par Trino, sur les mêmes tables que le reste du système d'information.
Indexation sémantique et recherche vectorielle dans PostgreSQL, à côté des données plutôt que dans un service tiers.
Restitution exposée en MCP : les outils déjà en place interrogent le fonds, sans interface supplémentaire à faire adopter.
Produit: L'information se retrouve en secondes, le document affiché à côté de la réponse.
Une réponse sans source se repère immédiatement : elle n'en affiche aucune.
Le fonds reste exploitable par d'autres outils : les tables sont ouvertes, l'index est dans la base.
Mesure: 1 h
par jour et par collaborateur sur le traitement documentaire
Après intégration de la recherche documentaire assistée par IA. Périmètre : les collaborateurs équipés, sur un seul client.Arrêté au mars 2026.
Stack: TrinoApache IcebergOCRpgvectorMCP

Ni le nom du groupe, ni la nature des documents, ni les volumes.

Une mission comparable à la vôtre ? Décrivez le système et la contrainte qui pèse dessus.

Parler d'une mission comparable

Modes d'engagement

Trois façons de nous faire intervenir.

Le mode décide qui porte l'exploitation. Le périmètre se discute après, jamais avant.

Régie

Cadence 12 mois et plus

Des ingénieurs embarqués dans vos équipes

Nos ingénieurs travaillent dans vos équipes, sur vos outils et vos processus. Transfert de compétences continu, accès direct aux experts, priorité sur le support critique.

Inclus: Ingénieurs dédiés, pas de rotation subie
Transfert de compétences continu vers vos équipes
Priorité sur le support critique
Réversibilité : tout ce que nous écrivons vous appartient
Idéal pour: Transformation continue, équipes infrastructure et data.
Stack: KubernetesTalosArgo CDOpenTofuTrinoApache Iceberg

L'exploitation reste la vôtre : ni astreinte, ni hébergement.

Audit & architecture

Cadence 1 à 3 mois

Une décision d'architecture, chiffrée

Audit de data stack, audit de sécurité applicative, plan de migration, dimensionnement infrastructure et GPU. Le livrable est un rapport que votre comité peut lire — avec ses hypothèses et ses limites écrites au même endroit que ses conclusions.

Inclus: Audit de data stack et de sécurité applicative
Architecture cible et plan de migration
Dimensionnement infrastructure et inférence GPU
Livrable écrit, opposable en comité
Idéal pour: Cadrage, décision stratégique, instruction d'un dossier d'investissement.
Stack: Zero TrustmTLSRGPDNIS2vLLMTriton

Le rapport publie ses hypothèses. Il ne met pas le plan en œuvre et ne délivre aucune certification.

Support open source

Cadence continu

Un seul contrat pour toute votre stack open source

Vous ne voulez pas un contrat de support par brique. Nous couvrons l'ensemble de vos composants open source avec un forfait mensuel unique, un point de contact, et une escalade directe vers nos ingénieurs — pas une hotline généraliste.

Inclus: Un forfait unique, pas un contrat par composant
Escalade directe N2/N3 vers nos ingénieurs
MCO, correctifs et veille CVE inclus
Périmètre de composants écrit au contrat
Périmètre couvert: KubernetesTalos LinuxKubeVirtPostgreSQLTrinoCeph / MinIOGrafanaAirflowKafkaKeycloakIstio / Ciliumcert-manager
Idéal pour: Sécurité au quotidien, budget maîtrisé, stack open source large.
Stack: PostgreSQLCephKafkaKeycloakCiliumGrafanaAirflow

Les briques propriétaires tierces ne sont pas couvertes.

Les trois modes se combinent : un audit peut précéder une régie, un contrat de support peut couvrir ce qu'une régie a construit. ^▪

Voir les trois expertises en détail

Mesures transverses

Les deux chiffres qui portent sur l'ensemble.

Tout le reste vient d'une mission unique, et se lit sur la fiche correspondante.

1 M€

facturé sur nos vingt-six premiers mois

Chiffre d'affaires hors taxes cumulé, toutes missions confondues. Sans levée de fonds.Arrêté au ⟨mars 2026⟩.

100 %

de rétention client

Dénominateur : l'ensemble des clients entrés sous contrat depuis la création. Aucun n'a résilié.Arrêté au ⟨mars 2026⟩.

Ces deux mesures portent sur l'entreprise entière depuis sa création : le cumul facturé, et le nombre de clients partis. Les autres chiffres du site proviennent chacun d'une seule mission et sont publiés au registre avec leur dénominateur, leur méthode et leur date d'arrêté. ^▪

Chaque chiffre du site est repris au registre des sources. Voir le registre des sources.

Prendre contact

Une mission comparable à la vôtre.

Décrivez le système, sa criticité et la contrainte juridique qui pèse dessus. Nous répondons par ce que nous avons déjà fait de comparable, et par ce que nous n'avons jamais fait. Un ingénieur vous répond, pas un formulaire.

Parler d'une mission comparable Lire le dossier de souveraineté