Sécurité des données notariales : la checklist avant de connecter une IA

Une étude notariale ne choisit pas un logiciel sur la seule qualité d'une synthèse. Elle lui confie des actes, des pièces d'identité, des situations familiales, des données patrimoniales et des échanges couverts par le secret professionnel. La sécurité doit donc être démontrée sur tout le cycle de vie de la donnée, pas résumée par un lieu d'hébergement.

La CNIL rappelle que les systèmes d'IA restent soumis au RGPD. La conformité dépend du traitement réellement mis en œuvre par l'étude : ce qui est lu, pourquoi, par qui, pendant combien de temps et avec quelles décisions prises à partir du résultat.

Les dix contrôles d'un logiciel pour notaire

1. Définir la finalité avant de connecter les données

« Améliorer le produit » n'est pas une finalité assez précise. Le contrat doit distinguer la recherche dans un dossier, la préparation d'un e-mail, l'analyse LCB-FT, le suivi client et l'amélioration technique du service. Demandez si les données, requêtes ou corrections peuvent servir à entraîner un modèle, directement ou par un sous-traitant.

Pour Mibba, l'engagement est explicite : les données des études ne servent jamais à entraîner un modèle.

2. Limiter le périmètre lu

Un outil qui prépare une relance n'a pas nécessairement besoin de lire tous les dossiers historiques. Documentez les catégories de données, les logiciels connectés, les boîtes mail, les espaces partagés et les personnes concernées. La minimisation se juge par cas d'usage, pas par une autorisation globale donnée une fois pour toutes.

3. Gérer les habilitations par rôle

Un collaborateur ne doit voir que les dossiers nécessaires à sa mission. Vérifiez la création, la modification et le retrait des droits, ainsi que la propagation d'un départ ou d'un changement d'office. La CNIL recommande de limiter chaque profil aux données nécessaires à sa mission.

Mibba applique des accès granulaires par rôle et reprend le périmètre autorisé de l'étude. Le test important reste concret : retirez un utilisateur et vérifiez immédiatement ce qu'il peut encore ouvrir.

4. Exiger une source ouvrable pour chaque information

Une réponse « sourcée » ne doit pas seulement afficher le nom d'un document. Le collaborateur doit pouvoir revenir à la pièce, au mail ou à l'acte et au passage utilisé. Une contradiction doit être signalée au lieu d'être fusionnée silencieusement.

Dans Mibba, chaque information est conçue pour citer sa source, avec un raisonnement visible et une échelle de risque qui aide le juriste à relire d'abord les passages les plus sensibles.

5. Garder une validation humaine explicite

Un mail, un classement, un projet d'acte ou une relance ne doit pas partir parce qu'un modèle a jugé sa réponse probable. L'action proposée doit rester visible, modifiable et attribuée avant exécution.

Le contrat produit de Mibba est simple : rien ne part sans validation. L'outil prépare ; le notaire ou son collaborateur vérifie, décide et valide.

6. Cartographier l'hébergement et les sous-traitants

Demandez l'hébergeur, les régions utilisées, les sauvegardes, les prestataires d'IA, les outils de support et les transferts éventuels. La CNIL demande au responsable de traitement de connaître les garanties de ses sous-traitants.

Mibba annonce un hébergement en France, une possibilité de self-host et des données qui restent dans l'écosystème de l'étude. Ces engagements doivent apparaître dans le schéma de flux et le contrat du déploiement choisi.

7. Vérifier le chiffrement, les secrets et les environnements

Le chiffrement doit couvrir le transit et le stockage, mais aussi les sauvegardes et les exports. Demandez comment sont protégés les jetons d'accès au logiciel métier, comment les environnements de test sont séparés de la production et si le support peut ouvrir un dossier sans autorisation temporaire et tracée.

8. Fixer les durées de conservation et la suppression

Chaque catégorie doit avoir une durée : documents, extraits, conversations, journaux, sauvegardes et fichiers de support. La durée de conservation doit être liée à la finalité du traitement, pas laissée indéfinie. Testez la suppression d'un dossier de démonstration et demandez quand elle atteint les sauvegardes.

9. Préparer la réversibilité et l'incident

L'étude doit pouvoir exporter ses données, retirer les accès du prestataire et continuer à travailler si le service est indisponible. Demandez le format d'export, la procédure de fin de contrat, les délais de notification d'incident et le contact d'escalade.

10. Documenter l'analyse de risque

Lorsque le traitement est susceptible d'engendrer un risque élevé, une analyse d'impact sur la protection des données peut être nécessaire avant le déploiement. Le fournisseur apporte les informations techniques ; l'étude reste responsable de la finalité, du périmètre et de l'usage réel.

Le test de démonstration qui révèle les vraies garanties

Préparez un dossier fictif contenant quatre pièges : une information ancienne, une contradiction, une pièce qui ne doit pas être visible par tous et un e-mail prêt à partir.

1. Demandez une synthèse et ouvrez chaque source.
2. Vérifiez que la contradiction apparaît explicitement.
3. Connectez-vous avec deux rôles différents.
4. Retirez l'accès de l'un des utilisateurs.
5. Préparez l'e-mail et vérifiez qu'il attend une validation.
6. Exportez puis supprimez le dossier.
7. Demandez les traces des accès et des actions réalisées.

Ce scénario en dit plus qu'une démonstration parfaite sur un dossier choisi par l'éditeur.

Ce que Mibba affirme et ce qu'il ne faut pas inventer

Mibba est construit autour de trois engagements : traçabilité totale, validation humaine et données souveraines. L'accès au logiciel métier passe par l'API officielle Septeo, le prestataire est déclaré dans l'administration de l'étude et un NDA accompagne le déploiement. Les données sont hébergées en France, ne servent pas à entraîner un modèle et un self-host est possible selon le projet.

Ces engagements ne doivent pas être transformés en labels non obtenus. Mibba ne doit pas afficher un sceau RGPD, HDS ou une certification de sécurité tant que son périmètre n'a pas été formellement audité et délivré. Demandez les preuves disponibles et leur date, exactement comme pour un autre éditeur.

La connexion à Kivia ou iNot est expliquée dans notre guide Mibba, Kivia et iNot : compatibilité et différences. Pour comparer les engagements publics de plusieurs solutions, consultez aussi le comparatif des IA notariales et notre analyse de Klaire.

Sécurité et audit patrimonial : deux contrôles distincts

Un audit patrimonial vérifie et structure la situation du client. Un audit de conformité du logiciel vérifie que l'outil utilisé pour préparer cette situation respecte les finalités, les droits, les preuves et les durées décidés par l'étude. Le premier ne remplace pas le second.

Une étude peut donc demander au même outil de reconstituer un patrimoine et, séparément, lui faire passer le scénario de sécurité décrit ci-dessus. La qualité du conseil dépend à la fois de la matière retrouvée et de la confiance que l'équipe peut accorder à son origine.