Récit d’une migration cloud à haut risque pour le SI-SAMU
C’est le cloud qualifié SecNumCloud de Cloud Temple qui a été choisi pour héberger SI-SAMU, le système d’information qui porte le système national des urgences. Point d’entrée des appels d’urgence et de la prise en charge des patients, ce système est hautement critique.
À la fois régulateur du secteur de la santé, mais aussi promoteur de l’e-Santé et opérateur de services IT, l’ANS (Agence du Numérique en Santé) vient de mener une migration à haut risque. L’application SI-SAMU, qui gère notamment les appels au 15, a en l’occurrence été migrée sur Cloud Temple, un hébergement cloud qualifié SecNumCloud par l’ANSSI.
Historiquement, les SAMU travaillent au niveau du département. Ainsi, c’est une centaine de SAMU qui collectent et gèrent les appels d’urgence.
« L’objectif du programme SI-SAMU lancé en 2016 était de proposer un service de haute qualité, résilient, de niveau national et qui devait permettre l’entraide entre les SAMU », rappelle Laurent Joubert, directeur des opérations de l’Agence du Numérique en santé, que LeMagIT a pu rencontrer lors de la conférence SantExpo Paris 2024.
« Il s’agissait alors de décloisonner ce travail départemental et surtout de permettre aux SAMU les plus fragiles, notamment la nuit, de disposer de systèmes résilients. Ainsi, l’ANS espérait élever la qualité de service IT globale des services de SAMU sur l’ensemble du territoire. »
Le projet s’inscrit dans la logique de centralisation des ressources IT de l’État. Il doit apporter une réponse nationale aux problématiques d’interopérabilité et de coûts liés à l’approche historiquement décentralisée ; problématiques qui ont été soulignées par un rapport de l’IGAS (Inspection Générale des Affaires Sociales) de 2014.
Le programme est réorienté vers une approche plateforme en 2022
Unifier l’informatique d’une centaine de SAMU va s’avérer être une mission impossible, et un arbitrage ministériel va trancher en 2022 en faveur d’une approche plateforme. Il s’agit alors de permettre aux SAMU de continuer à travailler avec leurs solutions éditeurs, tout en bénéficiant d’une plateforme technique commune.
Laurent JoubertDirecteur des opérations, ANS
« Auparavant, les marchés passés par l’ANS étaient forfaitaires et monolithiques sur l’ensemble de leur solution. Nous avons travaillé sur une approche permettant l’intégration des éditeurs à une plateforme », explique Laurent Joubert.
« Ce n’était pas gagné d’avance. Surtout du point de vue des éditeurs de logiciel de régulation médicale, qui portent le dossier patient et la réponse de la régulation médicale. Nous avons dû arrêter les marchés existants et lancer de nouvelles consultations afin de trouver une solution plus agile, capable de s’adapter aux nouveaux besoins. »
La plateforme devra intégrer les différents modules du SI-SAMU, mais aussi de nouveaux projets comme le SAS (Service d’Accès aux Soins), une des priorités du ministère de la Santé.
D’une stratégie de marché où un seul acteur fournissait le logiciel et son hébergement, la stratégie plateforme va pousser à scinder les responsabilités entre les éditeurs, le fournisseur de la plateforme et l’infogérant chargé de son exploitation.
« Ce choix a été rendu possible parce que nous avons considéré que côté cloud, le niveau d’industrialisation est suffisant pour clore tout débat sur la responsabilité en cas d’incident. Nous nous sommes appuyés sur le marché UGAP C3 pour le choix de la solution cloud et avons lancé un marché pour trouver l’intégrateur », raconte Laurent Joubert. Ce marché a été remporté par Thales pour la construction et l’exploitation du SI-SAMU.
SecNumCloud s’impose comme une évidence
Pour l’hébergement de cette plateforme, le choix du cloud apparaissait alors en ligne avec la doctrine cloud au centre du gouvernement. Même si l’ANS est à l’origine de nature HDS (Hébergeur de données de santé), étant donnée la criticité de l’application, l’équipe veut privilégier une offre SecNumCloud.
À l’époque, seuls 3 acteurs bénéficiaient de ce niveau de certification : Wordline, déjà hébergeur de SI-SAMU, OVHcloud et Cloud Temple. Worldline est écarté, car il n’est pas considéré comme une offre cloud pure. Le fournisseur ne permettait pas de confier à un tiers l’infogérance de la plateforme.
Techniquement, OVHcloud ne répondait pas aux attentes de l’ANS en matière d’accès réseau et de latence pour la prise d’appel. De plus, SI-SAMU imposait l’exploitation de bases Oracle. Un seul acteur répondait aux contraintes fixées par l’ANS, Cloud Temple. Néanmoins, Cloud Temple n’étant pas un acteur connu des services de l’ANS, l’équipe préfère lancer une consultation auprès des fournisseurs cloud référencés par l’UGAP C3.
Laurent JoubertDirecteur des opérations, ANS
« Nous avons arrêté une liste et regardé tous les fournisseurs cloud capables de porter la solution SI-SAMU. Nous en avons retenu cinq et, du fait de toutes les problématiques techniques et les spécificités de SI-SAMU, il est apparu que la meilleure solution était Cloud Temple. Si nous n’exigions pas explicitement la qualification SecNumCloud, des points supplémentaires ont néanmoins été ajoutés à la note finale pour le respect des critères SecNumCloud », dit Laurent Joubert.
Les critères techniques imposent une qualité de service de type « Carrier Grade », notamment pour le module « Bandeau de communication », le véritable cerveau du routage des appels au 15.
« Celui-ci requiert des niveaux de service qui relève de ceux des opérateurs téléphoniques, car nous n’avons pas le droit d’avoir un taux de perte d’appel du fait qu’il s’agit d’appels au 15. Cela requiert le plus haut niveau de résilience et de disponibilité », précise notre interlocuteur.
Ce module s’appuie sur la gestion d’appel de Genesys. L’architecture applicative contient des composants au niveau national, mais aussi des niveaux de résilience au niveau local, avec une topologie réseau un peu particulière.
« Nous avons aussi besoin d’un certain niveau de personnalisation, avec notamment l’accès à des serveurs Bare Metal. D’autres hébergeurs proposaient des serveurs Bare Metal à leur catalogue, mais pas avec le bon niveau de support ni de gestion des configurations. Nous avons fait un compromis entre un cloud haute disponibilité, une bonne latence réseau, la capacité à porter Genesys et Oracle RAC, autant de capacités que n’offrent pas les autres fournisseurs cloud européens. »
La migration d’un premier lot a lieu la nuit du 22 et 23 avril
Au moment de la migration, dix services de SAMU mettaient en œuvre le composant Bandeau de communication, le plus critique de la plateforme. Or, il est apparu qu’il n’y avait pas de solution simple pour migrer ces départements un à un. La bascule a donc pris la forme d’un Big Bang dans la nuit du 22 au 23 avril, avec dix SAMU migrés d’un seul coup.
« Depuis le 23 avril, SI-SAMU est en production sur les infrastructures Cloud Temple. C’était une étape importante qui a demandé un énorme travail de préparation technique, avec des bascules à blanc, des rejeux de bascule, des tests de performance pour être certain que tout fonctionne correctement », se souvient Laurent Joubert.
Outre les ingénieurs, cette bascule a longuement été préparée avec les services du SAMU afin que ceux-ci passent en mode dégradé pendant la nuit du 22 au 23, puis sortent de ce mode le lendemain.
« Ce projet a mobilisé énormément d’acteurs, les équipes de Cloud Temple, de Thales, mais aussi celles du prestataire sortant. Ce fut un gros travail de transmission de relais avec Worldline et Orange, qui est l’opérateur téléphonique. Ce fut l’aboutissement de nombreux mois de travail », lance Laurent Joubert.
Nicolas DuffourDirecteur du développement stratégique, Cloud Temple
Nicolas Duffour, directeur du développement stratégique de Cloud Temple, commente cette bascule : « pour un SI aussi critique que peut l’être le SI-SAMU, une bascule vers le cloud se déroule un peu comme une gestion de crise. Le premier paramètre d’une opération aussi ambitieuse que celle du 22 avril, c’est l’engagement individuel et collectif de tous les acteurs. Ils étaient présents la nuit de la bascule, car tout n’a pas été un long fleuve tranquille et la nuit fut longue. Néanmoins, toutes les équipes ont réagi en temps réel, rapidement, pour atteindre l’objectif. »
Outre le bandeau de communications, la migration a porté sur les modules Bloc-Notes, qui peuvent jouer le rôle de LRM de secours (Logiciel de Régulation Médicale), et Portail, l’outil quotidien des SAMU. Il permet la gestion de crise et l’interconnexion avec SI-VIC, le système d’information pour le suivi des victimes d’attentats et situations sanitaires exceptionnelles.
Ces trois modules sont désormais exploités sur Cloud Temple. 95 départements utilisent le module Portail, 39 le module OTN (Opérateur Téléphonique National) et 10 le Bandeau de communication national.
L’enjeu de l’ANS est maintenant de travailler avec les éditeurs spécialisés afin d’interconnecter à la plateforme un maximum de solutions et, donc, un maximum de services SAMU.
« Il faut avoir le bon niveau d’ouverture. Nous partageons du code, des API et nous avons ouvert un Github. Ce sont des mesures très concrètes pour embarquer les éditeurs et que ceux-ci soient en mesure de se connecter à nous, en étant le plus transparent possible. Notre objectif est d’accélérer sur ce volet », insiste Laurent Joubert.
De nombreux modules manquent encore au SI-SAMU. L’ANS veut travailler avec les éditeurs et se positionner comme le socle de tout l’écosystème des solutions des SAMU.
Fraîchement migré, le système est encore en « Early Life Support » et va connaître son véritable baptême du feu à l’occasion des JO de Paris. Fort de ces longs mois de préparation et de la bascule réussie, Laurent Joubert estime que le système est maintenant prêt à faire face à cette période qui s’annonce particulièrement intense.