IA et cabinets d'avocats suisses : ce que le secret professionnel change dans l'architecture technique

Depuis l’adoption des lignes directrices de la Fédération Suisse des Avocats sur l’usage de l’intelligence artificielle en juin 2024, la question n’est plus de savoir si les cabinets suisses vont utiliser l’IA, mais comment. Traduction, analyse de grands volumes de documents, due diligence, enquêtes internes, résumé et amélioration de textes : les cas d’usage sont déjà identifiés par la profession elle-même.

Mais la plupart des outils d’IA générative grand public n’ont pas été conçus pour un secteur où la divulgation d’une information confidentielle est une infraction pénale, pas juste une mauvaise pratique. Pour un cabinet d’avocats suisse, brancher un agent IA sur ses dossiers clients n’est donc pas une décision technique comme une autre — c’est une décision susceptible d’engager la responsabilité pénale et disciplinaire de l’avocat responsable.

Cet article détaille ce que le secret professionnel change concrètement dans l’architecture d’un système IA, et quelles configurations permettent de construire une architecture compatible avec ces exigences.

1. Le secret professionnel n’est pas une précaution, c’est une infraction pénale

L’article 321 du Code pénal suisse ne relève pas de la déontologie ou des bonnes pratiques : c’est une norme pénale. Il couvre notamment les avocats inscrits au barreau et leurs auxiliaires, qui révèlent un secret qui leur a été confié dans l’exercice de leur profession. La sanction, poursuivie sur plainte de la personne lésée, va jusqu’à trois ans de peine privative de liberté ou une peine pécuniaire.

Ce dernier point mérite d’être souligné : l’article couvre explicitement les auxiliaires. Le fait que l’art. 321 CP vise également les auxiliaires rend particulièrement importante l’analyse du rôle des prestataires techniques : lorsqu’un fournisseur intervient dans le traitement d’informations couvertes par le secret professionnel, le cabinet doit déterminer précisément à quelles données il peut accéder, dans quelles conditions et sur quelle base contractuelle.

À cela s’ajoutent les sanctions pénales prévues par la nLPD, qui peuvent atteindre 250 000 CHF et viser personnellement la personne responsable dans les cas prévus par la loi. Les deux régimes se cumulent et pointent dans la même direction : l’architecture technique d’un cabinet d’avocats n’est pas un détail d’implémentation, c’est une question de conformité pénale.

2. Pourquoi un outil IA externe ne doit jamais être traité comme anodin

L’utilisation d’un outil d’IA externe pour traiter des informations couvertes par le secret professionnel ne peut pas être considérée comme anodine : elle nécessite de vérifier le cadre de sous-traitance, les accès aux données, leur stockage, les garanties contractuelles et, selon le cas, le consentement éclairé du client. Ce n’est pas un interdit automatique — c’est une analyse à mener avant toute mise en production, pas après.

Le réflexe classique consiste à chercher un fournisseur qui héberge ses serveurs en Europe ou en Suisse pour se rassurer. C’est insuffisant à soi seul. Le Cloud Act américain, adopté en 2018, prévoit qu’une entreprise soumise à la juridiction américaine peut être contrainte de produire des données placées sous son contrôle, indépendamment de leur localisation physique — le Department of Justice américain décrit lui-même explicitement ce principe. La localisation du datacenter ne suffit donc pas à elle seule à déterminer l’exposition juridique d’une infrastructure. Il faut également examiner l’identité de l’opérateur, les sociétés qui contrôlent le service, les juridictions auxquelles elles sont soumises et les conditions contractuelles d’accès aux données.

Cette distinction change la façon d’évaluer un outil IA pour un cabinet suisse : la géographie du datacenter est un critère parmi d’autres, pas une garantie en soi.

3. Ce que prévoient les lignes directrices de la FSA

Les lignes directrices adoptées par la Fédération Suisse des Avocats en juin 2024 ne ferment pas la porte à l’IA — elles envisagent trois voies permettant d’encadrer l’utilisation de l’IA au regard du secret professionnel.

La première consiste en un logiciel installé in situ, sur le réseau du cabinet, sans transmission des données à l’extérieur. C’est l’option la plus sûre juridiquement, mais elle exige une infrastructure et une expertise technique que peu de cabinets possèdent en interne.

