Espace Notarial V2 · case study
Ouidou × Notantis · 2026 · UX/UI & front

Refondre la dataroom des notaires sans déplacer un seul geste

L'Espace Notarial partage les pièces d'une vente entre l'étude, ses clients et leurs conseils. La V2 reconstruit tout le socle — multi-office, droits, sécurité — et reprend l'interface de zéro, sans casser les habitudes de milliers d'utilisateurs.

Rôle
UX/UI design, design system, intégration front
Période
Août – sept. 2026
POC en cours
Périmètre
3 espaces : étude, client, console
Stack
React 19 · TypeScript · Django DRF
Contexte

Un outil apprécié, sur un socle à bout de souffle

La V1 fonctionne et ses utilisateurs l'aiment. Mais une seule base pour tous les offices, des droits codés en dur et pas d'isolation : elle ne passera pas les exigences de sécurité de 2027. La consigne du client est claire : refaire le socle, ne pas réinventer l'outil.

6 946offices notariaux en France, marché adressé par Notantis
65 410dossiers sur la plateforme actuelle (février 2026)
01/2027conformité totale exigée par la directive sécurité du notariat (DSN 2026)
06/2027livraison du MVP, échéance déjà annoncée aux offices

Le problème à résoudre

  • Le cahier des charges ne contient aucune exigence UX : il parle de sécurité, de RGPD et de réversibilité.
  • Refaire à périmètre égal un outil connu, c'est risquer la régression perçue : un geste qui change de place se vit comme une perte (loi de Jakob).
  • Les notaires eux-mêmes ont été très peu interrogés : la connaissance du métier est éparpillée entre le support, l'équipe métier et les développeurs.

Le parti pris

  • Faire de l'UX le terrain de différenciation d'Ouidou, là où le client n'attend rien de précis.
  • Tout trancher dans un POC qui tourne pour de vrai : vrai code React, vraie API Django, déployé chez le client le 07/09.
  • Un design system en « marque grise » : chaque office peut rhabiller l'outil à ses couleurs sans toucher au code.

« Reconstruire un socle sain et refournir l'existant avec une interface améliorée. »La consigne du commanditaire, répétée à chaque atelier de cadrage

Avant / après

Du formulaire isolé à un espace de travail

La V1 accueille l'utilisateur sur un formulaire perdu dans une photo d'illustration. La V2 ouvre directement sur le travail : l'étude, ses datarooms, ce qui attend une réponse.

Écran de connexion de l'Espace Notarial V1 : petit formulaire centré sur une photo pleine page
V1Connexion actuelle. Deux champs sur une photo, aucune indication sur l'étude ni sur l'espace.
Dataroom V2 : arbre des dossiers à gauche, liste des pièces à droite, onglets en haut
V2Dataroom. L'arbre, les pièces et les onglets du dossier sur un seul écran.

Les mêmes gestes

Déposer, retrouver, inviter, répondre : les parcours V1 les plus fréquents restent au même endroit. Les mots changent seulement là où le lexique a été validé avec le client.

Moins d'écrans

Fiche d'une pièce, partage, commentaires : tout s'ouvre dans un volet ou une fenêtre au-dessus de la liste, sans quitter le dossier en cours.

Un état lisible

Statuts, pièces non consultées, questions à traiter : chaque compteur suit une seule règle, calculée une fois et affichée partout.

Démarche

Sept semaines, du benchmark au code

Chaque étape a produit un livrable réutilisable. Les arbitrages ont été tranchés un par un avec le client et l'équipe, et notés au fil de l'eau.

  1. BenchmarkDatarooms du marché et outils notariaux, lus geste par geste.
    25/08
  2. Carte de la V1Tous les écrans et fonctions de l'existant, pour fixer le périmètre.
    fin août
  3. LexiqueRapport de vocabulaire : un mot par notion, du côté de l'étude comme de la console.
    01/09
  4. ArborescenceLes trois espaces (étude, client final, console hyperadmin) sur un board FigJam.
    10/09
  5. Wireframes49 écrans en filaire, sur tout le périmètre, générés depuis le design system Figma.
    10/09
  6. Design systemTokens, composants, thème par office : la même source pour le web, les PDF et les e-mails.
    dès 26/08
  7. POC & recetteÉcrans réels en React, vérifiés dans le navigateur avec Playwright avant chaque livraison.
    en continu
