📦 Irritants 2026 — tous périmètres (hors Post Mortem)

📣 Communication interneLe runtime Netcore.App 6.0.36 est absent sur le serveur p01gx-gx01 (composant Middleware, Galaxie). Un ticket est ouvert et l'installation du composant manquant est en cours de traitement.

📣 Communication interneConti (groupe ITS) — crash applicatif suivi de lenteurs, latence réseau suspectée (Réseau/LB). Le comportement s'est stabilisé spontanément selon les premiers retours, mais des lenteurs persistent. Surveillance en cours, investigation active.

📣 Communication interneLors de la maintenance planifiée impactant tamm antilles et tamm mascareigne, un vidage de cache a provoqué une extension non prévue de l'interruption au client tamm.cab, hors périmètre planifié. L'incident a été résolu à 13h07 après identification du vidage de cache comme cause racine de l'impact étendu. Le temps d'indisponibilité non planifié pour tamm.cab doit être consolidé à partir des logs pour être communiqué précisément. Une correction technique est planifiée dans une prochaine version afin d'éviter qu'un vidage de cache puisse propager l'impact au-delà du périmètre cible lors des futures maintenances.

📣 Communication interneIncident en cours sur TAMM CAB : les utilisateurs signalent l'affichage d'une page blanche à l'ouverture de l'application. Thomas LOCTEAU a pris en charge l'investigation et a réussi à reproduire le problème en environnement. L'investigation est actuellement focalisée sur l'identification du serveur TAMM CAB responsable du comportement anormal. La root cause n'est pas encore déterminée, aucune action corrective définitive n'a pu être engagée à ce stade. L'impact côté client est une indisponibilité fonctionnelle totale de l'application TAMM CAB — la durée d'indisponibilité est en cours de calcul et sera précisée dès la résolution confirmée.

📣 Communication interneIncident multi-sites affectant deux cliniques du groupe Elsan : lenteurs applicatives et impossibilité d'ajouter des documents signalées sur les sites Conti et Estrée. Deux causes racines distinctes identifiées par Romain BROIS à 16h02 : côté Estrée, coupure du point de montage vers le filer (accès aux fichiers impossible) ; côté Conti, blocage des flux réseau vers les services tiers Imeds, Ameli et DMP, entraînant des dégradations fonctionnelles importantes. La résolution n'a pas été formellement confirmée dans le fil de suivi de l'incident — un point de vérification auprès des équipes techniques et des clients est nécessaire pour clôturer l'incident. Des actions correctives devront être engagées : surveillance des points de montage filer (alerting Zabbix à renforcer si non couvert) et audit des règles de filtrage réseau vers les services tiers pour éviter toute récurrence du blocage de flux sur Conti.

📣 Communication interneIncident de saturation disque sur le serveur MySQL1 ayant entraîné l'indisponibilité complète des environnements PBAY, PROC et PLYO (Ramsay Mediboard). La root cause est une production excessive de slow logs MySQL : 54 Go générés en moins de 24h, saturant intégralement l'espace disque disponible. Ce problème est récurrent et avait déjà été identifié dès le 15/06, sans qu'une action corrective pérenne ait été mise en place entre-temps. Mounir KHIDER est intervenu pour libérer manuellement l'espace disque sur MySQL1, ce qui a permis le retour à la normale des trois environnements. Actions correctives à engager en urgence : mise en place d'une politique de rotation et de purge automatique des slow logs MySQL, surveillance proactive via alerting (Zabbix) sur les seuils d'occupation disque, et traitement définitif de la source des slow queries pour éviter toute récurrence.

📣 Communication interneSuite à la migration d'hébergement du client 2100X3, une saturation CPU a provoqué des lenteurs applicatives importantes côté client, rendant l'application dégradée le temps de l'intervention. La root cause est un sous-dimensionnement des ressources allouées lors de la migration : 4 vCPU / 16 Go RAM se sont révélés insuffisants face à la charge réelle du client, alors que des environnements comparables (2082, 2072) nécessitaient déjà 8 vCPU. Correction appliquée en deux temps : CPU augmenté de 4 à 8 vCPU à 10h05, puis RAM portée de 16 à 32 Go à 10h30. Les tests applicatifs post-intervention ont été validés par Pierre. Action préventive à engager : systématiser la comparaison des profils de charge des environnements de référence avant toute migration afin d'éviter un sous-dimensionnement initial.

📣 Communication interneUne session Oracle bloquante (SID 914) a été détectée sur le serveur P02GX, initiée depuis le poste C11396-CTX02-1, avec une requête DBSCHEMA_INDEXES en attente sur la table CAISSE. Bastien SERRANO a identifié et pris en charge la session bloquante rapidement après détection. La session a été killée côté Oracle pour débloquer la situation. Aucun impact client confirmé côté C11396 à l'issue de l'intervention. Des investigations complémentaires sur l'origine de la requête bloquante (DBSCHEMA_INDEXES / table CAISSE) sont à envisager pour prévenir toute récurrence.

📣 Communication interneLe 16/06/2026 entre ~11h20 et ~11h45, les sites Epiconcept/Voozanoo ont été partiellement inaccessibles depuis l'extérieur (sondes externes). Une correction réseau a été appliquée par Florent LANDUCCI à 11h37, accès confirmé rétabli à 11h45 par Fabrice GIORDAN. Un incident parallèle sur les flux SFTP depuis les IPs 213.223.172.113 / 185.246.99.119 / 185.246.99.115 est également signalé (possible blocage géographique/pare-feu) et reste à investiguer.

📣 Communication interneLe 15/06/2026, une saturation complète de l'espace disque sur le serveur SQL1 a provoqué une indisponibilité des services pour les clients PLYO, PBAY et PROC. La cause racine est une saturation disque sur SQL1, sans mécanisme d'alerte préventive suffisamment anticipé — point à adresser en actions correctives (révision des seuils Zabbix sur les volumes SQL). KHIDER Mounir est intervenu à 07h13 et a libéré 10 Go d'espace disque sur SQL1, permettant le rétablissement du service confirmé à 07h16 par VINCENT Caroline, soit une durée d'indisponibilité estimée à environ 3 minutes entre l'action corrective et la confirmation de rétablissement (durée totale depuis apparition du symptôme non renseignée, à préciser). Actions post-incident à engager : audit de l'occupation disque sur l'ensemble des serveurs SQL, mise en place ou révision des alertes de seuil critique sur les volumes concernés, et investigation sur l'origine de la croissance disque (logs, fichiers tempdb, sauvegardes non purgées).

📣 Communication interneIncident de saturation disque sur sql1 ayant entraîné l'indisponibilité des instances PLYO, PBAY et PROC à partir de 3h du matin. La root cause est une production excessive de binlogs et slow logs (~4 Go/h depuis le vendredi 17h), générée par un flux documentaire depuis tamm.cab vers la sauvegarde bouclant toutes les minutes avec un zip de 50 Mo encodé en base64 (~70 Mo en base), saturant progressivement l'espace disque de sql1. KHIDER Mounir a libéré 10 Go sur sql1 à 07h13, permettant le rétablissement immédiat des accès — soit une indisponibilité estimée à environ 4h. BERTONNIER Florian a ensuite identifié et supprimé le document à l'origine du flux bouclant à 15h51, et BROIS Romain a confirmé à 20h20 une diminution drastique des slow logs, validant la résolution complète de la cause racine. Actions correctives engagées : suppression du document source du flux, surveillance de la production de logs et de l'espace disque à renforcer pour détecter ce type de dérive plus tôt (alerting Zabbix sur croissance anormale des binlogs/slow logs à revoir).

