La cybersécurité est devenue un enjeu central pour les établissements publics, notamment depuis la parution de l’Instruction générale interministérielle n°1337 du 26 octobre 2022, qui impose une obligation d’homologation des systèmes d'information (SI) pour toutes les structures concourant aux missions de l’État ou placées sous sa tutelle. Consulter : Texte officiel sur Légifrance Une obligation réglementaire à l'horizon 2025 Depuis avril 2023, les établissements disposent d’un délai de deux ans pour se mettre en conformité. Passé ce délai, les pénalités seront encadrées par l’ANSSI, comme précisé dans la section 6.3 de l’Instruction. Consulter : Section 6.3 sur Légifrance Qu’est-ce que l’homologation de sécurité ? L’homologation est un acte formel par lequel une autorité qualifiée (l’AQSSI ou son délégataire) atteste que : les risques de sécurité ont été identifiés les mesures de maîtrise des risques ont été mises en œuvre les risques résiduels sont acceptés en pleine connaissance de cause. Ce processus doit précéder toute mise en production d’un nouveau service numérique. Il s’applique à tous les SI relevant du périmètre de l’État ou de réglementations spécifiques, et est adapté en fonction de la sensibilité des systèmes concernés. Une gouvernance assumée L’autorité d’homologation doit occuper une position hiérarchique suffisamment élevée pour porter la responsabilité de la mise en ligne des services. Dans le cas de l’Abes, c’est le directeur qui fixe la durée de validité de l’homologation selon une échelle d’évaluation (ex. : note de 4,5 ➝ 3 ans d’homologation). L’Abes engagée avec MonServiceSécurisé En tant que DPO et RSSI de l’Abes, nous avons engagé début 2024 une démarche ambitieuse d’homologation, en nous appuyant sur MonServiceSécurisé, la plateforme développée par l’ANSSI pour faciliter cette mise en conformité. Ce chantier a mobilisé plusieurs parties prenantes en interne : les responsables applicatifs, un expert sécurité. l'AQSSI (rôle assumé par le directeur de l'Abes), la Déléguée à la Protection des données (DPO), le Responsables de la Sécurité des Systèmes d'Information (RSSI). Au total, plus de 50 applications ont été intégrées à la plateforme. Cette dynamique illustre une volonté forte de structurer la sécurité numérique à l’échelle de l’établissement. Retour d’expérience dans la communauté ESR Le 26 juin 2024, nous avons eu le plaisir de partager notre retour d’expérience lors d’un webinaire consacré aux synergies entre urbanistes SI, RSSI et DPO. Organisée par la communauté urbaESR, coanimée par l’Amue et le Csiesr, cette rencontre a rassemblé plus de 50 participants issus de ces trois domaines d’expertise. À cette occasion, Maria Castillo (DPO, Abes), Frédéric Pouilloux (RSSI, Abes)  et Catherine Balleydier (Grenoble INP) ont présenté des exemples concrets de collaboration au sein de leurs établissements.  Nous avons notamment présenté : les apports concrets de MonServiceSécurisé la méthodologie d’évaluation des applications l’intérêt d’une collaboration étroite entre urbanistes SI, DPO et RSSI Consulter : Les liens entre urbanistes SI, DPO et RSSI : retour sur un webinaire urbaESR Une reconnaissance inspirante Notre engagement a été salué en avril 2025 par l’équipe de MonServiceSécurisé, qui nous a adressé un message de remerciement chaleureux, soulignant notre rôle d’ambassadrice et d'ambassadeur des…

Incident survenu du 19 au 28 mai 2025 Quand on ne trouve pas, c’est qu’en général on ne cherche pas au bon endroit Tout a commencé vers la mi-avril, avec quelques signaux faibles : des retours isolés, des lenteurs sporadiques, parfois impossibles à reproduire, des utilisateurs gênés… mais rien de franchement alarmant. Puis, le 19 mai, la situation s’accélère : les alertes se multiplient. Calames devient poussif, le moissonnage des entrepôts de données rame, l’autocomplétion des auteurs sur idref.fr prend une pause-café, et même le Sudoc public (sudoc.abes.fr) débouche parfois sur un message "délai dépassé". Pour ne rien arranger, certaines de nos sondes de surveillance se sont mises à faire le yoyo (en ligne, hors ligne, de nouveau en ligne, puis encore hors ligne), accentuant la confusion et renforçant le sentiment d’instabilité générale. Le plus déconcertant ? À l’Abes, ou via notre VPN, tout fonctionne parfaitement. Aucune lenteur, rien à signaler. Impossible de reproduire le problème. En revanche, à distance, les soucis sont présents mais pas de façon constante. D’où cette impression étrange : ce n’est pas l’application qui flanche, mais l’accès. Et pourtant, côté réseau, tout semble en ordre. Aucun indicateur suspect, aucune alerte. Rien. Alors, on creuse. On mène des tests en direct avec un établissement impacté (la bibliothèque de l’Académie Nationale de Médecine). On inspecte les trames avec les outils de développement du navigateur, puis avec Wireshark. Les lenteurs sont tangibles. Et pourtant, dans les logs, aucune anomalie liée aux IP publiques des utilisateurs concernés. Le vide. Alors, on continue à chercher. On redémarre des services, on inspecte le DNS, les interfaces réseau, les journaux système, les pares-feux, le débit, la mémoire, la CPU, la couche de virtualisation, les bloqueurs de pub (oui, vraiment), et même Matomo, notre outil de statistiques web. Mais rien. Les lenteurs persistent, réelles, mesurables… et insaisissables. Comme si le problème s’amusait à jouer à cache-cache avec nous. Alors, où chercher maintenant ? Quand on finit (enfin) par chercher au bon endroit C’est en basculant notre application exemple « hello.abes.fr » sur un autre reverse proxy que l’on a le déclic. Lente et poussive derrière le reverse proxy central, elle devient fluide et réactive lorsqu’on la place derrière un autre proxy. Ce contraste nous met sur la piste. On met donc en place un nouveau reverse proxy central, puis on y migre l’application Calames. Résultat sans appel : sans VPN, tout fonctionne parfaitement. La source du problème se précise nettement. En creusant la piste du reverse proxy, on s’intéresse de plus près au pare-feu présent sur la machine, on analyse les différentes règles iptables présentes, dont certaines n’ont pas été modifiées depuis des années, sans jamais avoir été réellement réévaluées. En particulier, une règle limitait le nombre de connexions entrantes pour contrer les attaques DoS. Sauf qu’en 2025, avec plus d’applications, plus d’usagers, plus de moissonnages… ces seuils ont fini par faire du zèle. Trop de trafic ? Hop, on bloque. Résultat : un effet de seuil inattendu, où le trafic légitime se…