Protéger les secrets commerciaux avec les outils d'IA en Suisse

Pour protéger un secret commercial manipulé par des outils d'IA en Suisse, appliquez immédiatement une architecture souveraine, des clauses contractuelles strictes et une journalisation prouvée. Ces trois piliers forment le socle minimal exigé par la Loi fédérale contre la concurrence déloyale (LCD) et par la nLPD pour que votre secret reste juridiquement opposable en cas de litige.

Voici les actions à lancer dans les quelques jours suivant la détection :

• Isoler les flux de données sensibles : identifier quels prompts, documents ou datasets contiennent des informations confidentielles et les séparer des flux envoyés à des services tiers.
• Activer un hébergement suisse ou on-premise : s'assurer que les modèles d'IA traitant ces données sont hébergés sur des serveurs situés en Suisse, soumis exclusivement au droit suisse.
• Signer ou mettre à jour le contrat de traitement des données (DPA) avec chaque fournisseur d'IA, en y incluant une clause interdisant explicitement l'utilisation des données pour l'entraînement de modèles.
• Activer la journalisation des accès : configurer des logs immuables couvrant chaque interaction avec l'outil d'IA (identifiant utilisateur, horodatage, version du modèle, nature de la requête).
• Rédiger ou mettre à jour la charte IA interne : définir quelles catégories d'informations ne peuvent pas être soumises à un outil d'IA sans validation préalable.
• Lancer une analyse d'impact relative à la protection des données (AIPD) pour chaque usage d'IA manipulant des secrets d'affaires, conformément aux art. 22 nLPD.

Verdict : architecture souveraine + mesures contractuelles + preuve documentaire.

Points clés

La protection des secrets commerciaux face aux outils d'IA en Suisse repose sur trois piliers indissociables : architecture souveraine, mesures contractuelles opposables et documentation probatoire constituée en amont de tout incident.

Table des matières

• Quels objets numériques peuvent être protégés comme secrets d'affaires ?
• Quel cadre juridique suisse s'applique à la protection de vos secrets d'affaires numériques ?
• Quels risques spécifiques les outils d'IA font-ils peser sur vos secrets d'affaires ?
• Quelles mesures techniques concrètes réduisent le risque de fuite via l'IA ?
• Quelles clauses contractuelles et règles organisationnelles s'imposent face aux fournisseurs d'IA ?
• Comment évaluer un fournisseur d'IA lors d'un appel d'offres ?
• Quelle feuille de route opérationnelle suivre pour déployer l'IA en toute sécurité ?
• Que faire immédiatement en cas de fuite présumée d'un secret via un outil d'IA ?
• Comment constituer des preuves que vous avez pris des mesures raisonnables ?
• Trois cas pratiques pour appliquer ces mesures à des situations concrètes
• Pourquoi la souveraineté des données est-elle un enjeu stratégique pour les juristes et professionnels suisses ?
• Nectos : l'espace IA souverain pour protéger vos secrets commerciaux en Suisse
• Sources
• Questions fréquentes

Quels objets numériques peuvent être protégés comme secrets d'affaires ?

La Partie VII du guide WIPO sur les secrets d'affaires et les objets numériques confirme qu'un algorithme, un jeu de données ou un code source peut bénéficier de la protection des secrets d'affaires, à condition de satisfaire trois critères cumulatifs.

Condition 1 : le caractère secret. L'information ne doit pas être généralement connue ni aisément accessible dans les milieux qui s'y intéressent. Un algorithme de scoring client interne, non publié et non déposé, remplit ce critère. Un modèle de langage affiné sur des données propriétaires peut également le remplir, à condition que la procédure d'affinage elle-même reste confidentielle.

Condition 2 : la valeur commerciale tirée du secret. L'information doit procurer un avantage concurrentiel précisément parce qu'elle n'est pas connue. Un dataset d'entraînement constitué de transactions historiques propriétaires, ou une structure de prompt métier optimisée pour une pratique juridique spécifique, satisfont à cette exigence dès lors qu'ils permettent d'offrir un service différencié.

Condition 3 : des mesures de protection raisonnables. C'est ici que la plupart des organisations échouent. La protection ne se présume pas ; elle se prouve. Les mesures doivent être proportionnées à la valeur du secret et documentées.