📣 Communication interneIncident Galaxie V8 sur le client C000333 (COSEM) : le pool IIS du serveur c000333-gx01 s'est retrouvé arrêté lors d'une manipulation en cours sur le serveur (présence d'un fichier zippé en place), rendant l'application indisponible pour le client. La root cause est une procédure de manipulation incorrecte : aucune copie préalable n'a été effectuée avant intervention, ce qui a conduit à l'arrêt du pool IIS. Jordane CHAGNIOT a redémarré le pool IIS à 14h46, rétablissant le service. Une action corrective est à engager : la procédure doit être corrigée pour imposer une copie préalable des éléments avant toute manipulation sur les serveurs de production, afin d'éviter toute récurrence.

📣 Communication interneRedémarrage planifié des serveurs CTX associés aux clients IDEM11205, IDEM11103, IDEM11354 et XTS000562, effectué à la demande de Pierrick RIVET. Aucun symptôme d'incident déclaré — il s'agit d'une opération de maintenance programmée. Le redémarrage a été réalisé par Matthias HECKTOR le dimanche soir et confirmé le 15/06 comme effectif et nominal. Aucune anomalie technique signalée post-redémarrage. Aucune action corrective ou préventive particulière à engager, l'opération s'étant déroulée conformément au plan.

📣 Communication interneMediboard PDS indisponible pendant 1h30 le 12/06 suite au redémarrage des serveurs par l'hébergeur client : le service haproxy n'a pas redémarré automatiquement. Redémarrage manuel des services web et haproxy effectué, service rétabli, MySQL et réplication OK.

📣 Communication interne11/06 ~12h27 : pages blanches et accès consultation KO sur TAMM Cab et TAMM Galaxie (serveurs .8 et .10) suite à MàJ. Restart php-fpm effectué par Mounir KHIDER sur P01VL et liberal2 — service rétabli à 12h42 (durée ~15 min).

📣 Communication interneIncident de connexion sur le client C000300 : le serveur CTX02 est devenu inaccessible, entraînant une impossibilité de connexion pour les utilisateurs. Suite à l'indisponibilité de CTX02, CTX01 a également été impacté et s'est retrouvé indisponible consécutivement. Anthony LUCCHESI est intervenu et a procédé au redémarrage de CTX02 puis de CTX01, rétablissant la connexion sur les deux serveurs à 18h56. La root cause est un crash du serveur CTX02 nécessitant un redémarrage forcé, ayant entraîné en cascade l'indisponibilité de CTX01. Des actions de surveillance renforcée sur ces deux serveurs sont à envisager pour prévenir toute récurrence.

📣 Communication interneDepuis 08h55 le 10/06/2026, des lenteurs ont été signalées sur l'application TAMM pour le client TAMM Cab, en lien avec un impact présumé sur le datacenter STDN. LOCTEAU Thomas a été impliqué dans l'investigation côté infra, mais n'a pas pu confirmer de dégradation de l'infrastructure à ce stade. La root cause n'a pas été identifiée dans ce fil : aucune anomalie infra validée, aucune alerte Zabbix ou autre outil de supervision mentionnée comme déclencheur. La résolution n'est pas documentée — l'incident reste ouvert faute de confirmation de retour à la normale. Des investigations complémentaires sont nécessaires pour confirmer l'origine (réseau, datacenter STDN, applicatif TAMM) et documenter la clôture formelle de l'incident.

📣 Communication interneSEV-1 en cours — Faille de cloisonnement des droits d'accès inter-clients sur le composant Stockage (Galaxie), identifiée via pentests Haussmann Vision et Centre2soins/CD59. Correctif disponible dans Galaxie Desktop 8.014R6A (paramètre admin à activer côté client) ; reprise manuelle des droits NTFS en cours (DC Courbevoie OK, DC Saint Denis en déploiement).

📣 Communication interneDes lenteurs ont été signalées sur l'application TAMM pour le site Ramsay — Hôpital Privé, concomitamment aux ralentissements STDN survenus le 09/06 au matin. Aucun message d'erreur applicatif n'a été identifié côté TAMM, ce qui oriente la cause vers une dégradation infrastructure réseau/STDN externe à l'applicatif. La résolution a été confirmée par Romain BROIS à 08h40 avec un retour à la normale ('Tout va bien'). La durée exacte d'indisponibilité n'est pas précisément documentée, mais l'incident est circonscrit à la fenêtre de ralentissement STDN du matin du 09/06. Aucune action corrective applicative spécifique n'a été engagée, la cause étant externe ; il est recommandé de renforcer le suivi des alertes STDN pour anticiper ce type d'impact sur TAMM.

📣 Communication interneIncident de lenteurs générales constaté sur l'ensemble des instances TAMM hébergées sur le datacenter STDN (tamm.cab, Libéral 2, Galaxie TAMM, etc.), se traduisant par des ralentissements significatifs pour les utilisateurs. La cause racine identifiée est un ralentissement au niveau de l'infrastructure STDN, sans qu'une cause technique précise n'ait pu être déterminée à ce stade dans le fil de traitement. Un retour partiel à la normale a été signalé par RIBOULEAU Stéphane vers 09h39, mais aucune confirmation définitive de résolution complète n'a été formalisée. La durée d'impact n'a pas pu être calculée précisément faute d'horodatage de début d'incident dans les données disponibles. Des actions de suivi sont nécessaires : confirmer la résolution complète auprès de STDN, identifier la cause précise côté datacenter, et mettre en place une surveillance renforcée sur les métriques d'infrastructure STDN pour détecter ce type de dégradation plus tôt.

📣 Communication interneSuite à une intervention réseau, des flux ont été bloqués pendant ~8h sur l'environnement Epiconcept/Voozanoo. Les équipes réseau SWM (GOUPIL Guillaume, GOIFFON Willy) avec GIORDAN Fabrice ont corrigé les flux en erreur dans la matinée ; le flux smtp.intermedic.org:587 a été identifié comme bloqué et est traité via SF 03655641. Des tickets complémentaires (03655632, 03655640, 03655641) couvrent la réouverture des flux pop, un nouveau flux admin/sat et le SNAT associé.

📣 Communication interneSuite à une intervention réseau dans la nuit du 08 au 09/06/2026, des difficultés de routage ont été constatées sur les environnements Epiconcept/Voozanoo. L'incident est indiqué comme résolu, mais la résolution n'est pas documentée — merci de confirmer et de renseigner le détail de la correction appliquée.

📣 Communication interneLenteurs sur TAMM Libéral 2 empêchant l'ouverture des consultations — problème isolé par Thomas Locteau sur le serveur 10.39.175.35, investigation en cours.

📣 Communication interneRalentissement applicatif détecté sur le client C3335 entre 11h41 et 11h50 (durée : ~9 minutes), se manifestant par une dégradation des performances de l'application. L'analyse des logs révèle un empilement de workers sur le Tomcat 29 avec deux causes identifiées : une erreur sur comptabilite.selectionfactures ayant fortement saturé le Tomcat 29, et des erreurs ClassCastException sur aff.portail.do multipliées par 3 durant la fenêtre d'incident. L'incident s'est résolu spontanément à 11h50 sans intervention manuelle. La cause racine précise n'est pas encore établie — une investigation squad doit être initiée pour approfondir l'analyse post-incident et déterminer l'origine des deux erreurs identifiées. Des actions correctives et préventives seront définies à l'issue de cette investigation.

📣 Communication interneUn état d'alimentation inconnu a été détecté sur l'ensemble des VMs Citrix des deux datacenters, affectant potentiellement tous les clients utilisant notre infrastructure Citrix. La cause racine exacte n'a pas été documentée à ce stade, ce qui constitue un point d'amélioration à adresser en post-mortem. Valentin BARRET a pris en charge l'incident et a résolu le problème à 13h09, sans impact client signalé côté production. Aucune indisponibilité effective n'a été remontée par les clients malgré le périmètre étendu de l'alerte (deux datacenters). Il est recommandé de documenter précisément la cause racine, de vérifier les alertes de supervision associées et de mettre en place des contrôles préventifs sur l'état d'alimentation des VMs Citrix pour éviter une récurrence non détectée.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur c000333-ctx02 pour saturation du volume C: (espace disque < 20%). La cause racine est une accumulation de profils utilisateur Edge volumineux (426 profils) combinée à des fichiers applicatifs et des backups Vidal non purgés. Yohann GEMMIER est intervenu et a procédé à la suppression de deux fichiers volumineux identifiés comme principaux responsables de la saturation. Une purge des backups Vidal reste à planifier pour éviter une récurrence à court terme. Il est recommandé de mettre en place une politique de nettoyage régulier des profils Edge et des backups sur ce serveur pour le client C000333 (COSEM).

📣 Communication interneIncident de performance critique sur le microservice Vidal entre 16h00 et 21h17 (environ 5h17 de dégradation) impactant 4 clients (3444, 3241, 3528, 3449) : suite au déploiement automatisé de la mise à jour Vidal (309-3.2 → 309-4.2) à 16h00, la configuration YAML OpenShift indiquait 3 réplicas alors que le nombre avait été porté manuellement à 8 directement dans OpenShift — le déploiement a réappliqué la valeur YAML et ramené les pods à 3, provoquant une dégradation sévère des performances sur la fonctionnalité de prescription Vidal. Le retour à la normale a été constaté vers 21h17, probablement aidé par un vidage du cache Varnish. Actions correctives engagées le 02/06 au matin : mise à jour du YAML OpenShift pour fixer officiellement le nombre de réplicas Vidal à 8, et activation d'une supervision dédiée sur vidal-prod. Action préventive à prévoir : s'assurer que toute modification manuelle du nombre de réplicas dans OpenShift est systématiquement répercutée dans le YAML avant tout prochain déploiement automatisé, afin d'éviter tout écrasement silencieux de la configuration de production.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur p02gx-gx07-1 pour le service eHubHL7_C11157_1028 non démarré, impactant le client C11157 sur la réception/transmission de flux HL7. La root cause identifiée est un service eHubHL7 laissé en place après désinstallation, sans nettoyage des artefacts — oubli de procédure lors de la désinstallation. SETTAMA Yachan a pris en charge l'incident, identifié le service comme orphelin et procédé à sa suppression pour résoudre le problème. Il est recommandé de renforcer la checklist de désinstallation des services eHubHL7 afin de systématiser le nettoyage des services résiduels et éviter toute récurrence de ce type.

📣 Communication interneLes instances de contrôle test Mediboard ont été impactées suite à une chute de serveurs AWS, sans aucun effet sur les environnements de production. BROIS Romain a identifié et isolé le problème, MURCY Steven a confirmé la remontée côté Mediboard et un fix a été engagé côté TM. Le retour à la normale a été confirmé à 09h53. Les clients concernés étaient uniquement sur des environnements non-prod (HUDON Doriane, Antoine). Aucune action corrective côté infrastructure interne n'est requise, la cause étant externe (incident AWS) ; une vigilance sur la surveillance des instances de contrôle test est recommandée pour détecter plus rapidement ce type d'impact à l'avenir.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur CTX c000333-ctx05 (COSEM) pour saturation de l'espace disque sur le volume C: (seuil critique < 20% atteint). La root cause est une saturation du disque C: sur le serveur Citrix dédié au client COSEM, pouvant entraîner une dégradation ou une indisponibilité des sessions applicatives pour les utilisateurs. Aucune résolution documentée n'est disponible dans le fil de l'incident, ce qui ne permet pas de confirmer la nature ni le délai de l'action corrective appliquée. Il est impératif de documenter les actions menées (nettoyage, extension de volume, déplacement de données) ainsi que les mesures préventives (seuils d'alerte, politique de rétention, supervision renforcée) pour éviter toute récurrence. Le temps d'indisponibilité réel ne peut pas être calculé en l'absence d'horodatage de résolution dans le ticket.

📣 Communication interneLe 27/05 entre ~13h43 et 14h08, le serveur IIS COSEM était KO (pool IIS en défaut). PORTAL Thomas et BARCUCCI Johan ont redémarré le pool IIS ; la connexion applicative est rétablie depuis 14h08.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur c000024-ctx02 : espace disque insuffisant sur le volume C: (seuil < 20% atteint). La cause racine identifiée est une accumulation de fichiers CrashDumps ayant saturé le disque système. Aucun symptôme fonctionnel remonté par le client, mais la saturation du volume C: aurait pu entraîner une indisponibilité applicative si non traitée. Guillaume PASCAL (SMI) est intervenu et a procédé à la suppression des fichiers CrashDumps, ce qui a permis de restaurer un espace disque suffisant et de clore le ticket. Il est recommandé de mettre en place une politique de purge automatique des CrashDumps sur ce serveur afin d'éviter toute récurrence.

