Lenteurs des applications Abes : retour sur un incident aux multiples pistes
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…
