Réponse courte : fin septembre 2026, des inconnus ont attaqué un éditeur de logiciels pour caisses de pension. Depuis, de plus en plus de caisses annoncent que des données de leurs assurés pourraient avoir été dérobées. Ce ne sont pas les systèmes des caisses qui ont été attaqués. Les données se trouvaient chez le fournisseur.

Le cas soulève une question que toute organisation devrait se poser. En pratique, les fournisseurs sont souvent évalués uniquement au moyen d'un questionnaire, d'un certificat et d'un contrat de sous-traitance. La question de savoir si les données sont réellement protégées chez le fournisseur reste alors ouverte. La loi fédérale sur la protection des données (LPD) exige davantage. Quiconque confie des données à un tiers doit s'assurer que celui-ci est en mesure de garantir la sécurité des données.

Cet article résume ce que l'on sait au 18 octobre 2026. Il montre ce que le cas Xplain a déjà enseigné et où s'arrêtent les check-lists. Il décrit enfin un contrôle des fournisseurs qui va en profondeur. Les enquêtes en cours établiront les causes de l'attaque. Cet article ne porte de jugement sur aucune des entreprises ou caisses concernées. Il prend le cas comme point de départ d'une question générale.

Selon la communication de l'éditeur, des inconnus ont utilisé un logiciel malveillant pour accéder à une partie de son infrastructure informatique. L'environnement touché a été immédiatement déconnecté du réseau. L'entreprise a fait appel à des spécialistes externes et déposé une plainte pénale. Depuis le 2 octobre 2026, ses services sont de nouveau entièrement disponibles. Le 8 octobre, la Confédération a confirmé une fuite de données chez le fournisseur de logiciel de la Caisse fédérale de pensions Publica. Le Ministère public de la Confédération a ouvert une enquête.

Selon la NZZ, les données de plus de 100'000 assurés et bénéficiaires de rentes pourraient se trouver entre les mains de cybercriminels. Ce chiffre n'est pas confirmé.

Dans le pire des cas, selon la PKZH, la fuite porte sur le nom, la date de naissance, le numéro AVS et les coordonnées. S'y ajoutent l'état civil, des informations sur le partenaire, l'IBAN ainsi que le salaire assuré et l'avoir d'épargne. Selon les caisses, les avoirs de prévoyance et les rentes sont en sécurité. Les polices cantonales de Zurich et de Berne mettent toutefois en garde contre des appels de faux conseillers en placement qui pourraient utiliser de telles données.

Les caisses de pension gèrent généralement leurs assurés avec un logiciel spécialisé. Les données parviennent typiquement à un éditeur de logiciels par trois voies. Premièrement, l'éditeur exploite le logiciel pour la caisse sur ses propres systèmes. Deuxièmement, il a besoin de données réalistes pour les tests et les migrations. Troisièmement, il reçoit souvent de vrais enregistrements avec les annonces d'erreurs, afin de reproduire le problème.

L'expert en sécurité Marc Ruef cite, auprès de la SRF, l'exploitation chez l'éditeur ainsi que les tests et la maintenance comme voies typiques. Des données de test anonymisées ou pseudonymisées seraient une alternative. Marc Ruef s'exprime de manière générale sur la branche : anonymiser et pseudonymiser des données est « très laborieux et aussi sujet aux erreurs » (traduction). Parfois, dit-il, on privilégie la rentabilité au détriment de la sécurité. Selon son expérience, la cybersécurité ne figure souvent pas très haut sur la liste lors du choix d'un fournisseur.

Dans le cas de la PKZH, la voie est connue. La caisse prévoyait de passer au système de cet éditeur début 2027. Pour vérifier que les données seraient reprises de manière complète et correcte, elle a remis au fournisseur des données de test réalistes. Son système de production fonctionnait encore avec un autre logiciel. Pour le test, des données d'assurés se trouvaient chez le fournisseur.

De manière générale, l'endroit où se trouve une copie des données contribue à déterminer qui est touché par une attaque contre un fournisseur. S'y ajoute un risque de concentration pour toute la branche. Un fournisseur spécialisé sert de nombreuses caisses, et une seule attaque les touche simultanément. Une caisse qui ne sécurise que ses propres systèmes ne voit pas ce risque.

En mai 2023, une attaque par rançongiciel a frappé l'entreprise de logiciels Xplain. Un rançongiciel est un logiciel malveillant qui chiffre les données et souvent les copie au préalable. Xplain développait notamment des logiciels pour l'Office fédéral de la police (fedpol). Des données personnelles de l'administration fédérale se trouvaient aussi sur les systèmes de Xplain.

Le Préposé fédéral à la protection des données et à la transparence (PFPDT) a examiné le cas. Ses rapports finaux du 25 avril 2024 constatent notamment ce qui suit :

