Cyberattaque de la DGFiP : 678 000 personnes concernées. Et si on parlait vraiment de sécurité informatique ?
Après la cyberattaque ayant touché la DGFiP, découvrez les principaux risques pour les entreprises et les mesures que Dev-Booster met en place pour renforcer la sécurité des sites et applications web.
Le 14 août 2026, la Direction générale des Finances publiques a confirmé une importante compromission de son système d'information.
678 000 particuliers et professionnels sont concernés.
Parmi les informations consultées ou extraites figurent notamment des données fiscales comme le revenu fiscal de référence, le quotient familial ou le taux de prélèvement à la source, ainsi que certaines informations concernant les entreprises.
Mais ce qui nous intéresse particulièrement en tant que développeurs, c'est la manière dont l'attaque a été réalisée.
D'après la DGFiP, les intrusions intervenues en juin et juillet reposaient notamment sur l'usurpation des identifiants d'un agent de la DGFiP et d'un tiers habilité. Les accès ont finalement été interrompus, mais l'extraction des données n'avait initialement pas été détectée.
Autrement dit :
le problème n'était pas simplement une "faille dans une page web".
Et c'est probablement la première leçon à retenir.
Sécuriser un site internet ne consiste pas uniquement à sécuriser son code
Lorsque nous développons un site, un extranet, une application métier ou une plateforme e-commerce chez Dev-Booster, la sécurité ne s'arrête pas à :
- installer un certificat HTTPS ;
- vérifier les formulaires ;
- protéger une page d'administration.
Un système informatique moderne est une chaîne.
Il y a le site, bien sûr, mais également :
les comptes utilisateurs → les comptes administrateurs → les développeurs → Git → les serveurs → les accès distants → les bases de données → les sauvegardes → les services externes → les e-mails.
Il suffit parfois d'un seul maillon faible.
C'est pour cette raison que nous essayons d'intégrer la sécurité dans l'architecture même des projets, et pas uniquement après leur mise en production.
Voici quelques-unes des règles que nous appliquons ou recommandons sur les infrastructures que nous accompagnons.
1. Un compte par personne
C'est probablement l'une des règles les plus simples.
Et pourtant, les comptes partagés sont encore extrêmement fréquents.
Plutôt que :
marketing@... / motdepasse123
nous privilégions des comptes nominatifs.
Pourquoi ?
Parce que lorsqu'un salarié, un prestataire ou un développeur quitte le projet, ses accès peuvent être supprimés immédiatement.
Avec un compte partagé, personne ne sait réellement :
- qui l'utilise ;
- depuis où ;
- qui connaît encore le mot de passe ;
- quand celui-ci doit être changé.
La gestion des droits devient donc une vraie composante du projet.
2. Généraliser la double authentification
Un mot de passe peut être volé.
Par phishing.
Par réutilisation sur un autre service compromis.
Par un logiciel malveillant.
Ou simplement parce qu'il a été communiqué à la mauvaise personne.
La double authentification ajoute une barrière supplémentaire.
Nous la recommandons notamment sur les éléments les plus sensibles :
messagerie, GitHub, accès aux serveurs, outils d'administration et services cloud.
L'e-mail est particulièrement critique : prendre le contrôle d'une boîte mail permet souvent de réinitialiser les mots de passe de nombreux autres services.
L'ANSSI recommande d'ailleurs l'authentification multifacteur lorsqu'elle est disponible sur les accès sensibles.
3. Ne pas exposer inutilement les serveurs sur Internet
Une règle que nous essayons d'appliquer systématiquement :
Ce qui n'a aucune raison d'être accessible publiquement ne doit pas l'être.
Une interface d'administration serveur ou un accès distant ne devrait pas être exposé simplement parce que cela facilite la connexion.
Selon l'infrastructure, nous privilégions notamment :
- VPN ;
- filtrage réseau ;
- restrictions par adresse IP ;
- authentification renforcée ;
- limitation des services exposés.
Sur une infrastructure Windows, par exemple, un accès RDP directement exposé sur Internet augmente inutilement la surface d'attaque. Le CERT-FR recommande de filtrer ces accès et recommande l'utilisation de VPN pour éviter d'exposer directement les applications sensibles.
4. Appliquer le principe du moindre privilège
Un site internet n'a généralement aucune raison de disposer des droits administrateur sur tout un serveur.
Même chose pour un utilisateur.
Même chose pour une base de données.
Chaque composant doit idéalement disposer uniquement des permissions dont il a réellement besoin.
L'intérêt est simple.
Si un attaquant parvient malgré tout à compromettre une application, nous cherchons à éviter qu'il puisse immédiatement prendre le contrôle de toute l'infrastructure.
Sécuriser, ce n'est donc pas uniquement empêcher l'intrusion.
C'est aussi limiter les conséquences si elle arrive.
5. Mettre à jour les dépendances
De très nombreuses attaques ne nécessitent aucune technique révolutionnaire.
Des robots parcourent continuellement Internet à la recherche :
- de logiciels obsolètes ;
- de plugins vulnérables ;
- de frameworks non corrigés ;
- de services mal configurés.
Nous intégrons donc dans la maintenance de nos projets une surveillance des composants utilisés :
- framework backend ;
- dépendances PHP / .NET / Node ;
- packages frontend ;
- système d'exploitation ;
- serveur web ;
- outils tiers.
Lorsqu'une vulnérabilité importante est publiée, attendre plusieurs mois avant de mettre à jour revient parfois à laisser une porte ouverte dont l'adresse est devenue publique.
6. Les sauvegardes doivent survivre au serveur
C'est un point qui nous semble fondamental.
Une sauvegarde située uniquement sur le serveur qu'elle sauvegarde n'est pas suffisante.
En cas de :
- panne matérielle ;
- erreur humaine ;
- suppression accidentelle ;
- compromission ;
- rançongiciel ;
la sauvegarde peut disparaître en même temps que la production.
Nous privilégions donc, selon les projets, des sauvegardes régulières avec une copie externalisée et plusieurs générations conservées.
La CNIL recommande elle-même de stocker au moins une sauvegarde sur un site distinct et d'isoler au moins une sauvegarde du réseau de l'entreprise.
Mais il reste une règle encore plus importante :
une sauvegarde doit être testée.
Nous devons être capables de répondre à la question :
Si le serveur disparaît maintenant, pouvons-nous réellement reconstruire le système ?
7. Collecter le moins de données possible
C'est une règle de sécurité particulièrement efficace :
une donnée que vous ne possédez pas ne peut pas vous être volée.
Lors de la création d'un formulaire, nous nous demandons donc quelles informations sont réellement nécessaires.
Un formulaire d'inscription à une newsletter a-t-il besoin :
- du téléphone ?
- de la date de naissance ?
- de l'adresse complète ?
- du nom de l'entreprise ?
Pas forcément.
La même logique concerne la conservation.
Des candidatures, leads, fichiers importés ou historiques qui n'ont plus aucune utilité ne devraient pas rester indéfiniment dans une base simplement "au cas où".
Nous pouvons donc intégrer directement dans les applications des mécanismes automatiques de purge ou d'anonymisation.
C'est bon pour le RGPD.
Et c'est également bon pour la cybersécurité.
8. Savoir précisément où se trouvent les données
Une application moderne utilise rarement un seul serveur.
Les données peuvent être présentes :
- dans notre base de données ;
- chez un fournisseur d'e-mailing ;
- dans un CRM ;
- dans un outil de recrutement ;
- dans un système de statistiques ;
- dans un stockage cloud ;
- dans les sauvegardes.
Lorsqu'un incident survient, découvrir à ce moment-là l'emplacement des données fait perdre un temps précieux.
Cartographier les flux et les prestataires permet de savoir rapidement :
quelles données sont concernées, où elles sont stockées et qui peut y accéder.
9. Les journaux doivent servir à détecter quelque chose
Stocker des logs pendant plusieurs mois sans jamais les consulter n'apporte qu'une protection limitée.
Nous cherchons donc à identifier les événements qui méritent réellement une surveillance :
- échecs répétés de connexion ;
- connexion administrative inhabituelle ;
- modification des droits ;
- comportement anormal d'une API ;
- volume inhabituel de requêtes ;
- erreurs serveur répétées.
Le cas de la DGFiP est particulièrement intéressant sur ce point.
L'administration avait identifié et interrompu certains accès, mais les premiers contrôles n'avaient pas permis de constater l'extraction de données. Ce n'est qu'après de nouvelles investigations que son ampleur a été établie.
Détecter une connexion suspecte est une chose. Comprendre ce qu'elle a permis de faire en est une autre.
10. Préparer l'incident avant qu'il n'arrive
Aucune entreprise sérieuse ne devrait promettre :
"Nous ne serons jamais piratés."
Même les infrastructures disposant d'importants moyens peuvent être compromises.
Notre objectif doit donc être double :
réduire au maximum la probabilité d'une attaque ET réduire au maximum ses conséquences.
Cela passe aussi par un petit plan d'incident :
- Qui doit être contacté ?
- Quels accès devons-nous révoquer ?
- Quels systèmes devons-nous isoler ?
- Où se trouvent les sauvegardes ?
- Quels journaux devons-nous conserver ?
- Quelles données sont potentiellement concernées ?
- Quels clients ou utilisateurs devons-nous prévenir ?
Et lorsqu'une violation de données personnelles présente un risque pour les droits et libertés des personnes concernées, le RGPD prévoit une notification à la CNIL dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance.
Au milieu d'une attaque, 72 heures passent extrêmement vite.
Préparer la procédure à l'avance change complètement la manière de gérer la crise.
La cybersécurité est rarement une fonctionnalité visible
Un client ne verra probablement jamais :
- la politique de sauvegarde ;
- les permissions du compte exécutant son application ;
- les restrictions réseau ;
- les mécanismes de purge ;
- les alertes sur les connexions ;
- la politique de gestion des accès.
Et tant mieux.
Cela signifie souvent que tout fonctionne.
Mais pour nous, ces éléments font autant partie d'un projet informatique que l'interface visible par les utilisateurs.
Chez Dev-Booster, nous développons des sites internet, logiciels, applications métier et plateformes sur mesure.
Notre rôle n'est pas uniquement de faire fonctionner une application aujourd'hui.
Nous devons aussi réfléchir à :
comment elle sera maintenue, comment elle sera sauvegardée, qui pourra y accéder et comment elle réagira lorsqu'un problème surviendra.
L'affaire de la DGFiP nous rappelle finalement quelque chose d'assez simple :
La sécurité d'un système ne dépend pas uniquement de la qualité de son code. Elle dépend de toute la chaîne qui l'entoure.
Et cette chaîne doit être pensée dès le début du projet.
Vous avez un site internet ou une application métier existante et vous ne savez pas réellement comment sont gérés les accès, les sauvegardes, les mises à jour ou les données personnelles ?
Dev-Booster peut vous accompagner pour faire le point sur votre architecture et identifier les améliorations prioritaires à apporter.