par Ketl
28 mai 2026
16 min de lecture
IA dans les secteurs réglementés : le guide complet pour déployer l'intelligence artificielle quand rien ne peut être laissé au hasard
Comment déployer l'IA dans une étude d'avocats, une banque, une étude notariale ou une assurance sans compromettre le secret professionnel ni la conformité nLPD/FINMA. Les six principes que nous appliquons dans nos déploiements.
Quand on parle d'IA dans une étude d'avocats, une banque privée ou un cabinet médical, la conversation suit presque toujours le même chemin. On commence par une démonstration impressionnante d'un grand modèle de langage généraliste. Tout le monde s'enthousiasme pendant dix minutes. Puis quelqu'un pose la question : « Mais en pratique, on peut vraiment utiliser ça sur nos dossiers ? ». Et la conversation s'arrête.
C'est là que se situe le vrai sujet. L'IA dans les secteurs réglementés n'est pas un débat technologique. C'est un problème de design opérationnel et juridique. Une étude d'avocats peut utiliser ChatGPT pour rédiger un email à un fournisseur. Elle ne peut pas l'utiliser pour traiter un dossier client sans engager sa responsabilité au titre de l'art. 321 du Code pénal suisse. Une banque peut utiliser un copilote IA pour résumer un article de presse. Elle ne peut pas le faire pour analyser un dossier KYC sans documenter précisément où vont les données, qui y accède, et selon quelles règles.
Cet article rassemble les six principes que nous appliquons dans nos déploiements d'IA pour les secteurs où la confidentialité, la traçabilité et la conformité ne sont pas des options. Il s'adresse aux dirigeants d'études d'avocats, aux directions juridiques d'entreprise, aux compliance officers de banques et d'assurances, aux notaires et aux établissements de santé qui veulent passer de l'expérimentation à un déploiement structuré, sans compromis sur leurs obligations professionnelles.
Pourquoi l'IA grand public n'a jamais été conçue pour vos dossiers
Il y a un malentendu fondamental qui structure aujourd'hui le marché de l'IA en entreprise. Les grands modèles de langage généralistes — ceux que tout le monde a appris à utiliser via les chatbots du grand public — sont conçus selon une logique qui s'oppose terme à terme à celle des secteurs réglementés.
Ils sont conçus pour maximiser l'usage : plus on échange avec eux, plus ils apprennent, plus leur valeur économique augmente. Les secteurs réglementés exigent au contraire de minimiser l'exposition : chaque donnée transmise est un risque potentiel.
Ils sont conçus pour généraliser à partir d'un corpus public planétaire. Les secteurs réglementés exigent une précision sur un corpus métier restreint : la jurisprudence du Tribunal fédéral suisse, les circulaires FINMA, le droit des assurances helvétique.
Ils sont conçus pour paraître toujours sûrs d'eux, parce que l'utilisateur grand public préfère une réponse fluide à un aveu d'incertitude. Les secteurs réglementés exigent l'inverse : un modèle qui signale ses doutes et permet au professionnel de garder la main sur la décision.
Trois principes structurent en pratique tout déploiement d'IA dans un secteur réglementé.
Confidentialité absolue. Les dossiers, la correspondance, les pièces clients sont protégés par le secret professionnel. Aucun transfert vers une infrastructure non maîtrisée ne peut être justifié par un gain de productivité.
Auditabilité. Toute action de l'IA doit être traçable, explicable et reproductible a posteriori. Une réponse non journalisée est, par défaut, un risque.
Responsabilité humaine. La décision finale reste au professionnel. L'IA assiste. Elle ne signe pas. Cette ligne ne se discute pas, parce qu'elle est juridiquement structurante.
Les six principes qui suivent sont la manière concrète de tenir ces trois engagements dans un déploiement réel.
Principe 1 — Hébergez vos données là où le droit les protège
La juridiction d'hébergement est la première décision stratégique d'un projet IA en secteur réglementé. Elle est rarement traitée avec la rigueur qu'elle mérite, parce qu'elle semble technique alors qu'elle est avant tout juridique.
Le Cloud Act américain, le RGPD européen et la nLPD suisse ne couvrent pas les mêmes risques. Une donnée stockée chez un fournisseur américain — même dans un datacenter physiquement situé en Europe ou en Suisse — peut faire l'objet d'une réquisition par une autorité fédérale américaine. Le fournisseur est légalement tenu de fournir les données, indépendamment de leur localisation physique. C'est la conséquence directe du Cloud Act, dont on ne sort pas en activant une « région suisse » d'un hyperscaler.
Pour un déploiement d'IA en secteur réglementé, trois exigences sont à poser noir sur blanc dans le cahier des charges.
L'hébergement doit être en Suisse ou dans l'UE, sous juridiction locale, opéré par une société soumise au droit suisse ou européen — pas par une filiale d'un groupe étranger soumise à des lois extraterritoriales.
L'infrastructure doit être dédiée, jamais mutualisée avec des tiers inconnus dans des conditions qui empêcheraient d'isoler vos flux de données.
Les modèles doivent être opérés en interne, soit via des modèles propriétaires soit via une API LLM souveraine avec mécanisme de type bring-your-own-key, qui garantit que les requêtes ne sont pas utilisées pour entraîner des modèles tiers ni stockées au-delà du strict nécessaire.
Cette exigence d'hébergement souverain n'est pas un confort. Pour les professions soumises au secret professionnel pénal — avocats, notaires, médecins, banquiers privés — c'est une condition nécessaire pour pouvoir utiliser l'outil sans contrevenir à ses obligations professionnelles. Aucune clause contractuelle ne peut remplacer une bonne géographie.
Principe 2 — L'IA propose, l'humain décide
Aucun acte juridique, financier ou médical ne devrait être produit sans validation explicite d'un professionnel. Cette ligne paraît évidente formulée ainsi, mais elle s'efface très vite dans la pratique quotidienne quand on déploie un outil IA puissant et qu'on en mesure le gain de temps.
Le flux de travail à imposer est structuré en trois étapes que le système doit rendre obligatoires.
Étape 1 — Requête. Le professionnel formule une question contextualisée. Il ne se contente pas d'un prompt vague : il indique le dossier, le contexte, les contraintes applicables. Cette discipline d'entrée conditionne la qualité de la sortie.
Étape 2 — Proposition IA. Le système produit une analyse, cite ses sources, propose un projet explicable et sourcé. Pas une réponse définitive : une proposition étayée, dans laquelle chaque affirmation est traçable.
Étape 3 — Validation. Le professionnel valide, modifie ou rejette la proposition avant tout envoi, signature ou décision. Cette validation est elle-même journalisée, ce qui matérialise la chaîne de responsabilité.
Cette structure « propose / décide » n'est pas une lourdeur ajoutée pour rassurer le compliance officer. C'est ce qui permet de tirer pleinement parti de la productivité de l'IA sans transférer la responsabilité du professionnel vers une boîte noire. L'IA accélère l'analyse et la rédaction. Le professionnel apporte le jugement, la connaissance du client, l'évaluation du risque. Aucun des deux ne peut faire le travail de l'autre.
C'est aussi ce qui distingue un usage professionnel d'un usage grand public. Un avocat qui copie-colle un email du chatbot sans relecture engage sa responsabilité sans avoir exercé son métier. Un avocat qui utilise une IA pour préparer un projet, le retravaille à la lumière du dossier, le valide en connaissance de cause, fait son métier mieux et plus vite. La différence n'est pas dans l'outil mais dans le flux.
Principe 3 — À chaque dossier, ses permissions
L'IA ne doit voir que ce que l'utilisateur a déjà le droit de voir. Cette règle, qui paraît évidente, est régulièrement violée dans les déploiements naïfs où l'on connecte un grand modèle à l'ensemble du référentiel documentaire sans filtre.
Le cloisonnement par dossier, par client, par équipe, le contrôle d'accès — ce sont les fondations d'un déploiement responsable. Une IA qui peut, par construction, croiser deux dossiers en conflit d'intérêts entre eux est un risque déontologique majeur pour une étude d'avocats, et un risque réglementaire majeur pour une banque.
Quatre garde-fous non négociables structurent un déploiement sain.
Le cloisonnement par dossier. L'IA hérite des droits de l'utilisateur, jamais de droits étendus. Si un collaborateur n'a pas accès au dossier X, l'IA non plus, quand cet utilisateur l'interroge. Cette propagation des droits doit être technique, pas déclarative.
L'authentification forte et le SSO d'entreprise, avec MFA imposé pour les rôles sensibles. C'est la base que tout déploiement professionnel doit présenter. Sans authentification robuste, toute la chaîne de traçabilité repose sur du sable.
Le respect des murailles de Chine. L'IA ne fait jamais le pont entre des dossiers en conflit d'intérêts. Cette règle s'applique aussi à la phase d'indexation et d'apprentissage : un modèle qui aurait été exposé à deux dossiers concurrents pourrait fuiter des informations de l'un vers l'autre, même en l'absence de requête explicite. Le cloisonnement doit être structurel, pas seulement applicatif.
La révocation immédiate et la rotation régulière des accès. Un collaborateur qui quitte la structure perd ses accès dans l'heure, pas dans la semaine. Les accès sont revus régulièrement, parce que les permissions accumulées dans le temps sont l'une des principales sources de fuites.
Cette discipline d'accès est ce qui distingue un déploiement professionnel d'un déploiement bricolé. Elle est aussi ce qui rend les solutions IA grand public structurellement inadaptées : elles ne sont pas conçues pour propager finement les droits d'un référentiel métier complexe.
Principe 4 — Un modèle conçu pour votre métier
Un grand modèle de langage généraliste est impressionnant en démonstration. Sur vos propres dossiers, dans votre propre vocabulaire, la performance s'effondre. Cette observation, nous l'avons faite au point qu'elle est devenue une règle interne : avant tout déploiement, on benchmark le modèle envisagé sur 30 à 50 requêtes représentatives du métier client, et on mesure l'écart avec la démo standard.
L'écart est presque toujours significatif. Un modèle généraliste qui répond brillamment à « résume ce contrat » se trompe régulièrement sur « identifie les clauses non conformes à l'art. 199 CO dans ce contrat de bail commercial vaudois ». Pas parce qu'il est mauvais, mais parce qu'il n'a pas été entraîné spécifiquement sur le droit suisse, sur la jurisprudence cantonale, sur le vocabulaire technique du métier.
Trois éléments doivent être vérifiés avant tout déploiement à grande échelle.
Le modèle doit être entraîné ou orchestré pour votre domaine. Pour le droit suisse, cela implique une exposition aux corpus juridiques helvétiques — pas seulement français ou allemands. Pour la finance, une connaissance des normes IFRS, des circulaires FINMA, des standards de reporting locaux. Pour la santé, une maîtrise des codifications médicales et des protocoles applicables.
Un pilote sur vos propres dossiers. 30 à 50 requêtes représentatives, scorées par vos experts métier. Cette phase n'est pas optionnelle. Elle est ce qui permet de quantifier le gain réel et de détecter les angles morts du modèle avant qu'ils ne deviennent des incidents en production.
Un benchmark qualité quantifié avant tout déploiement à grande échelle. On définit des critères de précision, on mesure, on documente. Sans cette discipline, le déploiement repose sur une intuition — et l'intuition, dans un secteur réglementé, n'est pas un argument défendable face à un audit.
Cette exigence de spécialisation est ce qui justifie souvent le choix d'un modèle propriétaire dédié au métier, plutôt que d'un grand modèle généraliste appelé en API. Un modèle plus petit, entraîné sur un corpus métier ciblé, peut surpasser un LLM généraliste sur les tâches qui comptent réellement pour vos équipes — tout en restant assez économe pour être opéré sur une infrastructure souveraine, sans appel à un service tiers hors juridiction.
Principe 5 — Un responsable, une charte, une revue
La meilleure technologie ne survit pas à l'absence de gouvernance. Nous voyons régulièrement des déploiements techniquement brillants qui s'effondrent au bout de douze mois parce que personne n'a été désigné responsable, qu'aucune règle d'usage n'a été écrite, qu'aucune revue n'est organisée.
Trois briques de gouvernance doivent être posées dès le jour 1, et tenues dans la durée.
Un responsable IA identifié. Une personne — pas un comité, une personne — qui est le point de contact unique pour les utilisateurs et pour la direction. Cette personne arbitre les nouveaux cas d'usage, traite les incidents, fait remonter les besoins. Sans cette responsabilité incarnée, les décisions se diluent et la gouvernance devient théorique.
Une charte d'usage acceptable signée par chaque collaborateur. Cette charte précise ce qui est autorisé et ce qui ne l'est pas. Quels documents peuvent passer dans le système. Quelles informations doivent être anonymisées avant requête. Quels cas d'usage sont interdits. La charte n'est pas un texte juridique inerte : c'est un document opérationnel, court, lisible, qui crée une culture commune.
Une revue trimestrielle. Cas d'usage déployés, incidents rencontrés, retours utilisateurs, évolutions réglementaires. Quatre fois par an, le responsable IA réunit les parties prenantes — direction, IT, compliance, utilisateurs clés — et fait le point. C'est dans ces revues qu'on détecte les dérives, qu'on ajuste la charte, qu'on identifie les nouveaux besoins.
Cette gouvernance peut sembler bureaucratique pour une structure de taille modeste. Elle ne l'est pas. C'est ce qui distingue un déploiement qui dure d'un déploiement qui se grippe après le premier incident. Et en secteur réglementé, le premier incident finit toujours par arriver — la question est de savoir si l'organisation est prête à le traiter ou si elle le découvre lors d'un audit.
Principe 6 — L'outil ne vaut que par l'usage qu'on en fait
La technologie seule ne crée pas d'avantage. Ce qui fait la différence, c'est la capacité collective à questionner, vérifier et challenger l'IA. Cette compétence ne tombe pas du ciel. Elle se forme.
Trois piliers structurent un programme de formation efficace.
Une formation obligatoire à l'onboarding pour tout utilisateur ayant accès à l'IA. Pas une vidéo de quinze minutes : une session structurée qui couvre les capacités du modèle, ses limites connues, les cas d'usage validés, les pièges à éviter, la charte de gouvernance. Sans cette formation, les utilisateurs développent leurs propres pratiques, souvent contraires à la charte et aux exigences réglementaires.
Des cas d'usage documentés par métier, tenus à jour. Pour chaque rôle — associé, collaborateur, paralegal, assistant — la liste des cas d'usage validés est documentée, avec des exemples concrets de prompts, les vérifications attendues, les sources à consulter en complément. Cette documentation évolue avec la pratique : on y ajoute les nouveaux cas validés, on y retire ceux qui se sont révélés problématiques.
Une culture du doute productif. L'IA produit des réponses fluides qui inspirent confiance. C'est précisément le piège. Les équipes doivent acquérir le réflexe de vérifier les sources avant de citer, de challenger une affirmation qui « sonne » bien mais ne s'aligne pas avec leur connaissance du dossier, de signaler les erreurs au responsable IA pour qu'elles soient documentées. Cette culture ne se décrète pas : elle se construit en valorisant publiquement les détections d'erreurs, en partageant les retours d'expérience, en intégrant la vigilance aux revues trimestrielles.
Ce sixième principe est celui qu'on sous-estime le plus dans les déploiements. On investit massivement dans l'outil, modestement dans la formation. Le résultat est prévisible : un outil puissant utilisé en deçà de ses capacités, ou pire, utilisé d'une manière qui crée des risques. L'investissement dans la formation a un meilleur retour que l'investissement dans la version supérieure de l'outil.
Application sectorielle : ce qui change selon votre métier
Les six principes ci-dessus sont valables pour tous les secteurs réglementés. Mais leur mise en œuvre concrète varie selon le métier. Voici les points d'attention spécifiques par secteur.
Études d'avocats et études notariales
L'enjeu central est l'art. 321 du Code pénal suisse — le secret professionnel pénal. Tout transfert de données client vers une infrastructure hors juridiction suisse expose à un risque déontologique réel. Les murailles de Chine entre dossiers en conflit d'intérêts doivent être structurellement garanties par le système, pas seulement déclaratives. L'archivage à valeur probatoire est essentiel pour les actes et pour la traçabilité des conseils donnés. La spécialisation du modèle sur le droit suisse — fédéral et cantonal — est un facteur clé de performance.
Banques et établissements financiers
Le cadre est structuré par la FINMA, notamment par les circulaires sur l'externalisation (Circ.-FINMA 18/3) et sur les risques opérationnels. Toute solution IA est une externalisation au sens de la FINMA et doit être documentée comme telle. La cartographie écrite des flux de données est exigible. L'audit trail doit être conservé selon les durées légales applicables. Les modèles utilisés pour des décisions à enjeu — analyse KYC, scoring crédit, alertes LBA — doivent être explicables et défendables face à un audit. Un modèle propriétaire spécialisé sur les normes IFRS et le cadre prudentiel suisse est souvent préférable à un LLM généraliste.
Assurances
Le cadre est posé par la Loi sur la surveillance des assurances (LSA). Les enjeux sont la gestion des données particulièrement sensibles — santé en assurance complémentaire, données financières en prévoyance — et la traçabilité des décisions de souscription ou de sinistre. La spécialisation du modèle sur la terminologie LSA et sur les pratiques sectorielles suisses est un facteur de performance significatif. Les fonctionnalités de détection de fraude doivent être particulièrement encadrées en gouvernance.
Santé
Le cadre est celui de l'art. 321 CP (secret médical) et de la nLPD pour les données particulièrement sensibles. L'hébergement souverain est non négociable. Les flux de données doivent être documentés à un niveau de précision rarement exigé dans les autres secteurs. La spécialisation du modèle sur les codifications médicales — CIM-11, SwissDRG — et sur la pratique clinique helvétique est essentielle. Les cas d'usage doivent être strictement bornés et passer par une validation médicale systématique : l'IA ne diagnostique pas, elle propose une analyse documentaire.
Directions juridiques d'entreprise
L'enjeu est différent : pas de secret professionnel pénal, mais une exposition réelle au secret d'affaires, à la confidentialité contractuelle, et de plus en plus à l'AI Act européen pour les organisations qui opèrent en UE. Les cas d'usage typiques — contract review, due diligence, veille réglementaire — nécessitent une spécialisation sur le droit applicable et un cloisonnement strict des dossiers M&A en cours.
Comment évaluer une solution d'IA pour un secteur réglementé : la checklist
Si vous évaluez actuellement une solution d'IA pour votre étude, votre établissement financier ou votre organisation, voici les questions à poser à chaque éditeur. Si une seule reste sans réponse écrite claire, c'est un signal.
Hébergement et juridiction. Dans quel datacenter exactement les données sont-elles stockées ? Quelle société opère ce datacenter ? Sous quelle juridiction tombe-t-elle ? L'éditeur de la solution est-il une société suisse ou européenne, ou une filiale d'un groupe étranger ?
Traitement IA. Quand l'IA lit mes documents pour les analyser, où tourne-t-elle physiquement ? S'agit-il d'un modèle propriétaire opéré en interne, ou d'un appel à un service tiers ? Si appel à un tiers, lequel, et sous quelles conditions contractuelles ?
Conservation et usage. Mes données sont-elles utilisées pour entraîner d'autres modèles, même de manière anonymisée ? Combien de temps sont-elles conservées par le fournisseur d'IA ? Selon quelles règles peuvent-elles être détruites à la demande ?
Audit trail. Le système produit-il un journal d'audit signé exportable ? Quelles informations le journal contient-il ? Comment puis-je le consulter, l'exporter, le présenter à un auditeur externe ?
Gestion des accès. Comment les droits utilisateurs sont-ils propagés au modèle IA ? Le cloisonnement par dossier est-il technique ou déclaratif ? Comment les conflits d'intérêts sont-ils gérés au niveau du modèle ?
Spécialisation métier. Sur quels corpus le modèle a-t-il été entraîné ou fine-tuné ? Existe-t-il un benchmark sur des tâches représentatives de mon métier ? Puis-je organiser un pilote sur mes propres documents avant signature ?
Réversibilité. En cas de rupture du contrat, sous quel format mes données me sont-elles restituées, dans quel délai, à quel coût ? Cette réversibilité est-elle contractualisée ou laissée à la bonne volonté du fournisseur ?
Les réponses écrites à ces sept blocs de questions disent plus sur la qualité d'une solution IA en secteur réglementé que toutes les démonstrations commerciales.
Ce que nous avons construit avec Ketl, et pourquoi
Nous avons conçu Ketl, dès le départ, pour les exigences des secteurs réglementés. Pas comme un produit grand public adapté après coup, mais comme une plateforme dont l'architecture intègre les six principes ci-dessus par conception.
Concrètement, cela se traduit par trois choix structurants.
Un hébergement intégralement suisse, dans des datacenters certifiés opérés par des sociétés suisses, sous juridiction suisse. Aucun document ne quitte le territoire à aucune étape de son cycle de vie, y compris pendant le traitement par l'IA.
Des modèles d'IA propriétaires, développés en interne, spécifiquement entraînés sur les corpus métiers de nos clients — droit suisse, normes financières helvétiques, pratiques sectorielles. Ces modèles sont environ mille fois plus légers qu'un grand modèle de langage généraliste, ce qui les rend assez efficients pour tourner intégralement sur notre infrastructure souveraine, sans aucun appel à des services tiers hors juridiction.
Une traçabilité de bout en bout, avec journal d'audit immuable signé cryptographiquement, sources systématiquement citées et accessibles pour chaque réponse, cloisonnement par dossier propagé techniquement au modèle, et workflow « propose / décide » intégré par conception.
À ce jour, Ketl traite plus de 26 millions de documents pour plus de 1 000 utilisateurs dans 11 secteurs réglementés — études d'avocats, études notariales, banques privées, fiduciaires, assurances, immobilier, gestion de patrimoine. Cette base d'usage est ce qui nous a permis d'affiner les six principes présentés dans cet article : ils ne sont pas théoriques, ils sont la synthèse de ce qui marche réellement dans nos déploiements.
Si vous voulez voir concrètement ce que cela donne sur vos propres dossiers, vous pouvez demander une démonstration gratuite à ketl.ch/demo. Si vous voulez d'abord discuter de votre contexte sans engagement, contact@ketl.ch — nos experts basés à Genève seront à votre service pour vous conseiller.
Article rédigé par l'équipe Ketl. Nos bureaux sont situés au 15 Avenue de Sécheron, 1202 Genève, avec une présence à Lausanne sur rendez-vous. Nous sommes une société suisse, opérée depuis la Suisse, et nous accompagnons les secteurs réglementés sur leurs déploiements d'IA souveraine.