Cybermois 2026 : après l'été des fuites de données, relever le niveau
Le Cybermois 2026 est consacré à l'après-fuite de données. L'été en a donné la raison : DGFiP, Tchap, Éducation nationale, Revolut. Presque aucune de ces fuites n'a demandé de faille sophistiquée. Elles sont passées par un identifiant valide ou un canal de confiance. C'est là que le niveau doit monter, y compris dans les logiciels des PME.
Oct 16, 2026
En bref : le Cybermois 2026 se tient du 1er au 31 octobre. Cette année, la CNIL et Cybermalveillance.gouv.fr le placent sur l'après-fuite de données, et le moment s'y prête : selon leur baromètre, 45 % des Français ont déjà été notifiés d'une violation de leurs données. L'été a été chargé : DGFiP, Tchap, Éducation nationale, Bloctel, et en septembre deux incidents chez Revolut. Il ne s'agit pas de faire le procès de ces organisations. Elles ont des équipes de sécurité, des budgets et des audits que la plupart des PME n'auront jamais. Le constat est plus utile que ça : presque aucune de ces fuites n'a demandé de faille sophistiquée. Elles sont passées par un identifiant valide, un prestataire ou un canal de confiance. C'est le niveau qui doit monter, et il doit monter aussi dans les logiciels métier des entreprises plus petites.
Le Cybermois 2026 en deux mots
- Quand : du 1er au 31 octobre 2026, 14e édition, déclinaison française du Mois européen de la cybersécurité.
- La campagne : « Se cyber protéger, ce n'est pas si bête », portée par Cybermalveillance.gouv.fr.
- La ressource à garder : « Violation de données personnelles, que faire en 3 étapes clés ? », publiée avec la CNIL. C'est une liste d'actions du jour de la découverte jusqu'à J+30. Si votre entreprise n'a pas de procédure écrite pour le jour où une fuite est découverte, commencez par là.
Ce que l'été nous a appris
IT for Business a recensé les fuites des services numériques de l'État entre juin et août 2026. Ce qui frappe, c'est moins leur nombre que la façon dont elles se sont produites, quand elle a été rendue publique :
| Service | Personnes concernées (annoncé) | Point d'entrée rendu public |
|---|---|---|
| Tchap (7 juin) | 73 467 comptes | un compte utilisateur usurpé |
| JeVeuxAider.gouv.fr (juin) | environ 550 000 comptes | une faille permettant une extraction, corrigée depuis |
| Éducation nationale (25 juillet) | chiffre officiel non publié | un compte professionnel usurpé |
| Bloctel (12 août) | environ 600 000 inscrits | un compte professionnel autorisé, compromis |
| Santé publique France (13 août) | environ 80 000 personnes | une plateforme hébergée chez un prestataire |
| DGFiP (juin et juillet) | 678 000 particuliers et professionnels annoncés | les identifiants d'un agent et d'un tiers autorisé |
Pour la DGFiP, l'article ajoute un détail qui résume tout : les contrôles n'ont pas détecté l'extraction. Les identifiants étaient bons, donc les requêtes avaient l'air normales.
Chez Revolut, en septembre, le schéma est le même avec un autre canal. La banque a confirmé le 12 septembre avoir transmis des données de clients (pièces d'identité, adresses, dates de naissance) à des escrocs qui se faisaient passer pour une administration, avec des e-mails envoyés depuis le vrai domaine de cette administration (Help Net Security). Quelques jours plus tard, une seconde fuite touchait des clients via DriveWealth, le courtier américain qui gérait leurs actions, après une campagne d'ingénierie sociale les 4 et 5 septembre (The Register). Dans les deux cas, Revolut indique que ses propres systèmes n'ont pas été compromis. C'est exact, et c'est justement le sujet.
Le niveau qui doit monter
Le mot de passe solide et l'antivirus restent indispensables, mais ils ne répondent pas à ces scénarios. Quand l'attaquant a un vrai identifiant ou écrit depuis un vrai domaine, ce qui protège se trouve dans le logiciel lui-même :
- Vérifier les droits à chaque requête, côté serveur. Être connecté n'est pas être autorisé. Chaque écran, chaque export, chaque appel d'API doit vérifier que cette personne a le droit de voir ces données, au moment où elle les demande.
- Couper l'accès quand quelqu'un part. Un compte d'ancien salarié ou d'ancien prestataire qui fonctionne encore est un identifiant valide en attente d'être volé.
- Donner aux tiers le minimum. Un prestataire autorisé à interroger une base n'a pas besoin de pouvoir tout exporter.
- Traiter l'export en masse comme un événement. Une personne qui télécharge 500 000 lignes un mardi soir, ce n'est pas une requête comme les autres. Limitez-le, journalisez-le, et faites en sorte que quelqu'un le voie.
- Ne jamais faire confiance au canal seul. Une demande de données sensibles, même depuis une adresse officielle, se vérifie par un autre moyen : un numéro connu, un portail dédié, un second interlocuteur.
- Savoir où vivent vos données. Chez qui, sur quelle plateforme, avec quels accès. Une fuite chez un sous-traitant reste votre fuite, comme l'a rappelé la cyberattaque des Hauts-de-France.
Ce que nous faisons, et ce qui nous manque
Nous hébergeons et faisons tourner la plupart des logiciels que nous développons, donc ces six points sont les nôtres. Voici ce qui est en place, tel que décrit sur notre page sécurité :
Les droits viennent de la base, à chaque appel. Dans nos serveurs MCP, qui permettent à Claude ou ChatGPT d'agir dans un logiciel métier, ni les clés ni les jetons ne portent de rôle : à chaque requête, le serveur relit l'appartenance actuelle de l'utilisateur à son organisation. Une personne retirée perd l'accès à l'appel suivant, même avec un jeton encore valide. Chaque outil exige un droit de lecture ou d'écriture, et un outil non annoté est traité comme une écriture. Le détail est dans notre article sur la sécurité MCP.
Les comptes de vos équipes, pas des comptes à part. Vos utilisateurs se connectent avec les comptes Microsoft ou Google qu'ils ont déjà, et les droits dans l'application sont attribués par rôle. Quand vous désactivez quelqu'un chez vous, il ne garde pas un mot de passe oublié dans notre application.
Aucune administration sur Internet. Les outils d'administration et l'accès aux bases ne sont joignables que depuis notre réseau privé Tailscale. Les serveurs n'ont pas d'adresse IP publique, et les identifiants vivent dans HashiCorp Vault et Google Secret Manager, jamais dans le code.
Ce qui nous manque encore, parce qu'une liste sans manques est une plaquette commerciale :
- Notre réseau privé tient l'administration hors d'Internet, mais il ne restreint pas encore chaque personne à des services précis.
- Nous ne tenons pas encore de journal infalsifiable de chaque appel d'outil fait par un agent IA, avec ses arguments.
- Nous ne sommes certifiés ni SOC 2 ni ISO 27001. Nous répondons aux questionnaires de sécurité point par point, preuves à l'appui.
Les questions à poser pendant le Cybermois
À votre équipe, et à qui développe ou héberge vos logiciels :
- Qui peut exporter toute notre base clients, et quelqu'un serait-il prévenu s'il le faisait ?
- Les droits sont-ils vérifiés à chaque requête, ou seulement à la connexion ?
- Combien de comptes actifs appartiennent à des personnes ou des prestataires partis ?
- Quels tiers ont un accès à nos données, et à quoi exactement ?
- Comment vérifie-t-on une demande de données qui arrive par e-mail, même d'une adresse officielle ?
- Le jour où une fuite est découverte, qui fait quoi dans les 72 heures ? Si personne ne sait, téléchargez le support de la CNIL et de Cybermalveillance.gouv.fr et remplissez-le cette semaine.
Si les deux premières questions restent sans réponse, c'est dans le code qu'il faut regarder, et c'est ce que fait un audit.
À lire aussi : notre page sécurité, la cyberattaque des Hauts-de-France via deux prestataires, les frigos de supermarchés piratés, et comment nous répondons aux questionnaires de sécurité.