0 RAG sur clients : notre choix de souveraineté pour l'IA en cabinet fiduciaire
Pourquoi FidUp n'envoie aucun document client à OpenAI ou aux modèles US. Architecture, limites, et ce que ça change concrètement pour un cabinet suisse.
GA
Greg Annas
Co-fondateur BeGenerous Digital
Dans la conception de FidUp, une décision a été prise tôt et n'a jamais bougé : aucune donnée client ne traverse l'Atlantique. Aucun envoi à OpenAI, aucun appel à Google Gemini, aucun document fiscal indexé sur des serveurs US. Cette page explique pourquoi, comment, et ce que ça change concrètement pour un cabinet fiduciaire suisse.
TL;DR — Le principe
0 envoi à OpenAI / Gemini pour les données client (pièces fiscales, documents bancaires, identités)
IA générative uniquement via Claude API EU (Anthropic, hébergement Frankfurt) avec accord DPA
Embeddings via Voyage AI (vendor compatible EU, modèle voyage-finance-2)
RAG sur le seul corpus public (réglementation, OFC, OAR) — jamais sur les documents client
Toutes les inférences IA sont auditées et tracées par tenant
1. Le contexte : pourquoi cette question importe pour un cabinet
Un cabinet fiduciaire traite quotidiennement :
Bilans et comptes de PME (souvent confidentiels stratégiques)
Apprentissage par le modèle : par défaut, plusieurs vendors entraînent leurs modèles sur les données envoyées (sauf opt-out explicite)
nLPD / RGPD : le transfert vers les US sans garanties suffisantes peut être contraire au cadre suisse
Pour un cabinet qui doit garantir le secret professionnel (art. 321 CP) et la conformité nLPD, ces risques ne sont pas théoriques.
2. Le piège du "RAG sur tout"
Le pattern RAG (Retrieval Augmented Generation) est devenu standard pour les SaaS qui veulent ajouter de l'IA à leur produit. L'idée : indexer tous les documents d'un client dans une base vectorielle, puis interroger un LLM avec ces documents en contexte.
Le problème : pour que le RAG fonctionne, il faut envoyer le contenu des documents au LLM. Si le LLM est hébergé aux US (OpenAI, Anthropic US, Google), chaque requête expose un fragment de document client à un acteur soumis au Cloud Act.
La plupart des SaaS B2B contournent en disant "on utilise OpenAI mais on a opt-out de l'entraînement". C'est vrai techniquement, mais ne couvre pas les deux autres risques (Cloud Act + transfert nLPD).
3. Notre architecture : ce qu'on fait, ce qu'on ne fait pas
Ce qu'on fait
Stockage des documents : Infomaniak Public Cloud Genève (S3-compatible, hébergement suisse souverain)
IA générative : Claude API via endpoint EU (Anthropic Frankfurt), DPA signé
Embeddings : Voyage AI voyage-finance-2, fournisseur EU-compatible
Ce qu'on ne fait pas
Aucun appel OpenAI / GPT-4 / GPT-5 sur les documents client
Aucun envoi à Google Gemini, même via Workspace
Aucun envoi à Microsoft Copilot ou Azure OpenAI (juridiction Microsoft Cloud)
Aucun stockage de fichiers client sur Supabase Storage (Cloud Act US)
Aucun RAG sur les documents propres au tenant (sauf opt-in explicite avec consentement client documenté)
Ce que ça veut dire en pratique
Quand l'AMLCO de votre cabinet pose une question type "résume-moi les évolutions FATF 2026 pour les fiduciaires" :
Le LLM Claude reçoit la question + un corpus public (texte LBA, recommandations FATF publiques, jurisprudence FINMA)
Aucun document de votre tenant n'est envoyé
La réponse est générée, retournée, et n'est pas conservée chez Anthropic au-delà de la durée de traitement (DPA standard)
Quand un collaborateur génère un Brief Matin IA :
Le Brief utilise les métadonnées des mandats actifs (dates, échéances, alertes système)
Aucun contenu de pièce fiscale n'est envoyé au LLM
La rédaction du Brief est faite à partir d'un template + données structurées
4. Les limites de notre choix (transparence)
Ce choix a un coût. Il faut le reconnaître honnêtement :
Limite 1 — Pas de RAG conversationnel sur "tous vos documents"
Beaucoup d'outils SaaS proposent "demande à l'IA n'importe quoi sur tes dossiers clients". Nous, non. Une question sur le dossier du client X demandera à l'AMLCO d'ouvrir le dossier, sélectionner les pièces concernées, et la pose au Copilot avec un contexte explicite. L'IA voit ce que l'utilisateur lui montre, jamais plus.
Limite 2 — Pas d'auto-complétion sur les documents client
Pas de "GPT remplit la déclaration TVA automatiquement à partir de tous tes documents". L'auto-complétion utilise des données structurées (rubriques fiscales, montants en DB), pas un LLM lisant en arrière-plan.
Limite 3 — Coût d'infrastructure
Stocker les fichiers à Infomaniak Genève coûte plus cher que sur S3 US standard. Pas dramatiquement, mais c'est un choix budgétaire assumé.
Limite 4 — Pas d'OCR cloud des grandes marques
Pour l'OCR, on utilise pdfkit + Claude PDF natif (parse de PDF sans conversion image). Ce qu'on ne fait pas : Azure Document Intelligence, Google Document AI, AWS Textract. C'est moins puissant sur les cas exotiques mais sécurisé par design.
La cohérence est tout
Beaucoup d'outils annoncent "hébergement suisse" sur leur page d'accueil et envoient les documents à OpenAI dans le pipeline d'analyse. Lire les conditions techniques détaillées (DPA + sous-traitants) est essentiel pour vérifier la cohérence.
5. Pourquoi Claude et pas Mistral ou un modèle suisse ?
Question légitime. Notre choix Claude vs alternatives :
Mistral (français)
Pour : juridiction française, EU
Contre : performance plus faible sur le raisonnement juridique et les tableaux financiers complexes en 2026
Verdict : à reconsidérer en 2027 si Mistral Large ratrappe Claude sur ces cas d'usage
Modèles open-source en local (Llama, Qwen, DeepSeek)
Pour : 100% local, aucune donnée ne sort
Contre : qualité significativement inférieure pour les tâches de raisonnement fiduciaire, coût d'infrastructure GPU lourd
Verdict : pas viable pour la qualité requise en 2026
Claude (Anthropic, EU endpoint)
Pour : meilleur modèle disponible pour raisonnement juridique et analyse financière
Pour : endpoint EU disponible avec DPA, opt-out d'entraînement par défaut, log audit
Contre : Anthropic est une société US, donc le Cloud Act peut s'appliquer techniquement même via endpoint EU
Verdict : meilleur compromis pratique en 2026, à réévaluer si MistralLarge 3 ou un modèle européen sérieux émerge
Stack potentielle 2027
Si un acteur européen sérieux (Mistral, Aleph Alpha, ou un consortium suisse) atteint la qualité Claude, la stack peut être migrée. L'architecture est conçue pour permettre ce swap sans tout refactorer.
6. Ce que ça change pour votre cabinet
Sur le plan juridique
nLPD : pas de transfert vers les US, pas de DPIA US à documenter
Secret professionnel : pas d'exposition des documents client à un acteur soumis au Cloud Act
Audit OAR : la souveraineté des données IA est un point qui peut être contrôlé
Sur le plan opérationnel
Vous gardez le contrôle sur ce que l'IA voit
Les workflows IA sont prévisibles, pas magiques
Les performances sont équivalentes à un produit US pour 95% des cas d'usage fiduciaire
Sur le plan commercial
Vous pouvez répondre "oui, c'est conforme nLPD et souverain" à vos clients qui posent la question
Pour vos clients eux-mêmes en compliance critique (banques, assurances, médico-social), ce point peut faire la différence
Architecture IA souveraine de FidUp
Tous les détails techniques de notre architecture (sous-traitants, DPA, juridictions) sont publics dans nos engagements sécurité. Vous pouvez les fournir à votre AMLCO ou à votre DPO pour validation interne.
L'IA générative est un outil puissant. Mais "tout envoyer à OpenAI" n'est pas la seule architecture possible. Pour un cabinet fiduciaire suisse en 2026, faire des choix techniques précis sur la souveraineté n'est pas un luxe — c'est une condition de viabilité juridique.