La deuxième autorise le recours à un prestataire externe, à condition de respecter strictement les règles sur la sous-traitance : déterminer qui peut accéder aux données, où elles sont stockées et ce qui leur arrive, avec des garanties contractuelles équivalentes au secret professionnel lui-même. Les lignes directrices recommandent en complément l’anonymisation des informations confidentielles avant leur traitement par un système d’IA, chaque fois que c’est possible, et invitent chaque étude à établir ses propres directives internes.

Cette anonymisation n’a pas besoin d’être manuelle. Des outils open source comme Microsoft Presidio automatisent la détection et l’anonymisation ou la pseudonymisation : ils repèrent noms, adresses, IBAN, numéros de dossier ou autres identifiants dans un texte et les remplacent par des jetons avant l’envoi à un modèle d’IA. Une couche applicative peut ensuite assurer la correspondance entre ces jetons et les informations originales lorsque cela est nécessaire — ce mécanisme dépend de la façon dont le système est construit, Presidio n’assure pas cette restauration par lui-même. Concrètement, cette détection s’insère comme une couche placée entre le cabinet et le fournisseur d’IA : le prompt transmis au fournisseur contient alors moins d’informations directement identifiantes. C’est une brique technique qui vient compléter, sans la remplacer, la maîtrise contractuelle du flux de données.

La troisième, plus rarement mobilisée, prévoit la possibilité d’une renonciation au secret avec le consentement éclairé du client pour un usage précis — une option à documenter avec autant de rigueur que les deux premières, pas un raccourci.

Dans ce cadre, l’utilisation non encadrée d’un outil IA grand public ne peut pas être considérée comme une solution suffisante, quels que soient ses bénéfices en termes de rapidité ou de qualité de rédaction.

4. Les architectures possibles, concrètement

Pour un cabinet qui veut aller au-delà du logiciel in situ classique, deux approches se dégagent aujourd’hui.

Le modèle ouvert auto-hébergé. Des modèles comme Llama, Mistral ou Apertus peuvent être déployés sur une infrastructure entièrement maîtrisée par le cabinet ou par un prestataire suisse, sans transmission des données à un opérateur tiers. Apertus mérite une attention particulière : développé par l’EPFL, l’ETH Zurich et le Centre suisse de calcul scientifique, entraîné sur le supercalculateur Alps à Lugano, il est distribué en 8 et 70 milliards de paramètres sous licence Apache 2.0 — architecture, données d’entraînement et poids du modèle documentés et accessibles. Son caractère ouvert et sa possibilité de déploiement sur une infrastructure maîtrisée en font une option particulièrement intéressante pour concevoir des architectures IA souveraines en Suisse. Ouvert et auto-hébergeable ne signifie pas conforme en soi : c’est l’architecture construite autour du modèle — accès, stockage, contrats — qui détermine la conformité, pas le modèle seul.

Le prestataire suisse sous contrat strict. Des hébergeurs comme Infomaniak ou Swisscom permettent de déployer ces modèles sur une infrastructure basée en Suisse, avec des garanties contractuelles et techniques limitant strictement l’accès de l’opérateur aux données. Cette option convient aux cabinets qui ne souhaitent pas gérer eux-mêmes l’infrastructure, tout en gardant le contrôle juridique sur qui a accès à quoi.

Dans les deux cas, l’objectif est de maintenir les données dans un périmètre dont le cabinet maîtrise les accès, les flux et les conditions contractuelles — contrairement à l’utilisation non configurée d’une API généraliste.

5. Le véritable enjeu : isoler les données avant même le modèle

Choisir un modèle — Apertus, Mistral, Llama ou autre — n’est qu’une partie du problème. La question la plus déterminante se joue en amont, dans l’architecture applicative qui entoure ce modèle : comment les documents sont ingérés, indexés, et surtout qui peut y accéder.

Un système d’IA appliqué à un cabinet d’avocats repose typiquement sur une chaîne complète — ingestion des documents, OCR, anonymisation ou pseudonymisation, classification, indexation, embeddings, base vectorielle, RAG (retrieval-augmented generation), puis le modèle lui-même — avant même de parler de contrôle des accès et de journalisation. Le point clé, souvent négligé : le modèle ne devrait jamais avoir un accès non filtré à l’ensemble de la base documentaire du cabinet. Une architecture bien conçue isole les espaces documentaires par dossier et par avocat, de sorte que la requête d’un avocat sur son propre dossier ne remonte jamais, même indirectement, des informations d’un dossier auquel il n’a pas accès.

