Rapport d’incident DGFiP de l’ANSSI : quels enseignements pour la pratique contractuelle ?
Le 29 septembre 2026, l'Agence nationale de la sécurité des systèmes d'information (ANSSI) a rendu public son rapport d'incident consacré aux actes malveillants observés sur le système d'information de la Direction générale des Finances publiques (DGFiP) entre mai et août 20261. Établi à la demande du Premier ministre2, ce document retrace la chaîne de compromission, analyse les défaillances constatées et formule des mesures de remédiation.
La démarche est inédite. Le directeur général de l'ANSSI l'a lui-même rapprochée des rapports que le Bureau d'enquêtes et d'analyses publie à la suite des accidents aériens.3
Chronologie d'un incident au long cours
Le rapport décrit deux incidents distincts, revendiqués par le même acteur à un jour d'intervalle :
- Le 12 août 2026, l'attaquant a revendiqué le vol de données issues d'un outil de gestion de la relation avec les usagers de la DGFiP, concernant près de 353 000 particuliers et 252 000 professionnels. Les investigations ont établi que l'exfiltration était intervenue sept semaines plus tôt, au terme de plusieurs semaines d'exploration. L'attaquant s'était appuyé sur plusieurs dizaines d'identifiants d'agents dérobés, vraisemblablement au moyen de logiciels espions installés sur des ordinateurs non administrés par la DGFiP, ainsi que sur la compromission d'un autre ministère, qui lui avait ouvert l'accès au Réseau interministériel de l'État.
- Le 13 août 2026, une seconde revendication a visé les données cadastrales. La compromission du poste d'un géomètre-expert exerçant en cabinet privé a permis de contourner la double authentification par messagerie, puis d'accéder aux données et de les exfiltrer entre le 27 juillet et le 8 août 2026.
Aucune de ces exfiltrations n'a été détectée, ni par les moyens de supervision de la DGFiP, ni par ceux de l'ANSSI. L'Agence conclut que la compromission ne résulte pas d'une attaque sophistiquée, mais de l'exploitation de faiblesses touchant les domaines de l'identité, de l'architecture et de la détection.
Un rapport inédit, riche d'enseignements pour encadrer contractuellement les risques cyber
Ce rapport constitue une véritable mine d'informations pour les acteurs de la cybersécurité, mais également pour les juristes. Les enseignements à en tirer sont nombreux pour les praticiens du droit du numérique, de la protection des données et de la cybersécurité, en particulier s’agissant de la rédaction et négociations de contrats informatiques. Sans prétendre à l'exhaustivité, on relèvera notamment :
La notion d’« état de l’art ». Régulièrement invoquée dans les contrats comme référence, cette notion pouvait déjà s'appuyer sur un socle solide : le Référentiel Cyber France (ReCyF), publié par l'ANSSI en mars 2026, ainsi que les guides et fiches pratiques de l'Agence. Le rapport vient compléter cette base déjà riche en lui donnant un contenu tangible, éprouvé sur un cas réel. Idem pour l'« état des connaissances » que la directive NIS 24 impose de prendre en compte pour définir les mesures de gestion des risques de cybersécurité5. En cas de contentieux, ce rapport pourrait servir d’illustration pratique de ce qui constitue des mesures de sécurité « conformes à l’état de l’art ». Ainsi, le rapport juge insuffisant un code à usage unique adressé par courriel et recommande une authentification multi facteur résistante au vol du premier facteur6. Cela éclaire aussi les « mesures techniques et organisationnelles appropriées » au sens du RGPD7. Juristes, DPO et RSSI seront donc tentés de relire les modèles d’annexes sécurité et autres plans d’assurance sécurité afin de s’assurer qu’ils sont conformes aux recommandations formulées par l’ANSSI dans son rapport.
Le point de départ des délais de notification. L'exfiltration de données n'a été connue que par la revendication de l'attaquant, sept semaines après les faits. Or, les délais prévus par le RGPD8 et par NIS 29 courent à compter de la prise de connaissance de l'incident. Tant que l'incident n'est pas connu, aucun délai ne court. En revanche, une détection tardive pourrait constituer un manquement contractuel à l'obligation de sécurité pouvant peser sur le prestataire. Une bonne pratique contractuelle consisterait donc à conserver le principe selon lequel le point de départ du délai de notification reste la connaissance de l’incident, tout en encadrant plus précisément les obligations de détection des incidents. Le prestataire cherchera alors à limiter son engagement de détection à une simple obligation de moyens, tandis que le client aura intérêt à lister précisément les mesures de détection que le prestataire doit mettre en place.
La définition des rôles. Le rapport rappelle aussi qu'une compromission emprunte rarement un seul maillon : postes non administrés, poste d'un partenaire, réseau d'un autre ministère. Lorsque les systèmes d'information reposent sur de multiples intervenants (équipes internes, prestataires externes, freelance, agents IA, logiciels de détection…), la responsabilité de chacun doit être cadrée contractuellement en fonction de son rôle réel, et non de son seul statut. D'où l'importance de décrire précisément les prestations (périmètre technique, niveau de supervision, conservation des traces) et de formaliser dans une matrice RACI qui est responsable, qui répond en dernier ressort, qui est consulté et qui est informé pour chaque activité de sécurité : détection, réponse à incident, suspension, notification.
La responsabilité en cas d’incident. Dans l'affaire DGFiP, l'intervention de tiers n'atténue pas la responsabilité de l'administration, détentrice des données : le client reste responsable de la sécurité des données qu'il traite. Il faut donc se méfier des clauses qui transfèrent cette responsabilité au prestataire, jusqu'à lui faire garantir le client de toutes les conséquences d'un incident : le prestataire, qui ne maîtrise pas l'ensemble de la chaîne, se retrouverait sous une épée de Damoclès, que seuls un plafond de responsabilité, des exclusions et une répartition claire des rôles permettent de désamorcer.
Parmi ces enseignements, l'un mérite particulièrement l'attention des praticiens des contrats informatiques : la suspension.
La suspension, une mesure d'endiguement aux effets dommageables
Pour mettre fin à l'attaque, la DGFiP a coupé les accès de ses agents et de ses partenaires aux portails ayant permis les exfiltrations. Le rapport souligne que ces mesures ont entraîné des « impacts significatifs » sur les services de la DGFiP et sur ceux d'entités partenaires.
Certaines coupures sont désormais définitives pour les agents. D'autres affectent des professionnels extérieurs : le portail par lequel notaires et géomètres-experts accèdent aux données cadastrales est fermé depuis la mi-août, et sa réouverture n'était envisagée, fin septembre, qu'à la mi-octobre, sous réserve d'un renforcement de l'authentification.
Cet épisode met en lumière deux formes de suspension, dont les enjeux contractuels diffèrent sensiblement : la suspension des comptes utilisateurs compromis et la suspension du service lui-même.
La suspension des comptes compromis, une obligation du gestionnaire du système. La suspension des comptes compromis relève de la responsabilité de celui qui administre le système d'information. Elle participe directement des mesures qui lui incombent pour limiter les risques, et le rapport montre les conséquences d'une exécution imparfaite.
Ainsi, le 24 juin 2026, le mot de passe du compte utilisé par l'attaquant a été réinitialisé en cours de matinée, sans que la session ouverte soit interrompue : l'exfiltration s'est poursuivie jusqu'au lendemain. L'ANSSI recommande en conséquence d'assortir toute réinitialisation de la révocation des sessions actives sur l'ensemble des applications, ainsi que d'une analyse de l'activité du compte depuis la date présumée de sa compromission.
Lorsque cette gestion est externalisée, auprès d'un infogérant, d'un centre opérationnel de sécurité ou d'un fournisseur de solution de gestion des identités, il importe de répercuter précisément cette obligation dans le contrat : conditions de déclenchement, délais d'intervention, périmètre des mesures et compte rendu au client. À la lumière du rapport, une simple obligation de « réinitialiser les mots de passe » apparaît manifestement insuffisante.
La suspension du service en cas d’incident, une mesure protectrice à condition d'être proportionnée. La suspension du service pour motif de sécurité constitue, à l'inverse, une prérogative du prestataire. Moins familière que la suspension pour défaut de paiement, qui n’est que la traduction de l’exception d’inexécution, elle est fréquemment discutée par les clients, qui y voient un pouvoir unilatéral d'interrompre une prestation dont ils dépendent.
Pourtant, l'affaire DGFiP montre qu'une suspension rapide peut justement servir à protéger le client lui-même : tant que l'accès demeurait ouvert, chaque utilisateur, et partant chaque jeu de données, restait exposé. Elle en illustre aussi le revers. Selon la nature du service interrompu, une suspension peut affecter gravement l'activité de ceux qui en subissent les effets.
La question est d’autant plus sensible dans les services cloud, où la suspension pour motif de sécurité par le fournisseur est une stipulation courante. Pour des workloads critiques, chaque minute d'indisponibilité est susceptible de causer au client un préjudice important.
Le prestataire a donc intérêt à faire preuve de prudence au moment de désactiver des comptes ou des services, et à se doter de procédures de réactivation garantissant le caractère temporaire de la mesure. Le client veillera, pour sa part, à obtenir l'engagement contractuel du prestataire de lever la suspension dès la clôture de l'incident.
Encadrer contractuellement la suspension : les principaux points de négociation
Une clause de suspension pour motif de sécurité gagne à régler précisément les questions suivantes.
- Le motif de déclenchement. La suspension peut-elle intervenir sur une simple suspicion d'incident de sécurité, ou seulement en présence d'une menace avérée ? Le seuil retenu conditionne la proportionnalité du droit de suspension.
- L'information du client. Le client peut demander à être informé avant toute suspension, afin de pouvoir mettre en œuvre des mesures de remédiation susceptibles de l'éviter. Une exception sera naturellement réservée aux situations d'urgence.
- Le périmètre. Le prestataire peut s'engager à limiter la suspension à ce qui est strictement nécessaire : la seule portion compromise du service plutôt que l'ensemble des services, les seuls comptes concernés plutôt que l'ensemble des utilisateurs.
- Le prix. Le sort de la rémunération pendant la suspension doit être expressément réglé pour éviter toute déconvenue : maintien, réduction ou interruption du paiement. La question ne se pose pas en cas de paiement à la consommation, mais n’est pas simple en cas de prépaiement d’instances réservées qui sont alors inaccessibles pour le client, mais pourtant provisionnées par le fournisseur.
- La solution de repli. Il convient en outre de vérifier si le prestataire est en mesure de fournir une solution alternative pendant la suspension, ou, a minima, de permettre au client d’accéder à ses données par une solution de contournement. Une telle solution peut d'ailleurs justifier le maintien de la facturation.
- La durée. Côté client, on veille à ce que la période de suspension soit limitée dans le temps, avec une obligation pour le prestataire d’agir avec diligence pour mettre fin à la suspension dans les meilleurs délais, et au plus tard dès la clôture de l'incident ou dans un délai fixé.
- Les niveaux de service. Le prestataire veillera, de son côté, à ce que ses engagements de niveaux de service et les pénalités associées soient neutralisés pendant la durée de la suspension.
- La responsabilité. Demeure la question du dommage causé par la suspension elle-même. Prenons l’exemple d’un site de vente à distance dont les comptes seraient suspendus pendant plusieurs heures en pleine période de forte activité : la perte de chiffre d'affaires peut être considérable. Le contrat doit déterminer si, et dans quelle mesure, le prestataire en répond, notamment lorsque la suspension se révèle injustifiée ou disproportionnée.
Au-delà de la qualité de la gestion opérationnelle de l'incident, le contrat constitue alors un repère pour les parties, au moment précis où les décisions doivent être prises dans l'urgence.
Le cas des secteurs régulés
Dans les secteurs soumis à une réglementation spécifique, la clause de suspension doit en outre s'articuler avec les obligations propres au client.
- Le secteur financier (DORA). Le règlement DORA10 ne régit pas, en tant que telle, la faculté de suspension du prestataire de services TIC : il ne l'impose ni ne l'interdit expressément. Il exige en revanche que le contrat prévoie l'assistance du prestataire en cas d'incident lié au service11 et, pour les fonctions critiques ou importantes, des délais de préavis, des obligations d'information et la mise en place et le test de plans d'urgence12. Une suspension décidée sans information préalable s'accorde mal avec ces exigences. La clause doit donc être conçue en cohérence avec ces stipulations obligatoires et avec la stratégie de continuité de l'entité financière.
- Les entités essentielles et importantes (NIS2). La directive NIS 2 impose des mesures de gestion des risques couvrant notamment la gestion des incidents, la continuité des activités et la sécurité de la chaîne d'approvisionnement13. La suspension par un prestataire d'un service dont dépend l'entité peut tout à la fois constituer une mesure de traitement de l'incident et compromettre la continuité dont celle-ci doit répondre. L'entité a donc intérêt à en maîtriser les conditions et à s'assurer de recevoir l'information nécessaire au respect de ses propres obligations de notification14.
- L'hébergement de données de santé (HDS). Le contrat conclu avec l'hébergeur certifié doit comporter les mentions prévues par l'article R. 1111-11 du code de la santé publique, notamment des indicateurs de qualité et de performance. Une suspension affectant l'accès aux données de santé peut avoir des conséquences directes sur la prise en charge des patients. Elle appelle un encadrement particulièrement strict, articulé avec les engagements de disponibilité de l'hébergeur.
Ce rapport mérite une lecture attentive bien au-delà des seules équipes techniques. Il rappelle que la suspension, souvent perçue comme une prérogative du prestataire, peut constituer un instrument de protection du client, pour autant qu'elle demeure proportionnée et que ses modalités soient précisément définies.
Pour échanger sur ces questions, n'hésitez pas à nous contacter (de préférence depuis un poste sécurisé et avec une authentification forte).
1 ANSSI, Rapport d’incident n° 3033/ANSSI/SDO/NP du 23 septembre 2026, « Actes malveillants observés sur le système d’information de la Direction générale des Finances publiques entre mai 2026 et août 2026 », disponible sur le site de l’ANSSI : https://cyber.gouv.fr/documents/821/20260923_NP_TLPCLEAR_ANSSI_Rapport_incident_DGFIP.pdf
2 Vincent Strubel, directeur général de l’ANSSI, publication sur LinkedIn du 29 septembre 2026.
3 Vincent Strubel, publication LinkedIn du 29 septembre 2026, préc.
4 Directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’ensemble de l’Union (directive « NIS 2 »), dont la transposition en droit français se fait toujours attendre à la date d’écriture de cet article.
5 NIS 2 (préc.) article 21, paragraphe 1.
6 L’authentification multifacteur est exigée par l’article 21, paragraphe 2, point j), de NIS 2, préc., applicable aux entités essentielles et importantes.
7 Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 (« RGPD »).
8 RGPD, article 33 (notification à l’autorité de contrôle ; au paragraphe 2, information du responsable du traitement par le sous-traitant) et article 34 (communication aux personnes concernées).
9 NIS 2, article 23, paragraphe 4 (alerte précoce, notification d’incident et rapport final).
10 Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (« DORA »).
11 DORA, préc., article 30, paragraphe 2.
12 DORA, préc., article 30, paragraphe 3.
13 NIS 2, préc., article 21, paragraphe 2, points b), c) et d).
14 NIS 2, préc., article 23.
.png)
