Perturbations des accès internet ⇒ prochain point 24/04

Difficile à mesurer.

Je n’ai pas souvenir d’autre perturbation internet

L’incident a été détecté de manière indirecte, via la coupure de la supervision de plusieurs liens internet VPNclient.

Causes immédiates : La cause semble être liée à un problème de routage non identifié, possiblement chez nous (réseau d’accès) ou chez l’un de nos opérateur Internet. Possiblement l’historique des configurations de notre réseau d’accès et des changements en cours sur l’évolution de ce réseau suite à l’ouverture de nouvelles salles d’hébergement. Difficulté d’estimer l’impact client, direct et à postériori, donc la décision de couper le lien suspect a entrainé ++ de perturbations pour les clients.

L’incident a été résolu sans action softwaymedical.

Ce qui s'est bien passé : Estimation de l’impact client Ca a refonctionné. “Tout seul” on a détecté une perturbation dans nos accès internet Notamment pour citrix et ou Cosem :

règle de nat trop large, qui fait dysfonctionner les accès internet

Accès internet ko sur CRBV :

Aucune

Nombreuses alertes de supervision sur l’indisponibilité de services web

Causes immédiates : Une règle de NAT a induit un duplicate IP sur le réseau entre les ASR & Palo Alto de CRBV/STDN. De ce fait les sessions BGP nécessaires aux services internet étaient hors service. Mise en place d’une règle de NAT pour Epiconcept, pour donner accès à internet à un serveur. La règle a été discutée entre admin et archi, mais une incompréhension a fait qu’elle n’a pas été correctement paramétrée. Y a t’il eu des faits aggravants

Désactivation de la règle de NAT qui posait soucis sur le Palo Alto de CRBV.

Ce qui s'est bien passé : C’est un admin qui réalise une action non courante. Estimation, diagnostic vue des clients. Idée de comm pour le RI : (Flo) Cette erreur a été corrigée à 16h00 La résolution des adresses *.xtremcloud.cloud n’a pas été fonctionnelle sur les dns softwaymedical publics 193.23.123.3 et 193.23.123.193, 15h05 et 16h00. Les Dns softwaymedical internes ont gardé en cache les résolutions. Le fonctionnement

Le 19 mars 2026, la synchronisation entre Doctolib et One Manager (via les composants Tokitomi) a été interrompue pendant plus de 4 heures. Deux pods sur cinq/six étaient en état d'échec (OutOfMemory sur la JVM), ce qui a entraîné l'arrêt de la synchronisation des rendez-vous pour environ 2/5 du parc client interfacé avec Doctolib. L'impact principal a été un risque de surbooking pour les rendez-vous pris sur Doctolib pendant la période de coupure. Aucune perte de données n'a été constatée.

Périmètre technique : 2 pods Tokitomi sur 5-6 en échec → environ 2/5 du parc client interfacé Doctolib impacté Impact fonctionnel : synchronisation des RDV Doctolib interrompue, entraînant un risque de surbooking pour les RDV pris pendant la coupure Données : aucune perte de données ni données erronées Clients ayant remonté un problème : 1 client (Hôpital Franco-Britannique / Cognacq-Jay) a signalé un problème de surbooking Produits impactés : One Manager (module intégration Doctolib / Tokitomi)

Un incident similaire lié à la même cause racine (allocation mémoire insuffisante sur les composants Tokitomi) s'était produit la veille (18 mars) et avait été corrigé, mais la correction n'avait pas suffi à prévenir la récurrence.

L'incident a été détecté par appel client (Hôpital Franco-Britannique) à 16h45, soit plus de 4h après le début du problème. Aucun monitoring n'était en place pour détecter automatiquement la défaillance des pods ou les erreurs OutOfMemory de la JVM.

Causes immédiates : Deux pods Tokitomi sur cinq/six sont tombés en OutOfMemory (java heap space), cessant de traiter les synchronisations Doctolib pour les clients qui leur étaient attribués. Les pods en OOM restaient dans un état instable sans redémarrer automatiquement. Charge en memoire des documents : L’api de doctolib embarque le document dans du JSON, ce qui nous force à charger le document en mémoire. En cas normal, ca ne pose pas de problème mais les composant peuvent traiter plusieurs flux en parallèle pou

