Information Systems & Cloud

Every new requirement reopens the whole thing: three weeks announced, two months in practice, and a slightly more brittle system each time. The question is not the technology — it is what it lets you add without reopening everything.

An information system is judged by what it lets you add tomorrow without reopening everything.

Operable system

Billions of rows on a desk — and online when it must

An analytical database does not need a data centre to begin. The scene sorts five thousand four hundred rows into columns, compresses them, settles them onto the outline of a laptop, then sends a copy to a server rack and keeps both current: two copies, one truth. A shape and a movement — no real data in the scene.

Information systems & cloud

The database that fits on a desk

Five thousand four hundred rows in a heap sort themselves into columns, one per type; what looks alike compresses; the whole settles onto the outline of a laptop. Then a copy leaves for a server rack, and a pulse keeps both current: two copies, one truth.

A company that believes it takes a data centre to query billions of rows — and would like to start on the machine it already owns.

Watch the heap become columns, then go online.

Three.js · WebGL · 5 400 cubes instanciés · 4 types · compression · synchronisation · récit en 5 chapitres · repli sans WebGL

The data platform, seen from the infrastructure

What holds a platform up as it grows: contracts, layers, and what refuses to write when the count is off.

DEV & TECHNOLOGY · DATA

Know where data comes from before deciding with it.

Contracts, quality, lineage and ownership make the platform explainable.

Fast but untraceable data mainly accelerates the wrong decision.

RELIABLE · DEGRADED · QUARANTINED · N.A.

Method

Versioned data contracts, lineage events and freshness / quality SLOs.

Contract: schema · semantics · owner · compatibility
Lineage: dataset · job · run
Quality: completeness · uniqueness · validity · freshness
Breaking change · deprecation window
Quarantine and idempotent replay
Observability: traces · metrics · logs

Lineage establishes where data comes from and where it goes. Quality and lawfulness are assessed on top, and we assess them.

Systems that hold on their own, told without the names

A site served across two worlds, a warehouse run every night without intervention, a bridge to the outside where nothing nominative crosses: what we set up, what it produced, and what was hard. Names removed, volumes kept.

TRACK RECORD · REAL ASSIGNMENTS, NAMES WITHHELD

01
Our own house — a firm with three practices, two audiences that are not looking for the same thing, and two languages.
When · Summer 2026, in production and reworked weekly.
What we did
We designed and built this site end to end: architecture, design, copy, three-dimensional scenes, and the English mirror. English is not a button that repaints the page — it is a set of URLs of its own, without which no search engine ever sees it.
What it produced
A two-world site, fully bilingual, where every English page has its own URL and its reciprocal link to the French one. Seven automated checks guard the release, chained behind a single command: background regimes, stylesheets, brand charter, text tones, structured data, per-language URLs, sub-page substance. The first defect stops the chain — it is a refusal, not a warning.
What was hard
The English already existed, but as a display state: no URL served it. Two states of one document are not two documents — the tag that links languages links URLs, and it had nothing to link. The URLs had to be split before we could hope to be read outside France.
02
Our own house first, then the same pattern taken up for organisations whose data lives in tools that do not talk to each other.
When · Built in 2026, run every evening since.
What we did
We built an analytical warehouse and the scheduler that fills it. It starts on its own every evening, step by step. Machine off, it starts at next boot; no network, it waits; a failed step does not stop the others and runs again the next day. Every step writes its own dated verdict, and the evening report separates three states: failure, deferral, and success after a busy machine.
What it produced
A daily scheduler whose number of steps is read from the code and never from a document, a dated log per step, and a daily status page regenerated at a fixed path — having to hunt for the right file would already be human intervention.
What was hard
Billions of rows held on a desktop machine with sixteen gigabytes of memory. That is not a boast: it is what dictates the architecture — source-by-source processing, columnar formats, and a single write lock, because one reader left open is enough to block an entire night.
03
An organisation that must open part of its analysis to the outside without a single name crossing the wall.
When · September 2026, in service.
What we did
We connected a public interface to an internal analysis service: listening closed to the local loopback, per-caller rate limiting, machine secret read server-side — never typed on a command line, where it would linger in the history and in the process table — and a name-stripping pass run before anything is displayed.
What it produced
A bridge test that replays the four decisions (accepted host, rate, served mode, free text) and a bench that injects fabricated names into the chain to verify they come out stripped. Both run with no server switched on, so they actually get run.
What was hard
“Internal” was read from a header that any non-browser client sets freely: from the local network, a call could declare itself internal and obtain the full mode. You do not get better at checking who knocks — you close the door that opens onto the street.

No client name is published, with or without their consent. We publish no win rate: it is not measured, and an unmeasured figure is not a reference.

What we do

Architecture and IT master plan: what lives where, and why.
Cloud, hosting, environments, backups and tested restoration.
Integrations and APIs between existing tools: ERP, CRM, business applications.
Migrations: data transfer, staged cutover, planned rollback.
Industrialised deployment and production monitoring.
Separating what is read from what is written: a single process holding the lock is enough to block a nightly rebuild, and writes must retry rather than give up.
Measuring what weighs and what accumulates every month, with the decision that stops it. A logical size is not a disk footprint, and an index can be rebuilt: counting it as data is counting the table of contents in the page count.
Disaster recovery actually rehearsed: a restoration never executed is not a restoration, it is an intention.

What we deliver

Architecture diagram & IT master plan

