Fuite DGFIP : le malentendu français qui fragilise notre cybersécurité

Forward Global

La fuite massive de données subie par la DGFIP cet été met en exergue une exception française : nous avons un vrai problème avec la notion de responsabilité.

La langue française est généralement précise. Il est pourtant un mot qu'elle emploie avec une étonnante imprécision : "responsabilité".

Le terme confond trois choses :

  • La responsabilité technique ("faire"), c’est-à-dire le fait d’être responsable de l’exécution opérationnelle de certaines actions. Cette responsabilité peut être partagée et déléguée. Sa conséquence peut être un recadrage par la hiérarchie et/ou une mauvaise notation en matière de performance.
  • L’accountability ("arbitrer et décider"), que certains ont traduit en français par la notion de redevabilité. L’acteur accountable détient le pouvoir décisionnel d’autoriser, d’arbitrer ou d’interrompre une action, ce qui lui impose, en retour, de justifier a posteriori la pertinence de sa conduite. Elle ne souffre d’aucun partage et repose sur une tête unique, faute de quoi elle conduit à une dilution des responsabilités. Ses conséquences peuvent être un blâme ou une révocation.
  • La liability ("répondre juridiquement"), enfin, qui relève de la responsabilité juridique et assurantielle. Elle désigne l’obligation légale de répondre des conséquences d’un fait dommageable ou d’un manquement à une réglementation, avec à la clé l’éventualité de sanctions pécuniaires, des dommages-intérêts civils ou des peines pénales.

La meilleure preuve de ce malentendu est la difficulté avec laquelle nous remplissons généralement les fameux tableaux RACI (Responsible, Accountable, Consulted, Informed).

Cette exception française a, semble-t-il, des explications profondes. Selon le sociologue Philippe d’Iribarne, dans La Logique de l’honneur (1989), elle s’explique notamment par le fait que le modèle anglo-saxon s’appuie sur une logique transactionnelle explicite : les responsabilités, les critères d’évaluation et les métriques sont convenus par accord contractuel, la transparence documentaire et le contrôle périodique étant perçus comme des composantes neutres et indispensables du rapport de travail.

Selon lui, la culture organisationnelle française, en revanche, est un héritage de l’Ancien Régime, où l’autorité et l’action s’ordonnent autour des prérogatives et des devoirs propres à chaque rang. Le professionnel est donc supposé agir avec rigueur, dans le respect des règles de l’art de son métier, et supporte mal les vérifications systématiques et la traçabilité des actions, vécues comme une forme d’inquisition hiérarchique blessante, voire comme une présomption de défiance inadmissible à l’égard de son "corps". L’expert, parce qu’il est spécialiste, n’aurait donc plus besoin de se "justifier".

Cette culture est malheureusement à l’origine de bien des malentendus. 

Premier malentendu : en cas d’incident, nous recherchons systématiquement la faute individuelle et l’imputabilité juridique. Cela alimente une rétention des alertes au sein des équipes techniques, par crainte de sanctions hiérarchiques ou de mesures disciplinaires, et ralentit encore la vitesse de réaction face à l’assaillant.

À l’inverse, l’accountability à l’anglo-saxonne — avec notamment le principe du blameless postmortem — doit sanctuariser un espace d’apprentissage au bénéfice des "responsables" sur le plan opérationnel, tout en maintenant une exigence d’imputabilité pour les directeurs exécutifs (accountable), qui répondent de la robustesse des systèmes devant les organes de gouvernance et les tiers.

Bref, on cherche à virer tout de suite, souvent des fusibles, c’est-à-dire des "responsables" et non des accountables.

Bien sûr, cela soulage et flatte les bas instincts d’une opinion publique qui aime bien avoir quelques têtes à balader au bout de ses fourches. Mais cela ne sert à rien, voire est totalement contre-productif : cette pratique renforce le fait que tout contrôle et toute vérification sont perçus comme des signes de défiance et se heurtent à l’esprit de corps évoqué par Philippe d’Iribarne. Par ailleurs, on se satisfait trop souvent des sanctions, au détriment de la mise en œuvre d’un plan d’amélioration sérieux.

L’investigation doit donc écarter la désignation immédiate d’un coupable au profit d’un effort d’audit visant à identifier les causes racines organisationnelles et à renforcer la résilience du système. 

Deuxième conséquence : les exigences de conformité sont traitées sous un angle formel (check the box). Les entreprises formalisent des politiques théoriques, remplissent des formulaires, cochent des cases afin de s’exonérer de toute responsabilité en cas de problème. Et à l’ère de l’intelligence artificielle, cette pratique peut même être industrialisée avec des IA qui répondent à d’autres IA…

À cette conformité statique et purement déclarative, l’approche anglo-saxonne préfère une vision dynamique, fondée sur une démonstration continue de la maîtrise des risques. L’auditabilité ne sanctionne pas la présence ou l’absence d’un classeur documentaire, mais la capacité d’une gouvernance à administrer la preuve de l’efficacité opérationnelle de ses contrôles. L’affaire SolarWinds, aux États-Unis, en est une bonne illustration : la détention de certifications ou la rédaction de déclarations publiques n’a conféré aucune immunité.