Actions immédiates (19 mars) : Redémarrage manuel des pods en échec Augmentation du nombre de pods et de l'allocation mémoire pour les composants Tokitomi Modification de la configuration JVM pour forcer le kill sur OutOfMemory, permettant au container de redémarrer automatiquement en cas d'OOM (plus d'état instable) Mise en place d'un dashboard Grafana pour identifier au plus tôt les problèmes de java heap space

Ce qui s'est bien passé : La réactivité de l'équipe a été excellente : une fois le problème détecté, la résolution n'a pris que 11 minutes (16h45 → 16h56). Le problème avait déjà été corrigé la veille (18 mars), mais la correction s'est avérée insuffisante et l'incident nous est retombé dessus le lendemain. L'absence de monitoring a conduit à une détection par le client directement, plus de 4 heures après le début du probl

L’incident a été remonté par le GHT18 au travers de la demande SF : https://softwaymedical.lightning.force.com/lightning/r/Case/500Sm00000fqSK0IAM/view L’incident est lié à une régression introduite à partir de la version 2601.12. Cette régression provient de la correction d’une mauvaise gestion du contexte entre le bandeau HM et les listes de travail et de Résumé médical. "623343 - [PMSI_RUM] - Perte du contexte en accès au RUM depuis la synthèse générale" "587805 - [PMSI_SMR] - Anomalie naviga

Dans un contexte multi onglet, Mauvaise gestion du contexte entre le Bandeau HM et les fenêtre de navigation. Ceci provoquant des erreurs d’appréciations et des incohérences en base de données avec des risques Patients avérés. 6 clients impactés 19 prescriptions médicament: 2423 : 1 Prescription médicament 3214 : 1 Prescription médicament 2719 : 5 Prescriptions médicament 2844 : 2 Prescriptions médicament 2599 : 2 Prescriptions médicament 2732 : 8 Prescriptions médicament

Aléatoire en fonction du mode d’utilisation des clients, cas particulier sur un usage du multi onglet pour le Dossier Urgence.

Comment l’incident a t’il été détecté? L’incident a été remonté par le GHT18 au travers de la demande SF : https://softwaymedical.lightning.force.com/lightning/r/Case/500Sm00000fqSK0IAM/view

Causes immédiates : Dans un contexte multi onglet, Mauvaise gestion du contexte entre le Bandeau HM et les fenêtre de navigation. Ceci provoquant des erreurs d’appréciations et des incohérences en base de données. L’incident est lié à une régression introduite à partir de la version 2601.12. Cette régression provient de la correction d’une mauvaise gestion du contexte entre le bandeau HM et les listes de travail et de Résumé médical. "623343 - [PMSI_RUM] - Perte du contexte en accès au RUM depuis la synthèse généra

Court / Moyen termes Suppression, via paramétrage, de l’option « Multi Onglets » Renforcement des règles de bon usage auprès des clients concernés par la version 2601.12+ 2601.22 2601.23 Long terme : Stratégie

Ce qui s'est bien passé : Les versions patches. Pas d’alertes Comment on met des gardes fous Notion de session BackEnd vs  Mode Statique multiOnglets Sur le nombre de prescriptions vérolées, il y en a eu peu alors que le problème était live depuis 1 mois.

En lien avec la RFC 2026-001022 et suite validation en CAB activation pour les serveurs VDA de Gpos Hardening Citrix User et Hardening Citrix Computer pour les clients Galaxie de STDN.

Les serveurs CTX sur lesquels la GPO a été appliquée génèrent des dysfonctionnements sur les nouvelles sessions Citrix. Les utilisateurs déjà connectés avant l’application de la GPO ne sont pas impactés. Les dysfonctionnements vont de modules qui ne fonctionnent pas correctement à des messages d’erreur dès le lancement de l’application.

Première fois sur ce sujet.

Remontées du support et des clients

Causes immédiates : Modification de strategie windows. Renforcement de la sécurité Non

Correction via GPO + mise en place sup + traitement manuel Analyse des blocages

Ce qui s'est bien passé : La campagne de test le délai avant lancement de la cellule de crise Les regles du CAB ont ete mise a jour apres la RFC et ne sdont pas encore completement rodées. Non Contexte :

Après décommissionnent (via process automatisé) de rproxy7, l’ip 193.23.123.89 a été libérée. C’était aussi l’ip de production-crbv.xtremcloud.cloud (le tenant avi de production).

Les clients hébergées dont les url des applications sont sur le tenant avi de production-crbv.xtremcloud.cloud n’ont plus accès à l’application.

Très faible.

monitoring zabbix

Causes immédiates : Suppression de l’entrée DNS 193.23.123.89 = production-crbv.xtremcloud.cloud par le job de décommissionnent. Dans ipam, rproxy 7 réserve l’ip 193.23.123.89. Lenteur pour retrouver “l’auteur” des actions. l’utilisateur swm-api, c’est vague, ça ne permet pas de savoir quel actif est intervenu.

Création manuelle de l’entrée DNS A 193.23.123.89.

Ce qui s'est bien passé : Analyse, réaction et mobilisation. Le passage de puppet sur l’apigtw-node3 prend 30min, c’est trop long pour être réactif. Trouver “qui” (quel process automatisé) est difficile, “swm-api” est trop générique.

• Une opération de réplication de volume vers une salle distante a fortement impacté les performances de l’accès au composant de stockage, ce qui a engendré de forts ralentissements sur les applications, allant jusqu’à l’interruption d’accès.

Forts ralentissements sur toutes les applications sur CRBV, allant jusqu’à l’indisponibilité

RI du 05/11 sur le même problème même cause SoftwayMedical - Rapport d'incident du 05-11-2025.pdf

Supervision (1 minutes entre le début de l’événement et le passage en cellule de crise)

Causes immédiates : forte diminution des performances de l’accès au composant de stockage -opération de réplication de volume vers une salle distante -Instabilité d’un port d’attachement. -Débit de la solution ? Un port d’attachement du stockage en défaut intermittent Vitesse des interfaces d’attachement ? Non respect des décisions prises par la cellule de crise (annulation des opérations de rééquilibrage. Cela a fait trainer l’incident, car on attendait juste que ça se termine, jusqu’à quasiment 15h45…) Incompréhe

Arret de la réplication

Ce qui s'est bien passé : la détection Le change management avec notre prestataire Le respect des actions décidées par la cellule de crise. Je ne sais pas par quel miracle on s’est rendu compte qu’il y avait une réplication en cours. Échec de la génération : 423 Client Error: Locked for url: https://graph.microsoft.com/v1.0/sites/medicalsoftway.sharepoint.com,d6942434-828e-4a78-a171-61710c919ee4,caf50903-2106-444f-90c2-952

Licences citrix invalides

Nouvelles connexions citrix impossible sur p01ctx (stdn) entre 11h00 et 12h30. A noter une indispo du seul client qui a son propre fqdn (porté par nous…), centre-medical-ramsaysante.fr, on ne comprend pas pourquoi, entre 14h et 16h.

Aucune

Monitoring sur stdn, client sur crbv

Causes immédiates : La licence citrix netscaler est expirée car le délai de grâce de 30j sans connexion au serveur de licence dans le cloud est atteint. Les règles de pare feu permettant au serveur de licence récemment migré dans le cloud Citrix (février) d’être interrogé par les netscalers ont disparus.

Correction des règles de pare feu Reboot obligatoire pour prise en compte des nouvelles licences

Ce qui s'est bien passé : On n’a pas déclenché “d’incident majeur”, donc l’incident n’a été suivi que par les équipes techniques. Après la correction sur STDN, il n’y a pas eu de vérification sur CRBV. L’heure de fin de licence arrive à un moment où on peut penser que la plupart des utilisateurs ont déjà ouvert la connexion.