Environments & deployment pipeline

Documented APIs & connectors

Migration plan & cutover procedure

Backup plan & report of a restoration actually executed

Dated log of footprint measurements, with the gap computed between readings

Monitoring, alerting & run procedures

Repair procedure printed by the tool that reports the failure

The method

Map

The estate as it really is, including what is written down nowhere — and above all what runs by itself at night with nobody remembering it.

Draw

A sober target: complexity is only worth buying when it pays.

Cut over

In stages, with a rollback available at every step. We measure the space first and build alongside: destroying before knowing you can rebuild is not a rebuild, it is a destruction followed by hope.

Operate

Measure, alert, update: a system lives, it is never finished. And yesterday's reading is kept, or nothing can signal a drift.

WHAT YOU WILL HAVE IN HAND · The Flow and Dependency Map

Add one capability: the map reveals reused contracts, crossed boundaries and the point that must change.

What depends on what, in cascade.

We design a foundation that makes future change less expensive to understand, test and deliver. The visible architecture connects business capabilities, the data they use, the systems executing them and accountability boundaries.

The executive sees critical dependencies, single points of failure and what can be replaced without touching the rest. Cloud, on-premises, sovereign or air-gapped choices are presented as usage and operating boundaries, not labels.

Explore the architecture

Capability → contract → service → data → control

The specialist opens API contracts, events, owners, service objectives, data flows and recovery modes. The map separates logical dependency from physical implementation so migration remains an explicit change.

Scenario mode removes a dependency, closes a network zone or pins a release. It shows the service that continues, expected degradation, evidence to observe and recovery action. A dependency without an owner remains N.F. and blocks promotion.

Mapping of capabilities, applications, data and interfaces, with owners, obsolescence and technical debt.

C4, trust boundaries, ADRs, architecture principles and a responsibility matrix.

Workload placement based on latency, criticality, residency, connectivity, skills, reversibility and unit cost.

Control plane, data plane and management plane kept separate, with inbound and outbound flows explicitly authorised.

Zero Trust: human and service identity, per-resource authentication and authorisation, with no implicit network-based trust.

API, event, CDC, queue, bounded retry, stable event ID, idempotent consumer and circuit breaker.

Infrastructure as Code, immutable signed artefacts, configuration drift, promotion and attestation.

SLOs, error budget, metrics, logs, traces, profiles, alerts and runbooks.

RTO, RPO, immutable/offline backup, restoration, failover and recovery testing.

Progressive delivery, canary, blue/green, feature flags, rollback strategy and expand/contract migration.

SBOM, VEX, provenance, mirrored repository, offline updates, PKI/KMS/HSM and secrets lifecycle management.

FinOps and reversibility: allocation, cost per service unit, commitments, egress, data portability and a tested exit plan.

Where this comes from

ILLUSTRATIVE3 sites including 1 air-gapped zone, for a product depending on 27 incompletely inventoried interfaces.provisional
ILLUSTRATIVE4 external execution dependencies incompatible with the air-gapped profile: identity, artefact registry, telemetry, licence validation.provisional
ILLUSTRATIVEOffline package of 14 artefacts; 1 unapproved artefact triggers full package rejection.provisional
ILLUSTRATIVERestoration test beyond the 4 h target RTO, with a 38 min overrun: OPEN GAP status.provisional

The map illuminates the architecture and its dependencies; it claims no external status and replaces neither the physical and logical verification of an air-gapped profile, nor a qualification or accreditation, which fall under a separate scope and separate evidence.

THE QUESTIONS THAT SET THE PRICE

What we will ask you before we start.

Four questions we ask on every file in this domain. Each comes from an incident someone paid for — us, or a client before us.

Can a single reader block the whole night?

Yes: a single process holding the lock is enough to prevent a rebuild. We separate what is read from what is written, we publish frozen reference tables and we make writes retry.

If nobody asks it — A nightly update failing silently because of a tab left open.

Do we destroy before knowing whether we can rebuild?

Never. Every rebuild measures the space first and builds alongside; the existing asset is touched only once its replacement is proven. Destroying before knowing is not a rebuild: it is a destruction followed by hope.

If nobody asks it — An index destroyed at one in the morning, and a rebuild impossible for lack of twenty-five gigabytes.

What does the infrastructure really cost, and what makes it grow?

We measure what weighs — databases, files, indexes — and what accumulates every month, with the decision that stops it. A logical size is not a disk footprint, and an index can be rebuilt: it does not count as data.

If nobody asks it — A disk full in ten days, and nobody knows what filled it.

What happens when the system fails, for whoever arrives three weeks later?

The what-to-do-when-it-breaks is printed by the tool that reports the failure, with the command to run. The why always gets recorded; the repair always gets forgotten — yet it is the only thing the person who finds a red light needs.

If nobody asks it — A failure at eight in the morning and instructions nowhere to be found.

CAPABILITY SCENARIO — NOT A CLIENT REFERENCE

When we get the call

A company accumulates tools that do not talk to each other and re-enters the same data three times. We map the flows, open the integrations that remove the re-keying and place the rest behind an explicit architecture. The cutover runs in stages, with a rollback at every step.

Related disciplines

A file rarely draws on a single discipline.

Cybersecurity & Audit

Contained exposure

Development & Product Design

Operable product

All disciplines in this practice

Planning something in Information Systems & Cloud?

Write to us. We respond with an assessment, not a brochure.

Write to us