Décisions UX

Six choix qui structurent le produit

Pour chacun : ce que l'écran devait permettre, ce qui a été tranché, et pourquoi.

Dataroom

L'arbre et la liste, côte à côte

Une dataroom de vente compte souvent plus de 300 pièces. On s'y repère par sa position dans le plan, pas par son nom de fichier.

  • Un arbre avec ses traits de liaison : le chemin jusqu'au dossier ouvert est surligné, pour que l'emplacement se lise d'un coup d'œil.
  • Un numéro pour chaque pièce (2.1.3.) : c'est la référence que les notaires citent au téléphone.
  • La sélection multiple ouvre une barre d'actions contextuelle ; les sous-dossiers s'affichent dans la liste elle-même.
  • Des statuts toujours accompagnés d'un libellé (Consulté, Nouveau, Déposé, En attente) : la couleur seule ne porte jamais l'information.
Liste des pièces avec deux pièces sélectionnées, numérotation 2.1.1 à 2.1.5, statuts et avancement
Questions / Réponses

Les questions comme une messagerie

Banque, acquéreur, vendeur : chacun pose ses questions sur une pièce. Dans la V1, c'était une liste plate. Ici, chaque question devient un fil de discussion.

  • Deux colonnes : les fils à gauche, la conversation à droite, avec la pièce concernée toujours citée.
  • Un seul « à traiter » : quatre compteurs donnaient quatre chiffres différents pour le même sujet. La règle vit désormais dans un seul module (qaState.ts) et tous les compteurs en découlent.
  • La modération avant la réponse : une question non validée ne peut pas recevoir de réponse, et l'écran explique pourquoi en une phrase.
  • Une vue en cartes en complément, avec des filtres par pièce, par auteur et un tri.
Onglet Questions / Réponses en deux colonnes, fil sélectionné à modérer
Barre d'onglets de la dataroom avec le compteur de questions à traiter

Le compteur de l'onglet suit la même règle que le filtre « À traiter ».

Accueil

Un accueil que chacun compose

Un notaire, un clerc et un assistant ne regardent pas les mêmes choses le matin. L'accueil est une surface de widgets que chacun dispose à sa façon, avec un modèle de départ adapté à son rôle.

  • Une disposition libre sur une grille de 48 × 48 : on redimensionne par les quatre bords et les quatre coins, et les widgets peuvent se chevaucher.
  • Un magnétisme sur les bords et le centre des voisins, avec un repère qui n'apparaît qu'au moment où l'aimant accroche.
  • Un bouton « Réaligner » pour remettre de l'ordre quand l'accueil est trop dérangé, dans l'ordre de lecture.
  • Des widgets « action rapide » qui ouvrent vraiment la fenêtre de création, au lieu de simplement renvoyer vers une page.

Schéma. Les positions sont enregistrées en fractions de la grille, pas en pixels : le même accueil se redessine à l'identique sur tous les écrans.

Assistant

Un assistant qui montre avant d'agir

L'assistant ne s'ouvre pas dans une fenêtre flottante qui masque la liste : il prend sa place dans la page, comme une colonne.

  • Il s'ancre dans le contenu, on peut le redimensionner et le placer à gauche ou à droite. La liste reste lisible à côté.
  • Deux modes explicites, « Exécuter » et « Analyser » : il annonce ce qu'il va changer dans la dataroom avant de l'appliquer.
  • Une orbe animée pour l'accueil vide, qui ne bouge plus dès que le système demande de réduire les animations.
Liste des datarooms avec le panneau Assistant ancré à droite
Console hyperadmin

La console ne ressemble pas à une étude

L'équipe Notantis administre tous les offices depuis une console. Si elle ressemble à l'espace d'une étude, on finit par agir au mauvais endroit.

  • Un habillage sombre qui lui est propre : on sait toujours dans quel espace on se trouve.
  • Une navigation sur deux niveaux : les éléments fixes en haut, la navigation en dessous. Le nombre d'onglets affichés est mesuré, pour ne jamais déborder de la barre.
  • L'écran ouvert est inscrit dans l'URL : un lien collé dans un ticket ouvre exactement le bon onglet.
Console hyperadmin, liste des offices, thème clair
Console hyperadmin, liste des offices, thème sombre

