L’essentiel en bref
Le 11 août 2026, Bloctel — la liste nationale d’opposition au démarchage téléphonique — fermait définitivement ses portes, conformément à la loi du 30 juin 2025 instaurant le consentement préalable obligatoire (opt-in) pour le démarchage. Le lendemain, la DGCCRF alertait que la fermeture ne s’était pas faite sans accroc : un compte professionnel avait été compromis, permettant l’exfiltration de 3 millions de numéros de téléphone. La CNIL a été notifiée, le compte bloqué, et l’ensemble des accès professionnels audité.
L’incident ne remet pas en cause la solidité de la base de données centrale de Bloctel, mais il pointe une lacune que les équipes logicielles reconnaîtront immédiatement : lors de la mise hors service d’une plateforme, la révocation des accès API professionnels doit faire l’objet d’un plan formel. Sans cela, des comptes disposant de droits larges sur les données clients restent ouverts après la fermeture officielle. Pour les équipes qui développent des plateformes à accès B2B, cet incident est un cas d’école sur la gestion du cycle de vie des données et la conformité RGPD lors des transitions de service.
Chronologie de l’incident
Bloctel, créé en 2016 pour permettre aux particuliers de s’inscrire sur une liste d’opposition au démarchage téléphonique, a cessé ses activités le 11 août 2026. Sa suppression était prévue par la loi du 30 juin 2025, qui remplace le système d’opt-out (inscription sur liste d’opposition) par un régime d’opt-in obligatoire : désormais, les entreprises doivent recueillir le consentement préalable des consommateurs avant de les démarcher.
C’est dans cette fenêtre de transition — le jour même de la fermeture officielle ou les heures qui ont suivi — qu’un cybercriminel a exploité un compte professionnel compromis. Ces comptes pro permettaient aux entreprises de démarchage téléphonique de soumettre leurs fichiers clients à vérification contre la liste Bloctel, via une interface API. L’attaquant, en prenant le contrôle d’un de ces comptes, a pu récupérer des fichiers contenant 3 millions de numéros.
Le 12 août, la DGCCRF a publié un communiqué officiel alertant les consommateurs. La même journée, Bloctel a notifié les 600 000 abonnés directement concernés par courrier électronique.
L’angle clé : un compte professionnel, pas la base centrale
Il est important de comprendre ce que cet incident n’est pas : une attaque directe sur la base de données de Bloctel. La base centrale — l’ensemble des numéros inscrits — n’a pas été compromise. Ce qui a été compromis, c’est un compte professionnel d’entreprise, c’est-à-dire un accès de type B2B destiné aux sociétés de télémarketing qui devaient, avant chaque campagne, épurer leurs fichiers clients en les confrontant à la liste d’opposition.
Ce type d’accès constitue une surface d’attaque distincte et souvent sous-évaluée. En pratique, un compte professionnel donne à l’entreprise cliente la capacité d’interroger la plateforme avec des fichiers volumineux. La sécurité de ce canal repose donc sur deux piliers : la robustesse des identifiants du compte (mots de passe, 2FA) et la politique de révocation des accès au moment de la fermeture du service.
Sur le second point, l’incident révèle une lacune fréquente dans les plans de mise hors service (offboarding) de plateformes : la fermeture publique du service et la révocation effective de tous les tokens API sont deux opérations distinctes, qui doivent être orchestrées avec un plan formel. Sans délai d’expiration automatique des clés API ou procédure explicite de révocation, des comptes conservent leurs droits d’accès après la fermeture déclarée, ouvrant une fenêtre d’exploitation.
Réponse officielle : DGCCRF, CNIL et mesures correctives
La direction générale de la Concurrence, de la Consommation et de la Répression des fraudes (DGCCRF), qui supervisait Bloctel, a publié un communiqué de presse le 12 août 2026 décrivant l’incident et les mesures prises :
- Blocage immédiat du compte compromis dès la découverte de l’accès frauduleux.
- Audit de l’ensemble des comptes professionnels actifs pour identifier d’éventuelles anomalies similaires.
- Notification à la CNIL, conformément à l’obligation prévue par l’article 33 du RGPD (délai de 72 heures à compter de la découverte d’une violation).
- Information directe des abonnés concernés par courrier électronique, conformément à l’article 34 du RGPD qui impose d’avertir les personnes lorsque le risque pour leurs droits est élevé.
La DGCCRF a également diffusé des recommandations aux consommateurs : ignorer les appels et SMS provenant de numéros inconnus, ne jamais communiquer de données personnelles par téléphone, changer les mots de passe lorsqu’un numéro de téléphone sert d’identifiant, et rester vigilant face aux tentatives de phishing exploitant cet incident.
Le fait que seuls des numéros de téléphone aient été exposés — sans noms, adresses ou données bancaires — limite le risque immédiat. En revanche, ces numéros, croisés avec d’autres bases issues d’incidents antérieurs, peuvent alimenter des campagnes de vishing (hameçonnage téléphonique) ciblées. C’est précisément le risque contre lequel la DGCCRF met en garde.
Ce que cet incident révèle pour les équipes logicielles
Au-delà du cas Bloctel, cet incident pointe des pratiques de sécurité que toute équipe développant une plateforme avec accès B2B ou API professionnelle devrait avoir intégrées.
1. Planifier la révocation des accès API comme une étape de déploiement à part entière
La fin de vie d’un service implique des étapes techniques autant que juridiques. Les tokens API, les clés d’accès et les sessions actives des comptes professionnels doivent être révoqués selon un plan écrit, avec des dates et des responsables désignés. Un tableau de bord des accès actifs, mis à jour en temps réel, est un prérequis pour exécuter cette révocation correctement. Dans le cas d’une fermeture progressive, des délais d’expiration automatique sur les clés API constituent un filet de sécurité supplémentaire.
2. Appliquer le principe de moindre privilège aux comptes professionnels
Un compte professionnel n’a pas nécessairement besoin d’accéder à l’intégralité de la base de données. Dans le cas de Bloctel, chaque entreprise cliente soumettait ses propres fichiers à vérification : ses droits d’accès auraient pu être limités aux seules opérations nécessaires (soumettre un fichier, recevoir un résultat d’exclusion) sans lui permettre d’extraire des données en volume. La granularité des permissions réduit mécaniquement la portée d’une compromission.
3. Documenter et tester le plan de réponse RGPD
La conformité RGPD lors d’un incident ne s’improvise pas. La notification à la CNIL dans les 72 heures, la communication aux personnes affectées, la documentation de la violation et l’évaluation du risque doivent être prévues dans un plan formalisé, testé avant que l’incident survienne. Les audits de sécurité applicative incluent aujourd’hui systématiquement la vérification de ce plan et des procédures de notification, car une réponse tardive ou incomplète expose l’organisation à des sanctions supplémentaires de la CNIL.
4. Surveiller les accès même après une fermeture de service
La fenêtre de vulnérabilité post-fermeture est réelle et souvent négligée. Si une plateforme ou une API est mise hors service, la journalisation des accès doit rester active pendant une période minimale de transition — typiquement 30 à 90 jours — pour détecter les tentatives d’accès résiduelles sur des comptes qui n’auraient pas été correctement révoqués. L’incident Bloctel illustre que cette fenêtre peut être exploitée en quelques heures.
Questions fréquentes
Comment les données Bloctel ont-elles été compromises ?
Ce n’est pas la base de données centrale de Bloctel qui a été piratée, mais un compte professionnel disposant d’un accès API au service. Un cybercriminel a pris le contrôle de ce compte et récupéré des fichiers contenant 3 millions de numéros de téléphone, dont 600 000 appartenant à des inscrits sur la liste anti-démarchage.
Quelles données ont été exposées dans cette fuite Bloctel ?
Uniquement des numéros de téléphone. La DGCCRF a confirmé qu’aucune donnée personnelle complémentaire (nom, prénom, adresse postale) n’a été divulguée. Les personnes concernées ont été notifiées par e-mail par Bloctel.
Pourquoi cette fuite s’est-elle produite juste après la fermeture du service ?
La fermeture de Bloctel le 11 août 2026 ne signifiait pas la révocation immédiate de tous les accès professionnels API. Des comptes entreprises utilisés pour accéder aux données d’exclusion restaient potentiellement actifs dans la fenêtre post-fermeture. C’est dans cet intervalle que la compromission a eu lieu — un risque classique lors de la mise hors service d’une plateforme SaaS ou d’une API publique.
Quelles obligations RGPD s’appliquent à un incident comme Bloctel ?
En vertu de l’article 33 du RGPD, toute violation de données personnelles doit être notifiée à la CNIL dans les 72 heures suivant sa découverte. Si le risque pour les personnes est élevé, l’article 34 impose de les informer directement. Dans le cas Bloctel, la CNIL a été notifiée et les utilisateurs concernés ont reçu un e-mail d’alerte.
Que doivent retenir les équipes logicielles de cet incident ?
Trois enseignements principaux : premièrement, les accès professionnels API doivent être révoqués selon un plan formel lors de toute fermeture de service. Deuxièmement, le principe de moindre privilège appliqué aux comptes pro aurait contenu la portée de l’exfiltration. Troisièmement, un plan de réponse RGPD (notification CNIL 72 h, communication aux personnes) doit être rédigé et testé avant l’incident.
Sources
DGCCRF — La DGCCRF met en garde les consommateurs à la suite d’une fuite de données sur Bloctel (communiqué officiel, 12 août 2026)
Usine Digitale — Fuite de données chez Bloctel : 3 millions de numéros exposés juste avant la fermeture du service
Le Big Data — Bloctel : ce service anti-démarchage laisse fuiter des millions de numéros