• fedpol n'avait pas clairement réglé si, et à quelles conditions, des données personnelles pouvaient être transmises à Xplain dans le cadre de la maintenance et du support.
• Xplain a conservé des données personnelles après la correction des erreurs au lieu de les effacer.
• fedpol ne contrôlait pas Xplain régulièrement, par exemple au moyen d'audits. L'office invoquait un manque de ressources humaines et financières.
• Le PFPDT a rappelé que le mandant doit choisir le sous-traitant avec soin, l'instruire et, si nécessaire, le surveiller.

Les recommandations adressées à fedpol sont concrètes. Il faut d'abord clarifier si des données personnelles doivent vraiment quitter ses propres systèmes. Si oui, la minimisation et la sécurité des données doivent être appliquées de manière conséquente. Lors de la prochaine décision sur la collaboration, il faut vérifier l'existence d'un système de management de la sécurité de l'information (SMSI) certifié. Le respect des règles doit être contrôlé régulièrement, par des contrôles internes ou externes ou en exigeant des preuves.

Aucun indice public ne fait état de lacunes comparables chez l'éditeur concerné. Les enquêtes en cours établiront les causes de l'attaque. Le cas Xplain sert ici uniquement d'exemple des questions qui se posent lorsque des données partent chez un éditeur pour des tests, une migration ou du support. Le PFPDT a apprécié le cas Xplain selon l'ancien droit. Il a relevé que la LPD actuelle ne conduirait pas à un autre résultat.

L'art. 9, al. 2, LPD est bref : « Le responsable du traitement doit en particulier s'assurer que le sous-traitant est en mesure de garantir la sécurité des données. » S'assurer signifie se faire sa propre idée. Un contrat signé en est une condition, mais pas une preuve.

D'autres obligations complètent cette règle. Les responsables du traitement et les sous-traitants doivent assurer « une sécurité adéquate des données personnelles par rapport au risque encouru » (art. 8 LPD). Le besoin de protection, le risque et les mesures « sont réévalués pendant toute la durée du traitement » (art. 1, al. 5, OPDo). Les données personnelles « sont détruites ou anonymisées dès qu'elles ne sont plus nécessaires au regard des finalités du traitement » (art. 6, al. 4, LPD). Pour les données de test, cela signifie les effacer après le test. Si le sous-traitant subit une violation de la sécurité des données, il l'annonce au responsable du traitement « dans les meilleurs délais » (art. 24, al. 3, LPD).

La LPD s'applique aux institutions de prévoyance de droit privé et aux institutions de la Confédération comme Publica. Les caisses des cantons et des communes relèvent en partie du droit cantonal de la protection des données. La question de savoir si l'on connaît vraiment son fournisseur s'y pose tout autant. Le tableau suivant montre la différence entre une check-list et un contrôle.

Un fournisseur remplit la colonne de gauche en une heure. La colonne de droite exige des preuves, des entretiens et des tests techniques. Seule la colonne de droite montre si les données sont protégées.

Un contrôle approfondi n'a pas à traiter tous les fournisseurs de la même manière. Il commence par ceux qui détiennent de vraies données d'assurés sur leurs propres systèmes. Nous recommandons une démarche en cinq étapes.

1. Cartographier les flux de données. Quelles données se trouvent chez quel fournisseur, y compris les copies pour les tests, les migrations ou les analyses d'erreurs ? Le flux de production est généralement documenté. Les copies souvent pas.
2. Éviter les données réelles hors production. Des données synthétiques ou pseudonymisées suffisent souvent pour les tests et les migrations. Pseudonymisé signifie que les noms et les numéros AVS sont remplacés par des codes, et que la clé reste auprès de la caisse. Si des données réelles sont inévitables, on se limite à un extrait minimal, avec un délai d'effacement fixe et une confirmation écrite de l'effacement.
3. Des preuves plutôt qu'une auto-déclaration. Demandez le périmètre du certificat, le résumé du dernier test d'intrusion et l'état des constatations ouvertes. Un certificat sans périmètre en dit peu.
4. Faire contrôler techniquement. Convenez du droit de faire examiner l'environnement du fournisseur par des spécialistes indépendants. Un test d'intrusion simule une attaque contre le portail, les interfaces et les accès à distance. Un scan de vulnérabilités recherche automatiquement et régulièrement les failles connues. Une Revue architecture sécurité examine la conception : où se trouvent les environnements de test et de migration, comment sont-ils séparés, et qui y a accès ?
5. Régler le contrat et le cas d'urgence. Le contrat doit prévoir un délai d'annonce des incidents, des droits d'audit et des obligations d'effacement. S'y ajoutent l'autorisation des sous-traitants ultérieurs et un plan de sortie. Exercez une fois ce qui se passe lorsque le fournisseur annonce une attaque.

