Fuite de données aux impôts : ce que les entreprises doivent retenir pour sécuriser leurs applications

Fuite de données aux impôts : ce que les PME doivent retenir pour sécuriser leurs applications

Les intrusions ont eu lieu en juin et juillet. Elles reposaient notamment sur l’usurpation d’identifiants appartenant à un agent de la DGFiP et à un tiers habilité.

Les investigations ont ensuite montré que certaines données avaient été consultées et extraites. Au total, 678 000 particuliers et professionnels sont concernés à ce stade. Parmi les informations touchées figurent notamment le revenu fiscal de référence, le quotient familial, le taux de prélèvement à la source et certaines données concernant les entreprises.

Précision importante : selon le ministère, les espaces personnels des usagers n’ont pas été compromis. Les identifiants et mots de passe des particuliers et professionnels ne l’ont pas été non plus.

L’incident reste malgré tout un très bon rappel.

Une fuite de données ne commence pas toujours par un pirate qui trouve une énorme faille dans un site web.

Elle peut commencer par un compte compromis.

Un accès trop large.

Un outil interne mal surveillé.

Une API exposée.

Une clé stockée au mauvais endroit.

Ou une application qui fonctionne parfaitement depuis des années, mais dont personne n’a vraiment réévalué la sécurité.

Et ce problème ne concerne pas seulement l’État.

Pour une PME qui développe aujourd’hui une application métier, un portail client ou un SaaS, la question de la sécurité des applications doit arriver beaucoup plus tôt dans le projet.

Une fuite de données ne signifie pas forcément que toute l’application a été piratée

Quand on lit qu’une organisation a été "hackée", l’image est souvent la même.

On imagine une personne qui découvre une faille technique, entre dans le serveur et télécharge toute la base de données.

Dans la réalité, les scénarios sont souvent plus subtils.

Dans le cas de la DGFiP, le ministère évoque notamment des usurpations d’identifiants. Les comptes utilisés lors des intrusions ont bien été bloqués après leur détection. Mais les premiers contrôles n’ont pas permis d’identifier les extractions de données qui avaient déjà eu lieu.

C’est un point essentiel pour comprendre la sécurité des applications.

Sécuriser une application ne consiste pas uniquement à empêcher quelqu’un de se connecter.

Il faut aussi limiter ce qu’un utilisateur connecté peut faire.

Il faut savoir quelles données il peut consulter.

Il faut pouvoir détecter un comportement inhabituel.

Et il faut conserver suffisamment de traces pour comprendre ce qui s’est passé après un incident.

OWASP, l’une des principales références en matière de sécurité applicative, place d’ailleurs l’authentification, le contrôle d’accès, la protection des données et la journalisation parmi les grands blocs à vérifier lors de la sécurisation d’une application web.

Autrement dit, avoir un écran de connexion avec un mot de passe solide n’est que le début.

Plus une application devient utile, plus elle devient sensible

C’est un phénomène que nous rencontrons souvent sur les applications métier.

Une entreprise crée d’abord un petit outil.

Il sert à suivre quelques clients, gérer un planning, centraliser des demandes ou remplacer un fichier Excel.

Au départ, le périmètre est limité.

Puis l’outil fonctionne bien.

Les équipes l’adoptent.

On lui ajoute des utilisateurs.

Puis des documents.

Puis des données commerciales.

Puis une connexion au CRM.

Puis de la facturation.

Puis une API.

Puis une automatisation Make ou n8n.

Puis éventuellement une couche d’IA.

Six mois plus tard, le petit outil interne est devenu une pièce importante du système d’information.

La valeur de l’application a augmenté.

Mais son niveau de sécurité initial est parfois resté le même.

C’est particulièrement fréquent avec les prototypes, les applications no-code et les applications générées rapidement avec de l’IA. Ces technologies ne sont pas le problème en elles-mêmes. Le problème apparaît lorsqu’un outil conçu pour tester une idée passe en production sans revoir son architecture.

Nous en parlons notamment dans notre guide sur la manière de reprendre le contrôle d’une application Lovable. Une application en production ne se résume pas à son interface. Il faut regarder la base de données, l’authentification, le stockage, les rôles, les secrets, les fonctions backend, les webhooks, les sauvegardes et les accès administrateur.

La différence entre un prototype et une vraie application métier se joue aussi là.

La sécurité d’une application commence par les droits d’accès

Prenons un exemple très simple.

Votre entreprise possède un back-office utilisé par 40 personnes.

Un commercial doit voir ses comptes clients.

Un responsable commercial doit voir les comptes de son équipe.

La direction peut avoir accès à l’ensemble du portefeuille.

L’administrateur technique, lui, doit pouvoir gérer les utilisateurs sans forcément accéder à toutes les données métier.

