Automatisation des courriers d'une étude notariale, sans jamais envoyer à sa place

Une vente immobilière déclenche toujours la même série de courriers : création du dossier, accusé de réception au client, questionnaire au vendeur, demandes de pièces au syndic, à la mairie, à la banque.

Les variantes dépendent du dossier. Copropriété ou non, assainissement collectif ou individuel, lot isolé, prêt hypothécaire : chaque cas ouvre ou ferme une demande de pièces. Se tromper coûte une relance perdue, ou un courrier envoyé à quelqu'un qui n'avait rien à recevoir.

Les informations nécessaires sont réparties entre le fichier de pilotage de l'étude, les messageries des collaborateurs et un questionnaire rempli par le vendeur. Aucune de ces sources ne parle aux autres.

Le collaborateur passe ses journées à recopier, à vérifier ce qui est déjà arrivé, et à relancer ceux qui n'ont pas répondu. Le métier de notaire n'est pas là.

Écrire les règles avec l'étude, pas à sa place

Approche : partir des courriers réellement envoyés

Nous avons repris les courriers de l'étude un par un et transformé chacun en règle nommée, avec sa condition de déclenchement. Trente-trois règles au total, relues par l'étude avant d'être codées. Le référentiel appartient au client, il se modifie sans nous.

Rendre l'envoi techniquement impossible

Focus : une garantie vérifiable plutôt qu'une promesse

Le logiciel dépose des brouillons dans Outlook et n'envoie rien. L'application dispose de la permission de lire les messages et d'écrire des brouillons, elle ne dispose pas de la permission d'envoyer. Même en cas de bug, aucun courrier ne peut partir sans qu'un collaborateur clique.

Déclencher les demandes de pièces depuis les réponses du vendeur

Approche : une réponse, une règle, un destinataire

Le vendeur remplit un questionnaire en ligne. Ses réponses arment les bonnes demandes de pièces, et seulement celles-là : le syndic quand il y a copropriété, la banque quand il y a un prêt, la mairie selon le mode d'assainissement.

Lire les pièces jointes et retrouver les virements

Technologies : Microsoft Graph, SharePoint, modèle de vision documentaire

Les pièces reçues en réponse sont reconnues et cochées dans le fichier de suivi. Quand un virement apparaît sur un relevé au bon nom et au bon montant, la case correspondante passe à oui, dans le fichier que l'étude utilise tous les jours.

La chaîne complète a été rejouée dans le SharePoint de production : relevé de compte lu, mouvements analysés, case du dépôt de garantie passée à oui. Pas sur un jeu de test, sur le fichier réel de l'étude.

Le point le plus utile du projet n'est pas ce que l'outil trouve, c'est ce qu'il refuse de trancher. Notre audit a montré qu'un nom de famille trop court attrapait des virements appartenant à d'autres dossiers, et qu'un relevé de compte pouvait passer pour un RIB. Nous avons relevé les seuils de reconnaissance et changé le comportement : quand l'outil hésite sur le dossier auquel rattacher un document, il nomme les candidats et laisse le collaborateur décider.

L'étude garde la main sur chaque mot qui sort de chez elle. Le référentiel de règles, lui, est prêt à s'étendre aux autres actes que l'étude traite, sans repasser par une phase de conception.

Ce qui disparaît, c'est la recopie, la surveillance des relances et la vérification de ce qui est déjà arrivé. Ce qui reste chez l'humain, c'est la relecture et la signature.

Django, déployé sur serveur dédié via Coolify.
Lecture des boîtes Outlook par Microsoft Graph, avec des permissions volontairement limitées à la lecture et à l'écriture de brouillons.
Lecture du fichier de pilotage et écriture des cases de suivi directement dans SharePoint.
Reconnaissance des pièces jointes par un modèle de vision, avec un seuil de confiance relevé après audit.
Questionnaire vendeur en ligne dont les réponses déclenchent les règles de demande de pièces.