Four ways to put us to work.

A complete application when the tool does not exist. An agent when it saves real time on one precise task. Training when your teams must hold the wheel themselves. Every example below is already running.

Full App AI agent Automation Training

Use case 01

Full App, when the tool does not exist

You run your business in a spreadsheet, or in software that speaks a different trade than yours. We build the platform that is missing, and keep it alive in production.

Delivered projects

The data model

We start from your trade, not from a template. Which entities actually exist, what links them, what must be unique, what may be missing. It is the most expensive decision to correct later, so it is the first one we take with the users. On your real data, not on a test fixture

The working screens

One screen per real action, in the order the work happens. The scope narrows before it widens: we remove what forces a choice rather than adding one more feature. Shipped in batches, put in users' hands

Accounts and roles

Who sees what, who can do what. Authentication, separate organisations, role based rights, an audit log of sensitive actions. This is what lets a tool leave one team and serve the whole company. Isolation verified before go live

Going live

Identified hosting, backups, a restore that has been tested, and migration of the existing system without breaking addresses. Then we keep it alive: fixes, evolutions, and one contact who knows your system. France or European Union, written into the contract

The detailed method: deliverables, results, challenges

Use case 02

AI agent, when one precise task takes too long

A useful agent does not replace your trade, it absorbs the question you are asked forty times a day. With us, the model only writes prose: a price, an availability or an address is computed by the server, then re-read before display.

Delivered projects

The scope, written before the code

We write what the agent must do and above all what it must never do. The list of forbidden subjects is shorter than people expect, and more important than the rest. A document reviewed and signed before the first model call

Answers drawn from your content

The agent answers from a closed corpus: your pages, your catalogue, your practical information. It cites where the answer comes from. When the information does not exist, it says so and refers the visitor to you, instead of inventing. Closed corpus, cited source, the right not to know

Server side calculation

A price, an availability or an address is never produced by the model: the server computes it from the real data and inserts it into the answer. An amount appearing where it should not triggers replacement of the entire answer. The model writes, it does not quote figures

Handover to a human

The agent introduces itself as an agent and knows when to hand over. On anything involving advice or sales, it routes to the competent person. The back office shows you every question left unanswered. Transparency, and a way through to your team

The detailed method: deliverables, results, challenges

Use case 03

Automation, when a flow repeats with nobody to hold it

Not everything needs a conversation. Many costly tasks are silent chains: produce a document, follow up at the right moment, collect a piece of data, publish. They run with no interface, and nobody sees them as long as they work.

The trigger

What sets the job running: a form received, a file dropped, a time of day, an event in another tool. We write it down explicitly, because this is where the surprises hide. A single entry point, identified

The job

It runs without anyone starting it. A brief that becomes a published site, a follow up sent at the right moment, data collected as it comes. No model call for what a script does better and cheaper. The simplest thing that does the job

The outputs

Emails, documents, updates in your tools. Every send starts from a template you have reviewed, with an authenticated sending address so it does not land in spam. Nothing goes out before you have seen the template

The log and the alerts

A silent automation is a dangerous automation. Every run leaves a readable trace, and a failure is reported to you instead of being discovered three months later. You see what happened, and what failed

The detailed method: deliverables, results, challenges

Use case 04

Training, when your teams must hold the wheel

We train on what we practise every day, in our own projects. No tour of the tools of the moment: how to frame a use case, how to write instructions that hold, and how to know what you must never hand to a model.

Framing a use case, before opening a tool

Separate what can be automated from what must not be. Spot the repetitive tasks that really cost, and rule out the ones whose automation would create a bigger risk than the gain. Workshop format, half a day

Writing instructions that hold

An instruction is judged on what it prevents, not on what it asks for. Closed lists, explicit bans, server side checking: we replay the cases where a model invented a price or a guarantee, and we build the filter that stops it. Workshop format, one day

Working with agents day to day

Our own production method, passed on as it is: split the work by trade, route each request to the right skill, write the guardrails after each incident, and keep a memory that survives sessions. Coaching format, over several weeks

Responsible AI and digital restraint

What RGESN and AFNOR Spec 2314 change in practice in a design decision. Measure before optimising, and know how to say that a project does not deserve to be built. Workshop format, half a day

Note: these formats describe what we know how to pass on, taken from our projects in production. They are not off the shelf sessions, nor client references. The content is built with you, from your own cases.

The detailed method: deliverables, results, challenges

How we work

The framework we use to build all this

Our projects are not held together by one person who knows everything. They are held by a written method, applied to our own products as much as to our clients', and it can be passed on.

13 Trades tooled up

22 Written procedures

100+ Clients deployed

0 Invented prices

One trade, one skill

Design, integration, back office, security, search, deployment, testing: each domain has its owner and its written procedure, instead of one generalist improvising everywhere.

Routing, not improvisation

An incoming request is recognised by its signals and sent to the right skill. When two domains contradict each other, we settle it before executing, never after.

Guardrails written after incidents

Every cross cutting rule cost something once. They are written down, active on every project, and some are checked automatically on each file change.

A memory that survives sessions

What we learn on a project is written down and reloaded next time. A trap met once is not paid for twice.

A gate before delivery

Testing across several screen widths, a security check, detection of automatic writing tics. What is not verified is not announced as done.

Let's talk

Which of these three cases looks like yours?

We always start with a diagnostic: what can be automated, what must not be, and what it really costs.

Book a diagnostic See our products