La désactivation d'une règle de pare-feu suite à une demande d'Epiconcept (ticket 3578637) a provoqué un effet de bord non anticipé. Les infrastructures Epiconcept ont perdu l'accès au serveur DNS 10.49.180.65, rendant les applications indisponibles. La règle désactivée couvrait des flux nécessaires au fonctionnement des services, sans que cela ait été vérifié au préalable.

Les infrastructures Epiconcept ne pouvaient plus joindre le DNS 10.49.180.65, entraînant une indisponibilité applicative pour les utilisateurs concernés. L'incident a duré plusieurs heures entre la suppression de la règle (08h20) et sa détection via remontée client (12h14).

Aucune

Détection par remontée utilisateur final vers Fabrice, qui a signalé le dysfonctionnement dans le ticket 3578637 et via Teams.

Causes immédiates : La règle de pare-feu désactivée à la demande d'Epiconcept incluait des flux DNS nécessaires au fonctionnement des services. Aucune vérification de l'usage effectif de cette règle n'a été réalisée avant sa désactivation.

Causes racines : Les règles de flux appliquées sur les pare-feux ne correspondent pas exactement à la matrice de flux. Des règles ont été modifiées sans mise à jour correspondante de la matrice de flux, rendant impossible une analyse fiable de l'impact d'une modification.

Réactivation de la règle de flux désactivée, rétablissant l'accès au DNS 10.49.180.65 et le fonctionnement des applications Epiconcept.

Ce qui s'est mal passé : La détection de l'incident s'est faite uniquement par remontée utilisateur, sans aucune alerte de monitoring automatique. Aucune vérification de l'impact de la désactivation de la règle n'a été effectuée avant l'opération.

Dysfonctionnement aléatoire du port 5 du switch SAN stdn-b48f-01 (fabric prod_fabric1) dû à une défaillance du laser TX du SFP. Ce port assurait un lien ISL vers le switch stdn-b48f-05, provoquant des perturbations intermittentes sur plusieurs machines de base de données Oracle et quelques ESX. L'incident a été résolu par la désactivation du port fautif et un remplacement du SFP est en cours via Dell.

Perturbations intermittentes sur 9 serveurs de base de données Oracle (P07HM, P11HM, P13HM, P01AM, P05OM, P15HM, P01GX, P21HM, P01TM) ainsi que sur plusieurs ESX et leurs VM associées. Conséquences côté applicatif : lenteurs sur les applications hébergées (Galaxie, One, HM notamment), possibles déconnexions Galaxie, et afflux d'appels vers le support.

Très faible a priori, mais des occurrences précédentes n'ont peut-être pas pu être identifiées faute d'alerting adapté. Un dysfonctionnement physique similaire (côté carte serveur Oracle, non switch) avait déjà été constaté en 2025.

Alertes de supervision automatique sur montées de sessions Oracle et ralentissements détectés sur les webtests HM.

Causes immédiates : Perte du lien ISL sur le port 5 entre les switches stdn-b48f-01 et stdn-b48f-05 (fabric prod_fabric1), provoquant des perturbations intermittentes sur le stockage SAN.

Causes racines : Défaillance unilatérale du laser TX du SFP (PN 57-1000485-01) sur le port 5 de stdn-b48f-01 (S/N BRCFME1903U07D, ~5 ans de fonctionnement). La puissance TX tombe à 0 µW (-99,99 dBm) alors que la RX reste correcte à -8,9 dBm. Le switch distant stdn-b48f-05 remontait 35 800 erreurs FEC et plusieurs pertes de signal. Au total : plus de 7 millions d'erreurs FEC non corrigées et 245 000 BB_Credit zeros constatés.