📣 Communication interneLe serveur IIS de l'application Galaxie Ramsay (B.U. Ville) était KO pendant 21 min le 27/05/2026. Connexion rétablie à 14h06 par Pierrick RIVET (équipe SMI). Incident résolu.

📣 Communication interneIncident en cours sur Mediboard pour le client Ramsay Clinique Atlantique : des écrans bleus ont été signalés par les utilisateurs Mediboard (PROC signalé), indiquant une indisponibilité ou forte dégradation de l'application. L'investigation menée par BROIS Romain a permis d'identifier une grosse requête comme cause probable des perturbations, ayant vraisemblablement saturé les ressources et provoqué les crashes côté client. La root cause exacte est encore en cours de confirmation, aucune résolution définitive n'a été appliquée à ce stade. Les actions correctives (isolation et traitement de la requête fautive) sont en cours ; des mesures préventives sur le monitoring et le contrôle des requêtes lourdes devront être envisagées post-incident. L'équipe reste mobilisée jusqu'à stabilisation complète de l'environnement.

📣 Communication interneUn blocage de connexion via Wallix a rendu impossible l'accès aux deux serveurs Citrix C11157-ctx01-1 et ctx02-1 pour le client C11157, entraînant une indisponibilité totale des sessions utilisateurs sur ces nœuds. La root cause est un blocage au niveau du bastion Wallix, sans qu'un symptôme précis ait été documenté en amont. CHAGNIOT Jordane a pris en charge le diagnostic et la résolution du blocage Wallix, rétablissant la connexion à 18h33. La durée exacte d'indisponibilité ne peut être calculée précisément faute d'horodatage de début d'incident, mais l'impact client est avéré sur l'ensemble des accès transitant par Wallix vers ces deux serveurs CTX. Des actions correctives et préventives doivent être engagées pour surveiller et fiabiliser les sessions Wallix sur ce périmètre, notamment via la mise en place d'alertes proactives.

📣 Communication interneLe 26/05/2026 à partir de 10h09, des ralentissements globaux ont été constatés sur l'ensemble du datacenter STDN, impactant tous les clients TAMM hébergés sur cette infrastructure (TAMM Libéral, TAMM CAB, TAMM Galaxie, etc.). Un timeout sur un import XML côté TAMM Libéral 2 a été initialement identifié comme piste, mais il s'agit d'une conséquence des ralentissements STDN et non de la cause racine. La cause racine réelle est un ralentissement global au niveau du datacenter STDN, dont l'origine précise n'a pas été documentée ni résolue dans le fil d'incident. La résolution effective n'est pas tracée : il est nécessaire de compléter le post-mortem avec l'heure de retour à la normale, les actions correctives engagées côté infrastructure STDN, et les mesures préventives à mettre en place pour éviter qu'un incident datacenter se propage sans détection rapide via Zabbix ou équivalent.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur CTX c000333-ctx15 pour saturation du volume C: (espace disque inférieur à 20%). La cause racine identifiée est une accumulation de profils utilisateurs et de fichiers temporaires sur le disque système du serveur Citrix, entraînant un risque de blocage des sessions utilisateurs. Aucune résolution formelle n'a été documentée dans le fil d'incident, ce qui nécessite un suivi immédiat pour confirmer les actions correctives réalisées (nettoyage des profils, purge des fichiers temp, extension ou redimensionnement du volume si nécessaire). Des mesures préventives doivent être engagées : mise en place de politiques de nettoyage automatique des profils temporaires et des fichiers temp sur les serveurs CTX, et ajustement des seuils d'alerte pour anticipation plus précoce. Le client COSEM (C000333) est potentiellement impacté par une dégradation ou un blocage des sessions Citrix si le disque atteint la saturation complète.

📣 Communication interneIncident réseau opérateur : perte de la VISP1 Alphalink (l'un des 2 points d'attache côté opérateur pour les liens clients), entraînant l'indisponibilité ou la dégradation de connexion pour environ 50% des clients sur liens Alphalink. Le client Langogne (C2775) a été le plus fortement impacté, avec une impossibilité de connexion de la détection de l'incident jusqu'à 11h33. La récupération de la VISP1 Alphalink est intervenue automatiquement à 11h21, sans action de notre part, les clients concernés ayant basculé sur leurs liens secondaires le temps de la perturbation. La cause exacte de la perte de la VISP1 est toujours en cours d'investigation chez Alphalink, un suivi post-incident est attendu de leur part. Aucune action corrective interne n'a été nécessaire pour la résolution, mais le retour d'analyse de l'opérateur devra être exploité pour évaluer les mesures préventives à mettre en place côté architecture réseau.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur p02gx-gx04 : l'espace disque du volume D: est passé sous le seuil critique des 20% de disponibilité. Aucun symptôme applicatif remontant côté client n'est précisé à ce stade, mais la situation présente un risque d'indisponibilité ou de dégradation des services hébergés sur ce volume si aucune action n'est entreprise rapidement. La cause racine est une saturation progressive du volume D:, sans mécanisme de purge ou d'alerte préventive suffisamment tôt pour éviter le franchissement du seuil. La résolution est actuellement en attente d'une libération d'espace disque sur le volume concerné. Des actions correctives sont à engager : nettoyage des fichiers inutiles, purge des logs ou archives, et mise en place si nécessaire d'une politique de supervision plus fine pour anticiper ce type de situation à l'avenir.

📣 Communication interneMontée anormale des sessions Oracle sur le groupe P23HM détectée, impactant 10 clients (C2399, C2584, C2713, C3241, C3592, C3602, C3613, C3617, C3662, C3701) avec des verrous en cascade sur la table BAS_COMPTEURS générés par des SELECT FOR UPDATE non libérés, rendant les demandes de biologie inutilisables. La root cause est une régression introduite dans les versions 1.2509.36, 1.2601.23 et 1.2603.06 : un nouveau développement sur les numéros de prescription entre en conflit avec le paramètre BIO_PLAGE_NO_DEM_DEB lorsque sa valeur est supérieure au compteur réel, ce qui génère ces verrous bloquants en boucle. Contournement appliqué en urgence : passage du paramètre BIO_PLAGE_NO_DEM_DEB à NULL sur les environnements impactés, ce qui stoppe immédiatement les verrous et restaure la prescription sans risque de doublon ni rupture HL7 ; kill régulier des sessions bloquantes assuré en parallèle pendant la fenêtre d'intervention. Les clients ont été invités à ne plus utiliser les demandes de biologie le temps de la résolution définitive. Un fix correctif est actuellement en cours de validation par la squad DEV et devra être déployé sur les trois versions concernées pour clôturer définitivement l'incident.

📣 Communication interneImpossibilité de se connecter au serveur CTX01 du client COSEM (C000333) via Wallix avec le compte swm_galaxie. La root cause est que le serveur CTX01 était placé en mode maintenance, ce qui bloquait toute tentative de connexion via Wallix pour ce compte. MARINO Damien est intervenu en sortant temporairement le serveur du mode maintenance afin de permettre à GEMMIER Yohann d'effectuer son intervention, puis l'a remis en maintenance à l'issue. Aucune action corrective ou préventive formelle n'est documentée à ce stade, il est recommandé de systématiser la vérification du statut de maintenance des serveurs avant toute tentative de connexion via Wallix, et d'alerter les équipes concernées en amont pour éviter ce type de blocage.

📣 Communication interneSuite au déploiement de la mise à jour de midi, toutes les instances TAMM (Liberal2, Galaxie, MSP, P03TM, P05TM) ont été impactées par des pages blanches et des erreurs JavaScript côté client, causées par un cache PHP corrompu entraînant des erreurs 404 sur certains fichiers JS selon le serveur frontal atteint. La résolution a été assurée par Mounir KHIDER via le redémarrage du service PHP sur les serveurs P05TM (tamm-galaxie) et P03TM (liberal2 / msp), ce qui a permis de rétablir le service. À noter : un problème sous-jacent de cache PHP persistant a été identifié et n'est pas encore résolu — une investigation complémentaire est en cours pour en déterminer l'origine exacte et éviter toute récurrence. L'impact client a consisté en une indisponibilité totale de l'interface TAMM sur l'ensemble des instances concernées pendant la durée de l'incident. Des actions correctives et préventives sont à engager sur la gestion du cache PHP lors des déploiements afin d'éviter ce type de régression.

📣 Communication internePerte NTP détectée sur l'environnement de preprod (Réseau/LB) le 20/05/2026. Incident ouvert, aucune résolution documentée à ce stade. Investigation en cours.

📣 Communication interneAlerte Zabbix détectée : le service eHubHL7_C000475 est arrêté sur le serveur p02gx-gx07-1, impactant les flux HL7 du client C000475. La tentative de redémarrage manuel du service a échoué, la cause racine reste inconnue à ce stade et nécessite une investigation approfondie. Le client C000475 est en situation d'indisponibilité sur l'ensemble des flux HL7 traités par ce service tant que le problème n'est pas résolu. L'incident est actuellement ouvert, aucune résolution n'a encore été appliquée — une analyse des logs du service et de l'environnement système est nécessaire en priorité pour identifier la cause de l'échec au redémarrage. Des actions correctives et préventives (supervision renforcée, analyse post-mortem du service eHubHL7) seront engagées une fois l'incident résolu.

📣 Communication interneZabbix a déclenché une alerte de saturation disque sur le volume C: du serveur Citrix c000333-ctx34, hébergeant les sessions du client COSEM (c000333). La saturation du disque C: constituait la root cause de l'incident, pouvant entraîner une dégradation ou une indisponibilité des sessions Citrix pour les utilisateurs du client. Yohann GEMMIER est intervenu pour effectuer un ménage sur le volume concerné, permettant la résolution de l'incident et la disparition de l'alerte Zabbix à 09:19. Il est recommandé de mettre en place un suivi préventif de l'espace disque sur ce serveur et d'automatiser si possible les purges de fichiers temporaires ou logs pour éviter toute récurrence.

