Utiliser une IA en cabinet sans trahir le secret professionnel

Oui, à condition de savoir ce qui sort du cabinet. Chez AutomateX, les documents restent dans votre Drive ou votre OneDrive, les appels au modèle partent vers des régions européennes, et chaque geste laisse une ligne dans un journal qui vous appartient. Le reste de cette page dit comment, fichier par fichier.

Écrire à Bandiougou → contact@automatex.info

Une personne répond, sous un jour ouvré. Pas de formulaire, pas de rendez-vous imposé.

Ce qui sort du cabinet, et ce qui n'en bouge pas

C'est la première question, et elle mérite une réponse matérielle plutôt qu'une promesse.

Les pièces de vos clients vivent là où elles vivaient déjà : dans le Drive ou le OneDrive du cabinet. AutomateX n'en garde que la métadonnée — de quel dossier relève le document, de quel type il est, avec quelle confiance il a été classé, où il se trouve. Le fichier lui-même n'entre jamais dans notre base.

Pour être lu, un document a bien besoin d'être transmis une fois. Cette copie de travail est déposée dans un espace temporaire dont la clé porte l'identifiant du cabinet et celui du document, de sorte que deux cabinets ne partagent jamais un emplacement. Elle est supprimée à la fin du traitement.

Le mot important est à la fin, pas en cas de succès : l'effacement est écrit dans la clause de sortie de la procédure, celle qui s'exécute même lorsque le classement échoue et que le document repart en attente. Un stockage de secours efface de son côté ce qu'un incident aurait laissé derrière lui.

Ce que cela change en rendez-vous : à la question « où sont nos pièces client ? », la réponse n'est pas un nom de fournisseur, c'est le vôtre.

Le traitement reste dans l'Union européenne

Une garantie de résidence qui repose sur une bonne intention finit toujours par sauter un jour d'incident. Celle-ci tient à quatre endroits différents.

Chaque tâche confiée au modèle — classer un document, rédiger une relance, trier un message, résumer une réponse — est routée vers un profil d'inférence dont l'acheminement est borné aux régions européennes. La table de routage est écrite dans le code, pas dans un réglage d'environnement modifiable en production.

La politique d'accès de l'infrastructure n'autorise que ces profils. Un appel qui partirait vers un routage mondial serait refusé par le fournisseur d'infrastructure lui-même, et non silencieusement acheminé ailleurs : le mode de panne est le refus, jamais la fuite discrète.

La configuration d'infrastructure porte la même valeur, et un contrôle automatique refuse d'enregistrer une modification qui la ramènerait à un routage mondial. Le retour en arrière sous pression — le geste qu'on fait à deux heures du matin pour débloquer un incident — est rendu impossible plutôt que déconseillé.

Enfin, la décision est écrite, datée et motivée dans le dépôt, avec les solutions écartées et la consigne d'escalade en cas d'indisponibilité. Un cabinet qui doit répondre à son propre délégué à la protection des données a besoin de cette pièce-là, pas d'une phrase sur une plaquette.

Le contenu de vos clients est une donnée, jamais une consigne

Un message reçu, un texte extrait d'un scan, un nom de fichier : ce sont des contenus que personne au cabinet n'a écrits. Ils sont traités comme tels.

Tous les appels au modèle passent par un point d'étranglement unique. C'est là, et à cet endroit seulement, que le contenu d'origine externe est enveloppé dans des délimiteurs explicites qui le désignent comme une donnée à analyser. Toute tentative du contenu de refermer lui-même ces délimiteurs pour en sortir est neutralisée avant l'envoi.

Quatre traitements y font passer leur matière première : le classement de document avec le texte reconnu et le nom du fichier, le tri des messages avec l'objet, le corps et les noms de pièces jointes, la réponse pré-rédigée avec le message reçu, et l'analyse de ton avec la réponse du client — déjà masquée, à ce stade, car le masquage précède toujours l'enveloppe.

La consigne de sécurité jointe à chaque appel dit la règle en toutes lettres : ce qui se trouve à l'intérieur de ces délimiteurs ne s'obéit pas, même si le contenu prétend émaner du système, du cabinet ou du fournisseur du modèle.

Le nom du cabinet lui-même, qui voyage dans la consigne, est validé à l'inscription et à chaque modification : les caractères qui servent à construire un gabarit ou à imiter un tour de parole sont refusés à l'écriture, plutôt que rafistolés en silence.

Les données sensibles sont arrêtées avant l'enregistrement

Un bandeau d'avertissement ne protège personne. Ce qui protège, c'est un détecteur qui refuse l'écriture.

Quand un collaborateur saisit une donnée sensible — cinq des huit catégories de l'article 9 du RGPD, dont les données de santé, plus les données de l'article 10 — dans une note de dossier, AutomateX l'arrête avant que la note ne soit enregistrée. La détection s'exerce à la création comme à la modification : on ne contourne pas la règle en éditant après coup.