Les contrôles techniques chez un fournisseur requièrent toujours son accord et des règles claires. Qui demande un droit d'audit seulement après un incident négocie en position de faiblesse. L'effort se règle sur le risque. Pour le fournisseur du logiciel central qui détient toutes les données des assurés, le risque justifie des contrôles techniques réguliers. Pour un fournisseur sans accès à des données personnelles, un questionnaire suffit.

Les attaquants : une fraude personnalisée à grande échelle

Les données volées à des caisses de pension ont une grande valeur pour les escrocs. Elles associent nom, employeur, salaire et avoir d'épargne. Avec l'IA générative, il suffit de quelques minutes pour en tirer des messages personnels sans faute en allemand, en français ou en italien. Les appels avec une voix synthétique deviennent aussi plus faciles. Une fuite chez le fournisseur devient ainsi un risque de fraude pour les assurés de la caisse.

Les fournisseurs : l'IA dans le support, le développement et les migrations

Les éditeurs de logiciels utilisent eux aussi l'IA. Les équipes de support font résumer les tickets. Les développeuses et développeurs travaillent avec des assistants d'IA qui écrivent du code et pilotent des environnements de test. Lors des migrations, des modèles de langage aident à faire correspondre les champs de données. Chacun de ces usages peut toucher des données d'assurés. Cela vaut pour toute la branche et ne constitue pas un indice concernant le cas actuel.

Les anciens questionnaires fournisseurs n'abordent généralement pas ce point. Selon l'art. 9, al. 3, LPD, « le sous-traitant ne peut lui-même sous-traiter un traitement à un tiers qu'avec l'autorisation préalable du responsable du traitement ». Un service d'IA qui traite des données d'assurés est en règle générale un tel tiers. Demandez donc : quels services d'IA le fournisseur utilise-t-il, avec quelles données et sous quel contrat ? Le code généré par l'IA est-il contrôlé avant sa mise en service ?

La même question se pose en interne. Qui ne sait pas où l'IA traite des données d'assurés dans sa propre organisation peut difficilement en juger chez le fournisseur. Un AI Governance Check recense les applications d'IA utilisées, y compris dans les logiciels achetés, et évalue leurs risques.

L'attaque contre l'éditeur de logiciels n'est pas encore élucidée, et ses causes ne sont pas connues publiquement. Indépendamment de cela, une règle générale s'applique : des données ne sont pas mieux protégées que chacun des endroits où se trouve une copie. Une check-list fournisseur montre ce qu'un fournisseur promet. Les preuves et les contrôles techniques montrent si la promesse tient.

SIDD accompagne dans cette démarche les organisations qui traitent des données personnelles sensibles. Un test d'intrusion montre où les portails, les interfaces et les accès à distance sont vulnérables. Des scans de vulnérabilités réguliers aident à détecter les failles connues avant que des attaquants ne les exploitent. Une Revue architecture sécurité examine comment les données circulent entre vous et vos fournisseurs et où se trouvent les environnements de test et de migration. L'AI Governance Check montre où l'IA travaille avec vos données. Nous coordonnons toujours les contrôles chez un fournisseur avec celui-ci. Nous discutons volontiers d'une première évaluation via le formulaire de contact.

Sources

Toutes les sources consultées le 18 octobre 2026.

• Le Conseil fédéral : Cyberattaque contre un fournisseur de logiciel de Publica: fuite de données confirmée, communiqué du 8 octobre 2026
• Communication de l’éditeur concerné sur la cyberattaque (en allemand)
• Pensionskasse Stadt Zürich : communication sur la cyberattaque contre son éditeur de logiciels, état au 15 octobre 2026 (en allemand)
• SRF : Wie konnten heikle Daten bei externer Softwarefirma landen?, 10 octobre 2026 (en allemand)
• Netzwoche : Bundespensionskasse Publica meldet Datenabfluss, 8 octobre 2026, mis à jour jusqu’au 15 octobre 2026 (en allemand)
• IPE : Swiss pension funds investigate potential data breach after cyber attack, 9 octobre 2026 (en anglais)
• Inside IT : Cyberangriff auf Pensionskassen-Lieferant zieht Kreise, 14 octobre 2026 (en allemand)
• NZZ : Immer mehr betroffene Pensionskassen (accès payant, en allemand)
• PFPDT : Rapport final et recommandations concernant fedpol à la suite d’un incident de rançongiciel, 25 avril 2024 (en allemand)
• PFPDT : Rapport final et recommandations concernant Xplain AG à la suite d’un incident de rançongiciel, 25 avril 2024 (en allemand)
• 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

État des informations : 18 octobre 2026. Les vérifications des caisses et l'enquête pénale sont en cours, certaines indications peuvent encore changer. Cet article est une information générale et ne constitue pas un conseil juridique.