CNIL | SAN-2025-015 | 22 DÉCEMBRE 2025 | AFFAIRE NEXPUBLICA FRANCE |
NEXPUBLICA FRANCE | MONTANT : 1 700 000 EUROS
ANALYSE CRITIQUE MANQUEMENTS FAQ CONSEILS
PARTIE I — FAQ À L’ATTENTION DES RESPONSABLES DE TRAITEMENT
1. La CNIL peut-elle sanctionner directement mon sous-traitant sans me mettre en cause, même si je suis responsable de traitement ?
Oui. La délibération SAN-2025-015 le confirme de façon inédite : la formation restreinte a sanctionné NEXPUBLICA FRANCE, sous-traitant éditeur et hébergeur du progiciel PCRM, sans engager parallèlement de procédure de sanction à l’encontre de la MDPH du département du Nord, pourtant responsable de traitement. La formation restreinte rappelle expressément que l’« opportunité d’engager une procédure de sanction relève de la seule appréciation de la Présidente de la Commission ». La CNIL dispose donc d’un pouvoir discrétionnaire dans le choix de l’entité qu’elle décide de sanctionner en priorité. Il en résulte que la qualité de responsable de traitement ne constitue pas un bouclier contre une sanction dirigée exclusivement contre votre sous-traitant, et que ce dernier peut être tenu personnellement responsable de ses défaillances techniques indépendamment de la votre. Cela ne dispense pas pour autant le responsable de traitement de ses propres obligations, qui demeurent pleinement opposables.
2. En tant que responsable de traitement, suffit-il de prévoir contractuellement que mon sous-traitant est responsable de la sécurité du traitement pour m’exonérer ?
Non. La délibération rappelle clairement que la responsabilité du sous-traitant est autonome vis-à-vis de celle du responsable de traitement, mais qu’elle n’est pas exclusive. La formation restreinte considère qu’« indépendamment des obligations qui pèsent en propre sur le responsable de traitement, il revient au sous-traitant de proposer et de mettre en œuvre les solutions techniques et organisationnelles adéquates ». Cela signifie que les deux acteurs sont soumis simultanément à l’article 32 du RGPD, et que le responsable de traitement ne peut se dégager de sa propre obligation de sécurité en renvoyant contractuellement la charge exclusive au sous-traitant. Il reste tenu de vérifier que ce dernier présente des « garanties suffisantes » au sens de l’article 28 § 1 du RGPD, d’exercer son droit d’audit, de suivre les résultats des audits, et d’exiger la correction rapide des vulnérabilités identifiées.
3. Mon prestataire IT a réalisé des audits de code et des tests d’intrusion qui révèlent des vulnérabilités. Que dois-je faire, concrètement ?
La délibération SAN-2025-015 livre un enseignement pratique capital : l’existence d’un audit ne suffit pas — c’est la correction effective et rapide des vulnérabilités identifiées qui est exigée. La formation restreinte constate que les audits de code de février et décembre 2021 avaient révélé des vulnérabilités critiques et importantes, et que le test d’intrusion de mars 2023 constatait encore que « certaines vulnérabilités identifiées dans le rapport de décembre 2022 n’avaient toujours pas été corrigées ». La CNIL en tire la conséquence que « l’audit cesse d’être un outil de prévention pour devenir le simple témoin d’une vulnérabilité entretenue ». En pratique, dès réception d’un rapport d’audit révélant des vulnérabilités, vous devez : (i) exiger de votre prestataire un plan de remédiation daté et hiérarchisé par niveau de criticité (CVSS) ; (ii) contractualiser des délais maximaux de correction alignés sur les standards ANSSI ; (iii) vérifier formellement l’exécution des correctifs avant le délai imparti ; (iv) conserver la trace documentaire de ce suivi au titre de l’accountability (art. 5 § 2 RGPD).
4. Mon logiciel de gestion utilise des composants open source ou des briques technologiques tierces. Suis-je (ou mon prestataire) responsable des vulnérabilités affectant ces composants ?
Oui, le sous-traitant éditeur est pleinement responsable des vulnérabilités affectant les composants technologiques tiers qu’il intègre dans sa solution. La formation restreinte relève que le recours à une brique logicielle tierce (en l’espèce le framework LIFERAY) « relève d’un choix technique de la société NEXPUBLICA FRANCE et qu’à ce titre, il lui appartient de s’assurer que cette brique logicielle est exempte de vulnérabilités, au regard des finalités, des moyens et des risques pour le traitement en cause ». L’argument selon lequel le prestataire ne peut être tenu responsable de ce qu’il n’a pas développé lui-même est donc expressément écarté. En votre qualité de responsable de traitement, vous devez donc exiger de votre prestataire IT qu’il vous fournisse la liste des composants tiers (bibliothèques, frameworks, services cloud) intégrés dans sa solution, et qu’il justifie d’une veille active sur les bulletins de vulnérabilité les concernant (CERT-FR, NVD), avec procédure de correction rapide en cas d’alerte.
5. Mon sous-traitant utilise encore des algorithmes cryptographiques anciens (SHA-1, MD5, TLS 1.0/1.1). Est-ce un problème ?
Oui, et c’est un problème qui peut engager la responsabilité de votre sous-traitant — et la vôtre indirectement en tant que responsable de traitement ayant sélectionné un prestataire ne présentant pas de « garanties suffisantes » au sens de l’article 28 § 1 du RGPD. La formation restreinte sanctionne NEXPUBLICA pour son recours à SHA-1 en rappelant le bulletin ANSSI CERTFR-2017-ACT-013 du 27 mars 2017, qui avait indiqué que SHA-1 « est à présent l’objet d’une vulnérabilité immédiatement exploitable et doit être abandonnée ». La CNIL avait déjà retenu ce grief dans la délibération SAN-2023-023 du 29 décembre 2023. La position est donc constante : tout prestataire traitant des données à caractère personnel — a fortiori des données de santé ou de handicap — doit utiliser des algorithmes cryptographiques conformes aux recommandations actuelles de l’ANSSI (TLS 1.3, AES-256, SHA-256 minimum). Vous devez demander à votre prestataire de vous fournir la liste des protocoles cryptographiques utilisés et leur conformité avec le Référentiel Général de Sécurité (RGS) en vigueur.
6. Mon sous-traitant m’informe d’une violation de données. Que dois-je faire et dans quel délai ?
L’article 33 § 1 du RGPD impose au responsable de traitement de notifier la violation à l’autorité de contrôle « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance ». Dans l’affaire NEXPUBLICA, la MDPH a notifié la violation le 29 novembre 2022, soit 19 jours après les premiers signalements du 10 novembre 2022 et 29 jours après le début du premier incident du 26 octobre 2022. La notification a ensuite été complétée le 6 mars 2023 — soit plus de quatre mois après les incidents. Ces délais illustrent les difficultés pratiques de notification lorsque le responsable de traitement dépend d’informations techniques détenues par son sous-traitant. Pour éviter ce risque, vous devez contractualiser une obligation de notification immédiate (dans les 24 heures) par votre sous-traitant de tout incident susceptible de constituer une violation au sens de l’article 4 § 12 du RGPD, lui demander de vous fournir dans ce délai les informations minimales requises par l’article 33 § 3, et prévoir une procédure interne permettant de décider rapidement si la violation « est susceptible d’engendrer un risque pour les droits et libertés » (seuil de notification) ou « un risque élevé » (seuil de communication aux personnes concernées en application de l’art. 34 RGPD).
7. Mon logiciel traite des données de santé et de handicap. Dois-je réaliser une AIPD ?
Oui, obligatoirement. L’article 35 § 3 b) du RGPD impose la réalisation d’une analyse d’impact relative à la protection des données (AIPD) pour « le traitement à grande échelle de catégories particulières de données visées à l’article 9 § 1 », ce qui inclut expressément les données de santé et les données relatives au handicap. La MDPH du département du Nord traitait des données de santé, de handicap, le NIR et des données relatives à la situation personnelle de milliers de personnes — dépassant largement le seuil de la grande échelle. L’AIPD doit inclure une évaluation des risques de sécurité et des mesures prévues pour les atténuer : si elle avait été réalisée avec la rigueur requise, elle aurait dû identifier les risques d’accès non autorisé par insuffisance de contrôle des permissions (type IDOR), le risque lié aux algorithmes cryptographiques obsolètes (SHA-1) et le risque lié à l’absence de journalisation active. L’identification formelle de ces risques dans l’AIPD aurait généré l’obligation de prévoir des mesures correctives avant la mise en production.
8. Mon contrat de sous-traitance ne prévoit pas de droit d’audit. Est-ce un problème ?
Oui, c’est une lacune grave. L’article 28 § 3 h) du RGPD impose que le contrat de sous-traitance prévoie que le sous-traitant « met à la disposition du responsable du traitement toutes les informations nécessaires pour démontrer le respect des obligations prévues au présent article et pour permettre la réalisation d’audits, y compris des inspections ». Un contrat ne prévoyant pas de droit d’audit serait non-conforme à l’article 28 § 3 h) et priverait le responsable de traitement de l’un de ses principaux outils de vérification de la conformité de son sous-traitant. Mais au-delà de la présence formelle d’une clause d’audit, la délibération NEXPUBLICA enseigne qu’il faut également exercer effectivement ce droit : un droit d’audit contractuellement prévu mais jamais mis en œuvre ne produit aucun effet protecteur. La pratique recommandée est de prévoir des audits annuels, réalisés par un prestataire qualifié PASSI (Prestataires d’Audit de la Sécurité des Systèmes d’Information) indépendant du sous-traitant, et de contractualiser l’obligation pour le sous-traitant de prendre en charge le coût de l’audit en cas de manquement identifié.
9. Mon logiciel a été mis en production sans audit de sécurité préalable. Est-ce sanctionnable ?
La délibération est particulièrement nette sur ce point. La formation restreinte reproche expressément à NEXPUBLICA la « mise en production du PCRM présentant de telles failles », en plus de l’absence de correction rapide des vulnérabilités lors de leur identification ultérieure. Le PCRM avait été mis en production le 24 décembre 2019, et les premiers audits de code n’ont été réalisés qu’en février et décembre 2021, soit plus d’un an après la mise en production. La CNIL considère implicitement qu’un audit de sécurité préalable à la mise en production était exigé par l’état de l’art pour un logiciel traitant des données de santé et de handicap. Pour tout logiciel appelé à traiter des données de catégorie spéciale, vous devez exiger de votre prestataire la réalisation d’un test d’intrusion par un prestataire qualifié PASSI, indépendant du développeur, avant toute mise en production sur des données personnelles réelles.
10. La journalisation mise en place par mon sous-traitant suffit-elle si elle enregistre tous les accès ?
Non, si elle est purement passive. La formation restreinte distingue la journalisation passive — qui se contente d’enregistrer des événements sans mécanisme d’alerte — de la journalisation active préconisée par la délibération CNIL n° 2021-122 du 14 octobre 2021, qui doit « générer des alertes en cas de comportement anormal ». Une journalisation passive ne suffit pas lorsqu’elle « n’offre aucune capacité de détection et de réaction ». En outre, l’incapacité de NEXPUBLICA à « indiquer quelles données ont fait l’objet des violations » révèle que même la journalisation enregistrée était insuffisamment détaillée pour permettre une analyse forensique post-incident. Vous devez demander à votre prestataire de vous démontrer que sa solution de journalisation permet : (i) l’identification précise des données consultées, modifiées ou exportées ; (ii) la génération automatique d’alertes en cas de comportement anormal (volumes d’accès inhabituels, téléchargements massifs, accès depuis des IP non référencées) ; (iii) une conservation des journaux pendant une durée compatible avec les délais légaux de prescription et d’action en responsabilité.
PARTIE II — FAQ À L’ATTENTION DES PERSONNES CONCERNÉES
11. Mes données personnelles ont pu être exposées lors des violations de novembre 2022. Comment le savoir et que faire ?
Si vous avez déposé un dossier auprès de la MDPH du département du Nord entre le 24 décembre 2019 (mise en production du PCRM) et le 14 novembre 2022 (date de clôture du second incident), vos données personnelles ont pu être exposées. Ces données incluent potentiellement votre identité, votre numéro de sécurité sociale (NIR), des données de santé et relatives à votre situation de handicap, ainsi que des informations relatives à votre situation financière, familiale, scolaire et professionnelle. Pour en avoir la certitude, vous pouvez exercer votre droit d’accès prévu par l’article 15 du RGPD en adressant une demande écrite au DPO de la MDPH du département du Nord. La MDPH est tenue de vous répondre dans un délai d’un mois. En cas d’absence de réponse ou de réponse insuffisante, vous pouvez saisir la CNIL en ligne (https://www.cnil.fr/fr/plaintes).
12. Mon numéro de sécurité sociale (NIR) a été potentiellement exposé. Quels risques cela représente-t-il concrètement ?
Le NIR est une donnée particulièrement sensible car il constitue un identifiant unique utilisé dans de nombreuses bases de données administratives et sociales. Son exposition peut faciliter des tentatives d’usurpation d’identité (ouverture de comptes bancaires ou de crédit, demandes frauduleuses de prestations sociales, falsification de documents administratifs). En cas d’exposition de votre NIR, il est recommandé de : surveiller attentivement vos relevés de comptes bancaires et vos avis de droits sociaux (assurance maladie, CAF, etc.) ; signaler toute anomalie à votre caisse d’assurance maladie, à votre CAF et à votre banque ; consulter vos données fiscales sur impots.gouv.fr pour détecter toute déclaration frauduleuse ; en cas de tentative d’usurpation avérée, déposer une plainte auprès des forces de l’ordre et signaler les faits sur la plateforme Pharos (https://www.internet-signalement.gouv.fr) du Ministère de l’Intérieur.
13. Puis-je obtenir réparation pour le préjudice moral subi du fait de l’exposition de mes données de santé et de handicap ?
Oui. L’article 82 § 1 du RGPD dispose que « toute personne ayant subi un dommage matériel ou moral du fait d’une violation du présent règlement a le droit d’obtenir du responsable du traitement ou du sous-traitant réparation du préjudice subi ». Conformément à l’arrêt CJUE, 14 décembre 2023, Natsionalna agentsia za prihodite (C-204/21), la seule crainte d’un usage abusif des données de santé et de handicap exposées peut constituer un préjudice moral indemnisable, sans qu’il soit nécessaire de démontrer une exploitation effective et malveillante des données. Vous pouvez agir en responsabilité civile contre la MDPH du département du Nord (responsable de traitement) et/ou contre NEXPUBLICA FRANCE (sous-traitant) devant les juridictions civiles compétentes. L’article 82 § 4 du RGPD prévoit la responsabilité solidaire de ces acteurs, ce qui vous permet d’agir contre l’un ou l’autre pour l’intégralité de votre préjudice. La prescription de ce type d’action est en principe de cinq ans à compter de la connaissance du dommage (art. 2224 du Code civil).
14. J’aurais dû être informé individuellement de la violation de données. Pourquoi ne l’ai-je pas été ?
L’article 34 § 1 du RGPD impose au responsable de traitement de « communiquer dans les meilleurs délais » à la personne concernée toute violation susceptible d’engendrer « un risque élevé pour les droits et libertés ». Compte tenu de la nature des données exposées (santé, handicap, NIR), la question de l’obligation de notification individuelle aux personnes concernées peut légitimement se poser. Toutefois, l’article 34 § 3 c) RGPD prévoit une exception lorsque la communication « exigerait des efforts disproportionnés », auquel cas une communication publique peut y suppléer. Si vous estimez n’avoir pas reçu une information suffisante de la MDPH, vous pouvez lui adresser une demande d’explication et saisir la CNIL si sa réponse est insatisfaisante.
15. Dois-je changer mes mots de passe ou prendre d’autres mesures de précaution immédiates ?
Oui, par précaution. Même si la formation restreinte a relevé que « la société a pu exclure un accès aux pièces jointes (par exemple les justificatifs d’identité ou certificats médicaux) », l’exposition de données d’identité, du NIR et d’informations sociales suffit à justifier des mesures de précaution. Il est recommandé de : (i) modifier les mots de passe de tout service en ligne utilisant votre email ou votre NIR comme identifiant ; (ii) activer la double authentification (2FA) sur vos comptes Ameli, CAF, impots.gouv.fr et services bancaires en ligne ; (iii) mettre en place une alerte Banque de France contre l’inscription abusive au FICP (Fichier des Incidents de remboursement des Crédits aux Particuliers) en cas de risque d’usurpation d’identité dans le cadre d’une demande de crédit frauduleuse.
POINTS ESSENTIELS
Par sa délibération SAN-2025-015 du 22 décembre 2025, la formation restreinte de la CNIL a lourdement sanctionné la société spécialisée en ingénierie informatique NEXPUBLICA FRANCE à hauteur de 1 700 000 euros pour un manquement caractérisé à l’article 32 du RGPD, en raison de défaillances structurelles majeures affectant la sécurité de son progiciel de gestion sociale PCRM déployé au bénéfice de la Maison Départementale pour les Personnes Handicapées (MDPH) du Nord, ayant conduit en novembre 2022 à l’exposition non autorisée des données de santé, de handicap, d’identité et du numéro de sécurité sociale (NIR) de près de 15 000 personnes particulièrement vulnérables ; la décision fustige une négligence grave et persistante du sous-traitant qui, d’une part, a maintenu en production des vulnérabilités critiques d’accès (de type IDOR) formellement identifiées par des audits de code automatisés et des tests d’intrusion successifs menés entre 2021 et 2023 sans procéder à leur correction dans des délais compatibles avec l’état de l’art, et d’autre part, a persisté à utiliser la fonction de hachage cryptographique SHA-1 formellement déclarée obsolète et vulnérable par l’ANSSI depuis 2017, le tout aggravé par une journalisation purement passive inapte à détecter ou tracer précisément l’étendue des exfiltrations de données, confirmant ainsi de manière inédite et implacable la responsabilité autonome, directe et renforcée du sous-traitant éditeur de logiciel vis-à-vis des composants tiers qu’il intègre, sans qu’il puisse se retrancher derrière les instructions du responsable de traitement ou arguer de faux positifs techniques pour s’exonérer de son obligation impérative de garantir une véritable défense en profondeur.
24.05.2026 | Dernière Mise à Jour | Armand-Ari BETTAN & Dominique KARPISEK-BETTAN, Avocats