Liste des offices : statut, sous-domaine, modules activés, accès en impersonation.

Marque grise

Chaque étude à ses couleurs

Notantis vend l'outil à des milliers d'offices. Chacun doit pouvoir y mettre son logo et ses couleurs sans demander de développement.

  • Toutes les variables modifiables, une par une, en thème clair et en thème sombre. La première version, qui calculait tout à partir de deux couleurs, a été écartée : elle ne permettait pas de changer les fonds.
  • Sept palettes fournies, dont une néomorphique, et jusqu'à douze thèmes enregistrés par étude.
  • Le relief comme réglage : plat, élevé ou néomorphique. Les ombres sont calculées à partir des couleurs de l'office, avec des valeurs à part pour le thème sombre.
  • 16 polices hébergées sur le serveur, des rayons réglables au pixel près, et un fond animé en option.
Deux offices de démonstration : Office A en relief élevé clair, Office B en néomorphique sombre
Palette néomorphique en sombre et en clair, après correction des ombres
Fil d'activité récente avec les icônes 3D

À gauche, le néomorphique après correction des ombres en sombre (le premier calcul laissait un halo gris autour des cartes). À droite, les icônes 3D, utilisées partout sauf dans la navigation.

Design system

Une seule source de vérité pour le web, les PDF et les e-mails

Tout passe par des custom properties CSS. Les mêmes valeurs sont exportées en JSON et en Python, pour que les documents générés côté Django ressemblent à l'interface sans rien dupliquer à la main.

Couleurs de marque Notantis

Palette par défaut, thème clair. Les neutres tirent vers le violet de la marque.

brand-ink#1a1258
shell-bg-2#2c2170
brass-700#6b3fd4
brass-500#9668f4
brass-100#f0e9fc
ink-900#211c3d
ink-500#7d7896
border#e5e2f0
bg#fafafd

Statuts

Les quatre couleurs sont construites ensemble en OKLCH.

Validéh 152
À relireh 70
Manquanth 27
Reçuh 250

Même clarté (L 0,45), même intensité (C 0,135) : seule la teinte change. Elles restent à plus de 45° du violet de la marque, pour qu'un statut ne ressemble jamais à un bouton.

Typographie du produit

Trois familles, chacune avec un rôle précis.

display
Poppins
Dataroom de vente Caudan
ui · 14,5 px
Inter
312 fichiers, dernière modification aujourd'hui à 10:42.
mono
IBM Plex Mono
2.1.3. · 18,2 Go · #Q105

Composants en atomic design

Fichiers .tsx dans src/components, hors écrans repris de la V1.

Atoms
40
Molecules
32
Organisms
65
Templates
1
Pages
20

Un catalogue (UI kit) lit les props directement dans le code source : la documentation ne peut pas prendre de retard sur les composants.

Sept palettes livrées

59 tokens chacune, en version claire et sombre. Ajouter une palette ne modifie pas le schéma.

notantis
marine
ardoise
bordeaux
foret
parchemin
neomorphic

Pour chaque palette : brand-ink, brass-500 et brass-100 en thème clair, tirés de theme/palettes.ts. Chaque palette a été contrôlée en contraste, paire par paire, selon l'usage de chaque token (texte, chrome, icône).

Rayons

Échelle de base, réglable par office.

radius-sm
6 px
radius-md
10 px
radius-lg
16 px
Specs front

Ce qui tourne sous l'interface

Un front React volontairement léger en dépendances, branché sur une API Django multi-office. Les versions ci-dessous sont celles du dépôt du POC.

