Engagements

Four engagements, described by what they left in place.

You cannot operate what you do not understand. Every engagement goes down to the system that holds the nodes.

Four systems, four sectors, four ways of being critical: a banking data platform, a computing centre for public research, an inference cloud under public control, an industrial document base. In each case: the starting point, the stack that was built, and what the client's teams operate today. (1)

We go to the bottom of the stack because there is no other way to answer for it: the system that holds the nodes, the storage, the control plane. When the client library for a component we operate is not good enough, we write it — two of them are published in Rust, under free licences.

See what we publish

The four engagements, by sector and by model.
No.SectorModelDuration
01National banking groupEmbedded engagementongoing, more than 12 months
02Montpellier computing centreAdvisory and implementationongoing
03Montpellier MétropoleSovereign cloudongoing
04Industrial groupData & AIfixed-term engagement

Records

What the clients operate today.

01 · Embedded engagement · ongoing, more than 12 months

National banking group

An internal data platform rebuilt as code, as a GitOps flow, and self-service.

Starting point
An internal data platform shared by several business teams. Deployments were done by hand, environment by environment. Two installations meant to be identical were not, and nobody could say where they diverged. Opening a working environment for a team meant filing a request, then waiting.
Built

Engineers embedded in the client's teams, on their repository and their delivery chain. What was done by hand is now described, versioned and reviewed.

  • The base described as code: OpenTofu for what is a resource, Ansible for what is not.
  • Deployments as a GitOps flow under Argo CD: the repository is the reference, and drift from the cluster is read and corrected in the same place.
  • Working environments from a single template, opened by the teams themselves.
  • Metrics, logs and traces on one clock, from the application service down to the node.
  • Every change leaves a named trail: who proposed it, who reviewed it, when it was applied.
How it ran
An embedded engagement opened for twelve months, renewed since. Our engineers work on the client's repository, in its rituals and at its pace. Every piece of work is done in pairs, one of the client's engineers and one of ours; merging stays with the client. Skills transfer is not a closing workshop, it is how the work gets done.
Outcome
  • Two environments meant to be identical are; where they differ, the difference reads as a diff.
  • A team opens its own environment without going through us.
  • An incident can be replayed: the platform's state at the time sits in the repository history.
  • Reversibility: everything we write lives in the client's own repositories.
Measured
34 %
of data-engineering time recovered
A single engagement, after moving to self-service environments. Self-reported by the client team, before/after. Not generalisable.As of March 2026.
Stack
KubernetesArgo CDOpenTofuAnsibleGrafanaOpenTelemetry

The group is not named, and its network topology will not be described.

02 · Advisory and implementation · ongoing

Montpellier computing centre

A Kubernetes base on an immutable OS, and a GPU inference chain for public research.

Starting point
A computing centre serving public research. The compute was there; what was missing was a common operating layer. Every service arrived with its own installation method, and nothing guaranteed it could be brought back identically after an incident. Research teams were already asking for model inference, which means shared GPUs.
Built

A Kubernetes base on an immutable OS, described end to end in a GitOps repository that carries fourteen applications. That repository is the only way in: it holds the infrastructure as well as the services running on it.

  • Talos Linux on the nodes: no shell, no package manager. An API, and a versioned configuration.
  • A single GitOps repository describing fourteen applications. What is not in it does not run.
  • Infrastructure split into modules: bastion, cluster configuration, compute, network, security, Talos base.
  • Rook-Ceph distributed storage, PostgreSQL databases under CloudNativePG, secrets in OpenBao.
  • Ingress through Envoy Gateway, certificates issued and renewed by cert-manager, monitoring shipped with the rest.
  • GPU inference chain: NVIDIA GPU Operator for card access, KServe for model serving, LeaderWorkerSet to spread a model too large for a single node.
  • On top, what the teams actually use: a chat interface, and a sandboxed runtime for agents.
How it ran
The repository was built application by application: each one enters with its full description before it goes live. It stays with the centre and reads without us — the condition for the platform to outlive the engagement.
Outcome
  • A reinstallable platform: its description sits in a repository, not in an administrator's memory.
  • Inference served to research teams on the centre's own cards, with no data leaving the institution.
  • Fourteen applications updated through the same path, under the same control.
  • Less administration surface: on an immutable system there is no local configuration to reconcile.
Stack
Talos LinuxKubernetesRook-CephCloudNativePGOpenBaoEnvoy Gatewaycert-managerKServeNVIDIA GPU Operator

The shape of the platform is publishable; its plan is not — no host, no addressing, no sizing.

03 · Sovereign cloud · ongoing

Montpellier Métropole

A data and inference cloud operated under public control.

Starting point
A local authority that wants to explore AI use cases on its own data. Every available offer required one or the other: hand that data to an operator subject to extraterritorial law, or give up the ergonomics that make these tools usable by non-technical staff.
Built

