Protection des données avec l'IA : pourquoi la conformité par check-list n'est pas la sécurité
Réponse courte : ce que l'IA apporte à la protection des données, et ce qu'elle n'apporte pas
Réponse courte : les outils d'IA produisent en quelques minutes une déclaration de protection des données, un registre des activités de traitement ou une liste de mesures techniques et organisationnelles. Cela fait gagner du temps et constitue souvent un brouillon utilisable. Mais cela ne répond qu'à la question de savoir si un document existe. La loi fédérale sur la protection des données (LPD) pose une autre question : les données personnelles sont-elles réellement protégées de manière adéquate par rapport au risque ?
C'est précisément la différence entre la conformité par check-list et la sécurité réelle. Une check-list coche ce qui existe. La sécurité se mesure au fait que les mesures fonctionnent au quotidien et sont réexaminées régulièrement. Un outil d'IA ne connaît ni vos systèmes, ni vos autorisations, ni vos fournisseurs. Il peut décrire à quoi ressemble une entreprise sûre. Il ne peut pas savoir si la vôtre en est une.
Cet article s'adresse aux directions et aux responsables de la protection des données des PME suisses qui utilisent l'IA pour leur travail de protection des données ou qui l'envisagent. Il montre à quoi l'IA est adaptée, cinq écueils typiques, ce que la loi entend par sécurité des données et comment utiliser l'IA pour qu'il en résulte davantage que du papier.
Ce pour quoi l'IA est utile dans le travail de protection des données
Dans le travail de protection des données, l'IA n'est pas un problème mais un outil utile, à condition que la tâche s'y prête. Elle convient bien aux travaux dont un humain peut vérifier le résultat avec un effort raisonnable :
- structurer les premiers projets de directives, d'instructions et de supports de formation,
- résumer de longs contrats et contrats de sous-traitance et y repérer les clauses manquantes,
- reformuler des textes dans un langage compréhensible ou les traduire,
- vérifier la cohérence de documents existants, par exemple entre la déclaration de protection des données et le registre des activités de traitement,
- préparer des listes de questions pour les entretiens avec les services métiers.
Toutes ces tâches ont un point commun : l'IA travaille à partir de matériel que vous fournissez, et une personne compétente relit le résultat. Les choses se compliquent lorsque l'IA doit apporter des faits sur votre entreprise ou sur la situation juridique que personne ne vérifie. C'est là que commencent les écueils.
Écueil 1 : l'IA ne connaît pas votre entreprise
Quiconque demande à une IA d'établir un registre des activités de traitement pour une fiduciaire de douze collaborateurs obtient un registre plausible pour une fiduciaire moyenne. Savoir si votre entreprise a externalisé la comptabilité des salaires, quel CRM elle utilise, où aboutissent les candidatures et quel prestataire dispose d'un accès à distance au serveur ne figure pas dans le modèle. L'IA comble les lacunes par des hypothèses, et dans le document final ces hypothèses ont l'apparence de faits.
Pour la déclaration de protection des données, cela a des conséquences juridiques. L'art. 19 LPD exige que les personnes concernées soient informées de manière adéquate de la collecte de leurs données, notamment de la finalité du traitement et des destinataires. Une déclaration qui cite des outils que vous n'utilisez pas et passe sous silence ceux que vous utilisez ne remplit pas ce devoir. Elle est pire qu'un modèle visiblement inachevé, car elle donne l'impression que le travail est fait.
Mieux vaut : que les faits viennent de votre entreprise, et non du modèle. Établissez d'abord quels systèmes, catégories de données, destinataires et liens avec l'étranger existent réellement, et ne laissez l'IA rédiger qu'ensuite.
Écueil 2 : bien formulé, juridiquement à côté
Les modèles de langage produisent un texte convaincant. Ils ne vérifient pas si une affirmation est exacte. En protection des données, cela se manifeste très souvent par une confusion : il existe beaucoup plus de textes sur le RGPD européen que sur la LPD suisse. Il en résulte des documents destinés à des entreprises suisses qui reproduisent en réalité le droit de l'UE.
| Affirmation typique dans le projet de l'IA | Ce qui vaut en droit suisse |
|---|---|
| « Les violations de données doivent être annoncées dans les 72 heures. » | L'art. 24 LPD exige l'annonce au PFPDT « dans les meilleurs délais », et seulement en cas de risque vraisemblablement élevé pour les personnes concernées. Les 72 heures viennent de l'art. 33 RGPD. |
| « Tout traitement nécessite une base juridique, par exemple un consentement. » | Les personnes privées n'ont besoin d'un motif justificatif que si le traitement porte atteinte à la personnalité (art. 30 et 31 LPD). Le système des bases juridiques vient de l'art. 6 RGPD. |
| « L'entreprise doit désigner un délégué à la protection des données. » | Selon l'art. 10 LPD, les responsables du traitement privés peuvent nommer un conseiller à la protection des données. Une obligation de désignation existe dans certains cas selon l'art. 37 RGPD. |
| « L'entreprise risque des amendes jusqu'à 4 pour cent du chiffre d'affaires. » | Les art. 60 ss LPD prévoient des amendes de CHF 250'000 au plus contre la personne physique qui a agi, et seulement en cas d'intention. Les amendes calculées sur le chiffre d'affaires de l'entreprise relèvent de l'art. 83 RGPD. |
| « Un registre des activités de traitement est toujours obligatoire. » | Les entreprises de moins de 250 collaborateurs en sont déliées, sauf si elles traitent des données sensibles à grande échelle ou procèdent à un profilage à risque élevé (art. 12 al. 5 LPD, art. 24 OPDo). |
Si une entreprise relève en plus du RGPD, les deux régimes s'appliquent côte à côte. C'est précisément dans ce cas qu'il faut savoir quelle affirmation provient de quelle loi. S'y ajoutent des numéros d'articles inventés ou dépassés, difficiles à distinguer des vrais dans un texte suivi.
Mieux vaut : exiger la référence de chaque affirmation juridique et la vérifier dans la version officielle. Une affirmation sans source vérifiable n'a pas sa place dans un document que vous signez.
Écueil 3 : la conformité par check-list au lieu de la sécurité réelle
L'écueil le plus lourd de conséquences concerne la sécurité des données. Sur demande, une IA fournit une liste soignée de mesures techniques et organisationnelles : concept d'accès, chiffrement, sauvegarde, authentification multifacteur, formation. Chaque ligne peut être cochée. C'est justement ce qui rend la liste trompeuse, car elle décrit un état cible. Elle ne dit pas s'il est atteint.
La loi n'exige pas un catalogue, mais un résultat. Selon l'art. 8 LPD, les responsables du traitement et les sous-traitants doivent assurer « une sécurité adéquate des données personnelles par rapport au risque encouru ». L'ordonnance sur la protection des données (OPDo) le précise : le besoin de protection doit être établi, les mesures doivent être déterminées en fonction du risque, et le tout est réévalué « pendant toute la durée du traitement » (art. 1 OPDo). L'art. 3 OPDo décrit des objectifs, pas des documents. Les personnes autorisées ne doivent avoir accès qu'aux données dont elles ont besoin pour accomplir leurs tâches. Après un incident, les données doivent pouvoir être rapidement restaurées. Les failles critiques connues doivent être corrigées, et les violations de la sécurité des données rapidement détectées.
| Ce que la check-list coche | Ce que demande la sécurité réelle |
|---|---|
| « Concept de sauvegarde en place » | Quand une restauration a-t-elle été testée pour la dernière fois, combien de temps a-t-elle pris, et la sauvegarde est-elle protégée contre une attaque par rançongiciel ? |
| « Accès réglés selon le principe du besoin d'en connaître » | Qui peut réellement accéder aujourd'hui au lecteur des ressources humaines, et quand les autorisations ont-elles été revues pour la dernière fois ? |
| « Authentification multifacteur introduite » | S'applique-t-elle à tous les comptes, y compris les administrateurs, les comptes de service et l'accès à distance des fournisseurs ? |
| « Les systèmes sont tenus à jour » | Combien de temps une faille critique reste-t-elle ouverte, et que montre le dernier scan de vulnérabilités ? |
| « Contrats de sous-traitance conclus » | Vous êtes-vous assuré que le prestataire est en mesure de garantir la sécurité des données, comme l'exige l'art. 9 al. 2 LPD ? |
| « Processus de violation de données documenté » | A-t-il été exercé, et qui décide un samedi soir s'il faut annoncer ? |
| « Collaborateurs formés » | Les collaborateurs reconnaissent-ils et signalent-ils un message d'hameçonnage lorsqu'il arrive réellement ? |
| « Concept d'effacement établi » | Les données sont-elles réellement effacées à l'échéance du délai, y compris dans les archives et les services cloud ? |
Une IA remplit la colonne de gauche en quelques secondes. La colonne de droite ne trouve sa réponse que dans l'entreprise : en regardant dans les systèmes, en faisant un test, en produisant une preuve. Un attaquant ne lit pas vos directives. Il essaie de voir si le compte sans second facteur, le partage oublié ou le serveur non corrigé existent.
Écueils 4 et 5 : documents dépassés et fausse certitude
Les documents vieillissent, les entreprises changent
Un document généré par l'IA est un instantané. Un nouvel outil, un nouveau prestataire, un nouveau site : chaque changement rend le registre, la déclaration de protection des données et la liste de mesures un peu moins exacts. C'est pourquoi l'OPDo exige un réexamen continu et, au besoin, l'adaptation des mesures. La protection des données est une activité permanente, et non un projet qui s'achève avec la remise d'un classeur.
Mieux vaut : une personne responsable, un rythme de réexamen fixe et un déclencheur à chaque introduction d'un nouveau système ou prestataire.
Le document comme fausse preuve
Des documents de belle apparence font baisser la vigilance. La direction, le conseil d'administration et les clients lisent « Chiffrement : mis en œuvre » et partent du principe que c'est vrai. Si ce n'est pas le cas, le document devient lui-même le problème : en cas d'incident, il montre que l'exigence était connue et n'a pas été mise en œuvre. Celui qui garantit à ses clients, dans un questionnaire de sécurité, des mesures qui n'existent pas crée en outre un risque contractuel.
La responsabilité ne se délègue pas à un outil. L'entreprise reste responsable, et les dispositions pénales de la LPD visent les personnes qui agissent. Selon l'art. 61 let. c LPD, est puni sur plainte d'une amende de CHF 250'000 au plus quiconque, intentionnellement, ne respecte pas les exigences minimales en matière de sécurité des données.
Un dernier point est souvent négligé : celui qui, pour son travail de protection des données, copie des documents internes, des listes du personnel ou des détails contractuels dans un outil d'IA sans contrat professionnel commet lui-même une erreur de protection des données. Notre article sur les erreurs typiques de protection des données avec l'IA les passe en revue.
Bien utiliser l'IA : la laisser rédiger, vérifier soi-même
La voie raisonnable ne consiste pas à renoncer à l'IA, mais à répartir clairement le travail. L'IA rédige et structure. Les faits, l'appréciation juridique et le contrôle de l'efficacité restent l'affaire de personnes.
- Faire l'état des lieux avant d'écrire. Systèmes, catégories de données, destinataires, liens avec l'étranger et autorisations proviennent d'entretiens et des systèmes, non d'hypothèses.
- Déterminer le risque. Quelles données seraient les plus critiques en cas de perte, de divulgation ou d'indisponibilité ? Les mesures s'y alignent (art. 1 OPDo).
- Laisser l'IA rédiger. Avec votre matériel, et dans un outil couvert par un contrat professionnel.
- Vérifier chaque affirmation juridique à la source primaire. La loi et l'ordonnance sont accessibles au public.
- Contrôler l'efficacité au lieu de l'affirmer. Test de restauration, revue des autorisations, scan de vulnérabilités ou test d'intrusion. Consignez les résultats.
- Fixer la responsabilité et le rythme. Qui contrôle quoi et à quelle fréquence, et qu'est-ce qui déclenche un réexamen extraordinaire ?
Trois questions à poser à tout document de protection des données généré par l'IA
- Correspond-il à notre entreprise, ligne par ligne ?
- Est-il juridiquement exact, et où cela figure-t-il ?
- Qui vérifie qu'il est appliqué, et avec quoi ?
Comme point de départ, une check-list est tout à fait utile, car elle montre quels thèmes existent. C'est le rôle de notre check-list suisse de protection des données. Elle ne remplace pas la seconde étape : chercher la preuve derrière chaque ligne. Pour le volet technique, le guide du PFPDT relatif aux mesures techniques et organisationnelles constitue une bonne base.
Conclusion, accompagnement et sources
L'IA accélère le travail de protection des données, mais ne le rend pas exact d'elle-même. Les documents sont le début. La protection ne naît que lorsque les mesures sont mises en œuvre, contrôlées et tenues à jour. Qui connaît cette différence tire profit de l'IA. Qui l'ignore possède un classeur complet et un risque non vérifié.
SIDD travaille elle-même avec l'IA. LexCommand, notre IA juridique interne adossée à des citations, rattache chaque affirmation juridique à une source primaire consultable. L'appréciation et la responsabilité restent entre les mains de nos consultants. Dans le cadre de notre conseil en protection des données, nous établissons l'état réel de vos traitements de données. Avec un test d'intrusion, nous vérifions si les mesures techniques tiennent ce que promet la documentation. Une première appréciation peut être discutée via le formulaire de contact.
Sources
Toutes les sources consultées le 30 septembre 2026.
- Loi fédérale sur la protection des données (LPD, RS 235.1), Fedlex, état le 7 juillet 2025
- Ordonnance sur la protection des données (OPDo, RS 235.11), Fedlex, état le 1er décembre 2025
- Règlement (UE) 2016/679 (RGPD), EUR-Lex
- PFPDT : Guide relatif aux mesures techniques et organisationnelles de la protection des données (TOM), communication du 23 janvier 2024
Cet article constitue une information générale et non un conseil juridique.