📣 Communication interneEntre 9h et 9h30, des utilisateurs de TAMM Libéral (liberal2.tamm.cab) ont signalé l'affichage d'une page blanche lors de l'accès à l'application. Suite au signalement, KHIDER Mounir a procédé à une vérification complète de l'infrastructure : le service liberal2 était bien up et opérationnel sur l'ensemble des serveurs frontaux, sans aucune anomalie détectée. Aucun incident technique côté infrastructure n'a pu être confirmé ; la cause racine est vraisemblablement un incident transitoire isolé côté utilisateur (problème réseau local, cache navigateur, session expirée, etc.). L'incident est donc classé sans suite côté infrastructure, avec une durée de perturbation estimée à 30 minutes maximum sur la fenêtre 9h–9h30. Aucune action corrective infrastructure n'est requise à ce stade, mais il est recommandé de sensibiliser les utilisateurs aux procédures de premier niveau (vidage de cache, reconnexion) pour les incidents transitoires similaires.

📣 Communication interneAlerte Zabbix déclenchée sur le serveur Citrix COSEM (c000333-ctx20) : l'espace disque du volume C: est passé sous le seuil critique des 20%. L'incident n'a pas engendré d'indisponibilité applicative déclarée, mais représentait un risque réel de saturation pouvant impacter les sessions Citrix des utilisateurs COSEM. GEMMIER Yohann est intervenu et a effectué un ménage sur le volume C:, permettant la résolution de l'alerte à 13h19. Aucune action corrective structurelle n'est documentée à ce stade ; il est recommandé d'analyser l'origine de la consommation disque (logs, fichiers temporaires, profils) afin d'éviter une récurrence et d'envisager une politique de nettoyage automatique ou un ajustement des seuils d'alerte.

📣 Communication interneUne opération de restauration d'environnement pour le client C2563 sur le groupe Oracle Q03HM a généré des perturbations en cascade impactant l'ensemble des environnements hébergés sur ce groupe, soit plus de 40 clients HM. Les indisponibilités ont été de durée variable selon les environnements concernés, liées aux effets de bord de l'opération de restauration sur l'instance Oracle partagée. L'incident a été détecté et pris en charge rapidement, avec un retour à la normale confirmé à 10h55 après une durée totale d'environ 23 minutes. Point d'action post-incident : renforcer les procédures de restauration sur environnements mutualisés afin d'isoler les opérations à risque et éviter tout impact collatéral sur les autres clients du groupe Oracle.

📣 Communication interneL'application Galaxie présentait des plantages répétés sur le serveur CTX24 du client COSEM (C000333), rendant l'environnement instable et impactant la disponibilité de l'application pour les utilisateurs. La cause racine n'a pas encore été identifiée à ce stade, l'investigation est en cours. En attente de diagnostic approfondi, le CTX24 a été basculé en mode maintenance afin de stabiliser l'environnement et limiter l'impact client. Des investigations complémentaires sont nécessaires pour identifier l'origine des plantages (logs applicatifs, ressources serveur, conflits de sessions à analyser). Un suivi rigoureux est attendu pour documenter la root cause dès qu'elle sera établie et définir les actions correctives associées.

📣 Communication interneKO total sur toutes les instances Mediboard de Vivalto : le port 3306 (MySQL) a été bloqué côté réseau client, rendant impossible toute connexion aux bases de données et provoquant une indisponibilité complète de l'application pour l'ensemble des utilisateurs Vivalto. La root cause est un blocage réseau opéré par l'équipe infrastructure de Vivalto elle-même, sans coordination préalable avec nos équipes. Après identification du blocage sur le port 3306 comme point de défaillance unique, la résolution a été escaladée et prise en charge intégralement côté client par leur équipe réseau. Aucune action corrective n'était possible de notre côté, l'incident étant hors de notre périmètre technique. Il est recommandé de formaliser avec Vivalto un processus de communication préalable avant toute modification de leur infrastructure réseau impactant nos flux applicatifs.

📣 Communication interneIncident de type corruption de données détecté sur la base Oracle P05OM (environnement OMSAAS2), ayant entraîné une indisponibilité applicative nécessitant une bascule PRA effectuée à 12h53. Suite à la bascule, l'instance Oracle de PRA s'est révélée insuffisamment dimensionnée pour absorber la charge, provoquant une seconde vague d'instabilités. Un arrêt forcé de la base a été décidé à 14h10, suivi d'un redémarrage réussi avec retour de la base à 14h21 et confirmation de l'accessibilité applicative à 14h21 (heure de stabilisation définitive). La durée totale d'indisponibilité est estimée à environ 1h30, en cumulant les deux phases d'incident. Actions correctives engagées : ajustements de sizing sur l'instance Oracle PRA pour éviter toute sous-capacité lors d'une prochaine bascule, et analyse de la cause racine de la corruption initiale à poursuivre.

📣 Communication interneIncident de sécurité signalé sur la base One Manager du client IMACIMES : des modifications de paramétrage non autorisées ont été détectées, potentiellement liées à une intrusion externe selon le client. En conséquence directe, une panne OM a entraîné l'impossibilité pour le Dr Boulinguez de facturer. Une investigation est en cours via Graylog afin d'identifier les utilisateurs à l'origine des modifications de paramétrage suspectes. Les équipes suivantes sont mobilisées : BANDA Rémi, LEGRAND Maxime, ALVARO Christophe, LANDUCCI Florent et BABAYAN Alexandre. Aucune résolution définitive n'est encore confirmée à ce stade ; la priorité est d'identifier l'origine des modifications et de sécuriser la base.

📣 Communication interneAlerte reçue de la part du client IMACIMES (Dr Boulinguez) suite à des modifications suspectes sur des fiches PS dans One Manager, conduisant à une suspicion de piratage. L'accès HTTPS a été coupé préventivement par l'équipe en attente d'investigation. Analyse des logs Graylog par BANDA Rémi : les modifications ont été tracées et attribuées à une nouvelle secrétaire du cabinet qui avait effectué des changements de paramétrage sans en informer l'équipe interne — aucun piratage confirmé. Root cause identifiée : l'alerte mail générée lors de modifications de fiches PS ne mentionne pas l'identité de l'utilisateur responsable, ce qui a empêché le client de faire le lien avec ses propres utilisateurs. Accès HTTPS rétabli à 12h40 après validation client. Action corrective engagée : création d'une fiche réflexe par PELOSO Agnès, et il sera nécessaire d'enrichir les alertes mail de modification PS avec l'identité de l'utilisateur responsable pour éviter toute nouvelle fausse alerte de ce type.

📣 Communication interneDes erreurs de connexion intermittentes ont été constatées sur le serveur Citrix c000333-ctx01 pour le client COSEM, empêchant les utilisateurs de se connecter correctement via RDP. La root cause identifiée est double : un nombre de licences RDP insuffisant et une contrainte de configuration GPO inadaptée sur la GPO 'GALAXIE'. SAMSON Benoit a procédé à la modification de la GPO 'GALAXIE' en ajoutant 1000 licences RDP sans contrainte d'OS, ce qui a résolu les erreurs de connexion. BARRET Valentin a validé la résolution en confirmant que l'erreur n'est plus reproductible. RIVET Pierrick a informé LLORCA Sonia afin qu'elle recommunique la résolution au client COSEM.

📣 Communication interneL'environnement Qualif de Saint-Odile (BU Ville) est KO depuis ce matin. MARTINELLI Florian a pris en charge l'incident à 06h56, investigation en cours.

📣 Communication interneAlerte Zabbix : espace disque libre inférieur à 20 % sur le volume F: du serveur p01gx-dfs.swmcloud.net (Galaxie). Ticket 03601592 ouvert, aucune résolution documentée à ce stade — suivi en cours.

📣 Communication interneIndisponibilité totale de l'application pour le client P05TM (galaxie.tamm.cab + tamm_galaxie_guyane) consécutive à des dommages sur une table MySQL, eux-mêmes liés à l'incident du 04/05/2026. Le moteur MySQL a déclenché une réparation automatique de la table corrompue, rendant l'application inaccessible ; les serveurs Apache ont été volontairement stoppés pour réduire la charge sur MySQL et accélérer la réparation. L'application a été restituée à 10h49 après finalisation de la réparation automatique et redémarrage des Apache. Point d'attention post-résolution : la réplication MySQL est temporairement hors service, l'application tourne sur une instance unique avec un risque de dégradation des performances — ce point doit être suivi et traité en priorité. Des actions correctives sur la stabilité de la base et la réplication sont à engager pour éviter toute récurrence liée à cet enchaînement d'incidents.

📣 Communication interneAlerte Zabbix : espace disque libre inférieur à 20 % sur le volume C: du serveur c10723-ctx01-1.swmcloud.net (BU Galaxie). Incident ouvert au 2026-05-05, aucune action corrective documentée à ce stade — une analyse et un nettoyage/extension du volume sont à initier.

📣 Communication interneLe 05/05, une table MyISAM corrompue (user_action) a rendu P05TM indisponible pour TAMM Guyane pendant ~4h. Réparation de la table effectuée via mysqlcheck, réplication relancée à 11h49, retour nominal confirmé à 12h01.

📣 Communication interneAlerte de supervision : espace disque disponible inférieur à 20 % sur le volume C: du serveur c000333-ctx02.swmcloud.net (BU Galaxie). L'incident est ouvert et en attente de prise en charge.

📣 Communication interneLe 04/05, les utilisateurs TAMM Libéral ont rencontré un dysfonctionnement multi-composants pendant environ 3h. L'incident a été résolu dans le cadre de l'incident majeur du 04/05.

📣 Communication interneSuite à l'incident majeur de stockage STDN du 04/05, une rupture de réplication MySQL a été détectée sur le nœud P03TM, servant l'environnement TAMM Libéral 2 (liberal2.tamm.cab). Le serveur P03TM était complètement KO selon Stéphane RIBOULEAU, rendant l'application indisponible pour l'ensemble des utilisateurs de cet environnement. La root cause est directement liée à l'incident de stockage STDN qui a provoqué la rupture de la réplication MySQL sur ce nœud. La résolution a été menée dans le cadre de l'incident majeur du 04/05 : le mode slave a été désactivé sur P03TM et la réplication a été confirmée opérationnelle, sans corruption de données détectée sur ce nœud. Des vérifications complémentaires sur l'intégrité de la réplication et la stabilité du stockage STDN doivent être conduites pour prévenir toute récurrence.

