Le 21 janvier 2026, une saturation du volume contenant les journaux de transactions Oracle de l'instance P01GX a provoqué l'arrêt de la base de données et l'indisponibilité de l'application Galaxie. La saturation a été déclenchée par une opération de copie d'environnement sur cette instance. L'incident a duré 1 heure 44 minutes avant rétablissement complet du service.

Indisponibilité totale de l'application Galaxie pour l'ensemble des clients hébergés sur l'instance P01GX. Arrêt de la base de données Oracle suite à la saturation du volume des journaux de transactions (Archive Logs). GTI constatée : 6 minutes. GTR constatée : 1 heure 44 minutes.

2ème cas de saturation sur l'instance P01GX en 2 ans. Le 1er cas n'avait pas généré d'indisponibilité car il avait été traité juste avant la saturation totale. Récurrence jugée moyenne.

Détection automatique par la supervision Zabbix via alertes de remplissage élevé du volume de journaux de transactions.

Causes immédiates : Saturation des Archive Logs (AL) sur le volume de base de données de l'instance P01GX.

Causes racines : Opération de copie d'environnement sur P01GX ayant généré un volume anormalement élevé de journaux de transactions, conduisant à la saturation du volume dédié.

Faits aggravants : Cellule de crise partiellement déclenchée, ce qui a potentiellement ralenti la coordination et la prise de décision. Échec des opérations automatiques de vidage des Archive Logs en première intention, forçant le recours à des procédures manuelles plus longues.

Réinitialisation du composant Oracle, purge manuelle du volume des Archive Logs, redémarrage de la base de données, puis extension du volume des journaux de transactions pour prévenir une nouvelle saturation immédiate.

Ce qui s'est bien passé : Prise en charge rapide de l'incident en 6 minutes après détection de l'alerte.

Ce qui s'est mal passé : Déclenchement partiel de la cellule de crise, ayant impacté la réactivité collective. Les opérations automatiques de vidage des Archive Logs se sont révélées inopérantes en première intention, allongeant significativement la durée de résolution.

Chanceux : Bof, pas trop — aucun facteur de chance notable identifié. L'incident aurait pu être évité si les mécanismes de vidage automatique avaient fonctionné ou si le volume avait été étendu préalablement, comme lors du 1er épisode.

Entre le 21 et le 23 janvier 2026, plusieurs instances Tomcat de l'environnement OMSAAS ont subi une saturation CPU causée par l'exécution du rapprochement bancaire intelligent (mode N-N) lancé par un utilisateur du client HERMEUGOZ. Cette surcharge, maintenue plus de 24h, a provoqué de fortes lenteurs sur l'application ONE Manager pour l'ensemble des utilisateurs connectés aux Tomcats impactés. La résolution a nécessité le retrait des Tomcats du répartiteur, leur redémarrage et la bascule du client en mode de rapprochement non intelligent (1-1).

Jusqu'à une vingtaine de clients par Tomcat impacté ont subi de fortes lenteurs sur l'application ONE Manager (ex : 30 secondes pour l'affichage de l'écran de facturation). Le rapprochement bancaire initiateur n'a pas abouti. Une perte de productivité significative a été constatée côté clients. L'incident a également mobilisé fortement les équipes OPS, Support et Développement sur deux jours.

Détection via les webtests internes de monitoring infra : temps d'exécution 3x supérieur à la normale sur les Tomcats. Confirmation de l'origine via les logs GrayLog identifiant les requêtes de rapprochement bancaire comme source de la saturation CPU.

Causes immédiates : Threads du processus RapproBancProcessor bloqués dans une boucle prolongée (méthode getListeCombinaisonsSumRn), maintenant le CPU à plus de 93% sur les Tomcats concernés pendant plus de 24h.

Causes racines : Absence de limitation en amont du nombre de mouvements bancaires et de retours NOEMI à rapprocher dans le mode de rapprochement intelligent (N-N), permettant le déclenchement de calculs combinatoires potentiellement infinis sans garde-fou ni timeout applicatif.

Faits aggravants : Impossibilité de retirer un Tomcat du pool de répartition sans déconnecter les utilisateurs qui y sont attachés. Temps de réaction allongé pour identifier et isoler les instances en saturation. Relances utilisateur intempestives (plusieurs exécutions successives du rapprochement N-N) ayant amplifié et propagé la charge sur d'autres Tomcats.