Si tout le monde possède le même niveau d’accès, l’application fonctionne.

Mais elle est mal conçue.

Une bonne architecture applique le principe du moindre privilège : chaque utilisateur obtient uniquement les droits nécessaires pour réaliser son travail.

C’est ce qui limite l’impact d’un compte compromis.

Si un pirate récupère les accès d’un utilisateur standard, il ne devrait pas obtenir automatiquement un accès à l’ensemble de la base.

C’est pour cette raison que nous intégrons les rôles, permissions et règles d’accès dès la conception de nos applications métier sur mesure.

Sur une architecture basée par exemple sur PostgreSQL et Supabase, cela peut aussi passer par des politiques de sécurité appliquées directement au niveau des données.

L’idée reste la même quelle que soit la stack : ne jamais considérer qu’un utilisateur authentifié a le droit de tout voir.

L’authentification forte ne règle pas tout, mais elle change beaucoup de choses

L’usurpation d’identifiants est un scénario classique.

Un mot de passe peut être récupéré par phishing, réutilisé après une précédente fuite ou transmis de manière imprudente.

C’est pour cela que les applications sensibles gagnent à ajouter plusieurs niveaux de protection.

Une authentification multifacteur peut réduire le risque lié à un simple vol de mot de passe.

Les sessions peuvent avoir une durée adaptée au niveau de sensibilité.

Les comptes administrateurs peuvent suivre des règles plus strictes.

Les accès techniques peuvent être séparés des comptes humains.

Les droits d’un collaborateur peuvent être retirés rapidement lorsqu’il change de poste ou quitte l’entreprise.

Le sujet n’est donc pas seulement : "Avons-nous un login ?"

La bonne question est : "Que se passe-t-il si ce login tombe entre de mauvaises mains ?"

C’est une manière beaucoup plus utile de penser la cybersécurité d’une PME.

Une application doit aussi être capable de raconter ce qui s’est passé

Une application sécurisée doit produire des traces utiles.

Qui s’est connecté ?

Depuis quel compte ?

Quelles actions sensibles ont été réalisées ?

Quel utilisateur a changé des permissions ?

Combien de données ont été consultées ?

Un comportement sort-il totalement de l’usage habituel du compte ?

Une application qui ne journalise rien peut laisser passer un incident sans donner les moyens de le comprendre.

À l’inverse, il faut éviter de transformer les logs en deuxième base de données sensible.

OWASP recommande notamment de journaliser les événements de sécurité et certaines opérations d’authentification ou d’autorisation, tout en évitant d’enregistrer inutilement des informations confidentielles dans les journaux.

Le monitoring sert ensuite à rendre ces traces exploitables.

Un compte qui consulte 30 fiches clients dans une journée peut avoir un comportement normal.

Le même compte qui en consulte 40 000 en quelques minutes mérite probablement une alerte.

La sécurité ne doit donc pas seulement bloquer.

Elle doit aussi observer.

Les clés API et les secrets sont devenus un vrai sujet

Les applications modernes communiquent avec énormément de services.

Stripe.

OpenAI.

Un CRM.

Un outil d’e-mail.

Une API métier.

Un stockage cloud.

Un service de signature.

Chaque intégration ajoute souvent une clé API, un token ou un secret.

Et ces secrets donnent parfois accès à des fonctions très puissantes.

Les laisser directement dans le code, dans un dépôt Git ou dans un fichier partagé est donc une très mauvaise idée.

OWASP recommande l’utilisation d’une solution dédiée à la gestion des secrets et précise que ces derniers ne doivent pas être intégrés directement au code source ou aux artefacts de build.

C’est encore plus important avec la multiplication des automatisations et des outils IA.

Une application métier n’est plus un bloc isolé.

Elle est souvent au centre de dix autres services.

La sécurité d’une application dépend donc aussi de la sécurité de toutes ses connexions.

Développement rapide ne doit pas vouloir dire production improvisée

L’IA a énormément accéléré le développement.

Il est aujourd’hui possible de générer une interface en quelques minutes et d’obtenir une première application fonctionnelle en quelques jours.

C’est une excellente évolution.

Mais elle crée aussi un risque : confondre vitesse de développement et maturité de production.

Un prototype peut fonctionner avec peu de contrôle.

Une application utilisée chaque jour par 100 salariés ne peut plus suivre les mêmes règles.

À partir du moment où l’outil contient des données clients, des informations RH, des contrats, des données financières ou des documents confidentiels, il faut changer de niveau d’exigence.

C’est aussi pour cela que notre approche du développement d’applications sur mesure prévoit un cadrage des contraintes de sécurité et de RGPD, puis des tests et un audit de sécurité avant la mise en production.

L’objectif n’est pas de transformer chaque PME en banque.