📣 Communication interneSuite à un incident datacenter, une rupture de réplication a entraîné la désactivation du mode slave sur les frontaux P01TM, rendant invisibles en temps réel les manipulations effectuées par les utilisateurs TAMM CAB pendant la période de dégradation. Les données saisies durant cette fenêtre n'étaient pas synchronisées, provoquant une perte apparente de manipulations côté client. La résolution a consisté à remettre les frontaux P01TM en mode nominal après vérification exhaustive de la cohérence des tables, opération finalisée le 05/05 à 07h17 — la durée d'indisponibilité effective dépend du début de la rupture de réplication, non renseigné dans les données transmises. Les données ont été vérifiées et confirmées conformes après test post-rétablissement. En actions correctives, il convient de renforcer la supervision de l'état du mode slave (via Zabbix ou équivalent) et de définir une procédure d'alerte automatique en cas de rupture de réplication afin d'éviter toute période silencieuse de ce type.

📣 Communication interneLe 04/05/2026, l'instance de Medipôle Hôpital Mutualiste a subi une indisponibilité d'environ 5 à 6 minutes. La cause racine identifiée est l'exécution simultanée de deux requêtes particulièrement lourdes ayant provoqué une surcharge temporaire de l'instance. MARTINELLI Florian a détecté et identifié ces deux requêtes au moment de l'incident. La résolution est intervenue spontanément une fois la surcharge résorbée, sans intervention corrective manuelle nécessaire. Le client a été informé ; des analyses complémentaires sur ces requêtes problématiques sont à envisager pour éviter toute récurrence.

📣 Communication interneSuite à l'incident STDN du 04/05, les frontaux P01TM de TAMM.cab ont été remis en mode nominal le 05/05 à 07h17 après vérification des tables et relance du mode slave. Durée totale d'impact : 21h.

📣 Communication interneSuite à une mise en production sur TAMM Libéral 2, une désynchronisation des fichiers JS entre les serveurs web a provoqué une instabilité applicative avec apparition de pages blanches à l'ouverture des consultations — les hashs de build différaient selon les serveurs, certains étant encore sur l'ancienne version. L'impact client s'est traduit par une indisponibilité fonctionnelle de l'accès aux consultations pour les utilisateurs TAMM Libéral 2. BROIS Romain a pris en charge la résolution en procédant à un rebuild et un redéploiement JS serveur par serveur afin de rétablir la cohérence des fichiers. L'incident a été résolu à 09h16 et confirmé stable à 09h33. Des actions correctives doivent être engagées sur le processus de déploiement afin de garantir la synchronisation des builds sur l'ensemble des serveurs web avant remise en service, notamment via une vérification systématique des hashs post-déploiement.

📣 Communication interneUn incident est en cours concernant l'impossibilité de lancer des applications via VPN IPsec, remonté sous le ticket 03552361. La root cause n'est pas encore identifiée à ce stade : Mickael BERNAUDEAU indique ne pas avoir la main côté client, ce qui limite l'investigation technique. Aucune durée d'indisponibilité précise n'est calculable faute de données horodatées sur le début de l'incident. Un point client est planifié pour la semaine du 28/04/2026 avec Loïc ROBERT et l'équipe afin d'avancer sur le diagnostic et obtenir les accès nécessaires. La résolution est donc suspendue à ce rendez-vous — à suivre impérativement pour débloquer la situation.

📣 Communication interneUne perte de résolution DNS interne a rendu une grande partie des applications Epiconcept indisponibles le 24 avril 2026. L'incident est toujours ouvert, aucune résolution n'a été confirmée à ce stade. Les équipes sont mobilisées pour identifier et corriger la cause.

📣 Communication interneAlerte Zabbix déclenchée suite au verrouillage du compte Oracle du client C11157 sur la machine p02gx-gx07-1, causé par le module w3wp.exe qui effectuait des tentatives de connexion Oracle répétées avec un mot de passe erroné. La root cause est une mauvaise configuration du mot de passe du compte applicatif C11157 au niveau du module w3wp.exe, générant des échecs d'authentification Oracle en boucle jusqu'au verrouillage automatique du compte. L'impact côté client s'est traduit par une impossibilité de connexion ou d'accès aux fonctionnalités dépendantes de ce compte Oracle. La résolution a été effectuée par SETTAMA Yachan le 24/04/2026 au matin via la correction du mot de passe du compte C11157. Une vérification de la cohérence des credentials applicatifs sur les modules w3wp.exe est recommandée en action préventive pour éviter toute récurrence sur d'autres environnements.

📣 Communication interneLe 20/04 à 22h10, une mise à jour de l'ASR a entraîné une perte de contact internet sur l'ensemble de la production Epiconcept pendant environ 10 minutes. Le service a été rétabli à 22h20. Une intervention complémentaire est planifiée en CAB pour finaliser la MAJ ASR (durée estimée : 20 min max).

📣 Communication interneUn verrou de session Oracle a été détecté sur la base P01GX (client C10737) : la session SID=740, originaire du serveur C10737-CTX02, bloquait 1876 sessions en attente sur la table INTERVENTION. La cause exacte du blocage n'a pas pu être déterminée — aucun ordre INSERT/UPDATE initiateur n'a été identifié selon l'analyse de RAIMOND Philippe. FERREIRA Hugo a résolu l'incident en killant la session fautive via la commande Oracle ALTER SYSTEM DISCONNECT SESSION '740,16544' IMMEDIATE. Le retour à la normale a été confirmé en environ 8 minutes après l'action corrective. Point de vigilance : la cause racine restant indéterminée, un suivi des sessions longues et des verrous sur cette base est recommandé pour prévenir une récurrence.

📣 Communication interneIncident Wallix (bastion) : la page d'authentification ne répondait plus pour l'équipe Epiconcept. Résolu et confirmé par Guillaume Goupil à 11h25.

📣 Communication interneAugmentation des temps de réponse constatée sur l'environnement STDN avec une latence impactant le module ASR, affectant l'ensemble des clients STDN. La root cause provisoire identifiée est une dégradation du débit réseau entre STDN et MRS, localisée sur le port-channel Po3 et l'interface Eth1/52 — le stockage a été écarté comme cause, et le composant Palo RAS a été investigué. Le retour à des temps de réponse normaux a été confirmé à 11h50, le ticket réseau 03562677 a été ouvert pour suivi et investigation approfondie de l'interface concernée. Aucune communication client n'a été envoyée durant l'incident. Des actions correctives sont attendues dans le cadre du ticket ouvert afin d'identifier si une remédiation matérielle ou de configuration est nécessaire sur Po3/Eth1/52.

📣 Communication interneLe 14/04/2026, une alerte espace disque faible (< 20%) a été détectée sur c000333-ctx22.swmcloud.net (volume C:). GEMMIER Yohann a effectué un nettoyage manuel à ~10h36, résolution confirmée par HECKTOR Matthias. Une tâche planifiée de purge est à l'étude pour éviter la récurrence.

📣 Communication interneLe dump Oracle de la base Ramsay prod a été exporté par Damien MARINO dans le répertoire D:\Dump_Prod_Ramsay sur le serveur c000333-gxq01-1. L'environnement de qualification est désormais alimenté et l'incident est résolu.

📣 Communication interneUne demande de redémarrage de serveurs a été reçue et traitée, mais le périmètre et la nature exacte de la maintenance associée n'ont pas été documentés dans le fil de l'incident. Les serveurs ont été redémarrés par l'équipe d'administration, qui procède également à la mise en inaccessibilité des serveurs depuis Citrix — selon les indications de Lucas BONNET. La root cause est un manque de documentation de la demande de maintenance : aucun périmètre clair, aucun contexte technique ni justification formelle fournis en amont. Les clients potentiellement impactés ne sont pas identifiés à ce stade, ce qui empêche toute communication ciblée. Action corrective à engager : imposer un process de demande de maintenance structuré (périmètre, serveurs concernés, durée estimée, impact attendu) avant toute exécution.

📣 Communication interneIncident déclaré sur le client C3030 : le lien HM Bloc ainsi que HM sont signalés inaccessibles. Les symptômes précis, la root cause et les étapes de résolution ne sont pas encore documentés dans le ticket — ces informations sont à compléter dès que disponibles. L'équipe est invitée à renseigner rapidement les détails techniques (logs, erreurs remontées, composants impactés) afin de qualifier l'incident et d'engager les actions correctives appropriées. En l'état, l'indisponibilité impacte directement l'accès aux modules HM Bloc et HM pour ce client, ce qui constitue un impact fonctionnel critique sur son activité métier.

📣 Communication interneLe volume D: du serveur c000333-gx01.swmcloud.net est passé sous le seuil de 20% d'espace disque disponible le 08/04. Un nettoyage a été effectué par Y. GEMMIER le 09/04 à 09h35, résolution confirmée par L. FLANT.

📣 Communication interneTAMM LIVI — Défaut d'affichage sur l'e-prescription V3 détecté ce matin (durée ~10 min). KHIDER Mounir a effectué un restart PHP sur le serveur web2 ; retour à la normale confirmé à 06h15.

📣 Communication interneDepuis 10h00, un pic de requêtes lentes a été détecté sur la base de données de TAMM Libéral 2, avec 40 requêtes dépassant les 2 minutes d'exécution. Les praticiens connectés ont subi des lenteurs significatives sur leur session, impactant la fluidité d'utilisation de l'application. L'analyse a permis d'identifier deux requêtes problématiques à l'origine du pic : 'thumbnail' et 'dmp_gui_can_general_rights'. Aucune action corrective manuelle n'a été nécessaire, le retour à la normale ayant été constaté après observation et surveillance. Des investigations complémentaires doivent être menées sur ces deux requêtes afin d'optimiser leur plan d'exécution et éviter toute récurrence.

📣 Communication interneUn verrou sur la table de recherche patients a provoqué une indisponibilité de l'application Galaxie TAMM, rendant la fonctionnalité de recherche de patients inaccessible pour les utilisateurs. La cause racine est un problème connu : une requête de recherche patients a déclenché un verrou bloquant sur la table concernée — ce point est déjà identifié et planifié côté développement pour correction. Aucune intervention manuelle n'a été nécessaire : le verrou s'est libéré de lui-même après quelques minutes, permettant un retour à la normale. Le temps d'indisponibilité est estimé à quelques minutes, sans perte de données connue. Il est rappelé que le correctif permanent est en cours de planification côté dev et doit être priorisé pour éviter la récurrence de cet incident.

