Un assistant d'IA s'active en quelques minutes, un chatbot est en ligne en quelques jours, un copilote se déploie d'un clic de licence. La tentation est grande d'aller vite d'abord et de traiter la protection des données plus tard. C'est précisément cet ordre qui coûte cher. Non pas parce que l'IA relèverait d'un droit spécial, mais parce que le droit existant s'applique pleinement : le Préposé fédéral à la protection des données et à la transparence (PFPDT) a précisé que la loi fédérale sur la protection des données (LPD), formulée de manière technologiquement neutre, s'applique directement aux traitements de données fondés sur l'IA. En cas de lien avec l'UE, le RGPD et le règlement européen sur l'IA (AI Act) s'y ajoutent.

Les coûts apparaissent rarement là où les entreprises les attendent. L'amende n'en est qu'une partie. En pratique, ce qui pèse le plus lourd, c'est le projet stoppé qu'il faut reconstruire après coup, le client grand compte qui se retire lors du vendor review et l'incident au cours duquel des données confidentielles se retrouvent dans le modèle d'un tiers. Les six mêmes erreurs reviennent sans cesse. Aucune n'est exotique, toutes sont évitables. Cet article montre ce que beaucoup d'entreprises font mal en ce moment, ce que cela coûte et comment mieux faire.

L'erreur la plus fréquente commence sans projet et sans décision. Des collaborateurs copient de la correspondance client, des dossiers de candidature ou des projets de contrat dans des comptes d'IA gratuits, parce que cela accélère le travail et que personne n'a fixé d'autre règle. Pour l'entreprise, il s'agit d'une communication de données personnelles à un tiers : sans contrat, sans vérification du pays destinataire et souvent avec la possibilité que les saisies servent à entraîner le modèle. Pour les études d'avocats, les cabinets médicaux, les banques ou les fiduciaires, le secret professionnel est en outre en jeu.

Cela coûte cher à double titre. Un prompt qui a quitté l'entreprise ne se rattrape pas, et une interdiction générale ne fait que déplacer l'usage vers les appareils privés. Mieux vaut une directive IA courte et compréhensible, en trois éléments. Premièrement, une liste d'outils autorisés avec compte professionnel. Deuxièmement, une classification simple des données qui fixe ce qui n'a jamais sa place dans un prompt. Troisièmement, une formation qui illustre les deux par des exemples concrets. Nos articles sur ChatGPT au travail et sur le modèle de politique IA pour les PME montrent à quoi ressemble un tel cadre.

Quiconque fait traiter des données personnelles par un outil d'IA recourt en règle générale à un sous-traitant. L'art. 9 LPD et l'art. 28 RGPD exigent alors un contrat de sous-traitance, et ce avant que les premières données ne circulent. En pratique, il manque souvent, parce que l'outil a été acheté par carte de crédit ou que personne n'a vérifié si l'abonnement choisi comprend un tel contrat. Tout aussi souvent, il reste à clarifier si le fournisseur peut utiliser les saisies pour améliorer ses modèles, à quels sous-traitants ultérieurs il fait appel et combien de temps les prompts et les résultats sont conservés.

S'y ajoute la communication à l'étranger. De nombreux fournisseurs d'IA traitent les données aux États-Unis ou y accèdent depuis ce pays. Cela n'est admissible que sur une base conforme aux art. 16 et 17 LPD, par exemple une certification du fournisseur au titre du Swiss-U.S. Data Privacy Framework ou des clauses contractuelles types assorties d'une évaluation des risques documentée. Celui qui s'en dispense intentionnellement risque une amende personnelle selon l'art. 61 LPD et, lors du vendor review, la question gênante de savoir sur quelle base les données clients se trouvent chez le fournisseur du modèle. Mieux vaut choisir un abonnement business ou enterprise avec contrat de sous-traitance, exclure contractuellement l'utilisation à des fins d'entraînement et documenter le lieu de traitement et les sous-traitants ultérieurs. Notre article sur le contrat de sous-traitance suisse en explique le contenu minimal.