L’objectif est d’adapter la sécurité au risque réel.

Le vieux logiciel interne mérite lui aussi votre attention

Il serait facile de croire que le problème concerne seulement les nouvelles applications créées trop vite.

C’est faux.

L’autre zone de risque se trouve souvent dans des outils anciens.

Une application PHP développée il y a quinze ans.

Un ERP très personnalisé.

Une vieille base Access.

Un serveur que personne ne veut redémarrer.

Un logiciel métier dont le développeur historique est parti.

Ces systèmes peuvent contenir certaines des données les plus importantes de l’entreprise.

Ils ont aussi parfois été conçus à une époque où les usages étaient très différents.

Moins de télétravail.

Moins d’API.

Moins de connexions avec des services externes.

Moins de données accessibles depuis Internet.

Maintenir ces outils sans jamais réévaluer leur architecture peut devenir un problème.

La réponse n’est pas forcément de tout jeter.

Une modernisation progressive du SI legacy peut permettre de reprendre le contrôle sans interrompre l’activité.

Où sont vraiment les données de votre entreprise ?

La sécurité des applications pose enfin une question très simple : savez-vous précisément où passent vos données ?

Beaucoup de PME utilisent aujourd’hui un empilement de services.

L’application envoie une donnée vers une automatisation.

L’automatisation l’envoie vers un CRM.

Le CRM déclenche un e-mail.

Une partie du contenu passe ensuite dans une API d’IA.

Un document est stocké ailleurs.

Chaque outil pris séparément peut sembler maîtrisé.

Mais l’ensemble devient plus difficile à suivre.

C’est pourquoi la souveraineté numérique des PME est aussi un sujet de sécurité.

Il ne s’agit pas forcément de tout héberger soi-même.

Il s’agit de savoir quelles briques sont critiques, où résident les données, quels prestataires peuvent y accéder et comment récupérer l’ensemble si une plateforme devient inadaptée.

Une entreprise qui ne connaît pas son architecture numérique aura beaucoup plus de mal à évaluer son exposition réelle.

Le RGPD intervient aussi après l’incident

Une fuite de données n’est pas uniquement un problème technique.

Lorsqu’une violation de données personnelles présente un risque pour les droits et libertés des personnes, le responsable du traitement doit la documenter et la notifier à l’autorité compétente dans les meilleurs délais, avec un délai maximal de 72 heures après en avoir pris connaissance lorsque les conditions du RGPD sont réunies.

Lorsque le risque est élevé, les personnes concernées doivent également être informées, sauf exceptions prévues par le règlement.

Cela change aussi la manière de concevoir une application.

Après un incident, l’entreprise doit être capable de comprendre ce qui a été touché.

Quelles données ?

Quels utilisateurs ?

Pendant combien de temps ?

Par quel accès ?

Avec quelles conséquences possibles ?

Sans logs, sans cartographie des données et sans architecture claire, répondre à ces questions devient vite très compliqué.

Ce que l’affaire des impôts doit vraiment rappeler aux entreprises

L’incident de la DGFiP fera probablement encore parler de lui à mesure que les investigations avancent.

Mais pour les entreprises, le principal enseignement est déjà là.

La cybersécurité n’est pas seulement une affaire de pare-feu ou de mots de passe.

C’est une propriété globale de l’application.

Elle dépend de son architecture, de ses rôles, de ses accès, de sa base de données, de ses API, de ses secrets, de ses logs et de la façon dont elle est maintenue.

Et surtout, la sécurité doit évoluer avec l’application.

L’outil interne presque vide créé il y a deux ans n’est peut-être plus un petit outil aujourd’hui.

Il gère peut-être vos clients.

Vos opérations.

Vos documents.

Votre facturation.

Ou une partie de votre savoir-faire.

À ce niveau, continuer à le traiter comme un prototype devient risqué.

Une application robuste se construit aussi sur ces choix

Chez Scroll, nous développons et reprenons des applications métier, des SaaS et des outils internes.

La vitesse reste importante.

Nous utilisons l’IA et des stacks modernes justement pour avancer plus vite.

Mais une application destinée à la production doit aussi rester maîtrisable.

Cela passe par une architecture claire, des permissions adaptées, une gestion sérieuse des accès et des secrets, des environnements séparés, des sauvegardes, des tests et une vraie réflexion sur les données sensibles.

Le but n’est pas de rendre chaque projet plus lourd.

C’est d’éviter qu’un outil devenu critique repose encore sur les choix faits lorsqu’il n’était qu’un prototype.

Si vous avez une application interne, un SaaS ou un outil no-code devenu central dans votre activité, Scroll peut auditer l’existant et concevoir une application sur mesure avec un niveau de sécurité adapté à vos données et à vos usages.