À cela s’ajoutent des exigences techniques concrètes : chiffrement des documents au repos et en transit, garantie contractuelle que les données client ne servent jamais à entraîner ou ré-entraîner un modèle tiers, politique de rétention et de suppression définie à l’avance, et isolation des environnements entre cabinets si l’infrastructure est mutualisée chez un prestataire. C’est cette couche applicative — pas le choix du LLM — qui détermine si une architecture IA respecte réellement le secret professionnel.

6. Ce qui peut être automatisé sans toucher au secret professionnel

Toutes les tâches d’un cabinet ne portent pas sur des informations protégées. La gestion administrative — accueil téléphonique, prise de rendez-vous, facturation, relances, organisation des plannings — peut s’appuyer sur des outils d’automatisation standards, y compris des agents IA grand public, sans exposer de secret professionnel, tant qu’aucune information relative à un dossier client n’y transite.

Cette distinction se structure en trois niveaux, utiles pour prioriser un déploiement :

• Niveau 1 — Données non sensibles (accueil, planning, facturation) : automatisation classique, avec les contrôles de protection des données applicables.
• Niveau 2 — Données internes au cabinet (recherche générale, rédaction non liée à un dossier précis) : IA externe possible avec garanties contractuelles et contrôle des flux.
• Niveau 3 — Données couvertes par le secret professionnel (contenu d’un dossier client) : architecture fortement contrôlée — in situ, infrastructure souveraine ou consentement éclairé documenté, selon le contexte.

Elle permet à un cabinet de commencer par automatiser ce qui ne présente aucun risque, avant d’investir dans une architecture plus lourde pour l’assistance rédactionnelle ou la recherche sur dossier. C’est la même logique que nous développons pour l’automatisation de logiciels métier dans d’autres secteurs : cartographier précisément ce qui est sensible avant de décider ce qui peut être automatisé, et comment.

7. Pourquoi une architecture sur mesure plutôt qu’un outil générique

Le marché commence à proposer des solutions IA packagées pour cabinets d’avocats, promettant une conformité prête à l’emploi. Le même principe que nous détaillons dans notre article sur Lovable et le développement sur-mesure s’applique ici : utiliser une techno conforme sur le papier ne suffit pas à produire une architecture réellement adaptée à un cabinet précis, avec ses volumes de dossiers, ses domaines de pratique et son organisation interne.

Un cabinet de droit des affaires traitant des due diligence volumineuses n’a pas les mêmes besoins qu’un cabinet de droit de la famille. Le périmètre de ce qui doit rester in situ, ce qui peut être externalisé sous contrat strict, et ce qui peut être automatisé sans précaution particulière, se définit au cas par cas — pas par un abonnement générique. C’est une question d’architecture et de modernisation technique autant que de droit.

Cet article ne constitue pas un conseil juridique : la mise en conformité définitive d’un cabinet reste une question à valider avec son ordre cantonal ou un conseil juridique spécialisé. Notre rôle se limite à la conception et à la mise en œuvre de l’architecture technique qui rend cette conformité possible.

8. Comparatif des architectures IA pour un cabinet suisse

Aucune architecture n’est “conforme” par nature : la conformité dépend du système complet — données, accès, contrats, sous-traitants, stockage, gouvernance. Ce tableau situe chaque option selon ce qu’elle permet, pas selon un statut juridique acquis d’avance.

9. Conclusion : l’architecture avant l’outil

L’intelligence artificielle a une vraie valeur pour un cabinet d’avocats suisse — gain de temps sur la recherche, la rédaction et la gestion administrative. Mais le secret professionnel n’est pas une case à cocher, c’est une infraction pénale qui peut directement engager l’avocat responsable.

Le sujet n’est finalement pas de choisir entre ChatGPT, Mistral, Llama ou Apertus. Le véritable enjeu est de concevoir sur mesure une architecture dans laquelle le modèle n’a accès qu’aux données qu’il doit traiter, dans un environnement dont les flux, les accès et les responsabilités sont maîtrisés — plutôt que d’acheter un produit générique.

Sources

• Code pénal suisse, art. 321 — Fedlex, base de données officielle du droit fédéral
• Lignes directrices de la FSA sur l’utilisation de l’IA (juin 2024), Fédération Suisse des Avocats
• CLOUD Act White Paper, US Department of Justice
• Apertus : a fully open, transparent, multilingual language model, communiqué de presse ETH Zurich
• Microsoft Presidio, dépôt open source