Beaucoup d'entreprises ne savent pas dire quelles applications d'IA tournent chez elles, quelles données y entrent et qui en est responsable. Sans cette vue d'ensemble, la base de tout le reste fait défaut. Le registre des activités de traitement selon l'art. 12 LPD reste lacunaire, la déclaration de protection des données n'est plus exacte, et personne ne remarque qu'un pilote devient tacitement un système de production.

L'absence d'analyse d'impact relative à la protection des données (AIPD) est particulièrement lourde de conséquences. L'art. 22 LPD l'exige lorsqu'un traitement est susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées. La loi mentionne expressément le recours à de nouvelles technologies et le traitement à grande échelle de données sensibles. L'art. 35 RGPD suit la même logique. Les applications d'IA impliquant des données de santé, des données de candidats, du profilage ou du scoring en relèvent régulièrement. Celui qui ne réalise l'AIPD qu'après la mise en production découvre les risques alors que l'architecture, le fournisseur et les contrats sont déjà fixés. Chaque correction coûte alors plusieurs fois plus cher. Mieux vaut un inventaire IA comme premier livrable, un bref examen de seuil par application et l'AIPD avant la décision sur le fournisseur et l'architecture.

Les assistants d'IA qui accèdent aux espaces de stockage internes, aux e-mails et aux chats n'inventent pas de nouvelles autorisations. Ils utilisent celles qui existent, et plus systématiquement que n'importe quel humain. Ce qui dormait jusqu'ici dans un dossier oublié au partage trop large, l'assistant le fournit désormais en réponse à une simple question : listes de salaires, dossiers du personnel, certificats médicaux, procès-verbaux du conseil d'administration. Le problème n'est pas l'IA, mais la prolifération des autorisations accumulée au fil des ans, qu'elle rend visible.

Juridiquement, il s'agit d'une question de sécurité des données au sens de l'art. 8 LPD. L'ordonnance sur la protection des données exige un contrôle d'accès limitant les personnes autorisées aux données personnelles dont elles ont besoin pour accomplir leurs tâches. Si un accès interne à des données RH tourne à l'incident, il s'ensuit un travail d'analyse, une éventuelle annonce au PFPDT selon l'art. 24 LPD et une perte de confiance au sein du personnel. S'y ajoutent de nouveaux vecteurs d'attaque comme l'injection de prompt, où des contenus manipulés amènent l'assistant à divulguer des données. Mieux vaut nettoyer les autorisations avant le déploiement, activer des niveaux de confidentialité pour les données sensibles, démarrer avec un groupe pilote et activer la journalisation. Notre article sur Microsoft Copilot et la protection des données décrit les étapes concrètes pour Microsoft 365. Pour le contrôle technique des applications d'IA, il existe notre prestation AI Security.

Les personnes concernées doivent savoir que leurs données sont traitées et dans quel but. Le devoir d'informer selon l'art. 19 LPD vaut aussi pour l'IA. Quiconque introduit un chatbot au service client, une présélection assistée par IA dans le recrutement ou une analyse automatique des entretiens avec la clientèle doit adapter sa déclaration de protection des données. Le PFPDT attend que la finalité, le fonctionnement et les sources de données des traitements fondés sur l'IA soient rendus transparents. En cas de lien avec l'UE, l'art. 50 de l'AI Act exige en outre, depuis le 2 août 2026, que les personnes puissent reconnaître qu'elles interagissent avec un système d'IA.