Chaque catégorie repose sur un lexique fermé et versionné. Fermé, parce qu'un détecteur qui ratisse large devient inopérant par accoutumance et finit ignoré. Versionné, parce qu'un élargissement ou un rétrécissement silencieux se verrait alors en relecture, et pas seulement en production.

Le compte rendu de détection mérite un mot, car c'est là que la plupart des dispositifs fuient : il ne peut porter qu'un nom de catégorie et un nombre. Aucun champ n'y permet de transporter le terme trouvé, un extrait de la note, ou sa position dans le texte — une position suffirait à reconstituer le terme depuis la note d'origine.

Le même service porte aussi le masquage des identifiants d'entreprise, des coordonnées bancaires, des numéros de téléphone et des adresses électroniques. Un seul point de détection, jamais deux moteurs qui divergeraient avec le temps.

Qui voit quoi, et pourquoi ce n'est pas la même chose

Le secret professionnel ne dit pas « personne ne voit rien ». Il dit que les noms de vos clients vous appartiennent.

La même ligne de journal a donc deux lectures. Consultée par un collaborateur du cabinet, elle s'affiche en clair : ce sont ses dossiers, ses clients, et lui les connaît déjà. Consultée depuis nos écrans d'exploitation, elle s'affiche avec les valeurs sensibles masquées.

Cette distinction n'est pas une règle d'usage : c'est une valeur portée par le code, qui accompagne la ligne jusqu'à l'affichage. Nous voyons la structure et les métadonnées dont nous avons besoin pour diagnostiquer une panne. Nous ne voyons pas vos clients.

À l'intérieur du cabinet, le journal se lit selon le rôle. Un gestionnaire voit l'activité de ses propres dossiers. Un administrateur voit l'ensemble et peut exporter. Le rôle de secrétariat n'y a pas accès, avec un refus explicite et un message en français qui dit pourquoi.

Un cabinet ne lit jamais les données d'un autre

C'est l'objection qu'on nous oppose le plus souvent sur un logiciel partagé, et elle est légitime.

Le cloisonnement ne repose pas sur une condition ajoutée à chaque requête, que l'on peut oublier d'écrire. Il est posé dans la base elle-même : chaque table portant des données de cabinet applique une politique d'isolement, et cette politique est déclarée en mode forcé.

Le mot compte. Sans ce mode, une politique d'isolement s'efface dès que l'application se connecte avec un rôle privilégié — et c'est précisément ce qui se produit sur un poste de travail, où le cloisonnement ne mord donc jamais. Le mode forcé fait tenir la règle quel que soit le rôle de connexion.

Au-dessus, chaque requête entrante pose le cabinet courant dans la session de base de données avant d'atteindre le moindre enregistrement. Les deux mécanismes ne se remplacent pas : le premier est la serrure, le second est la clé, et la serrure tient même si la clé est mal tournée.

Ce qu'il reste écrit, et ce qui ne s'efface pas à la main

Une IA dont on ne peut pas reconstituer les gestes est une IA que l'ordre professionnel ne vous laissera pas défendre.

Le vocabulaire du journal est fermé et énuméré dans le code : 143 actions distinctes au jour de cette page, du classement d'un document à la validation d'une relance, de la connexion d'un écosystème à la purge d'une donnée. Le vocabulaire ne se renomme jamais, il s'ajoute : une valeur ancienne reste lisible des années après.

L'écriture est transactionnelle. La ligne de journal est écrite dans la transaction du geste qu'elle décrit, avec le même cloisonnement, et elle est attendue avant validation — jamais lancée en tâche de fond. Un geste réussi dont la trace se serait perdue en chemin ne peut donc pas exister.

Le journal ne se supprime pas à la main. La base refuse la suppression d'une ligne qui n'a pas atteint sa durée de conservation ; seule la purge programmée, qui ne travaille que sur les lignes expirées, peut effacer, et par lots. Effacer la trace d'une action gênante d'hier n'est pas une question de droits, c'est une opération que le moteur refuse.

L'export est réservé aux administrateurs, sur une plage de dates bornée, et il se lit dans un tableur. C'est la pièce qu'on tend à un contrôle, sans avoir à demander quoi que ce soit à l'éditeur.

Partir, et ce que cela veut dire concrètement

La réversibilité se juge le jour où l'on s'en va, pas le jour où on la promet.

Il n'y a rien à rapatrier : vos documents n'ont jamais quitté votre Drive ou votre OneDrive, et votre classeur de suivi est chez vous. Ce qui existe de notre côté est la métadonnée, et elle s'exporte — dossiers, documents, relances, échéances, notes, journal, configuration — dans une archive lisible sans nous.

La suppression, elle, est un chemin de code et non une demande à formuler. Elle coupe les accès à vos outils, efface les jetons encore en mémoire et supprime les données du cabinet en cascade.

Un détail dit l'esprit de la chose : la ligne de journal qui atteste la suppression est écrite avant la cascade, pas après. Si l'effacement échouait à mi-chemin, la preuve de ce qui a été demandé subsisterait quand même.