Retrait des Tomcats saturés (CPU > 90%) du répartiteur de charge puis redémarrage, avec communication préalable aux clients concernés sur le risque de déconnexion. Bascule du paramétrage du client HERMEUGOZ en mode rapprochement bancaire non intelligent (paramètre CDCT_RAPPRO_BANC_MULTIPLE = 0) en attente d'un correctif applicatif pérenne.

Ce qui s'est bien passé : Identification rapide de l'origine via GrayLog (moins de 20 minutes après détection). Coordination efficace entre les équipes OPS, Support et Dev. Contact direct avec le client HERMEUGOZ ayant été constructif et facilitant la prise de décision. Procédure d'extinction de l'incident claire et appliquée.

Ce qui s'est mal passé : Absence de garde-fou applicatif sur le volume de données traitées par le rapprochement N-N. Impossibilité de retirer proprement un Tomcat du répartiteur sans impact utilisateur. Délai important entre la détection (15h03) et le début d'analyse développement (17h21). Relances utilisateur non maîtrisées ayant propagé la saturation à d'autres Tomcats.

Chanceux : L'incident s'est déclaré en journée, permettant une mobilisation rapide des équipes. Le client HERMEUGOZ a été coopératif et a accepté la bascule en mode non intelligent sans résistance. Le trafic global de rapprochement bancaire n'était pas en augmentation sur la période, limitant l'ampleur de la p

Suite au remplacement du convertisseur JOD par le Report Converter OnlyOffice, une augmentation significative des lenteurs et des timeouts HTTP 504 a été observée sur plusieurs SaaS (OMSAAS3, OMSAAS7, OMSAASDOM) durant la semaine du 12 janvier 2026. Un rollback complet vers JOD a été effectué le 16 janvier, rétablissant immédiatement les performances nominales. La cause précise des lenteurs liées au Report Converter n'est pas encore totalement identifiée et fait l'objet d'un plan de migration sécurisé.

Les clients utilisant les SaaS OMSAAS3, OMSAAS7 et OMSAASDOM ont subi des lenteurs perceptibles sur la génération et la conversion de rapports (API /reports/converter/api/v1/documents/converter/), se traduisant par des timeouts HTTP 504. Les temps de traitement ont dépassé les valeurs normales (moyenne habituelle ~2,46s, pic jusqu'à 29,3s). Aucune erreur HTTP 500 significative n'a été constatée. L'impact financier n'a pas été mesuré.

Le problème n'avait pas été observé avant la bascule vers le Report Converter OnlyOffice. Il s'est manifesté uniquement après cette bascule sur certains SaaS et a disparu après le rollback. L'incident est considéré comme non récurrent en production à ce stade, mais une récurrence reste possible tant que la migration vers le Report Converter n'est pas finalisée et sécurisée.

L'incident a été détecté via la surveillance des métriques de performance dans Grafana, avec une hausse des timeouts HTTP 504 sur l'API de conversion (/reports/converter/api/v1/documents/converter/). La dégradation a été confirmée par l'analyse des logs Graylog (requête : http_request:/reports/converter/api/v1/documents/converter/ AND http_status:504). Des retours clients signalant des temps de génération de rapports anormalement longs ont également contribué à l'identification du problème.

Causes immédiates : Le passage de JOD au Report Converter OnlyOffice a augmenté le temps de traitement des conversions de documents, entraînant des timeouts HTTP 504 sur l'API /reports/converter/api/v1/documents/converter/. Un sous-dimensionnement des pods OpenShift (CPU/mémoire insuffisants) et un nombre de pods insuffisant par rapport à la charge sont suspectés comme causes principales.

Faits aggravants : La bascule a été appliquée simultanément sur plusieurs SaaS (OMSAAS3, OMSAAS7, OMSAASDOM), augmentant la charge globale sur la stack OnlyOffice/Report Converter. La dépendance à une stack OnlyOffice partagée a potentiellement amplifié l'effet sur d'autres usages (notamment la partie radio utilisant déjà OnlyOffice).

Résolution immédiate : rollback complet vers le convertisseur JOD sur l'ensemble des SaaS concernés, supprimant l'utilisation du Report Converter OnlyOffice et permettant un retour immédiat aux performances nominales avec disparition des timeouts HTTP 504. Résolution durable en cours : définition d'un plan de migration progressif incluant la validation de la configuration OpenShift cible, l'ajustement des ressources des pods, une migration par lots avec phases de tests de 24–48h et une possibilité de rollback à chaque étape.