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 retrouve victime d’une politique de sécurité un peu trop stricte.
Les petits réglages qui font toute la différence
Une fois la cause identifiée, les ajustements s’enchaînent avec méthode.
Les règles iptables de protection contre les attaques DoS sont repensées : les seuils sont relevés et les limitations appliquées par adresse IP source. Une approche à la fois plus juste et moins restrictive.
Du côté du serveur web Apache (HTTPd), plusieurs optimisations sont opérées : augmentation des caches pour les sessions HTTPS (de 2 Mo à 5 Mo puis à 10 Mo), ajout de threads sur les serveurs, ajustement du nombre de connexions simultanées… chaque paramètre est affiné pour garantir un fonctionnement fluide et stable.
Enfin, une des règles iptables, oubliée lors des dernières modifications, a provoqué, par effet de bord, le blocage involontaire des accès HTTP. Sa correction a rétabli le fonctionnement normal.
Et le plus réjouissant dans tout ça ? C’est que ça marche. Les lenteurs disparaissent. Les applications redeviennent fluides. Les sondes se stabilisent. Et l’équipe respire enfin.
Ce qu’on en retient
Derrière cet incident se cache une belle leçon de mécanique logicielle et d’archéologie système : des règles oubliées, des seuils devenus obsolètes, un reverse proxy vieillissant, et une croissance d’activité sous-estimée. Cet effet de seuil est, par ailleurs, inhérent à tout système. Un système en fonctionnement repose sur un équilibre défini par de multiples paramètres techniques, fixés à un moment de sa conception ou de son déploiement, qu’il est essentiel de réévaluer dès lors que les usages évoluent.
Mais surtout, c’est l’occasion de rappeler que, quand on ne trouve pas, ce n’est pas toujours parce qu’il n’y a rien. C’est peut-être simplement qu’on ne cherche pas au bon endroit.
Remerciements au SIAT (Service Infrastructure et architecture technique de l’Abes) pour son intervention réactive, aux collègues de l’Abes pour leurs précieuses remontées, ainsi qu’à la Bibliothèque de l’Académie Nationale de Médecine pour sa collaboration lors des tests.