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

Une vente immobilière, c'est une trentaine 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.

Aucun n'est tout à fait le même que le précédent. Copropriété ou non, assainissement collectif ou individuel, lot isolé, prêt hypothécaire : chaque réponse du vendeur ouvre ou ferme une demande. Se tromper, c'est un syndic qui reçoit un courrier qui ne le concerne pas, ou une pièce que tout le monde croit demandée et que personne n'a réclamée.

Pour savoir où en est un dossier, il faut ouvrir le fichier de pilotage, puis la boîte de la cheffe, puis celle du rédacteur, puis celle du formaliste. Aucune de ces sources ne parle aux autres. Personne ne peut répondre de tête.

Au bout du compte, une étude paie des gens formés au droit pour faire du secrétariat.

É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.

Le collaborateur relit et clique. C'est tout ce qu'on lui demande de faire.

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.