Automatiser le traitement de dossiers sans exposer ses données

Quand la donnée ne peut pas sortir

De plus en plus d’organisations veulent automatiser le traitement de leurs documents — classement, résumé, recherche — sans que leurs données ne quittent leurs murs. Ce besoin ne concerne pas que les établissements médico-sociaux (EHPAD, ESSMS) ou les cabinets juridiques, habitués à manier des données sensibles au sens réglementaire. Il concerne tout aussi bien :

• des entreprises qui refusent, par principe ou par contrat, que leurs documents internes servent à entraîner les modèles d’un fournisseur cloud
• des administrations ou collectivités soumises à des exigences de souveraineté numérique
• des organisations opérant sur des réseaux isolés (air-gapped) pour des raisons de sécurité, où toute connexion sortante vers un service cloud est tout simplement impossible
• des structures qui ont simplement perdu confiance dans la promesse “vos données ne sont pas utilisées” des grands fournisseurs d’IA

Le point commun à tous ces cas : la donnée ne doit pas transiter vers l’extérieur, point final. Voici, à titre illustratif, comment se construit une architecture qui répond à cette contrainte — sans client ni chiffre inventés.

Le point de départ : pourquoi le cloud pose problème

Envoyer ses documents vers une IA en ligne, c’est accepter par défaut une série de risques : on ne maîtrise pas toujours ce que le fournisseur fait de ces données une fois envoyées (conservation, réutilisation pour l’entraînement de futurs modèles, exposition via des incidents de sécurité), et pour les secteurs réglementés (santé, droit), il faut en plus qualifier ce transfert au regard du RGPD.

Pour un ESSMS, cela prend une forme concrète : les dossiers patients relèvent de données de santé au sens du RGPD (article 9), potentiellement soumises à des obligations d’hébergement de données de santé (HDS). Mais le principe est le même pour une entreprise qui ne veut simplement pas que ses contrats ou ses documents internes finissent, même indirectement, dans les données d’entraînement d’un modèle tiers.

La réponse technique n’est pas l’abandon de l’IA, mais son déplacement : faire tourner le modèle dans le réseau de l’organisation plutôt que d’y faire transiter les données vers l’extérieur — y compris sur un réseau totalement isolé d’Internet si nécessaire.

Étape 1 — Ingestion et OCR en local

Les documents (souvent scannés) sont traités par un pipeline OCR local, sans appel réseau externe. L’objectif à ce stade est purement l’extraction de texte brut, pas encore l’analyse.

Points d’attention techniques :

• Serveur dédié dimensionné pour le volume réel de l’organisation (souvent quelques centaines à quelques milliers de documents par mois, pas des millions — le dimensionnement matériel doit rester raisonnable, pas de sur-investissement)
• Isolation réseau : la machine d’ingestion n’a pas besoin d’accès sortant vers Internet une fois les modèles téléchargés — ce qui la rend compatible avec un réseau totalement air-gapped

Étape 2 — Classement via une IA installée sur place

C’est ici qu’intervient un modèle d’IA installé directement sur le serveur local, à l’aide d’outils spécialisés dans ce type de déploiement (les plus connus dans cet écosystème s’appellent llama.cpp ou Ollama). Contrairement à une idée reçue, faire tourner ce type de modèle ne demande pas une salle de serveurs entière : des versions allégées et optimisées (“quantifiées”, au format GGUF pour les connaisseurs) tiennent sur une seule carte graphique grand public. Le modèle classe le document par type (consultation, examen, facturation, courrier) à partir de son contenu, sans qu’aucune donnée ne sorte du réseau local.

Un point souvent sous-estimé : la vérification humaine reste indispensable. Un modèle local, même bien choisi, se trompe — l’enjeu n’est pas de viser le zéro-erreur mais de mettre en place une revue rapide qui capte les cas ambigus sans re-ralentir le processus.

Étape 3 — Résumé et recherche dans la base documentaire

Pour retrouver rapidement une information précise (“quels sont les derniers traitements prescrits pour ce résident ?”, “que dit ce contrat sur la clause de résiliation ?”), on utilise une technique appelée RAG (retrieval-augmented generation) pour les initiés. En pratique, c’est un moteur de recherche interne couplé au modèle : au lieu de demander au modèle de “connaître” tout le dossier par cœur, on indexe les documents localement, puis on ne lui transmet que les passages pertinents au moment de la question.

L’avantage de cette approche, quel que soit le secteur : on peut ancrer strictement les réponses aux passages retrouvés, ce qui limite le risque d’hallucination — un point critique aussi bien pour une information médicale erronée que pour une clause contractuelle mal interprétée.

Étape 4 — Contrôle d’accès et traçabilité

Le traitement local des données ne dispense pas d’une gestion rigoureuse des accès : contrôle basé sur les rôles (RBAC), journalisation des consultations et modifications, formation continue du personnel. Ce sont des briques classiques de gouvernance des données, mais leur absence est souvent ce qui fait échouer un audit RGPD — bien plus que le choix technique du modèle.

Ce qu’il faut retenir

• Le traitement local n’est pas un compromis technique, c’est une réponse à une exigence concrète — qu’elle soit réglementaire (santé, droit), contractuelle (clauses de confidentialité), ou de simple souveraineté sur ses propres données
• Les modèles allégés actuels permettent des déploiements sur site réalistes, sans nécessiter d’infrastructure cloud coûteuse ni de compétences en data center
• La recherche documentaire locale plutôt que le réentraînement de modèle pour la plupart des cas d’usage : plus simple à maintenir, plus traçable, plus facile à auditer
• Compatible avec les environnements les plus contraints, réseaux isolés compris, puisque rien ne transite vers l’extérieur une fois l’installation faite

FAQ

Faut-il un data center pour faire tourner une IA en local ? Non. Avec des modèles allégés (dits “quantifiés”) et des outils comme llama.cpp ou Ollama, une seule carte graphique dédiée suffit généralement pour les volumes d’une organisation de taille moyenne.

Cette architecture fonctionne-t-elle sur un réseau totalement isolé d’Internet (air-gapped) ? Oui, c’est même l’un des principaux cas d’usage. Une fois les modèles et les outils installés, aucune connexion sortante n’est nécessaire pour faire fonctionner l’ensemble du pipeline.

Est-ce que mes documents peuvent servir à entraîner un futur modèle si je passe par une IA en ligne ? Cela dépend entièrement des conditions contractuelles du fournisseur, qui peuvent aussi changer dans le temps. Le traitement local supprime la question : aucune donnée ne sort jamais du réseau de l’organisation, donc aucun risque de réutilisation, quelle que soit la politique du fournisseur.

La recherche documentaire locale (RAG) remplace-t-elle le réentraînement d’un modèle ? Pas systématiquement, mais pour la majorité des cas d’usage (recherche, résumé, classement), c’est plus simple à maintenir et plus facile à auditer, car les réponses restent ancrées aux documents source.

Cette architecture est-elle compatible avec une obligation d’hébergement de données de santé (HDS) ? Le traitement local réduit le périmètre de sous-traitance externe, mais la qualification HDS dépend de l’architecture globale et doit être vérifiée au cas par cas avec un DPO ou un juriste spécialisé.

---

Cet article présente une architecture type à titre illustratif et ne décrit pas un déploiement client nommé.