Making-of
Notacor : construire un outil de conseil sur des données qu’on n’a pas le droit de mélanger
Comment on a fabriqué une couche d’intelligence au-dessus des données d’une étude notariale, et pourquoi l’architecture ressemble à ça.
Rôle Looptra
Conception, développement, exploitation
Statut
En production
Terrain
Études notariales, multi-clients
Socle
TypeScript strict, Next.js, NestJS, PostgreSQL, Redis
Section 01
Le problème réel
Une étude notariale a vingt ans d’historique dans son logiciel métier et presque aucun moyen de s’en servir. Les données existent, clients, actes, biens, dates, mais elles sont là pour produire du dossier, pas pour voir. Résultat : des clients qu’on n’a pas rappelés depuis huit ans, des situations qui ont bougé, et personne pour le remarquer.
Le notaire a un devoir de conseil. Ce qui lui manque, ce n’est pas la volonté : c’est un outil capable de regarder tout un portefeuille et de dire où le conseil est légitime. Le hors-tarifé, celui qui se joue sur la relation, pas sur l’acte, est précisément la partie qu’aucun logiciel métier ne fait remonter.
Notacor ne produit pas une liste de 300 clients à rappeler. Il produit des cartes : le signal détecté, la raison pour laquelle il compte, l’angle de conseil à ouvrir. Un collaborateur peut lire une carte en vingt secondes et décider s’il décroche.
Section 02
La contrainte dure
Trois contraintes qui ne se contournent pas. Tout le reste en découle.
La déontologie n’est pas un paramètre
Cibler un client sur un mauvais critère n’est pas une conversion perdue, c’est une faute professionnelle. Les règles qui décident qu’une situation mérite un conseil doivent être explicites, relisibles par un juriste et vérifiables une par une. Elles ne peuvent pas vivre dans un modèle statistique ni dans une consigne rédigée en langage naturel.
La confiance se prouve, elle ne se plaide pas
La profession est prudente quand il s’agit de confier ses données, et elle a ses raisons. Nous n’y répondons pas par un argument de vente. Notre position tient en une phrase : nous ne promettons pas l’absence de risque, nous promettons un niveau de maîtrise, de contrôle et de preuve supérieur à l’existant.
- Hébergement en France, sur une chaîne qualifiée (ANSSI / SecNumCloud)
- Exploitation industrialisée : supervision, sauvegardes vérifiées, mises à jour tracées
- Conformité RGPD par construction : périmètre de données borné dès le modèle
- Continuité et reprise documentées (PCA / PRA), incidents journalisés
- Réversibilité contractuelle : les données de l’étude restent les siennes, exportables, et l’étude peut sortir
Des données qui n’ont pas été faites pour ça
L’entrée, c’est un export du logiciel métier de l’étude (FICHORGA, Septeo). Schémas hétérogènes, doublons, champs libres, historiques partiels. Le nettoyage n’est pas une étape technique cachée : c’est un morceau du produit, avec ses règles et ses tests, parce qu’une opportunité fondée sur une donnée fausse est pire qu’une opportunité manquée.
Section 03
Les décisions d’architecture, et ce qu’elles coûtent
Chaque décision coûte quelque chose. On dit quoi.
Une base isolée par étude
Pourquoi : chaque client vit dans son propre schéma PostgreSQL (etude_<id>). L’isolation n’est pas un filtre dans une requête qu’un développeur pourrait oublier : elle est dans la structure. Même un bug ne fait pas traverser deux études.
Ce que ça coûte : chaque migration se joue autant de fois qu’il y a de clients, et l’outillage de déploiement doit être irréprochable.
Le front ne touche jamais la base
Pourquoi : l’interface Next.js sert de façade : elle appelle une seule API métier, qui est la seule à parler à PostgreSQL. Une porte d’entrée, donc un seul endroit à auditer, à journaliser et à durcir.
Ce que ça coûte : un aller-retour réseau de plus et des contrats d’API à tenir à jour entre deux applications.
Le métier vit dans un package pur
Pourquoi : le moteur de ciblage et les garde-fous déontologiques sont dans un package sans base de données ni HTTP. Les règles deviennent lisibles, testables une par une, et s’appliquent à l’identique dans l’interface, dans les traitements de nuit et dans les exports. Il n’existe pas de chemin qui les contourne.
Ce que ça coûte : de la discipline : tout ce qui ressemble à une règle métier doit remonter dans ce package, y compris quand un raccourci irait plus vite.
Les traitements lourds sortent du chemin de l’utilisateur
Pourquoi : ingestion, enrichissement, export et rédaction tournent dans des workers séparés, orchestrés par une file d’attente. Chacun a son périmètre de données, l’enrichissement, notamment, est borné à ce que le RGPD autorise et rien d’autre. Une source tierce en panne ralentit un worker, pas l’écran du collaborateur.
Ce que ça coûte : de l’orchestration : reprises, idempotence, observabilité. Un système asynchrone ne se débogue pas en lisant un écran.
L’IA rédige, elle ne décide pas
Pourquoi : le choix des clients à contacter est fait par le moteur de ciblage, déterministe et testé. Le modèle de langage intervient après, pour proposer un brouillon de message, et il tourne sur une infrastructure européenne (Mistral EU). Le texte reste une suggestion : le collaborateur relit, le notaire signe.
Ce que ça coûte : on renonce à l’automatisation complète de la prise de contact. C’est volontaire : la responsabilité reste chez le professionnel.
Section 04
Ce qui tourne en production
- Ingestion et nettoyage d’exports réels d’études, avec journal des rejets
- Détection d’opportunités hors-tarifé chez les clients dormants, présentées en cartes argumentées
- Rédaction assistée du premier contact, relue avant envoi
- Multi-étude : chaque étude cliente cloisonnée dans son propre schéma, sans rien partager
- Exploitation par Looptra : supervision, sauvegardes, mises à jour, incidents
Notacor a son propre site : c’est là qu’on explique le produit et ses écrans. Ici, on explique comment il est construit.
Section 05
Ce que ça prouve
Si votre métier a des règles qui ne se négocient pas, des données qu’on ne mélange pas et des clients qui veulent des preuves plutôt que des promesses : c’est exactement le terrain sur lequel on construit déjà.