Parmi les objets numériques éligibles, on trouve notamment :

• Les algorithmes de décision ou de recommandation développés en interne.
• Le code source d'applications propriétaires, y compris les scripts d'automatisation.
• Les datasets d'entraînement constitués à partir de données clients ou de transactions internes.
• Les structures de prompts métier contenant des instructions stratégiques ou des critères d'évaluation confidentiels.
• Les métadonnées de procédé révélant une méthode de production ou d'analyse non publique.

Pour prouver l'existence du secret en cas de litige, conservez un historique de versioning daté (Git avec commits signés, par exemple), des journaux d'accès restreint, et des contrats de confidentialité signés par toute personne ayant eu accès à l'objet. La gestion documentée des documents confidentiels avec l'IA constitue un point de départ pratique pour structurer cet archivage.

Conseil de pro : Créez un registre interne des secrets d'affaires numériques, mis à jour trimestriellement, qui liste chaque objet protégé, sa valeur commerciale estimée, les personnes y ayant accès et les mesures de protection en vigueur. Ce registre devient votre première pièce à conviction en cas de contentieux.

Quel cadre juridique suisse s'applique à la protection de vos secrets d'affaires numériques ?

La protection des secrets commerciaux en Suisse repose sur deux textes principaux, auxquels s'ajoute l'influence croissante du règlement européen sur l'IA pour les acteurs transfrontaliers.

La LCD : art. 6 et art. 15

L'art. 6 LCD qualifie d'acte de concurrence déloyale le fait d'exploiter ou de divulguer des secrets de fabrication ou d'affaires qu'on a surpris ou dont on a eu connaissance de façon illégitime. L'art. 15 prévoit des mécanismes de préservation des secrets en procédure civile, permettant au tribunal de restreindre l'accès aux pièces confidentielles. Ces dispositions s'appliquent pleinement aux objets numériques, à condition que les trois critères d'éligibilité soient réunis et documentés. Le SECO précise les voies d'intervention disponibles en cas de pratiques commerciales déloyales, notamment les actions civiles en cessation et en dommages-intérêts.

La nLPD et les obligations liées à l'IA

La nouvelle loi fédérale sur la protection des données (nLPD), en vigueur depuis le 1er septembre 2023, impose des obligations concrètes pour tout traitement de données personnelles par des outils d'IA. Les art. 22 nLPD exigent une analyse d'impact relative à la protection des données (AIPD) lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits des personnes concernées. Les obligations de sécurité (art. 8 nLPD) requièrent des mesures techniques et organisationnelles proportionnées. La conformité nLPD pour les PME suisses utilisant l'IA détaille ces exigences pratiques, notamment la tenue d'un registre des traitements et la mise en place d'une gouvernance des accès.

L'AI Act européen et son impact sur les acteurs suisses

Le règlement européen sur l'IA (UE) 2024/1689 s'applique aux fournisseurs dont les systèmes sont utilisés sur le territoire de l'UE, ce qui concerne directement les entreprises suisses qui exportent des services ou collaborent avec des partenaires européens. Les exigences de documentation technique, de journalisation et de surveillance humaine pour les systèmes à haut risque créent des obligations de facto pour les acteurs suisses transfrontaliers. La norme eCH-0272 offre un cadre local aligné sur ces exigences, en définissant des objectifs de transparence, d'explicabilité et de gestion des risques pour les systèmes d'IA déployés en Suisse.

