IBAN en clair, mots de passe en base : ce que la sanction Free apprend à un éditeur de logiciel
La CNIL a sanctionné Free 42 millions d'euros pour des IBAN stockés sans chiffrement. La leçon pour tout éditeur de logiciel : le chiffrement applicatif est devenu un prérequis de contrat, pas une option.
Pourquoi la sanction Free concerne-t-elle un éditeur de logiciel ?
Parce que la CNIL n'a pas sanctionné une négligence exotique : elle a sanctionné l'absence d'une mesure élémentaire, le chiffrement de données bancaires, sur des systèmes conçus par des ingénieurs. Un éditeur de logiciel qui stocke les IBAN, mots de passe ou données personnelles de ses clients est exposé au même reproche, au titre de sa responsabilité de sous-traitant. La sanction Free fixe un standard de fait que vos propres clients régulés vont désormais vous réclamer par contrat.
En janvier 2026, la CNIL a rendu publique sa sanction de 42 millions d'euros contre Free (délibérations SAN-2026-001 et SAN-2026-002 du 8 janvier 2026, publiées sur Légifrance). Le détail technique a glacé les professionnels : l'opérateur, qui gère les coordonnées bancaires de millions de Français, n'avait pas chiffré ces données. Un attaquant a pu siphonner 5,1 millions d'IBAN. Ce n'est pas un incident isolé, c'est un symptôme.
L'article 32 : la mesure que le RGPD nomme explicitement
Le RGPD, entré en application le 25 mai 2018, comporte 99 articles. L'article 32, consacré à la sécurité des traitements, concentre une part majeure des sanctions prononcées par la CNIL. Sa force tient à une phrase, alinéa 1(a) : le responsable et le sous-traitant mettent en œuvre « la pseudonymisation et le chiffrement des données à caractère personnel ».
C'est une anomalie remarquable. Le RGPD, rédigé selon le principe de neutralité technologique, évite de prescrire des outils. Il fait deux exceptions, deux seulement : la pseudonymisation et le chiffrement. En les nommant, le législateur leur a conféré le statut de mesures de référence, le seuil sous lequel un acteur aura du mal à démontrer sa conformité.
L'approche reste fondée sur le risque. Mais pour des données bancaires, de santé ou des fichiers de millions de personnes, cette analyse conduit invariablement à la même conclusion : le chiffrement n'est pas optionnel. La CNIL le qualifie de mesure « élémentaire ». Point important pour un éditeur : l'article 28 du RGPD vous rend, comme sous-traitant, directement tenu de ces mesures, pas seulement votre client responsable de traitement.
Le bal des données nues
L'affaire Free n'a pas ouvert le bal, elle l'a rendu impossible à ignorer. France Travail, l'ancien Pôle emploi, a subi en 2024 une compromission exposant 43 millions d'usagers. L'enquête de la CNIL, sanctionnée 5 millions d'euros en janvier 2026, a révélé un seuil de blocage des tentatives de connexion fixé à 50 essais là où l'autorité recommande 10, et une authentification multifacteur absente.
SFR a vu des IBAN clients exposés dans une fuite distincte. Boulanger a découvert 27,5 millions de lignes de données accessibles sur un forum criminel, sans aucune couche de chiffrement, lisibles et monnayables en quelques heures. La CNIL a aussi sanctionné un e-commerçant pour avoir stocké des numéros de carte bancaire en clair dans des champs commentaires. Pas dans une base mal configurée : dans des commentaires libres.
Ces affaires dessinent un schéma récurrent. Les données sensibles sont collectées, traitées, stockées, parfois sous-traitées, sans que personne, à aucun maillon, ne les ait rendues illisibles en cas de compromission. Le chiffrement n'a pas échoué : il n'a jamais été envisagé. Et dans une chaîne de sous-traitance, ce maillon défaillant est souvent un logiciel tiers.
Pourquoi les éditeurs ne chiffrent-ils toujours pas ?
Trois obstacles reviennent, et aucun ne résiste à l'état de l'art actuel.
La dette technique d'abord. Une part importante des systèmes en production ont été conçus quand le chiffrement au repos n'était pas un sujet. Ajouter une couche cryptographique à une base configurée il y a quinze ans effraie : il faut auditer les flux, choisir les algorithmes, gérer les clés, tester les performances. Le chantier est reporté.
Le déficit de compétences ensuite. Le chiffrement reste perçu comme une affaire de cryptographes. L'idée qu'un développeur puisse intégrer de l'AES-256-GCM en quelques appels d'API n'a pas encore percé dans tous les comités techniques. Selon le baromètre 2025 de Cybermalveillance.gouv.fr, le manque de connaissances en cybersécurité reste le premier frein cité par les TPE et PME.
L'erreur de périmètre enfin. Pendant des décennies, la doctrine de sécurité s'est construite autour du château fort : on érige des murailles (pare-feu, VPN, segmentation) et on considère l'intérieur comme sûr. Les données n'y sont pas chiffrées puisqu'elles sont « derrière les murs ». Cette approche est morte avec le cloud et la sous-traitance. Les attaques contre Free, France Travail ou Boulanger n'ont pas forcé un datacenter : elles ont exploité des accès légitimes et des chaînes de sous-traitance mal sécurisées. Le périmètre est une fiction. La seule protection qui survit à une compromission du réseau, c'est le chiffrement des données elles-mêmes.
Le rapport Thales Data Threat Report 2024 quantifie le décalage : seulement 57 % des données sensibles stockées dans le cloud sont chiffrées, et la totalité des répondants déclarent qu'au moins une partie de leurs données cloud sensibles ne l'est pas. Personne n'est irréprochable, tout le monde le sait, personne ne corrige.
Le chiffrement n'est pas une ligne Maginot
Il serait malhonnête de présenter le chiffrement comme la solution unique. Il protège les données au repos et en transit contre les accès non autorisés. Il ne protège pas contre un employé malveillant aux droits légitimes. Il ne compense pas l'absence de MFA, comme l'a montré France Travail. Il ne détecte pas les exfiltrations, comme l'a illustré Free.
La sécurité repose sur une architecture multicouche : contrôle d'accès strict, journalisation, détection d'anomalies, segmentation, gestion des identités. Le chiffrement en est le pilier de dernier recours, celui qui transforme une fuite catastrophique en incident maîtrisé. Quand tout le reste a échoué, la question devient : les données exfiltrées sont-elles exploitables ? Chiffrées avec un algorithme robuste et des clés bien gérées, la réponse est non. Les IBAN restent des séquences de bits sans signification. C'est précisément ce filet que la majorité des éditeurs n'ont pas tendu.
Ce qui vient : RGPD durci, DORA, et NIS2 en approche
La jurisprudence CNIL de janvier 2026 (Free, France Travail) fait du défaut de chiffrement de données bancaires ou d'identité, dans une organisation qui en a les moyens, une négligence caractérisée. Le RGPD Article 32 est la base la plus sûre pour affirmer cette obligation, car il est en vigueur et opposable.
Pour les éditeurs qui vendent au secteur financier, le règlement DORA, en application depuis le 17 janvier 2025, ajoute une exigence documentée de chiffrement et de gestion des clés qui descend jusqu'aux prestataires TIC via son article 28.
Un point d'honnêteté sur NIS2, souvent présentée à tort comme déjà applicable : la directive (UE) 2022/2555 n'est pas transposée en France. La Commission européenne a saisi la Cour de justice de l'Union européenne le 8 juillet 2026 pour défaut de transposition (Le Monde Informatique, juillet 2026), et l'examen du projet de loi Résilience est repoussé à septembre 2026 au plus tôt. NIS2 arrive, elle s'anticipe. Aujourd'hui, l'obligation présente et opposable vient du RGPD et, pour la finance, de DORA.
La bonne question pour un éditeur
La question n'est plus « faut-il chiffrer ? » : la loi est claire depuis 2018. Elle est devenue opérationnelle : avec quels outils, selon quelle architecture, dans quel calendrier. Et surtout : construire soi-même une gestion de clés et un journal d'audit opposable, ou intégrer une brique qui le fournit ?
C'est le job d'une plateforme de chiffrement applicatif. MAFATE chiffre les champs sensibles (IBAN, données personnelles) via API, garde les clés en France chez UNIVILE SAS, opérateur français non soumis au CLOUD Act, et génère le dossier de preuves que votre client régulé réclame. Précision d'honnêteté : le rapport de conformité contribue au dossier, il ne constitue pas un certificat, et le HSM qui protège les clés est logiciel aujourd'hui, la migration vers un HSM matériel FIPS 140-2 est planifiée.
MAFATE s'adresse aux éditeurs SaaS régulés, avec l'architecture publiée sur sa page sécurité. Si un contrat vous est bloqué parce qu'un client vous réclame une preuve de chiffrement conforme, parler à un ingénieur fait gagner les semaines que vos concurrents passent encore à assembler ce dossier à la main.
Sources
- CNIL, sanction Free 42 M€, janvier 2026
- CNIL, sanction France Travail 5 M€, janvier 2026
- Légifrance, délibérations CNIL SAN-2026-001 et SAN-2026-002 du 8 janvier 2026
- CNIL, fiche « Sécurité : chiffrer pour garantir la confidentialité des données »
- RGPD, règlement (UE) 2016/679 (art. 28 et 32)
- Cybermalveillance.gouv.fr, baromètre maturité cyber TPE-PME 2025
- Thales, Data Threat Report 2024
- Le Monde Informatique, saisine CJUE France pour non-transposition NIS2 (juillet 2026)
Articles connexes
Chiffrer les données de vos clients quand vous éditez un SaaS régulé
Un client régulé bloque la signature sur une preuve de chiffrement ? Guide pour l'éditeur SaaS : AES-256-GCM, architecture DEK/KEK, HSM et preuves qui répondent à un questionnaire de sécurité, sur la base du RGPD Art. 32.
ConformitéDORA et le chiffrement : ce qu'un éditeur fintech doit prouver à ses clients financiers
DORA est en application depuis le 17 janvier 2025. Son article 28 descend jusqu'aux prestataires TIC, dont les éditeurs de logiciels. Ce que vos clients régulés vont vous demander de prouver sur le chiffrement.
TechniquePourquoi utiliser plusieurs clés de chiffrement : le guide des architectes sécurité
Marriott, LastPass, 29 millions de secrets sur GitHub : les architectures mono-clé sont un piège. Bonnes pratiques NIST SP 800-57, ANSSI PG-083, et envelope encryption.