📣 Communication interneLe 7 avril 2026, les pods proxy OpenShift utilisés par le SSO ont atteint leur limite mémoire (OOM), entraînant des erreurs "context deadline exceeded" pendant 2h02 sur One Manager et Hôpital Manager. Résolution : ajout de mémoire aux pods proxy par J. CLAUDE à 11h11 ; les pods proxy-46 ont automatiquement remplacé les proxy-45 en échec.

📣 Communication interneAlerte Zabbix déclenchée sur l'espace disque du volume C: des serveurs ctx16 et ctx11 (seuil < 20%) en raison d'une accumulation de fichiers CrashDumps dans C:\\Users\\%%\\AppData\\Local\\CrashDumps, sans purge automatique configurée. L'analyse menée par YOUSSOUF Kaïlan a confirmé que l'absence de politique de nettoyage automatique sur ces répertoires est la cause racine de la saturation progressive du disque. Le ménage a été effectué manuellement sur ctx16 par CHAGNIOT Jordane le 07/04/2026 à 21h53, restaurant la disponibilité disque sur le serveur concerné. Les clients hébergés sur ctx16 et ctx11 étaient potentiellement exposés à un risque de dégradation de service en cas de saturation complète du volume C:. Action corrective à engager : mettre en place une politique de purge automatique des dossiers CrashDumps sur l'ensemble des serveurs Citrix concernés afin d'éviter toute récurrence.

📣 Communication interneAlerte espace disque (<20%) sur c000333-ctx14 volume C: le 2026-04-06. Cause identifiée : dossiers CrashDumps dans les profils utilisateurs. Pris en charge et résolu ; les détails de l'action corrective n'ont pas été documentés dans le fil.

📣 Communication interneLors de l'application de la RFC-2026-001028 (migration rproxy vers RHEL8), une incompatibilité avec OnlyOffice sur les domaines *.onemanager.fr a provoqué une coupure totale d'accès impactant l'ensemble des clients .onemanager.fr et .hopitalmanager.fr. Le symptôme exact côté client n'a pas été renseigné dans le ticket, mais l'indisponibilité est confirmée sur tous ces périmètres. La root cause est clairement identifiée : la nouvelle version du rproxy RHEL8 n'est pas compatible avec la configuration OnlyOffice en place. La résolution a été effectuée par rollback sur rproxy6, rétablissant l'accès à 09h24 (ticket 03552087). Des actions préventives sont nécessaires : valider la compatibilité OnlyOffice avant toute future migration rproxy, et intégrer un test de non-régression OnlyOffice dans le process de la RFC.

📣 Communication interneAlerte espace disque faible (< 20 %) détectée sur le volume C: du serveur c000333-ctx24.swmcloud.net le 03/04. Un ménage a été effectué par Yohann Gemmier ; la disparition de l'alerte a été confirmée par Maxime Glaneux. Incident résolu en 3h10.

📣 Communication interneLe flux SFTP depuis e000001-eai1-1.swmcloud.net vers le serveur SYNAPSE était bloqué. L'ouverture du flux a été réalisée par MOREAU Gaëtan ; l'IP source côté SYNAPSE reste à confirmer.

📣 Communication interneLe 2026-04-01, une alerte espace disque insuffisant (< 20%) a été détectée sur le volume C: du serveur c000333-ctx12.swmcloud.net (durée : 5h18). Un ménage a été effectué par GEMMIER Yohann ; la disparition de l'alerte a été confirmée par CHAGNIOT Jordane. Incident résolu.

📣 Communication interneLe 01/04, une alerte Zabbix a détecté une consommation CPU anormalement élevée sur le serveur p01gx-gx04, causée par des processus eHubHL7 en comportement pathologique, et ce malgré l'augmentation de la capacité à 6 vCPU réalisée en mars. GEMMIER Yohann est intervenu et a procédé à l'endormissement des processus eHubHL7 incriminés, ce qui a permis de rétablir la situation vers 15h05. Le ticket associé est le 03549422. Une surveillance renforcée a été demandée suite à la résolution, car la root cause profonde du comportement anormal d'eHubHL7 n'est pas encore totalement élucidée — l'augmentation de vCPU n'ayant pas suffi à corriger le problème. Les clients Galaxie hébergés sur p01gx-gx04 ont pu subir une dégradation de service pendant la durée de l'incident, le temps d'indisponibilité effective n'étant pas précisément renseigné dans les données disponibles.

📣 Communication internePlusieurs VMs (procbddh1, dns01, lokigarage1/2/3) ne pouvaient pas joindre le serveur SMTP interne (10.90.1.4, port 25). Une règle réseau a été corrigée par Gaëtan MOREAU ; résolution confirmée par Fabrice GIORDAN à 10h17.

📣 Communication interneLe flux SFTP sortant vers 185.64.131.51 (application ESISDOCS-OCC, depuis profntd1 et satproxy) était bloqué suite à la migration. Gaëtan MOREAU a débloqué le flux en ouvrant les ports non standards SFTP — validé en test applicatif.

📣 Communication interneAlerte espace disque faible (< 20%) détectée sur le volume C: du serveur c000333-ctx06.swmcloud.net le 31/03/2026. Un ménage a été effectué par Yohann GEMMIER ; la disparition de l'alerte a été confirmée par Lorenzo SHAHBAZ. Incident résolu en 46 min.

📣 Communication interneDepuis 14h50, le client C10737 subit des erreurs ORA-04031 récurrentes liées à une saturation ou fragmentation de la shared pool Oracle, empêchant l'allocation de 12312 octets de mémoire partagée. Ce type d'incident est connu et référencé dans un ticket similaire précédent (03536407 — ORA-XXXXX in alert_P01GX.log), ce qui indique un problème potentiellement récurrent sur cet environnement. Un ticket de suivi 03548304 a été ouvert pour traitement, mais aucune résolution documentée n'est disponible à ce stade. Les actions à engager : analyse de la fragmentation de la shared pool Oracle, évaluation d'un redimensionnement ou d'un flush de la shared pool, et mise en place d'une surveillance proactive (alertes Zabbix) pour anticiper les prochaines saturations.

📣 Communication interneDisparition des paramètres LDAP constatée sur 5 clients (C3241, C2270, C2564, C2743, C3444) le 26/03, C2743 impacté depuis le 24/03. Remise manuelle des paramètres effectuée client par client par Soizic Garrido ; accès rétabli sur C3241 et C2270, C2743 traité via modification AUTH_MODE (ticket 03537713), C2564 en cours de confirmation.

📣 Communication interneDepuis 15h45, le client C1863 est impacté par des verrous sur TMP_TRT_MASSE. Florent LANDUCCI a demandé au client de bloquer la requête awbtxsvs5pvk2 afin de libérer les ressources ; une réunion de crise avec les DBA client est en cours. Incident résolu.