Troisième conséquence : cette approche de conformité passive doit céder la place à un dispositif d’analyse continue. Les organisations doivent soumettre leurs infrastructures critiques et leurs processus métiers à des exercices réguliers, à des campagnes de tests d’intrusion et, pour les acteurs financiers couverts par DORA, à des tests de pénétration avancés fondés sur les menaces. Et pourquoi pas, également, à des programmes de bug bounty, comme cela a été proposé par le ministre de l’Action et des Comptes publics à la suite de la fuite de données DGFIP.

Tout ceci explique notre appropriation, parfois douloureuse, des normes européennes de cybersécurité qui sont largement inspirées du modèle anglo-saxon. Nul besoin de cette exception française pour justifier notre retard dans la transposition de NIS 2, mais force est de constater que nous digérons souvent bien mal ces normes. À commencer par le cadre NIST 2.0 ou la norme ISO 27001.

Si nous admettons que la cybersécurité n’est plus uniquement une question d’administration technique des systèmes d’information, mais bien une composante majeure de la gouvernance globale des risques d’entreprise, alors le "Govern" doit désormais être placé sur un pied d’égalité avec les traditionnelles fonctions Identify, Protect, Detect, Respond et Recover.

Ce "Govern" stipule en effet que la stratégie de cybersécurité et l’appétence au risque doivent être arrêtées, financées et surveillées au plus haut niveau de la gouvernance de l’organisation. Il impose donc des canaux d’accountability reliant les équipes opérationnelles aux organes de décision.

De manière analogue, la norme ISO/IEC 27001 subordonne l’efficacité d’un Système de management de la sécurité de l’information (SMSI) à l’engagement explicite de la direction générale — clause 5, "Leadership" — et exige que les responsabilités et les autorités soient formellement déléguées et auditables à chaque strate hiérarchique.

La gouvernance des risques cyber exige donc une séparation étanche entre la responsabilité technique et l’accountability stratégique, avec, comme niveaux ultimes, la direction générale et le conseil d’administration.

Ce sont eux qui définissent la politique globale de tolérance aux risques, allouent les budgets nécessaires et exercent une surveillance active sur la résilience de l’organisation. À un niveau intermédiaire, les directions métiers et les propriétaires d’actifs assument, eux, la propriété des risques cyber générés par leurs activités commerciales ou industrielles.

Le CISO, lui, intervient au titre d’expert et d’autorité de contrôle interne, avec une responsabilité opérationnelle : concevoir les protocoles de défense, analyser la surface d’attaque, quantifier les menaces et alerter les instances décisionnaires sur les vulnérabilités constatées. Les équipes informatiques et d’exploitation portent, quant à elles, la responsabilité du déploiement des correctifs logiciels et du maintien en conditions de sécurité.

La décision de différer un correctif ou de refuser un budget relève donc d’un arbitrage exécutif d’acceptation du risque, et donc de la personne accountable.

Dans le cas de la DGFIP, le fait d’avoir autorisé la mise en ligne d’un système sans la mise en place d’une véritable authentification à facteurs multiples (MFA), tant pour les agents que pour les utilisateurs, relève donc d’un arbitrage stratégique, et non technique. Il faut donc comprendre pourquoi cet arbitrage a été fait. Et si l’accountable n’est, bien sûr, pas responsable de l’incident au sens technique du terme, il est en revanche redevable du niveau de risque que son organisation a choisi d’assumer.

Même chose pour la dette technique, dont on comprend qu’elle est la priorité absolue du contrat d’objectifs et de moyens de la DGFIP. Dans sa feuille de route informatique, le fisc assure ainsi vouloir améliorer la situation, avec 52,2 % de ses systèmes répondant aux normes techniques actuelles, contre seulement 31 % en 2021, et un objectif de 78 % à fin 2027 (source : https://www.capital.fr/economie-politique/fisc-pirate-seuls-52-de-ses-logiciels-et-serveurs-etaient-modernises-fin-2025-1529488). 

L’exposition résiduelle -conséquente- que génère cette dette technique non encore résolue doit donc être assumée par les dirigeants de la DGFIP au titre de leur accountability, ou redevabilité. Mais il ne faut pas confondre cette responsabilité avec celle du niveau politique. En ce sens, la démission du ministre, à laquelle ont appelé certains responsables politiques, n’avait aucun sens. Elle peut constituer une sanction politique, mais ne constitue nullement une démonstration d’accountability. Il ne suffit pas de demander : qui était responsable ? 

Il faut donc, dans le cas de la DGFIP comme dans toute organisation, reconstruire la chaîne de décision : quelles décisions relevaient de qui ? Quels risques étaient connus à chaque niveau ? Quelles options avaient été envisagées et quels arbitrages avaient été rendus ? C’est à cette condition que l’on pourra distinguer les différents niveaux de responsabilités et surtout améliorer notre résilience.