CoucheChoixPourquoi
FrameworkReact 19.2 · TypeScript 6.0Typage strict de bout en bout, y compris le schéma de thème et le registre des widgets.
BuildVite 8.2 · @vitejs/plugin-react 6Serveur de dev instantané ; build lancé après tsc -b.
Lintoxlint 1.75Lint rapide, et un contrôle du design system à part (voir plus bas).
UIComposants maison, aucune bibliothèque de composantsLe thème par office doit tout piloter : une bibliothèque tierce imposerait ses propres variables.
DispositionMoteur maison (dashboard/freeLayout.ts), pointer eventsreact-grid-layout refusait le chevauchement et le redimensionnement par le haut ou par la gauche. Le calcul est pur et se teste sans navigateur.
IcônesPhosphor via @iconify-json/ph → sprite SVG duotoneLe contour garde la couleur du texte (contraste), le second ton porte l'identité de l'office.
Fond animéthree r186 (WebGL)Monté seulement si l'office l'a choisi ; en pause quand l'onglet est caché, remplacé par une image fixe si l'utilisateur limite les animations.
RoutageRoute dans l'ancre de l'URLÉcran et sous-onglet partageables par simple lien, sans configurer le serveur.
APIDjango 6.1 · DRF 3.18 · django-otpUn office par sous-domaine, MFA, historique d'audit, impersonation encadrée pour le support.
FichiersS3 (django-storages, SeaweedFS en local)Stockage compatible S3, versions de pièces, dépôt de dossiers entiers.
DéploiementDocker Compose · Traefik v3 · manifestes k8sImages front et back séparées ; POC déployé sur la VM de recette le 07/09.

Moteur de thème par office

Du schéma au rendu : une seule définition, appliquée au navigateur et reproduite côté serveur.

theme/schema.tsTOKEN_SCHEMA : chaque variable, son groupe, son type (couleur, couleur + opacité, halo).
theme/palettes.tsLes palettes remplissent le schéma sans le modifier.
API /tenant-theme/Thème de l'office stocké côté serveur ; une réponse 204 signifie « palette Notantis ».
theme/engine.tsProduit les variables, le relief en color-mix, la densité de la navigation.
<style id="tenant-theme-vars">Injecté dans la page ; l'écran Apparence est lui-même généré à partir du schéma.
tokens.json — copie à plat pour les outils hors navigateur et les scripts JS.
tokens.py — resolve(), theme_css(), TenantTheme : PDF (WeasyPrint/ReportLab) et e-mails générés depuis Django. Vérifié à l'identique, caractère par caractère, avec le moteur JS.

Arborescence du front

frontend/src, dossiers principaux.

components/   atoms · molecules · organisms · templates · pages
dashboard/    registry, freeLayout, templates par rôle
theme/        schema, palettes, engine, ThemeProvider
access/       droits et capacités côté client
hyperadmin/   console multi-office
upload/       dépôt de fichiers et de dossiers
search/       recherche dans l'étude (Ctrl K)
uikit/        catalogue des composants
styles/       tokens · components · dashboard · fonts
v1/           écrans repris de l'existant

Outillage qualité

Scripts npm run … du dépôt.

  • check:dsRepère les couleurs en dur et les composants recopiés à la main au lieu d'être importés. Une liste de dette connue évite qu'un ancien écart bloque une nouvelle livraison.
  • check:diffContrôle les suppressions inattendues avant un commit, sur des fichiers que plusieurs personnes modifient en même temps.
  • build:iconsGénère le sprite duotone à partir des icônes Phosphor utilisées.
  • Recette PlaywrightChaque livraison est vérifiée par des captures dans le navigateur, en clair et en sombre.

Accessibilité et robustesse

Ce qui est déjà en place dans le POC.

  • Le statut ne dépend jamais de la couleur seuleChaque pastille a un libellé, et les icônes duotone gardent un contour contrasté.
  • Le focus reste visibleMême en néomorphique, où les bordures disparaissent, l'anneau de focus clavier est conservé.
  • Animations réduites respectéesL'orbe, le fond WebGL et la transition d'écran s'arrêtent si l'utilisateur limite les animations.
  • Contraste contrôlé par usageLes paires sont vérifiées par registre (contenu, chrome, icône), au seuil de l'usage le plus exigeant.
  • Mise en page plein écranLa page ne défile plus : chaque zone défile seule, l'en-tête et les onglets restent en place.
  • Thème clair ou sombre par étudeSystème, clair ou sombre, avec un réglage par office et un aperçu exact pendant l'édition.

Ce qui reste à faire

Fenêtres modales

Fermeture par Échap et focus maintenu dans la fenêtre : relevé en audit UX, à traiter en priorité.

Contraste dans Apparence

L'édition libre n'empêche pas une étude de choisir des couleurs illisibles : il faut un avertissement en direct.

Échelles à formaliser

Pas encore de tokens pour l'espacement ni pour les tailles de texte, et la navigation latérale n'a pas de version mobile.