Les analogies avec le RGPD (notamment l'art. 35 sur les DPIA) restent pertinentes pour les entreprises suisses traitant des données de résidents européens, mais la nLPD constitue le référentiel primaire pour les traitements purement suisses.

Quels risques spécifiques les outils d'IA font-ils peser sur vos secrets d'affaires ?

Les vecteurs d'attaque propres aux systèmes d'IA diffèrent fondamentalement des risques informatiques classiques. L'analyse technique disponible via DOI identifie plusieurs catégories de menaces qui méritent une attention particulière dans les contextes métier sensibles.

• Injection de prompt (prompt injection) : un utilisateur malveillant ou un document piégé insère des instructions cachées dans un prompt pour contourner les filtres de sécurité et extraire des informations confidentielles stockées dans la base de connaissances de l'outil. Dans un contexte de revue contractuelle, cela peut conduire à l'exfiltration de clauses confidentielles d'un autre dossier.
• Divulgation par entraînement (training data leakage) : si un fournisseur utilise les données soumises pour affiner ses modèles, ces données peuvent réapparaître dans les réponses générées pour d'autres utilisateurs. Ce risque est particulièrement aigu pour les outils grand public sans clause d'interdiction d'entraînement explicite.
• Extraction de modèle (model extraction) : un attaquant interroge systématiquement un modèle pour reconstituer son comportement et, par extension, les données propriétaires sur lesquelles il a été affiné. Dans un contexte de M&A, un modèle affiné sur des données de valorisation internes devient une cible directe.
• Dérive de sources RAG (RAG source drift) : dans une architecture de génération augmentée par récupération, des documents mal classifiés ou mal isolés peuvent être récupérés et inclus dans des réponses destinées à des utilisateurs non autorisés. Le contrôle des sources et des niveaux de confiance est souvent négligé lors du déploiement initial.
• Empoisonnement de données (data poisoning) : un acteur malveillant introduit des données corrompues dans le corpus d'entraînement ou dans la base documentaire, altérant les réponses du modèle de façon à induire des décisions erronées ou à masquer des informations critiques.

L'OWASP LLM Top 10 classe l'injection de prompt et la divulgation de données sensibles parmi les risques les plus critiques pour les applications basées sur des modèles de langage. Ces risques se matérialisent concrètement dans des scénarios d'assistance juridique automatisée, de due diligence M&A ou d'analyse de dossiers médicaux, où la valeur des informations traitées est maximale et où une fuite peut engager la responsabilité professionnelle du praticien.

À retenir : les erreurs fréquentes dans l'utilisation de l'IA avec des données clients sont souvent liées à une mauvaise configuration des droits d'accès et à l'absence de filtres de sortie. Consulter le guide sur les erreurs d'utilisation de l'IA avec des données clients permet d'identifier les points de défaillance les plus courants avant qu'ils ne deviennent des incidents.

Quelles mesures techniques concrètes réduisent le risque de fuite via l'IA ?

Architecture recommandée

L'architecture de base pour protéger des secrets commerciaux numériques repose sur trois principes : hébergement souverain, séparation des environnements et contrôle des modèles. Concrètement, cela signifie déployer les modèles d'IA sur des serveurs situés en Suisse, soumis au droit suisse, avec une séparation stricte entre les environnements de test et de production. Les modèles à poids ouverts (open-weight) hébergés localement offrent une garantie supplémentaire : aucune donnée ne transite vers un serveur tiers lors de l'inférence. Pour les entreprises qui ne peuvent pas gérer une infrastructure on-premise, un cloud suisse certifié avec contrat de traitement des données conforme à la nLPD constitue une alternative acceptable. L'analyse des architectures souveraines et leurs bénéfices juridiques détaille les options disponibles pour les organisations suisses.

Mesures techniques détaillées

1. Chiffrement au repos et en transit : utiliser AES-256 pour les données stockées et TLS 1.3 pour les communications. Gérer les clés de chiffrement en interne (HSM ou KMS souverain) plutôt que de déléguer cette gestion au fournisseur.
2. Contrôle d'accès basé sur les rôles (RBAC) et principe du moindre privilège : chaque utilisateur n'accède qu'aux données strictement nécessaires à sa fonction. Les accès aux datasets sensibles et aux bases de connaissances confidentielles doivent être nominatifs et révocables immédiatement.
3. Tokenisation logique des données sensibles : avant d'envoyer un document à un modèle d'IA, remplacer les entités sensibles (noms, montants, identifiants) par des jetons neutres. Le modèle traite la structure logique sans jamais voir les valeurs réelles. Cette approche, distincte du chiffrement, préserve l'utilité analytique tout en éliminant le risque d'exposition directe.
4. Données synthétiques et confidentialité différentielle : pour les usages d'entraînement ou de test, générer des datasets synthétiques qui reproduisent les propriétés statistiques des données réelles sans en contenir. La confidentialité différentielle ajoute un bruit mathématique contrôlé qui empêche la réidentification.
5. Filtres d'entrée et de sortie : configurer des règles de détection automatique des informations sensibles (numéros de compte, données personnelles, mentions de projets classifiés) dans les prompts entrants et les réponses sortantes. Ces filtres doivent être mis à jour régulièrement.
6. Contrôle des sources RAG avec niveau de confiance : dans une architecture RAG, chaque source documentaire doit être étiquetée avec un niveau de classification (public, interne, confidentiel, secret). Le moteur de récupération ne doit retourner que les sources correspondant au niveau d'habilitation de l'utilisateur.
7. Journaux immuables pour audits : configurer des logs en écriture seule, horodatés et signés cryptographiquement, couvrant chaque interaction avec le système d'IA. Ces journaux constituent la preuve de diligence en cas de contrôle ou de litige.
8. Red-teaming et pentests ciblant l'OWASP LLM Top 10 : réaliser des tests d'intrusion spécifiques aux LLM au moins une fois par an, couvrant l'injection de prompt, l'extraction de modèle et la dérive de sources RAG.

Conseil de pro : La tokenisation logique est souvent sous-estimée par rapport au chiffrement, car elle semble moins « technique ». Pourtant, dans un contexte RAG, elle offre une protection supérieure : même si un attaquant accède aux chunks récupérés, les valeurs sensibles sont absentes. Appliquez-la en priorité aux datasets contenant des données financières, des identités ou des clauses contractuelles.

Checklist technique priorisée

Court terme (0–4 semaines) :

• Activer le chiffrement au repos et en transit sur tous les systèmes IA.
• Configurer le RBAC et révoquer les accès génériques.
• Mettre en place des filtres de sortie basiques (expressions régulières sur données sensibles).

Moyen terme (1–3 mois) :

• Déployer la tokenisation logique sur les flux documentaires sensibles.
• Implémenter le contrôle des sources RAG avec niveaux de classification.
• Activer les journaux immuables et tester leur exportabilité.

Long terme (3–12 mois) :

• Réaliser un premier red-teaming complet ciblant l'OWASP LLM Top 10.
• Mettre en place un programme de confidentialité différentielle pour les usages d'entraînement.
• Viser la certification ISO/IEC 27001 et préparer l'alignement sur ISO/IEC 42001:2023.

Quelles clauses contractuelles et règles organisationnelles s'imposent face aux fournisseurs d'IA ?

Clauses contractuelles indispensables dans un DPA

Tout contrat de traitement des données conclu avec un fournisseur d'IA doit contenir, au minimum, les clauses suivantes :

• Interdiction d'utilisation pour l'entraînement : formulation explicite interdisant au fournisseur d'utiliser les données soumises, les prompts ou les outputs pour affiner, entraîner ou améliorer ses modèles, que ce soit directement ou via des sous-traitants.
• Résidence des données : obligation contractuelle que toutes les données traitées restent sur des serveurs situés en Suisse ou dans un pays offrant un niveau de protection équivalent reconnu par le PFPDT.
• Droits d'audit et accès aux logs : droit contractuel d'auditer les pratiques du fournisseur et d'obtenir l'export complet des journaux d'accès sur demande, dans un délai défini (généralement 5 jours ouvrables).
• Notification d'incident : obligation de notifier toute violation de données dans un délai de 72 heures, conformément aux exigences de la nLPD.
• Obligations de conservation et de suppression : définir précisément la durée de conservation des données et les procédures de suppression certifiée en fin de contrat.
• Responsabilité des sous-traitants : le fournisseur principal reste responsable des pratiques de ses sous-traitants ; toute modification de la chaîne de sous-traitance doit être notifiée et approuvée.

Cette formulation-cadre doit être adaptée par un juriste au contexte spécifique du contrat, mais elle pose les éléments essentiels que la pratique contractuelle suisse reconnaît comme opposables. Pour les cabinets juridiques, les obligations spécifiques en matière de confidentialité et de conformité ajoutent une couche déontologique à ces exigences contractuelles.

Gouvernance organisationnelle interne

La charte IA interne est le document fondateur de la gouvernance. Elle doit définir : quelles catégories d'informations peuvent être soumises à un outil d'IA, qui peut autoriser des exceptions, et quelles sont les sanctions disciplinaires en cas de non-respect. Le registre des traitements, exigé par la nLPD pour les organisations de taille significative, doit inclure chaque usage d'IA comme traitement distinct, avec sa finalité, ses catégories de données, ses mesures de sécurité et sa base légale. La formation des collaborateurs n'est pas optionnelle : un employé qui ne comprend pas pourquoi il ne peut pas coller un contrat confidentiel dans un outil d'IA grand public représente un risque aussi élevé qu'une faille technique.

Comment évaluer un fournisseur d'IA lors d'un appel d'offres ?

Questions techniques et de sécurité

1. Où sont physiquement hébergés les serveurs traitant nos données ? Pouvez-vous fournir une attestation de résidence des données en Suisse ou dans un pays équivalent ?
2. Vos modèles sont-ils entraînés ou affinés sur les données de vos clients ? Si oui, dans quelles conditions et avec quel mécanisme d'opt-out ?
3. Quels types de logs d'accès conservez-vous ? Sont-ils exportables dans un format standard (JSON, CSV) et dans quel délai ?
4. Avez-vous réalisé des pentests ou des exercices de red-teaming couvrant l'OWASP LLM Top 10 au cours des 12 derniers mois ? Pouvez-vous partager un résumé des résultats ?
5. Disposez-vous d'une certification ISO/IEC 27001 en cours de validité ? Êtes-vous en cours d'alignement sur ISO/IEC 42001:2023 ?
6. Comment gérez-vous la chaîne de sous-traitance ? Quels sous-traitants accèdent à nos données et dans quelles conditions ?

Questions juridiques et contractuelles

• Acceptez-vous d'inclure une clause d'interdiction d'entraînement dans le DPA ?
• Quelles sont vos garanties contractuelles en cas de violation de données (indemnités, SLA de notification) ?
• Quel est votre délai contractuel de notification en cas d'incident de sécurité ?
• Acceptez-vous un droit d'audit indépendant de vos pratiques de traitement des données ?

Questions commerciales et opérationnelles

• Quelle est votre procédure de suppression certifiée des données en fin de contrat ?
• Proposez-vous un environnement dédié (tenant isolé) pour les clients traitant des données sensibles ?
• Quelles sont vos procédures de continuité de service et vos SLA de disponibilité ?

Pondération indicative pour la sélection :

• Sécurité et souveraineté des données : 40 %
• Conformité juridique et contractuelle : 30 %
• Fonctionnalités et adéquation métier : 20 %
• Coût total de possession : 10 %

Les risques liés aux outils d'IA gratuits illustrent concrètement pourquoi la pondération sécurité/conformité doit primer sur le coût dans tout contexte professionnel sensible.

Quelle feuille de route opérationnelle suivre pour déployer l'IA en toute sécurité ?

Un déploiement maîtrisé suit une séquence en quatre phases, avec des jalons mesurables à chaque étape.

1. Phase 0 — Inventaire et classification (semaines 1–4) : recenser tous les outils d'IA déjà utilisés dans l'organisation, identifier les flux de données sensibles qu'ils traitent, et classer les secrets d'affaires numériques selon leur valeur et leur niveau de sensibilité. Impliquer les juristes, l'équipe IT et les responsables métier dès cette étape.

2. Phase 1 — AIPD et pilote contrôlé (mois 1–3) : réaliser une AIPD pour chaque usage d'IA identifié comme traitant des données à risque élevé, conformément aux art. 22 nLPD. Lancer un pilote sur un dataset anonymisé ou synthétique, avec un périmètre d'utilisateurs restreint et des logs activés dès le premier jour. La conformité nLPD dès la conception rappelle que le principe de Privacy by Design s'applique dès la phase de pilote, pas seulement en production.

3. Phase 2 — Validation et red-teaming (mois 3–6) : soumettre le système à un exercice de red-teaming ciblant les vecteurs OWASP LLM Top 10. Faire valider l'architecture et les contrats par un juriste spécialisé. Obtenir la validation formelle du responsable de la protection des données (RPD) avant toute extension du périmètre. Les indicateurs de succès à ce stade : zéro fuite détectée lors du red-teaming, AIPD validée, DPA signé avec le fournisseur.

4. Phase 3 — Production et surveillance continue (mois 6–12) : déployer progressivement, par département ou par type de cas d'usage. Mettre en place un tableau de bord de surveillance des anomalies (requêtes inhabituelles, volumes d'accès atypiques, tentatives d'injection). Planifier une revue annuelle de l'AIPD et un pentest annuel. Engager la démarche de certification ISO/IEC 42001:2023, qui, combinée à ISO/IEC 27001, facilite la gouvernance IA selon les recommandations de SIDD.

Les parties prenantes à impliquer à chaque phase : direction juridique, responsable IT/sécurité, DPO ou RPD, responsables métier des départements concernés, et, pour les phases 2 et 3, un auditeur externe indépendant.

Que faire immédiatement en cas de fuite présumée d'un secret via un outil d'IA ?

1. Isoler le système concerné : suspendre immédiatement l'accès à l'outil d'IA impliqué, révoquer les tokens d'API et couper les connexions aux bases de données sensibles. Ne pas attendre la confirmation de la fuite pour agir.

2. Préserver les preuves numériques : prendre des snapshots immuables des logs d'accès, des journaux d'audit et des configurations système dans leur état actuel. Toute modification ultérieure doit être documentée. Faire appel à un expert en investigation numérique si la fuite semble significative.

3. Notifier en interne : alerter immédiatement la direction juridique, le RPD/DPO et la direction générale. Constituer une cellule de crise avec des rôles définis (coordinateur juridique, responsable technique, responsable communication).

4. Mettre à jour l'AIPD : si la fuite concerne des données personnelles, l'AIPD doit être révisée pour refléter le nouvel état du risque. La nLPD impose une notification au Préposé fédéral à la protection des données et à la transparence (PFPDT) dans les meilleurs délais si la violation est susceptible d'engendrer un risque élevé pour les personnes concernées.

5. Évaluer les recours juridiques disponibles :

   • Mesures provisionnelles (art. 261 CPC) pour obtenir en urgence l'interdiction de toute exploitation ou divulgation supplémentaire des informations volées.
   • Action en cessation et en dommages-intérêts sous la LCD (art. 9 LCD), sur la base de la violation de l'art. 6.
   • Plainte pénale pour violation du secret d'affaires (art. 162 CP) si les éléments constitutifs sont réunis.
   • Pour les professions réglementées (avocats, médecins, notaires), signalement aux instances disciplinaires compétentes si un tiers est impliqué.

6. Coordonner avec le SECO si nécessaire : dans les cas de concurrence déloyale avérée impliquant un concurrent, le SECO peut orienter vers les voies d'action administratives et civiles appropriées.

7. Documenter toutes les mesures prises : chaque action, chaque décision et chaque communication doit être consignée avec horodatage. Cette documentation démontre la diligence de l'organisation et renforce sa position en cas de litige.

Comment constituer des preuves que vous avez pris des mesures raisonnables ?

La démonstration de « mesures raisonnables » est une condition sine qua non pour invoquer la protection de la LCD et de la nLPD. Elle ne s'improvise pas au moment du litige ; elle se construit en amont, de façon systématique.

Les artefacts essentiels à conserver sont :

• Registre des traitements IA : liste de tous les systèmes d'IA utilisés, avec leur finalité, les catégories de données traitées, les mesures de sécurité en place et la base légale.
• AIPD/DPIA : document d'analyse d'impact, daté et signé, pour chaque traitement à risque élevé. Doit être mis à jour lors de tout changement significatif.
• Charte IA interne : politique formelle définissant les règles d'usage, signée par la direction et distribuée à tous les collaborateurs.
• Contrats et DPA signés : exemplaires signés de tous les contrats de traitement des données avec les fournisseurs d'IA, incluant les clauses d'interdiction d'entraînement et de résidence des données.
• Journaux d'accès immuables : logs couvrant chaque interaction avec les systèmes d'IA, conservés dans un format non modifiable.
• Rapports de tests : comptes rendus des exercices de red-teaming et des pentests, avec les vulnérabilités identifiées et les mesures correctives appliquées.
• Registre des secrets d'affaires : liste interne des objets numériques protégés, avec leur classification et les mesures de protection associées.

Les champs de logs à conserver impérativement pour chaque interaction avec un outil d'IA :

Pour la conservation, une durée minimale de cinq ans est recommandée pour les logs liés à des secrets d'affaires, en format immuable (WORM ou équivalent). Devant une autorité ou un tribunal, ces artefacts doivent être présentés de façon structurée, avec une note explicative rédigée par le RPD ou le juriste interne décrivant le dispositif de protection mis en place et son évolution dans le temps. La confidentialité des données professionnelles et l'IA en Suisse offre un cadre pratique pour structurer cette documentation.

Trois cas pratiques pour appliquer ces mesures à des situations concrètes

Cas 1 : protéger un algorithme de décision propriétaire

Une PME suisse a développé un algorithme de scoring de risque crédit utilisé en interne. Elle souhaite utiliser un outil d'IA pour automatiser la documentation de cet algorithme.

1. Classer l'algorithme comme secret d'affaires dans le registre interne, avec horodatage et versioning Git signé.
2. Héberger l'outil d'IA sur infrastructure suisse, avec accès restreint aux seuls ingénieurs autorisés.
3. Soumettre uniquement des descriptions fonctionnelles anonymisées à l'outil, jamais le code source complet.
4. Conserver les logs de chaque session de travail avec l'outil d'IA.

Cas 2 : sécuriser un dataset propriétaire pour le scoring client

Un établissement financier dispose d'un dataset de transactions historiques utilisé pour entraîner un modèle de scoring. Ce dataset constitue un avantage concurrentiel direct.

1. Pseudonymiser ou tokeniser toutes les données personnelles avant tout traitement par un outil d'IA externe.
2. Réaliser une AIPD spécifique à cet usage, documentant les risques résiduels et les mesures compensatoires.
3. Inclure dans le DPA avec le fournisseur une clause d'interdiction d'entraînement et un droit d'audit annuel.
4. Générer un dataset synthétique pour les phases de test et de développement, en réservant les données réelles à la production sur infrastructure souveraine.

Cas 3 : protéger un prompt métier contenant un secret stratégique

Un cabinet de conseil a développé une structure de prompt qui encode sa méthodologie propriétaire d'analyse concurrentielle. Cette structure représente plusieurs années de développement et constitue un différenciateur commercial.

1. Stocker le prompt dans une base de connaissances privée, accessible uniquement aux associés habilités, sur infrastructure souveraine.
2. Configurer une architecture RAG contrôlée où le prompt n'est jamais exposé directement à l'utilisateur final ni aux logs accessibles au fournisseur.
3. Activer des filtres de sortie qui détectent et bloquent toute tentative d'extraction de la structure du prompt via des questions indirectes.
4. Documenter la propriété du prompt dans le registre des secrets d'affaires, avec les preuves de développement (historique de versions, dates de création).

Pourquoi la souveraineté des données est-elle un enjeu stratégique pour les juristes et professionnels suisses ?

La souveraineté des données n'est pas une préférence technique. Pour les professions soumises au secret professionnel — avocats, médecins, notaires, conseillers financiers — elle conditionne directement le respect des obligations déontologiques. Envoyer des données couvertes par le secret professionnel à un serveur situé hors de Suisse, sans garanties contractuelles solides et sans analyse d'impact préalable, expose le praticien à des sanctions disciplinaires, voire pénales, indépendamment de toute fuite effective. Le risque n'est pas hypothétique : il est structurel, inscrit dans l'architecture même des outils grand public.

Ce que les instances professionnelles suisses rappellent avec constance, c'est que l'IA reste un outil sous contrôle du mandataire, et que la responsabilité personnelle du praticien n'est pas transférée au fournisseur technologique. Choisir une architecture souveraine n'est donc pas une option parmi d'autres : c'est la condition minimale pour exercer avec l'IA sans compromettre son statut professionnel.

L'enjeu réputationnel est tout aussi concret. Une fuite de données confidentielles traitées via un outil d'IA peut détruire en quelques heures une relation de confiance construite sur des années. Pour les PME suisses, dont la compétitivité repose souvent sur des savoir-faire propriétaires, la perte d'un secret d'affaires numérique peut se traduire par une perte d'avantage concurrentiel durable, sans recours garanti si les mesures de protection n'étaient pas en place.

La certification ISO/IEC 42001:2023 prend ici une dimension stratégique qui dépasse la conformité. Elle signale aux clients, aux partenaires et aux autorités que l'organisation a mis en place un système de management de l'IA documenté, auditable et aligné sur les meilleures pratiques internationales. Dans un marché où la confiance est le premier actif, cette certification devient un argument commercial autant qu'une protection juridique.

Nectos : l'espace IA souverain pour protéger vos secrets commerciaux en Suisse

Les professionnels suisses qui traitent des informations confidentielles avec l'IA n'ont pas à choisir entre efficacité et sécurité. Nectos est la plateforme IA dont les données ne quittent jamais la Suisse : hébergement 100 % sur serveurs suisses, conformité nLPD intégrée, journaux d'audit exportables et contrôle d'accès granulaire par rôle.

Conçue pour les cabinets juridiques, les équipes M&A, les établissements de santé et les services financiers, Nectos couvre les cas d'usage où la confidentialité n'est pas négociable : analyse de documents sensibles, bases de connaissances privées, transcription de réunions confidentielles et recherche web anonymisée. Contrairement aux outils grand public, aucune donnée soumise à Nectos n'est utilisée pour entraîner des modèles tiers. Les logs d'audit sont exportables à la demande, ce qui vous permet de démontrer vos mesures de diligence devant toute autorité ou juridiction suisse.

Pour évaluer si Nectos correspond à votre contexte, consultez la page sécurité et conformité ou demandez directement une démonstration sur Nectos.

Sources

Les ressources suivantes constituent le socle documentaire pour toute démarche de protection des secrets commerciaux numériques en Suisse :

• Partie VII : Secrets d'affaires et objets numériques
• SECO — Généralités LCD
• eCH-0272 — Transparence, explicabilité et risques des systèmes d'IA
• Doi

Cet article constitue une information générale et ne remplace pas l'avis d'un avocat qualifié. Consultez un professionnel du droit qualifié à propos de votre cas personnel avant d'agir sur la base de ce contenu.

Questions fréquentes

Quels secrets commerciaux sont protégés face aux outils d'IA ?

Tout objet numérique satisfaisant aux trois critères cumulatifs — caractère secret, valeur commerciale tirée du secret, mesures de protection raisonnables — peut être protégé, qu'il s'agisse d'un algorithme, d'un dataset propriétaire ou d'une structure de prompt métier, conformément au guide WIPO Partie VII et à la LCD art. 6.

Quelle solution IA respecte la confidentialité en Suisse ?

Une solution conforme doit héberger les données exclusivement en Suisse, interdire contractuellement leur utilisation pour l'entraînement de modèles, et fournir des journaux d'audit exportables.

Comment le RGPD s'applique-t-il aux usages d'IA en Suisse ?

La nLPD est le référentiel primaire pour les traitements en Suisse. Le RGPD s'applique directement lorsque des données de résidents européens sont traitées ; l'art. 35 RGPD sur les DPIA est fonctionnellement analogue à l'art. 22 nLPD sur l'AIPD, ce qui facilite une conformité simultanée pour les acteurs transfrontaliers.

Quelles stratégies de protection des données s'appliquent aux outils d'IA ?

Les stratégies prioritaires combinent hébergement souverain, tokenisation logique des données sensibles, contrôle d'accès basé sur les rôles, filtres d'entrée/sortie et journalisation immuable, complétées par des clauses contractuelles d'interdiction d'entraînement et une AIPD documentée pour chaque usage à risque élevé.

Recommandation

• Secret médical et IA en Suisse : protéger vos données en 2026
• IA souveraine en Suisse : sans surveillance des géants du numérique
• IA souveraine en Suisse : travailler sans comptes étrangers
• Erreurs utilisation IA données clients : guide Suisse 2026