Des perturbations des accès internet ont affecté les liens télécoms VPNclient le temps d'une matinée. Une modification de routage appliquée sans concertation par l'opérateur GTT a été identifiée comme facteur déclenchant. La tentative de bascule sur le lien secondaire (Zayo) a aggravé la situation avant un retour à la normale spontané.

Accès internet coupés entre 11h43 et 11h49, avec des perturbations plus larges entre 11h20 et 11h58. Impact client difficile à mesurer précisément. Les services exposés sur internet depuis le datacenter (Citrix, Cosem notamment) ont été perturbés. 6 à 7 liens VPNclient ont nécessité un redémarrage manuel.

Détection indirecte via la supervision : remontée d'indisponibilité de plusieurs liens télécoms VPNclient dans l'outil de monitoring réseau.

Causes immédiates : Problème de routage non complètement identifié, possiblement lié à une modification appliquée sans concertation par l'opérateur GTT (réduction des routes internet annoncées), combinée à un problème plus large chez un ou plusieurs opérateurs (Alphalink).

Causes racines : Historique des configurations du réseau d'accès et changements en cours liés à l'ouverture de nouvelles salles d'hébergement. La complexité de l'architecture réseau en évolution rend difficile l'anticipation des impacts de chaque modification.

Faits aggravants : Difficulté d'estimer l'impact client en temps réel : la décision de couper le lien GTT suspect, prise sans visibilité suffisante, a provoqué une aggravation des perturbations au lieu de les corriger. La bascule actif/actif entre opérateurs n'a pas fonctionné comme prévu et n'avait pas été testée dans ce scénario.

L'incident s'est résolu sans action corrective technique de SWM côté infrastructure. Les 6-7 liens VPNclient restants ont été manuellement coupés puis relancés entre 11h58 et 12h28. Les analyses se poursuivent avec les opérateurs (Zayo). Une révision et un test du mécanisme de bascule entre opérateurs internet sont planifiés.

Ce qui s'est mal passé : Estimation de l'impact client insuffisante en temps réel, ayant conduit à une décision de bascule qui a aggravé les perturbations. La bascule entre opérateurs internet n'a pas fonctionné correctement et n'était pas suffisamment qualifiée.

Chanceux : Le retour à la normale s'est produit spontanément, sans action corrective identifiée côté SWM. La perturbation aurait pu durer bien plus longtemps si le problème ne s'était pas résorbé de lui-même chez les opérateurs.

Une règle de NAT mal configurée sur le Palo Alto de CRBV a provoqué un conflit d'adresse IP (duplicate IP 91.208.222.253) entre l'ASR et le pare-feu. Cela a mis hors service les sessions BGP, rendant les accès internet et les résolutions DNS publiques inopérants. L'incident a duré de 15h05 à 16h27.

Accès internet indisponible sur le site CRBV. Applications publiques inaccessibles. Serveurs DNS publics SWM (193.23.123.3 et 193.23.123.193) incapables de résoudre les adresses *.xtremcloud.cloud entre 15h05 et 16h00. Les clients dont les DNS locaux n'avaient pas de cache ont subi des indisponibilités d'accès aux applications. Les DNS internes ont conservé leur cache, préservant le fonctionnement interne des applications.

Nombreuses alertes de supervision Zabbix sur l'indisponibilité de services web et d'équipements opérateur (VISP).

Causes immédiates : Une règle de NAT créée à 14h55 sur le Palo Alto de CRBV a provoqué un duplicate IP : l'IP 91.208.222.253 était portée simultanément par l'ASR CRBV et le Palo Alto CRBV. Ce conflit a mis hors service les sessions BGP nécessaires aux services internet.

Causes racines : Lors de la création d'une règle de NAT pour donner accès internet à un serveur Epiconcept, l'interface de sortie n'a pas été spécifiée — seul le pool d'adresses 91.208.222.250/29 a été renseigné. Le Palo Alto a alors utilisé une IP du pool 91.208.222.248/29, récupérant l'IP 91.208.222.253 déjà attribuée à l'ASR. La règle avait été discutée entre un administrateur et un architecte, mais une incompréhension a conduit à un paramétrage incorrect.