Faits aggravants : Absence d'alerting hardware dédié sur les équipements SAN (switches Brocade, métriques SFP). L'outil de supervision hardware xormon récemment mis en place n'est accessible qu'au compte 'admin', limitant la visibilité des équipes. Support Brocade mal défini (processus d'escalade flou). Seul un compte nominatif (Benoit) permettait d'ouvrir un ticket IBM, bloquant les administrateurs standards (ex. J

Désactivation du port 5 du switch stdn-b48f-01 en CLI pour stabiliser le fabric prod_fabric1. Case Dell ouverte (SR # 225743679), logs supportshow fournis. Dell a confirmé la défaillance du SFP et créé le Work Order # 466424924 pour expédition du SFP de remplacement (PN 100-652-959) vers le datacenter.

Ce qui s'est mal passé : Manque d'expertise et de maîtrise technique sur les switches Brocade SAN. Processus de support Brocade non clarifié (interlocuteurs, modalités de contact). Accès IBM pour ouverture de tickets restreint à un seul collaborateur (Benoit) — les comptes admins standards (JBeau) ne le permettent pas. Accès aux données xormon limité au compte 'admin' uniquement. Gestion de la cellule de communication de

Chanceux : Le fabric SAN disposait d'une redondance (lien ISL), ce qui a limité l'impact à des perturbations intermittentes plutôt qu'une coupure totale. L'incident ne s'est pas produit sur l'ensemble du fabric ni sur la baie de stockage elle-même, évitant une indisponibilité généralisée.

Suite à des modifications en production le 21/04 au soir (nouveau cron, volume de stockage, montage sur pods OnlyOffice), des dysfonctionnements sont apparus le 22/04 matin : documents vides après validation et chargements aléatoires. La résolution est intervenue en milieu d'après-midi après réduction de RabbitMQ et Redis de 2 pods à 1.

Impact métier important : des comptes rendus validés sont redevenus vides, des accès aux documents OnlyOffice étaient intermittents ou en échec. Comportement aléatoire (fonctionnement normal puis dégradé) ayant généré une perte de confiance sur les documents et un blocage partiel de l'activité pour plusieurs structures clientes.

Incident remonté par les utilisateurs (clients finaux et praticiens). Aucune alerte monitoring n'a permis une détection proactive. Les erreurs 504 côté converter ont été identifiées a posteriori via les logs lors des investigations techniques.

Causes immédiates : Dysfonctionnement dans la gestion des composants RabbitMQ et Redis en configuration multi-pods (2 pods chacun), entraînant des comportements instables et des erreurs de traitement côté OnlyOffice (converter/docservice). Le redémarrage des pods OnlyOffice lors du rollback semble avoir réveillé les 2 instances de RabbitMQ et Redis dans un état incohérent.

Faits aggravants : Absence de monitoring fonctionnel permettant de détecter rapidement les anomalies côté utilisateurs. Comportement intermittent et aléatoire rendant le diagnostic particulièrement difficile. Intégration Claude Code / Grafana / Graylog non encore disponible au moment de l'incident (demande de tokens en cours auprès de Nicolas Hermitte et Patrice Perronnet). Dossier /data trop volumineux ayant empêch

Réduction du nombre de pods RabbitMQ, Redis et StatsD de 2 à 1 (simplification de l'architecture). Redémarrage complet de l'ensemble des pods dans un ordre contrôlé. Nettoyage des tables doc_changes et task_result en base. Retour sur un volume propre. Stabilisation immédiate observée après ces actions.

Chanceux : La possibilité de basculer vers Word à la place de OnlyOffice existait en tant que solution de contournement. Cette bascule aurait dû être activée dès le matin pour limiter l'impact client, et non à 12h00.

Le 07/04, lors du renouvellement des certificats TLS swmcloud.net, le redémarrage du cluster Elasticsearch 'Alicante' a entraîné la prise en compte d'un fichier de configuration incorrect, empêchant l'accès aux index clients. Le cluster apparaissait pourtant en état 'green' dans la supervision, masquant le problème. L'incident a provoqué une indisponibilité complète de Dimbox pendant près de 24 heures.

Dimbox indisponible du mardi 07/04 à 19h35 au mercredi 08/04 à 19h07, soit environ 23h30 d'interruption. Une petite dizaine de clients en production impactés. Périmètre fonctionnel limité car produit récent avec peu de clients en prod.

Détection par les équipes fonctionnelles. Aucune alerte supervision n'a remonté malgré l'indisponibilité du service, le cluster Elasticsearch apparaissant en état 'green'.

Causes immédiates : Suite au redémarrage du cluster Elasticsearch 'Alicante' pour prise en compte des nouveaux certificats TLS, le service a chargé un fichier de configuration incorrect (paramétrage standard Softway) qui pointait vers un mauvais répertoire DATA. Les index clients n'étaient donc plus accessibles, bien que le cluster soit vu comme opérationnel.

Causes racines : Installation non-conforme du cluster Elasticsearch : deux fichiers de configuration coexistaient avec des paramétrages différents, et le fichier chargé par le service système pointait vers le mauvais répertoire DATA. Des index étaient présents dans ce 'mauvais' répertoire, rendant la détection plus difficile. La configuration système n'était pas alignée avec la configuration Elasticsearch. L'interface Kibana était déployée directement sur le serveur, accessible par un prestataire externe sans authentification (non conforme aux pratiques de sécurité, non documenté) et ne redémarrait pas automat

Faits aggravants : Absence de supervision du service Dimbox — aucune détection automatique de l'indisponibilité. Absence de détection du problème au niveau base de données. Mauvais diagnostic initial sur le port de connexion et la configuration sécurisée, entraînant des reparamétrages et redémarrages inutiles (~1h perdue). Temps de redémarrage de l'application extrêmement long pour un déploiement en containers. Décl

Identification du mauvais fichier de configuration Puppet utilisé par le service Elasticsearch. Modification de la configuration Puppet pour pointer vers le répertoire DATA contenant les index clients corrects. Réactivation de Puppet et redémarrage du service validés avec succès. Service Dimbox rétabli à 19h07 le 08/04.

Ce qui s'est bien passé : Disponibilité et réactivité de la squad (C. Arizzi et F. Petit) et du prestataire (Julien T.) pour traiter l'incident.

Ce qui s'est mal passé : Détection de l'incident non assurée par la supervision — remontée uniquement par les équipes fonctionnelles. Déclaration faite à un admin unique plutôt qu'au support. Déclenchement trop tardif de la cellule de crise alors que tous les clients étaient impactés. Mauvais diagnostic initial sur le port de connexion ayant ralenti le rétablissement et faussé l'analyse pendant environ 1 heure.

Chanceux : Disponibilité du prestataire externe (Julien T.) pour intervenir en dehors des heures ouvrées. Le fait que Dimbox soit un produit récent avec peu de clients en production a limité l'étendue de l'impact.

Lors de la migration du socle technique Tomcat 6 vers Tomcat 9 sur les sites RAMSAY, des dysfonctionnements applicatifs multiples ont été constatés progressivement sur l'ensemble des sites migrés. Les écarts de configuration entre les deux versions de Tomcat ont provoqué des comportements incompatibles impactant plusieurs fonctionnalités critiques de l'application.

Les clients RAMSAY ayant migré vers Tomcat 9 ont rencontré des dysfonctionnements sur : l'accès et la récupération de traitements antérieurs, des erreurs lors des imports HM, des difficultés sur la composition et génération de documents Word, des anomalies sur les chaînes de traitement (cueillette) et sur la saisie de masse.

Le problème s'est étendu progressivement à tous les sites RAMSAY migrés vers Tomcat 9.

L'incident a été détecté suite à un signalement client au support.

Causes immédiates : Migration vers une nouvelle infrastructure Tomcat 9 avec des écarts de configuration non anticipés par rapport à Tomcat 6 : valeurs par défaut plus restrictives sur Tomcat 9 provoquant des rejets d'appels à fort volume de paramètres, différences de comportement de compilation nécessitant un ajustement JVM, paramètres manquants pour assouplir certaines vérifications, divergences de configuration entre Tomcat 9 et Tomcat 6 empêchant certaines actions applicatives d'aboutir.

Causes racines : Problèmes de configuration Tomcat non identifiés lors de la phase de préparation de la migration, conduisant à des comportements plus stricts et non compatibles avec l'application existante.

Faits aggravants : Absence de site pilote établissement avant déploiement élargi. Couverture de tests insuffisante et jeux de données de validation inadaptés. Migration Oracle concomitante ayant potentiellement brouillé les pistes d'analyse. Méconnaissance des changements opérés par le client dans son infrastructure (VLAN, EDR, migrations Oracle ponctuelles). Sites On-Premise non télé-exploités, rendant les investig

Des corrections de configuration Tomcat 9 ont été préparées et appliquées. Des tests de validation incluant des tests réseau et VLAN ont été réalisés et se sont avérés concluants le 24/04. Une liste d'actions de suivi est en cours de pilotage pour sécuriser la migration sur l'ensemble des sites restants.

Ce qui s'est bien passé : Bonne mobilisation des équipes Infra, Mindcraft et Support face à l'incident.

Ce qui s'est mal passé : Méconnaissance de l'infrastructure client (sites On-Premise non télé-exploités). Latence importante pour localiser et comprendre l'origine des problèmes. Absence de visibilité sur les changements d'infrastructure côté client (VLAN, EDR, Oracle).

Suite à une mise à jour des Netscaler (RFC-2026-001034) le 31/03 à 21h, les certificats Citrix se sont retrouvés non pris en compte ou absents, rendant l'accès à Galaxie indisponible. L'incident a été détecté le 01/04 au matin via remontée client et résolu à 09h26 par remise en place des certificats.

Accès à Galaxie indisponible pour les clients concernés. Détection tardive via remontée client (Ramsay) sans alerte supervision. Interruption de service en début de journée du 01/04.

Ponctuelle

Appel client vers CP / DP / responsable BU — aucune alerte supervision déclenchée.

Causes immédiates : Les certificats Citrix n'ont pas été pris en charge après la mise à jour des Netscaler : absents sur stdn, non reconnus sur crbv.

Causes racines : Incompatibilité entre les caractères spéciaux présents dans les certificats SWM et la nouvelle version du Netscaler. Référence Citrix : https://support.citrix.com/external/article/CTX461396/certificate-binding-lost-after-upgrade.html

Faits aggravants : La RFC prévoyait des tests post-mise à jour qui n'ont pas été réalisés ou ont été insuffisants. Le process de contact support en HNO n'est pas existant, connu ou correctement appliqué par le client. L'incident n'a pas été détecté par la supervision.

Remise en place manuelle des certificats Citrix sur les équipements concernés (crbv et stdn).

Ce qui s'est mal passé : Tests post-RFC non effectués ou insuffisants. Le client n'a pas su contacter le support en dehors des heures ouvrées (process HNO absent ou mal connu). La supervision n'a pas détecté la perte des certificats.

Chanceux : Suite à une mise à jour de sécurité effectuée le 31/03 à 21h sur le Netscaler Citrix, un dysfonctionnement imprévu a impacté le certificat HTTPS, rendant l'accès indisponible. L'incident a été identifié et corrigé le 01/04 à 09h26. Des contrôles complémentaires post-mise à jour ainsi qu'une supervis