Making of
Notacor: building an advisory tool on data we are not allowed to mix
How we built an intelligence layer on top of a notary firm's data, and why the architecture looks the way it does.
Looptra's role
Design, development, operation
Status
In production
Field
Notary firms, multi-tenant
Stack
TypeScript strict, Next.js, NestJS, PostgreSQL, Redis
Section 01
The real problem
A notary firm holds twenty years of history in its practice management software and almost no way to use it. The data is there, clients, deeds, properties, dates, but it exists to produce case files, not to see. The result: clients nobody has called back in eight years, situations that have changed, and no one to notice.
A notaire has a duty to advise. What is missing is not the will: it is a tool able to look at a whole client base and say where advice is legitimate. Off-schedule work, the kind that turns on the relationship rather than on the deed, is exactly the part no practice management software surfaces.
Notacor does not produce a list of 300 clients to call back. It produces cards: the signal detected, why it matters, the advisory angle to open. A staff member can read a card in twenty seconds and decide whether to pick up the phone.
Section 02
The hard constraint
Three constraints that cannot be worked around. Everything else follows from them.
Professional conduct is not a setting
Targeting a client on the wrong criterion is not a lost conversion, it is professional misconduct. The rules that decide a situation deserves advice must be explicit, readable by a lawyer and verifiable one by one. They cannot live in a statistical model, nor in an instruction written in plain language.
Trust is proven, not pleaded
The profession is cautious about handing over its data, and it has its reasons. We do not answer that with a sales argument. Our position fits in one sentence: we do not promise the absence of risk, we promise a level of control, oversight and evidence above what exists today.
- Hosting in France, on a qualified chain (ANSSI / SecNumCloud)
- Industrialized operation: monitoring, verified backups, traced updates
- GDPR compliance by construction: data scope bounded from the model up
- Continuity and recovery documented (PCA / PRA), incidents logged
- Contractual reversibility: the firm's data stays its own, exportable, and the firm can leave
Data that was never made for this
The input is an export from the firm's practice management software (FICHORGA, Septeo). Heterogeneous schemas, duplicates, free-text fields, partial histories. Cleaning is not a hidden technical step: it is a piece of the product, with its own rules and tests, because an opportunity built on wrong data is worse than an opportunity missed.
Section 03
The architectural decisions, and what they cost
Every decision costs something. We say what.
One database isolated per firm
Why: each client lives in its own PostgreSQL schema (etude_<id>). Isolation is not a filter in a query that a developer could forget: it is in the structure. Not even a bug crosses from one firm to another.
What it costs: every migration runs as many times as there are clients, and the deployment tooling has to be beyond reproach.
The front end never touches the database
Why: the Next.js interface acts as a facade: it calls a single domain API, the only one that speaks to PostgreSQL. One door, therefore one place to audit, log and harden.
What it costs: one more network round trip, and API contracts to keep in step between two applications.
The domain lives in a pure package
Why: the targeting engine and the professional-conduct guardrails sit in a package with no database and no HTTP. The rules become readable, testable one by one, and apply identically in the interface, in the nightly jobs and in the exports. No path goes around them.
What it costs: discipline: anything that looks like a business rule has to move up into that package, including when a shortcut would be faster.
Heavy jobs leave the user's path
Why: ingestion, enrichment, export and drafting run in separate workers, orchestrated by a queue. Each has its own data scope, and enrichment in particular is bounded to what the GDPR allows and nothing more. A third-party source going down slows a worker, not the staff member's screen.
What it costs: orchestration: retries, idempotency, observability. An asynchronous system is not debugged by reading a screen.
The AI drafts, it does not decide
Why: which clients to contact is decided by the targeting engine, deterministic and tested. The language model comes in afterwards, to propose a draft message, and it runs on European infrastructure (Mistral EU). The text stays a suggestion: the staff member reviews, the notaire signs.
What it costs: we give up fully automating the first contact. That is deliberate: responsibility stays with the professional.
Section 04
What runs in production
- Ingestion and cleaning of real firm exports, with a rejection log
- Detection of off-schedule opportunities among dormant clients, presented as argued cards
- Assisted drafting of the first contact, reviewed before sending
- Multi-firm: every client firm walled off in its own schema, sharing nothing
- Operated by Looptra: monitoring, backups, updates, incidents
Notacor has its own site: that is where we explain the product and its screens. Here, we explain how it is built.
Section 05
What it proves
If your trade has rules that are not negotiable, data that is not mixed, and clients who want evidence rather than promises: that is exactly the ground we already build on.