Désactivation de la règle de NAT incorrecte sur le Palo Alto de CRBV, suivie d'un flush ARP et d'un flush de session BGP sur l'ASR de CRBV pour éliminer le duplicate IP résiduel et rétablir l'ensemble des accès publics.

Ce qui s'est mal passé : Action non courante réalisée par un administrateur sans filet de sécurité suffisant. Le diagnostic a été compliqué par le manque de visibilité précise sur la chaîne de défaillance (accès KO vs résolution KO). Les remontées clients étaient vagues ("ça ne marche pas") et il a fallu creuser pour identifier le composant défaillant exact.

Chanceux : Les DNS internes SWM ont conservé leur cache, préservant le fonctionnement interne des applications pendant l'incident. De nombreux DNS publics et DNS locaux sur site ont également conservé leur cache, limitant l'impact à une partie seulement des utilisateurs externes (ceux dont les DNS n'avaient pa

Une régression introduite dans la version 2601.12 a provoqué une mauvaise gestion du contexte entre le bandeau HM et les fenêtres de navigation en mode multi-onglets. Cette anomalie a engendré des incohérences en base de données avec des risques patients avérés, notamment sur des prescriptions médicamenteuses. 6 établissements clients ont été impactés avec 19 prescriptions médicaments concernées.

6 clients impactés avec 19 prescriptions médicaments erronées (client 2423 : 1, client 3214 : 1, client 2719 : 5, client 2844 : 2, client 2599 : 2, client 2732 : 8). Risque patient avéré lié à des erreurs d'appréciation et des incohérences en base de données dans un contexte d'utilisation multi-onglets. Le problème était en production depuis environ 1 mois avant détection.

Aléatoire en fonction du mode d'utilisation des clients. Cas particulier identifié sur l'usage du multi-onglet pour le Dossier Urgence.

L'incident a été détecté via une remontée terrain du GHT18, qui a créé une demande Salesforce le 16 avril 2026. Aucune alerte automatique n'a permis de détecter la régression en amont.

Causes immédiates : Dans un contexte multi-onglets, mauvaise gestion du contexte entre le bandeau HM et les fenêtres de navigation, provoquant des erreurs d'appréciations et des incohérences en base de données avec des risques patients avérés.

Causes racines : Régression introduite à partir de la version 2601.12, issue de la correction de deux anomalies PMSI : '623343 - [PMSI_RUM] - Perte du contexte en accès au RUM depuis la synthèse générale' et '587805 - [PMSI_SMR] - Anomalie navigation RHS depuis LT RHS'. La correction de ces anomalies a introduit un effet de bord sur la gestion du contexte en mode multi-onglets, non détecté avant la mise en production.

Faits aggravants : Risque patient avéré. Absence d'alerte automatique permettant une détection précoce. Notion de session backend vs mode statique multi-onglets insuffisamment maîtrisée. Le problème était en production depuis environ 1 mois avant d'être remonté. Absence de garde-fous sur les versions patches.

Court terme : suppression de l'option « Multi Onglets » via paramétrage et renforcement des règles de bon usage auprès des clients concernés par la version 2601.12+. Moyen terme : livraison de la version 2601.22 (rollback des corrections PMSI, arrêt du risque patient) et planification de la version 2601.23 (correction des problèmes PMSI avec prise en compte des effets de bords). Long terme : définition d'une stratégie sur la gestion du mode multi-onglets et la notion de session backend vs mode statique.

Ce qui s'est mal passé : Absence d'alertes automatiques pour détecter la régression. Absence de garde-fous sur les versions patches (v1.2601.22, v1.2603.05, v1.2602 non patchée, v1.2604.01). Mauvaise maîtrise de la notion de session backend vs mode statique multi-onglets. Délai d'un mois entre l'introduction de la régression et sa détection.

Chanceux : Malgré un mois de présence en production, le nombre de prescriptions impactées est resté limité à 19 sur 6 clients. La situation aurait pu être bien plus grave compte tenu de la durée d'exposition et du risque patient avéré.

Suite à l'activation de GPO de durcissement Citrix (Hardening Citrix User et Hardening Citrix Computer) dans le cadre de la RFC 2026-001022, les serveurs VDA Citrix des clients Galaxie hébergés sur STDN ont rencontré des dysfonctionnements bloquants sur les nouvelles sessions Citrix. Un rollback immédiat s'est avéré inefficace, nécessitant une cellule de crise et des actions manuelles de nettoyage suivies de redémarrages serveurs pour rétablir le service.

Les nouveaux utilisateurs Citrix ne pouvaient plus ouvrir de session applicative Galaxie correctement (messages d'erreur au lancement, modules non fonctionnels, blocage au niveau de la facturation, blocage Wallix). Seuls les clients Galaxie hébergés sur STDN étaient concernés. Les utilisateurs déjà connectés avant l'application de la GPO n'étaient pas impactés. Deux clients (Livi et Ramsay) disposant de plus de 30 serveurs chacun nécessitaient une intervention différée.

Première remontée de dysfonctionnement signalée par les équipes support Galaxie à 10h35, soit 21 minutes après l'application des GPO par l'équipe Infra.

Causes immédiates : L'activation des GPO de durcissement Citrix (Hardening Citrix User et Hardening Citrix Computer) sur les serveurs VDA STDN a introduit des politiques AppLocker incompatibles avec le fonctionnement de l'application Galaxie, bloquant les nouvelles sessions Citrix.

Causes racines : Les GPO de durcissement ont été activées sans validation préalable de leur compatibilité avec l'application Galaxie en environnement de production. L'absence de tests applicatifs métier en amont du change (recette sur environnement représentatif) a permis à une configuration bloquante d'être déployée directement en production.

Faits aggravants : Le rollback initial s'est avéré inefficace car les configurations GPO (notamment AppLocker) persistent dans les clés de registre et les fichiers système (%windir%\System32\AppLocker\) même après désactivation de la GPO, nécessitant un nettoyage manuel et un redémarrage obligatoire des serveurs. L'absence de procédure documentée de rollback complet pour ce type de GPO a rallongé significativement l

Suppression de la stratégie AppLocker, nettoyage des clés de registre associées, suppression des fichiers résiduels dans %windir%\System32\AppLocker\, exécution d'un gpupdate /force suivi d'un redémarrage obligatoire des serveurs VDA. Mise en place d'une supervision Zabbix pour cartographier l'ensemble des serveurs encore impactés. Pour Livi, redémarrage planifié le 11/03 entre 7h00 et 7h30. Suivi en cours pour Ramsay.

Ce qui s'est bien passé : La cellule de crise a été constituée rapidement et les équipes Infra, RUN et BU Galaxie ont collaboré efficacement. Les communications Everbridge vers les clients ont été envoyées rapidement et régulièrement mises à jour. La cause racine a été identifiée et la procédure de remédiation stabilisée en moins de 3 heures.

Ce qui s'est mal passé : Absence de tests de non-régression applicatifs (Galaxie) avant l'application du change en production. Le rollback GPO n'était pas documenté et s'est avéré plus complexe que prévu (persistance des configs AppLocker en registre et fichiers). Le rollback initial a été insuffisant, ce qui a prolongé l'incident de près de 2 heures. Manque de procédure claire pour la remédiation d'une GPO AppLocker mal

Chanceux : Les utilisateurs déjà connectés au moment de l'application de la GPO n'ont pas été impactés, ce qui a limité l'impact global. L'incident s'est produit en journée, permettant une mobilisation rapide des équipes. Si la GPO avait été appliquée en dehors des heures ouvrées, la détection aurait pu être b

Lors du décommissionnement automatisé du serveur rproxy7, l'entrée DNS A associée à l'IP 193.23.123.89 a été supprimée. Or cette IP était également celle du tenant AVI de production (production-crbv.xtremcloud.cloud). Les CNAMEs de production ont alors redirigé vers une machine par défaut (rppriv) au lieu du tenant AVI, rendant les applications inaccessibles aux clients hébergés.

Tous les clients hébergés dont les URLs applicatives pointaient vers le tenant AVI de production se sont retrouvés sans accès à l'application pendant environ 55 minutes. Les requêtes étaient redirigées vers l'IP d'une machine non prévue à cet effet (rppriv).

Incident de faible récurrence, mais cette entrée DNS s'est déjà révélée critique. Une erreur manuelle lors d'un déploiement avait déjà altéré cette même entrée DNS le 26/06/2025. Cette fois-ci, la suppression a été causée par un job d'automatisation.

Détection par monitoring Zabbix.

Causes immédiates : Suppression de l'entrée DNS A 193.23.123.89 (production-crbv.xtremcloud.cloud) par le job Rundeck de décommissionnement de rproxy7.

Causes racines : Dans l'IPAM, rproxy7 était propriétaire de la réservation de l'IP 193.23.123.89. La suppression de l'objet rproxy7 et de sa réservation d'IP a donc entraîné par cascade la suppression de l'entrée DNS A associée. Or cet enregistrement DNS était utilisé comme cible des CNAMEs du tenant AVI de production, créant une dépendance critique non identifiée entre l'objet rproxy7 et l'infrastructure de production AVI.

Faits aggravants : L'utilisateur ayant effectué la suppression est identifié sous le nom générique 'swm-api', ce qui ne permet pas de déterminer rapidement quel processus ou quel actif automatisé est intervenu, allongeant le temps d'investigation.

Création manuelle de l'entrée DNS A 193.23.123.89 pointant vers production-crbv.xtremcloud.cloud. Modification manuelle des CNAMEs de production pour pointer vers cette entrée A nouvellement créée. Passage de Puppet sur les apigtw pour vérification de l'absence de changement impactant. Vérifications approfondies en soirée pour s'assurer de la stabilité de la configuration jusqu'au lendemain.

Ce qui s'est bien passé : Bonne réactivité dans l'analyse, la mobilisation des équipes et la résolution technique. Communication clients engagée rapidement via Everbridge.

Ce qui s'est mal passé : Le passage de Puppet sur apigtw-node3 prend environ 30 minutes, ce qui est trop long pour permettre une réactivité optimale en situation d'incident. L'identification de l'auteur d'une action automatisée est difficile : l'utilisateur 'swm-api' est trop générique et ne permet pas de tracer précisément quel process ou quel actif a déclenché l'action.

Une opération de réplication de volume vers une salle distante, lancée par un prestataire sans être recensée dans le change management, a fortement dégradé les performances du composant de stockage sur le site CRBV. Cela a provoqué de forts ralentissements sur l'ensemble des applications, allant jusqu'à l'indisponibilité complète. L'incident a été résolu par l'arrêt forcé de la réplication via la suppression du volume répliqué.

Forts ralentissements sur toutes les applications hébergées sur CRBV, avec des périodes d'indisponibilité totale. L'ensemble des utilisateurs du site ont été impactés pendant environ 2h10 (de 14h52 à 17h05).

Incident récurrent : un incident similaire avec la même cause a déjà eu lieu le 05/11/2025 (voir rapport d'incident SoftwayMedical du 05-11-2025).

Détection automatique par la supervision, avec passage en cellule de crise 1 minute après le début de l'événement (14h52 → 14h53).

Causes immédiates : Forte diminution des performances d'accès au composant de stockage, causée par une opération de réplication de volume en cours consommant massivement les ressources d'I/O.

Causes racines : 1. Opération de réplication de volume vers une salle distante lancée par un prestataire sans être déclarée ni recensée dans le change management SWM. 2. Instabilité d'un port d'attachement du composant de stockage. 3. Interrogations sur le débit disponible de la solution de réplication.

Faits aggravants : 1. Un port d'attachement du stockage en défaut intermittent, aggravant la dégradation des performances. 2. Non-respect des décisions prises par la cellule de crise (les opérations de rééquilibrage n'ont pas été annulées immédiatement), ce qui a fait traîner l'incident jusqu'à ~15h45. 3. Incompréhension des éléments écrits lors de la crise : l'équipe a cru que la réplication était stoppée alors qu'

Arrêt de la réplication de volume en cours : la procédure d'annulation directe n'ayant pas abouti, la suppression du volume répliqué a été lancée, interrompant mécaniquement la réplication. Le composant de stockage a retrouvé ses performances nominales, permettant le retour progressif du service.

Ce qui s'est bien passé : La détection a été très rapide : 1 minute entre le début de l'événement et l'ouverture de la cellule de crise, grâce à la supervision en place.

Ce qui s'est mal passé : 1. Le change management avec le prestataire est défaillant : une opération de réplication impactante a été lancée sans être déclarée à SWM. 2. Les décisions prises en cellule de crise n'ont pas été respectées (annulation des opérations de rééquilibrage). 3. La communication interne pendant la crise a manqué de clarté, entraînant des erreurs d'interprétation sur l'état réel des actions en cours.

Chanceux : La réplication en cours a été identifiée quasi par hasard, sans processus formel l'ayant permis. Sans cette découverte fortuite, l'incident aurait pu durer beaucoup plus longtemps.

Les licences Citrix NetScaler ont expiré suite à l'atteinte du délai de grâce de 30 jours, causée par des règles de pare-feu manquantes empêchant les NetScalers d'interroger le serveur de licences migré dans le cloud en février. L'incident a impacté successivement deux serveurs Citrix (p01ctx/STDN puis p02ctx/CRBV), rendant toute nouvelle connexion Citrix impossible pendant plusieurs heures. Un client disposant de son propre FQDN (centre-medical-ramsaysante.fr) a également subi une indisponibilité dont la cause reste inexpliquée.

Impossibilité d'établir de nouvelles connexions Citrix sur p01ctx (STDN) entre 11h00 et 12h30, puis sur p02ctx (CRBV) entre ~13h00 et 15h00. Indisponibilité du service pour le client centre-medical-ramsaysante.fr entre 14h00 et 16h00 (cause non élucidée). Les utilisateurs déjà connectés n'ont pas été affectés ; seules les nouvelles connexions étaient bloquées.

Détection par le monitoring sur STDN. Détection par signalement client sur CRBV.

Causes immédiates : La licence Citrix NetScaler a expiré car le délai de grâce de 30 jours sans connexion au serveur de licences dans le cloud a été atteint.

Causes racines : Les règles de pare-feu permettant aux NetScalers d'interroger le serveur de licences Citrix, migré dans le cloud en février, ont disparu suite à cette migration. Sans accès au serveur de licences, le délai de grâce de 30 jours s'est écoulé jusqu'à expiration.

Correction des règles de pare-feu pour rétablir la communication entre les NetScalers et le serveur de licences Citrix cloud. Reboot obligatoire des équipements pour prise en compte des nouvelles licences.

Ce qui s'est mal passé : Aucun incident majeur n'a été déclenché, l'incident n'a donc été suivi que par les équipes techniques sans coordination élargie. Après la correction sur STDN, aucune vérification n'a été effectuée sur CRBV, entraînant un second incident identique quelques heures plus tard.

Chanceux : L'expiration des licences est survenue à un moment de la journée où la majorité des utilisateurs étaient déjà connectés, limitant ainsi le nombre de personnes effectivement bloquées.