An internal cloud for data and inference, deployed under public control: the models run on the authority's own infrastructure, and the logs stay on its side.

  • Inference runs on the authority's own infrastructure: queries do not leave the perimeter.
  • One identity across every service: who gets access to what is decided in a single place.
  • Access logs kept and readable by the authority, without going through us.
  • Object storage and relational database under its control, keys included.
  • Open source components end to end: operations can be taken over by a third party.
Outcome
  • Use cases explored without the data leaving the public perimeter.
  • Keys and logs on the authority's side, not ours.
  • A bounded dependency: no component of the base is proprietary.
Stack
KubernetesvLLMKeycloakPostgreSQLMinIO

Not the business use cases, not the datasets, not the ongoing deliberations.

04 · Data & AI · fixed-term engagement

Industrial group

A heterogeneous document base made searchable, every answer citing its document.

Starting point
A document base accumulated over years: scanned PDFs, emails, line-of-business exports. The information was there. Finding it meant knowing in advance where it had been filed — which meant having been there when it was.
Built

An ingestion pipeline that takes documents as they come, a base of open tables queried in SQL, semantic indexing — and one rule on the answering side: an answer without a source document is not an answer.

  • Ingestion of formats as they come, OCR included for what is only an image.
  • Tables in the open Iceberg format on object storage: the engine that reads need not be the one that wrote.
  • SQL querying through Trino, on the same tables as the rest of the information system.
  • Semantic indexing and vector search inside PostgreSQL, next to the data rather than in a third-party service.
  • Answering exposed over MCP: the tools already in place query the base, with no extra interface to get adopted.
Outcome
  • Information is found in seconds, with the document shown next to the answer.
  • An answer without a source is obvious: it displays none.
  • The base stays usable by other tools: the tables are open, the index sits in the database.
Measured
1 h
per day per employee on document handling
After deploying AI-assisted document search. Scope: equipped employees, at a single client.As of March 2026.
Stack
TrinoApache IcebergOCRpgvectorMCP

Not the group's name, not the nature of the documents, not the volumes.

An engagement comparable to yours? Describe the system and the constraint that bears on it.

Discuss a comparable engagement

Engagement models

Three ways to bring us in.

The model decides who carries operations. Scope is discussed afterwards, never before.

Embedded

Cadence 12 months and up

Engineers embedded in your teams

Our engineers work inside your teams, on your tooling and your processes. Continuous skills transfer, direct access to the experts, priority on critical support.

Included
  • Dedicated engineers, no imposed rotation
  • Continuous skills transfer to your teams
  • Priority on critical support
  • Reversibility: everything we write belongs to you
Best suited to
Continuous transformation, infrastructure and data teams.
Stack
KubernetesTalosArgo CDOpenTofuTrinoApache Iceberg

Operations stay yours: no on-call, no hosting.

Audit & architecture

Cadence 1 to 3 months

An architecture decision, costed

Data stack audit, application security audit, migration plan, infrastructure and GPU sizing. The deliverable is a report your committee can read — with its assumptions and its limits written in the same place as its conclusions.

Included
  • Data stack and application security audit
  • Target architecture and migration plan
  • Infrastructure and GPU inference sizing
  • A written deliverable that holds up in committee
Best suited to
Scoping, strategic decisions, building an investment case.
Stack
Zero TrustmTLSRGPDNIS2vLLMTriton

The report publishes its assumptions. It does not implement the plan and issues no certificate.

Open source support

Cadence ongoing

One contract for your whole open source stack

You do not want one support contract per component. We cover your open source stack with a single monthly fee, one point of contact, and direct escalation to our engineers — not a general-purpose helpdesk.

Included
  • A single fee, not one contract per component
  • Direct L2/L3 escalation to our engineers
  • Maintenance, patching and CVE monitoring included
  • Component scope written into the contract
Covered scope
KubernetesTalos LinuxKubeVirtPostgreSQLTrinoCeph / MinIOGrafanaAirflowKafkaKeycloakIstio / Ciliumcert-manager
Best suited to
Day-to-day security, predictable budget, a broad open source stack.
Stack
PostgreSQLCephKafkaKeycloakCiliumGrafanaAirflow

Third-party proprietary software is not covered.

The three models combine: an audit can precede an embedded engagement, a support contract can cover what an embedded team has built. ▪

See the three practices in detail

Cross-cutting measurements

The two figures that cover the whole company.

Everything else comes from a single engagement, and reads on that engagement's record.

1 M€
invoiced over our first twenty-six months
Cumulative revenue excluding tax, all engagements combined. No outside funding.As of ⟨March 2026⟩.
100 %
client retention
Denominator: every client under contract since inception. None has terminated.As of ⟨March 2026⟩.

These two measurements cover the company as a whole since inception: cumulative invoiced revenue, and the number of clients that have left. Every other figure on this site comes from a single engagement and is published in the register with its denominator, its method and its cut-off date. ▪

Every figure on this site is listed in the source register. See the source register.

Get in touch

An engagement comparable to yours.

Describe the system, how critical it is, and the legal constraint that bears on it. We answer with what we have already done that is comparable, and with what we have never done. An engineer replies, not a form.

Discuss a comparable engagement Read the sovereignty brief