Manufacturing & production
In-line quality control, predictive maintenance and forecasting, under cycle-time and CE marking constraints.
View sector
Industries
Four sectors where we are useful
We work where AI has to reach production under constraint: data produced by ageing line-of-business systems, decisions that must be justified to a third party, and errors that do not cost the same depending on which way they go.
The four sectors
Healthcare & social care
Clinical text structuring, document retrieval and activity forecasting, under HDS hosting, GDPR and medical device constraints.
View sector
Public sector
Request routing, retrieval over regulatory corpora and archive transcription, under sovereignty, accessibility and reversibility constraints.
View sector
Insurance & mutuals
Assisted case handling, audit targeting and risk modelling, with explainability and validation treated as design requirements.
View sector
Why these four
These four sectors share three traits that change how the work is done. Their data comes from ageing line-of-business systems rather than analytics tooling, so a project starts with access and quality, never with the choice of model. Their decisions have to be justified to a third party, an auditor, a supervisor, a court, a policyholder or a citizen, which rules out certain architectures from the start. And error is asymmetric: a false negative and a false positive do not carry the same cost, which changes everything about how you pick a threshold.
This is the ground our two engineers have shipped on. We have no industry practices, no offices, and no management layer to bill. We have a method, a measurement written down before we start, and the habit of environments where nothing goes live without a file. For a mid-market company that is usually what is missing: not one more consultancy, but engineers who stay until it runs in production.
That choice has a cost and we own it. With two of us, we take one engagement at a time. If your programme needs twenty consultants deployed in parallel across several countries, we are not the right people, and we will say so at the first meeting rather than the third.
We also work outside these four sectors, wherever the mechanics are the same: a documented process, accessible data, a baseline we can actually record. These pages simply describe the contexts where we arrive with the most perspective, and where scoping costs you the least.
How we qualify a use case.
We rank every lead on two axes: estimated annual gain and integration effort. The workshop aims at the top-left corner, the quick win, and screens out the traps before they cost anything.
Glossary
The terms that come up in our conversations, explained for a decision-maker rather than a data scientist.
- Agent
- A program that chains calls to a model and to tools to carry out a task in several steps, rather than answering in one shot. The autonomy you grant it is a design choice: the wider it is, the more guardrails and traceability matter.
- AI Act
- The European regulation on artificial intelligence. It classifies systems by risk level and imposes growing obligations, up to a heavy regime for high-risk systems. In our sectors it combines with existing sector rules rather than replacing them.
- Computer vision
- The automatic analysis of images: spotting a defect on a part, reading a document, locating an object. Its performance depends as much on the acquisition protocol, framing, lighting, cadence, as on the model itself.
- Data governance
- The set of rules that state where data comes from, what it is used for, who accesses it and how long it is kept. It is the first building block of a regulated AI project: without it, neither compliance nor reproducibility holds.
- DORA
- The European regulation on digital operational resilience for the financial sector. It governs, among other things, third-party ICT risk: an AI service called from a third party falls within this perimeter, with its contractual and monitoring requirements.
- Fine-tuning
- Readjusting a pre-trained model on your own data to specialise it for your task. Useful when the expected behaviour is stable and well defined; often unnecessary when good document retrieval (see RAG) is enough to give the model its context.
- GDPR
- The General Data Protection Regulation. It sets the legal bases for processing, the rights of individuals and the obligations of the controller. Health data falls under a reinforced regime; fully automated decisions are specifically governed.
- Gradient boosting
- A family of models that combines many simple decision trees, each correcting the errors of the previous ones. On tabular data it often stays more accurate and more explainable than a neural network, and it is easier to defend in front of a supervisor.
- Guardrail
- A control that bounds what an AI-based system can produce or do: input and output filtering, explicit refusal outside its scope, a confidence threshold below which a human takes over. A guardrail does not improve average performance, it limits the cost of extreme cases.
- Hallucination
- A false answer that a language model produces with the same confidence as a correct one. The risk is not removed, it is contained: output constrained by a schema, mandatory source citation, explicit refusal when the knowledge base does not hold the answer.
- HDS
- Hosting of health data (hébergement de données de santé). In France, hosting personal health data requires a certification. The constraint also covers training environments and backups, not just production.
- High-risk system
- The AI Act category that triggers the heaviest set of obligations: risk management, data governance, documentation, logging, human oversight, demonstrated robustness. Several use cases in our sectors fall into it, often overlapping obligations that already exist under sector law.
- Industrialisation
- The move from a working prototype to a service that holds in production: integration into the information system, monitoring, controlled cost, handover to your teams. This is where most AI projects stop, for lack of having prepared it.
- Inference
- Using an already-trained model to produce a prediction on new data, as opposed to training, which builds the model. Where inference runs, on your side or at a third party, is a compliance decision as much as a technical one.
- Inference cost
- What a prediction costs once the model is in service, compute, hardware and energy, multiplied by the real volume. A model that impresses in a demo can become unreasonable at scale: inference cost is measured before industrialisation, not after.
- MLOps
- The practices and tools that keep a model alive in production: versioning of data and models, reproducible deployment, monitoring, retraining. The equivalent, for machine learning, of what DevOps is to software.
- Model drift
- The loss of performance a model suffers when the world it observes changes: new products, new behaviours, new hardware. A model is not delivered once and for all; without drift monitoring and a retraining procedure, it degrades in silence.
- OCR / HTR
- Recognition of printed characters (OCR) and of handwriting (HTR), turning a document image into usable text. Quality depends on the document type and the hand: a model tuned to the collection beats a generic one.
- POC / POV
- Proof of concept or proof of value: a prototype built to settle, on your real data, whether a use case delivers on its promise. Its job is not to impress, it is to decide whether to industrialise or stop.
- Pseudonymisation
- Replacing the data that identifies a person with substitute identifiers, to limit direct re-identification. In free text it has to be handled inside the text itself, names, dates, addresses, then checked on a re-read sample.
- RAG
- Retrieval-augmented generation. The model does not answer from memory: relevant passages are first retrieved from your documents, then the model is asked to answer from those passages, with a source citation. It is the surest way to get an answer that is verifiable rather than merely plausible.
- SecNumCloud
- A French qualification attesting a high level of security and sovereignty for a cloud hosting offering. For the most sensitive public data it may be required, which rules out from the start some architectures that rely on a service hosted outside this perimeter.
- Sovereignty
- Control over where your data and processing live, and which law applies to them. In concrete terms, it is what pushes toward running open models on your own infrastructure rather than calling a third-party service hosted elsewhere.
- Success criterion
- The numeric threshold, written before starting, that decides whether a prototype goes to production or stops. Without it, a project never truly ends, it lingers. We put it in the contract before the first line of code.
- Time series
- A sequence of measurements ordered in time: consumption, a machine’s vibration, a flow of requests. Forecasting one means accounting for seasonality and comparing against a naive baseline, without which a "good" number means nothing.
Let us talk about your use case.
An hour is enough to tell whether your subject stands up. If it does not, we will tell you then, not after three months of project.