📣 Communication interneLe 26/03, la Clinique des Sports a subi un KO complet de son accès applicatif suite à l'arrêt du service PHP sur le serveur web2. La cause racine identifiée est un arrêt du processus PHP sur web2, pris en charge par KHIDER Mounir et MARTINELLI Florian. Le retour à la normale a été confirmé à 08h38. Le temps d'indisponibilité n'est pas calculable précisément faute d'horodatage de début d'incident, mais l'impact client était total (aucun accès à l'application). Des actions correctives et préventives doivent être engagées pour surveiller l'état du service PHP sur les serveurs web afin d'anticiper ce type d'arrêt, notamment via une alerte Zabbix dédiée sur le processus PHP si ce n'est pas déjà en place.

📣 Communication interneLe 26/03, un pic de charge anormal sur le datacenter STDN a provoqué des ralentissements significatifs sur l'ensemble des applications TAMM, Galaxie et Libéral2 hébergées sur cette infrastructure. Le pic a été identifié via la supervision (visible sur les outils de monitoring du datacenter), permettant une détection rapide de l'origine du problème. L'ensemble des clients hébergés STDN ont été impactés par des dégradations de temps de réponse globales, sans indisponibilité totale confirmée à ce stade. La résolution s'est faite par retour progressif à la normale une fois le pic de charge résorbé, sans intervention corrective spécifique documentée. Des actions de surveillance renforcée et d'analyse des causes du pic de charge sont à engager pour prévenir toute récurrence.

📣 Communication interneLe 23/03, une alerte Zabbix a détecté une surcharge CPU sur le serveur p01gx-gx02 hébergeant des clients Galaxie. La charge CPU anormalement élevée a entraîné une dégradation des performances pour les clients hébergés sur ce nœud. SETTAMA Yachan a pris en charge l'alerte à 16h07 et a traité l'incident (ticket 03536307). La résolution a été apportée suite au traitement de la surcharge CPU identifiée. Les données de symptôme initial et l'heure de début de l'incident ne sont pas renseignées, ce qui ne permet pas de calculer précisément la durée d'indisponibilité.

📣 Communication interneLe 23/03, une alerte Dictalive a signalé un problème d'accès massif sur l'infrastructure Citrix STDN, impactant les clients Mediboard, LIVI, Libéral et Ramsay. La root cause est liée à un incident réseau survenu le 20/03 qui a fragilisé l'environnement Citrix STDN, entraînant une indisponibilité totale d'accès pour l'ensemble des clients concernés. Le service a été rétabli à ~11h35 grâce à l'intervention de SEARA Florence, MARQUES Thomas et DRILLET Pierrick. Le lien de causalité entre l'incident réseau du 20/03 et cette panne doit faire l'objet d'une analyse post-mortem pour identifier les actions correctives à mettre en place afin d'éviter qu'un incident réseau ne déstabilise durablement l'infrastructure Citrix. Il est recommandé de renforcer la supervision des composants Citrix STDN au lendemain de tout incident réseau afin de détecter plus tôt d'éventuelles dégradations résiduelles.

📣 Communication interneIncident Espace Pro sur VH Easylink : les utilisateurs se retrouvaient en boucle de connexion, empêchant tout accès à l'application. La root cause identifiée est une erreur 404 sur le favicon OIDC servi par auth.swmapps.fr, côté infrastructure VH Easylink, qui perturbait le flux d'authentification. Les clients impactés sont CML 1546 TOURS (ORSEC), CML 1175 FRANCHEVILLE, Les Cèdres (Ramsay) et C1489000. La résolution a été prise en charge et appliquée par le partenaire VH Easylink (IWEINS Nicolas) à 17h20. Des échanges avec le partenaire doivent être engagés pour mettre en place une surveillance renforcée côté OIDC et éviter qu'une erreur 404 sur une ressource non critique (favicon) puisse bloquer l'ensemble du flux d'authentification.

📣 Communication interneIncident de blocage Oracle sur la base du client C10723 : la session ws_galaxie_C10723 a généré une contention de type 'enq: TM Row-X' lors d'opérations concurrentes UPDATE sur INFO_ADMIN et MERGE INTO ADRESSE, provoquant un verrou en chaîne avec les SID bloquants 4377 et 30581. L'ensemble des centres du client C10723 s'est retrouvé dans l'impossibilité de valider des actions dans le module Centre de soins. À 13h05 le 17/03, Hugo FERREIRA a identifié et tué la session bloquante côté Oracle, ce qui a immédiatement libéré les locks et restauré le fonctionnement normal. La durée d'indisponibilité n'a pas pu être précisément calculée faute d'heure de début renseignée, mais la résolution est intervenue à 13h05. Des actions correctives doivent être engagées pour analyser la cause de la contention sur ces tables (volume, fréquence des MERGE/UPDATE concurrents) et envisager un mécanisme de détection proactive des sessions bloquantes via monitoring Oracle.

📣 Communication interneLe client C11352 a subi une indisponibilité complète de son accès Galaxie WEB suite à l'absence d'une entrée CNAME dans l'IPAM pour l'hôte c11352-gx-prod.xtremcloud.cloud — la cause de la disparition de cette entrée reste inconnue à ce stade (ticket 03520874). Un consultant était sur site chez le client au moment de l'incident, ce qui a rendu la situation particulièrement bloquante. La résolution a été assurée par Damien MARINO à 08h55 le 17/03 en recréant manuellement l'entrée CNAME dans l'IPAM, rétablissant immédiatement l'accès. La durée d'indisponibilité exacte n'est pas calculable faute d'horodatage de début d'incident dans les données disponibles. Une investigation complémentaire est nécessaire pour comprendre pourquoi cette entrée CNAME a disparu et des mesures préventives (contrôle de cohérence IPAM, alerting sur suppression d'entrées critiques) doivent être envisagées.

📣 Communication interneDepuis le matin du 17/03, l'instance TAMM Galaxie Guyane est KO en raison d'un fichier browscap.serialize défaillant — sujet déjà connu et référencé. Le fichier corrompu ou invalide empêche le bon fonctionnement de l'application, rendant le service totalement indisponible pour le client. Adrien BOTUHA a pris en charge le correctif, lequel était en phase de tests et de revue de code à 13h17 le 17/03. La durée d'indisponibilité est en cours depuis le matin du 17/03, le temps exact de remise en service dépendra de la validation du correctif. Des actions correctives sont engagées ; il conviendra post-résolution de vérifier le mécanisme de génération/mise à jour du fichier browscap.serialize afin d'éviter toute récurrence.

📣 Communication interneLe 16/03, Mediboard était indisponible pour PLYO, PROC et PBAY pendant 1h30 suite à un incident sur le composant de stockage. Accès rétabli à 08h46, réplication en cours de compensation.

📣 Communication interneLe 13/03, une alerte Zabbix signale une saturation CPU sur le serveur p01gx-gx04, hébergeant des clients Galaxie. La root cause est un sous-dimensionnement de la VM : configurée avec 4 vCPU au lieu des 8 requis par les prérequis Galaxie, aggravée par la consommation des services eHubHL7 dont le comportement a visiblement évolué (cf. ticket 03523724). À 14h49, Anthony LUCCHESI intervient et augmente les vCPUs de p01gx-gx04 et p01gx-gx03 à 6 vCPU chacun, ramenant la charge CPU autour de 50%. L'ensemble des clients Galaxie hébergés sur p01gx-gx04 ont subi une dégradation des performances pendant la durée de l'incident. Des actions correctives sont à prévoir pour aligner les configurations de toutes les VMs Galaxie sur les prérequis officiels et surveiller l'évolution de la consommation des services eHubHL7.

📣 Communication interneDepuis 11h55 le 12/03, le client C10737 rencontrait une indisponibilité totale de son application avec des erreurs ORA-03114 (perte de connexion Oracle côté client), causée par une requête MERGE INTO ADRESSE générant un volume massif de locks sur la table ADRESSE et bloquant l'ensemble des connexions. L'incident a été repris formellement à 12h10 (ticket 03473951). Hugo FERREIRA a identifié la session Oracle bloquante et l'a terminée manuellement à environ 13h00, libérant ainsi tous les locks et restaurant la connectivité. La durée d'indisponibilité est estimée à environ 1h05 (11h55 → 13h00). Des actions correctives et préventives doivent être engagées sur la requête MERGE INTO ADRESSE afin d'éviter la génération de locks en masse (revue du plan d'exécution, ajout de monitoring sur les locks Oracle, potentiel refactoring de la requête).

📣 Communication interneIncident du 10/03 : alerte Zabbix détectée sur p02gx-gx07-1 suite à l'absence des pools IIS ws_galaxie_C11157 et eGalaxie_C11157, rendant l'application indisponible pour le client C11157. La root cause identifiée est une différence de nommage des pools IIS entre les environnements hébergé et non hébergé, ayant entraîné la non-création ou la mauvaise nomination des pools lors du provisionnement du serveur (ticket 03518861). À 15h34, Yohann GEMMIER est intervenu et a recréé manuellement les deux pools IIS avec le nommage correct, ce qui a permis la résolution de l'alerte Zabbix et le rétablissement du service. Point d'attention : ce type d'écart de nommage entre environnements hébergé et non hébergé représente un risque récurrent ; une standardisation et une vérification automatique des conventions de nommage à la création des pools devraient être envisagées comme mesure préventive.

📣 Communication interneL'application PLANIF était inaccessible pour les clients C3352 et C2069, empêchant tout accès au module de planification. La root cause et le symptôme technique précis n'ont pas été renseignés dans le ticket — il est nécessaire de les documenter a posteriori pour assurer la traçabilité. La résolution a été assurée par CIANCIOLO, avec un traitement séquentiel : C3352 rétabli en premier, puis C2069. Aucune information sur la durée d'indisponibilité n'est disponible dans les données fournies, ce qui limite l'analyse d'impact. Des actions correctives et préventives devront être formalisées une fois la root cause identifiée et documentée.

📣 Communication interneSuivi purge Quartz C3214 (Bourg en Bresse) : PERRONNET a reconfiguré le job en 2 exécutions par jour le 04/02, la purge est maintenue. Sujet clôturé.

📣 Communication interneIndisponibilité des environnements 9915005F/T et 9915004F/T constatée vers 14h le 03/03/2026 (composant réseau/LB). Le service est rétabli. LANDUCCI demande les captures d'écran et heures précises aux équipes concernées.

📣 Communication interneLe 02/03, les serveurs frontaux ERP ont subi une dégradation critique avec un IOWait MariaDB dépassant 75% et un load average supérieur à 20, rendant l'ERP multi-clients très fortement dégradé voire inaccessible pour les utilisateurs. La cause racine identifiée est une saturation I/O sur la couche MariaDB, générant une charge en cascade sur les serveurs frontaux. BROIS Romain a suivi l'évolution de la charge et a confirmé vers 16h05 une détente significative de la charge, réduite d'un facteur 3 par rapport aux 15 minutes précédentes, marquant le retour à la normale. Des investigations complémentaires doivent être menées pour identifier l'origine précise de la saturation I/O (requêtes lourdes, verrous, flush disque, etc.) et mettre en place des actions préventives. Un suivi via les outils de supervision est à maintenir pour s'assurer de la stabilité et éviter une récurrence.

📣 Communication interneUne régression introduite dans la version v1.2509.30 a impacté le module radio, entraînant une dégradation fonctionnelle pour 6 clients (C2347, C2909, C2296, C2757, C2557, C2789). La cause racine est un merge incorrect de la régression dans la branche 1.2509, effectué le 20/02 (référence Tuleap #607848). Un correctif a été livré mardi soir, résolvant le problème pour l'ensemble des clients concernés. Des contrôles post-déploiement devront être renforcés sur les merges de branches pour éviter ce type de régression en production. Un suivi sur Tuleap est en place pour tracer les actions correctives associées.

📣 Communication interneLe 24/02 à 03h39, l'agent Zabbix sur le serveur p01gx-dfs02 est devenu injoignable en raison d'une saturation CPU accompagnée d'une forte sollicitation de la RAM sur ce serveur. Cet incident de supervision est directement lié à l'incident de perte de documents COSEM (C000333) : la charge anormale du serveur DFS P01GX était la conséquence des problèmes sous-jacents traités dans ce ticket. La résolution a été effectuée le 24/02 à 14h25 via un changement de chemin dans le cadre de la résolution de l'incident C000333 (ticket 03493635), ce qui a permis de rétablir la joignabilité de l'agent Zabbix et de normaliser la charge serveur. La durée d'indisponibilité de la supervision sur ce nœud DFS a été d'environ 10h46 (de 03h39 à 14h25). Des vérifications doivent être conduites pour s'assurer que la configuration du serveur DFS P01GX est stable et que des alertes préventives sur la charge CPU/RAM sont correctement paramétrées dans Zabbix pour anticiper ce type de saturation.

📣 Communication interneIncident Medimail : tous les clients utilisant Medimail ont été impactés par un échec de connexion lié à un problème de gestion de l'autorité de confiance du certificat, introduit lors de la MEP Tokitomi. Le symptôme se traduisait par des échecs de connexion au service Medimail, entraînant une indisponibilité totale de l'envoi de messages pour l'ensemble des clients concernés. La correction pérenne a été appliquée par William DEGRYSE à 15h40. Les envois en erreur accumulés durant l'incident font l'objet d'un retraitement automatique, aucune action manuelle supplémentaire n'est requise de ce côté. Point d'attention préventif : vérifier systématiquement la chaîne de confiance des certificats lors des prochaines MEP impactant les composants d'authentification ou de communication sécurisée.

📣 Communication interneLe 24/02, le client COSEM Ramsay (C000333) a constaté la perte d'accès à environ 1700 documents patients suite à un conflit de réplication DFS sur le serveur p01gx-dfs02, déclenché par une saturation CPU à 03h39. Le redémarrage du serveur effectué par Cyberwatch à 23h10 le 23/02 dans le cadre d'un patch sécurité a aggravé le conflit de réplication, l'agent Zabbix étant par ailleurs injoignable (ticket 03493635), empêchant toute détection proactive. Les fichiers n'ont pas été répliqués depuis le 23/02, générant une indisponibilité effective des documents patients d'environ 10h45 (23h10 le 23/02 → 14h25 le 24/02). La résolution a été conduite en trois temps : modification en urgence du chemin Documents_Patients en base le 24/02 à 14h25 (ticket 03493907), mise à jour en base des chemins créés durant la période d'incident le 30/03, puis remise du chemin d'origine le 09/03 après mise en place d'une alerte supervision dédiée. En corrective : une supervision renforcée a été déployée pour détecter tout futur conflit de réplication DFS, et la coordination entre les opérations de patch Cyberwatch et la surveillance des services DFS doit être revue pour éviter ce type d'effet de bord.

📣 Communication interneLe 19/02, une saturation de mémoire virtuelle a été détectée sur le serveur c000333-gx01, entraînant une dégradation des services IIS et rendant le serveur inaccessible via Wallix. Une fuite mémoire est suspectée (identifiée par SAMSON Benoit), principalement portée par les services eHubHL7_test_1028 et eHubHL7_test_10210 qui consommaient anormalement — ticket 03487298 ouvert. À 09h26, BILGIN Enes a procédé au redémarrage des deux services eHubHL7, ce qui a permis une stabilisation partielle, un redémarrage complet du serveur étant planifié pour la nuit. Le redémarrage complet de c000333-gx01 a finalement été avancé et effectué par SERRANO Bastien à 13h30, avec retour à la normale confirmé — durée totale de dégradation/indisponibilité estimée à environ 4h. Des investigations complémentaires sur la fuite mémoire suspectée des services eHubHL7 sont à engager pour éviter toute récurrence.

📣 Communication interneIncident d'indisponibilité totale sur le client Synergia c2584 : le CVH, l'Espace Patient et le paiement en ligne étaient inaccessibles suite à une mauvaise configuration DNS — l'URL c2584-prod.xtremcloud.cloud pointait vers une instance HM vide mise en place lors de la préparation de la migration hébergée prévue au 30/06/2026. La root cause est une erreur de configuration survenue en amont lors de la préparation de l'environnement cible, sans garde-fou suffisant pour éviter que l'URL de production soit redirigée prématurément vers l'instance vide. Prise en charge et résolution assurées par ALVARO Christophe, tickets associés : 03481167 & 03483786. Action corrective immédiate : reconfiguration du pointage DNS vers l'instance de production active. Point de vigilance pour les prochaines préparations de migration : isoler strictement les URL de production des environnements cibles en préparation afin d'éviter toute bascule accidentelle.

📣 Communication interneMaintenance planifiée sur l'instance Oracle P02GX dans la fenêtre 22h00-22h30 le 16/02 : redémarrage de l'instance pour modification de paramètres, avec communication Everbridge envoyée aux clients en amont. Durant la fenêtre de coupure, les ~61 clients Galaxie hébergés sur P02GX ont subi une indisponibilité d'environ 24 minutes (22h00-22h24). Le redémarrage a été effectué avec succès, et le retour à la normale a été confirmé par Hugo FERREIRA à 22h24. Aucun incident technique non planifié à déplorer, l'opération s'est déroulée conformément au planning prévu.

📣 Communication interneUne alerte générale a été déclenchée sur le service Sclite, impactant l'ensemble des clients utilisant ce service. Les symptômes exacts et la root cause n'ont pas été documentés dans le ticket, ce qui constitue un point d'amélioration pour la gestion post-incident. La résolution a été assurée par Enes BILGIN via des redémarrages du service suivis de tests de bon fonctionnement confirmant le retour à la normale. Il est recommandé de compléter le ticket avec les détails techniques (logs, root cause identifiée, durée d'indisponibilité) afin d'alimenter le retour d'expérience et d'engager d'éventuelles actions préventives.

📣 Communication interneLa sauvegarde médicale UF Chimio était en échec sur les produits One Manager & Hôpital Manager. En accord avec le client, Nicolas Chanavat a procédé à la désactivation de cette sauvegarde. Incident résolu.

📣 Communication interneIncident de ralentissements sur P12HM causé par le quartz C3214 (tomquartz2) générant deux vagues de verrous Oracle, avec la requête FacFactureDebiteurDao (sql_id da8g3772msntg) consommant 25% de charge. En parallèle, un job de comptabilité EMEIS provoquait un plant Tomcat, aggravant la situation et impactant 8 clients simultanément (C2005, C2179, C2733, C2985, C3214, C3249, C3352, C3385). Résolution en deux temps : PORTAL Thomas a procédé au kill des sessions Oracle bloquantes pour débloquer les verrous, et DI MATTEO Emilia a espacé le batch compta et acté l'arrêt de la compta EMEIS en accord avec le client. Actions correctives engagées : espacement du batch compta pour éviter la contention Oracle, et suspension de la compta EMEIS côté client pour prévenir les plants Tomcat récurrents.

📣 Communication interneLe job comptabilité EMEIS provoquait un crash Tomcat/JVM sur P12HM. En accord avec le client, la comptabilité EMEIS a été arrêtée et le batch espacé (E. Di Matteo). Une investigation et un plan d'action sont prévus (V. Pinel).

📣 Communication interneLe 2026-02-03, des ralentissements (2 vagues ~15 min) ont affecté plusieurs clients One Manager & Hôpital Manager suite à des verrous Oracle sur C3214. Résolution : kill des sessions bloquantes (PORTAL Thomas), espacement du batch compta (DI MATTEO Emilia) et arrêt du batch compta EMEIS en accord avec le client. Incident résolu.

📣 Communication interneAlertes espace disque déclenchées sur plusieurs volumes des serveurs Galaxie p01gx/p02gx (D:, I:, F: et divers). Résolution : ménage manuel effectué par Y. Gemmier et K. Youssouf — 50 Go supprimés sur p02gx-gx03 ; alerte levée sur p02gx-gx06 (volume I: figé, aucune progression constatée).

📣 Communication interneC3214 BHB – Dysfonctionnement Quartz et envoi des SMS de rappel KO. Résolution : purge quotidienne Quartz mise en place (script transmis à LANDUCCI/PORTAL), job replanifié à 1x/jour en accord avec le client, reboot effectué pour rétablir la page de mire.

📣 Communication interneIncident détecté à 10h20, résolu en soirée (veille 20h), soit une durée d'indisponibilité estimée à environ 9h40 pour 44 clients sur les périmètres CRBV, OMSAAS, OMSAAS3 et OMPILOTE. Le service a été très fortement perturbé durant toute cette fenêtre, avec un impact significatif sur l'accès aux fonctionnalités pour l'ensemble des clients concernés. La cause racine est encore en cours d'investigation, prise en charge par ANCHE Simon. Le service a été rétabli mais l'analyse post-incident est en cours afin d'identifier précisément l'origine de la perturbation et d'engager les actions correctives nécessaires. Un suivi de l'investigation est attendu pour compléter ce dossier et définir les mesures préventives à mettre en place.

📣 Communication interneLe 29/01, Wallix s'est retrouvé inaccessible depuis l'ensemble des postes clients dès le matin, impactant tous les utilisateurs Galaxie transitant par Wallix (dont C11157, C10737 et d'autres). La cause racine n'est pas documentée à ce stade — PERRONNET Patrice a pris en charge le sujet côté infrastructure et a travaillé à la résolution. L'accès Wallix a été rétabli vers 10h45, bien que quelques clients soient restés en anomalie quelques minutes supplémentaires avant retour à la normale. Le temps d'indisponibilité est estimé à environ 1h45 minimum (début de matinée jusqu'à 10h45), mais sans heure de début précise documentée, ce chiffre est à consolider. Il est nécessaire de documenter la cause racine auprès de Patrice et d'engager une action corrective/préventive pour éviter une récurrence de ce type d'indisponibilité globale sur Wallix.

📣 Communication interneDepuis la veille à 20h, 44 clients utilisant le service CRBV (instances OMSAAS, OMSAAS3, OMPILOTE, dont C3352 et C2069) ont rencontré une perturbation de service. Le symptôme exact et la root cause ne sont pas encore formellement documentés, l'investigation de la cause racine est toujours en cours. La correction a été appliquée par ANCHE Simon, ce qui a permis de rétablir le service. La durée d'indisponibilité est estimée à plusieurs heures (depuis 20h la veille jusqu'à l'application du correctif). Il est impératif de finaliser l'analyse de la cause racine afin d'identifier les actions correctives et préventives à mettre en place pour éviter toute récurrence.

📣 Communication interneLe 22/01/2026, des lenteurs sur OmSaaS (client multi-établissements) ont été causées par une saturation CPU Tomcat lors du traitement du rapprochement bancaire. Un restart des Tomcats a résolu l'incident ; une stack trace a été transmise à Graylog via Zabbix (30 min de saturation détectées). L'investigation se poursuit pour identifier la cause racine.

📣 Communication interneL'incident sur le site CML 1202 (ISTRES/MARTIGUES) concerne deux dysfonctionnements liés : un import de justificatif KO et une erreur lors de la prise de RDV sur OMPILOTE, apparus depuis la version 2601.01. La cause racine identifiée est un defect dans GAPpétit (référencé sous Tuleap #607828) provoquant une StaleObjectStateException au moment de la prise de RDV, ce qui entraîne une dégradation fonctionnelle côté client. LIVINE Lydia a pris en charge la résolution via un report correctif, tracé sous Tuleap #607828. Le client est impacté fonctionnellement sur ces deux points tant que le correctif n'est pas déployé. Les équipes doivent s'assurer du suivi du ticket Tuleap et de la bonne livraison du correctif auprès du site concerné.