La situation devient délicate lorsque l'IA ne se contente pas d'assister, mais décide. Si une décision produisant des effets juridiques ou affectant la personne de manière significative repose exclusivement sur un traitement automatisé, par exemple un refus de crédit, un rejet de candidature ou une résiliation de contrat, l'art. 21 LPD et l'art. 22 RGPD s'appliquent. La personne concernée doit être informée, peut faire valoir son point de vue et peut demander un réexamen par une personne physique. Dans son arrêt SCHUFA de décembre 2023 (C-634/21), la Cour de justice de l'Union européenne a retenu qu'un score calculé automatiquement peut déjà constituer une telle décision s'il est déterminant pour l'issue. Un humain qui se borne à valider le résultat de l'IA n'y change rien. Mieux vaut consigner pour chaque application si l'IA prépare ou décide, prévoir un véritable réexamen humain disposant d'une marge de décision, et intégrer l'information dans la déclaration de protection des données et dans le processus.

Les données collectées pour l'exécution d'un contrat ne sont pas automatiquement du matériel d'entraînement. Le principe de finalité selon l'art. 6 al. 3 LPD et l'art. 5 RGPD exige que les données personnelles ne soient traitées que d'une manière reconnaissable lors de la collecte ou compatible avec celle-ci. Quiconque utilise des tickets de support, des enregistrements d'entretiens ou des documents clients pour entraîner son propre modèle, affiner un modèle tiers ou alimenter la base de connaissances d'un assistant a besoin d'une justification solide et doit informer les personnes concernées. Dans les relations B2B s'ajoute le fait que le contrat de sous-traitance conclu avec le client exclut régulièrement un tel usage.

La seconde partie de l'erreur se révèle plus tard. Si une personne demande l'accès à ses données ou leur effacement, l'entreprise doit savoir où elles se trouvent : dans les prompts, les journaux, les bases de données vectorielles et les jeux de données d'entraînement. Il est pratiquement impossible de retirer de manière ciblée des enregistrements isolés d'un modèle entraîné. Dans le pire des cas, il ne reste qu'un nouvel entraînement sans les données concernées. Mieux vaut vérifier et documenter la compatibilité des finalités avant toute réutilisation, travailler autant que possible avec des données anonymisées ou synthétiques, fixer des durées de conservation pour les prompts et les journaux, et étendre les processus d'accès et d'effacement aux systèmes d'IA.

Les sanctions directes sont connues, mais souvent mal situées. La LPD prévoit des amendes jusqu'à CHF 250'000, non pas contre l'entreprise, mais contre la personne physique responsable. Est punissable la violation intentionnelle, par exemple, des devoirs d'informer, des règles sur la sous-traitance, sur la communication à l'étranger ou des exigences minimales en matière de sécurité des données. Notre article sur les amendes LPD et la responsabilité personnelle en détaille les contours. Le RGPD prévoit des amendes jusqu'à EUR 20 millions ou 4 pour cent du chiffre d'affaires annuel mondial, l'AI Act, selon l'infraction, jusqu'à EUR 35 millions ou 7 pour cent. Le PFPDT peut en outre ordonner qu'un traitement soit adapté, suspendu ou interrompu et que des données personnelles soient effacées. En pratique, les coûts indirects pèsent généralement plus lourd : la refonte d'un système déjà introduit, des retards de vente parce que le questionnaire de sécurité du client ne peut pas être rempli proprement, et la charge liée au traitement d'un incident.

Ces six erreurs s'évitent avec un effort raisonnable si l'ordre est le bon : inventaire avant le déploiement, contrat avant le flux de données, AIPD avant le choix d'architecture, autorisations avant l'assistant, information avant la mise en production, examen de la finalité avant l'entraînement. SIDD vous accompagne avec l'AI Governance Check, qui fournit un inventaire IA documenté, une classification initiale et une liste de mesures priorisées. L'AI Officer maintient votre gouvernance de l'IA à jour en continu. Notre conseil en protection des données couvre le volet juridique, du contrat de sous-traitance à l'AIPD. Une première appréciation de vos applications d'IA peut être discutée via le formulaire de contact ; pour la mise en œuvre, demandez une offre via notre formulaire d'offre.