Francfort opère un cloud sans équipe Kubernetes

Le service de santé de Francfort exploite avec GA-Lotse une plateforme fédérée dédiée aux applications du service public de santé. L’aspect remarquable réside dans la répartition des tâches : l’autorité utilise une plateforme souveraine et chiffrée, sans avoir à constituer une équipe spécialisée en Kubernetes.

Les points clés en bref

En lien:BSI C3A : la souveraineté cloud devient vérifiable  /  Premier supercalculateur exascale européen : qui a le droit de calculer ?

L’expertise métier ne doit pas dépendre du cluster

Les services de santé ont besoin de procédures numériques capables de gérer au quotidien les examens, les planifications et les contrôles. Ils n’ont cependant pas à former leur propre département dédié à Kubernetes pour exploiter ces procédures en toute sécurité. GA-Lotse sépare ces deux missions.

Le service de santé de Francfort a modernisé son infrastructure avec Red Hat OpenShift en tant que service managé. La plateforme est fédérée et intègre un contrôle d’accès ainsi qu’un chiffrement. Red Hat a publié l’étude de cas le 6 juillet 2026.

Trois mois jusqu’au lancement en production

Selon le partenaire d’exploitation VSHN, l’attribution du marché a eu lieu en août 2024, et la plateforme est entrée en service trois mois plus tard. Ce délai ne remplace pas une analyse de projet. Il montre cependant ce qui se passe lorsque l’hébergement, l’exploitation de la plateforme et le travail sur les applications métiers ne reposent pas sur une seule équipe surchargée.

GA-Lotse est désormais utilisée en production dans plusieurs régions de la Hesse, selon VSHN. Les applications soutiennent notamment les bilans de santé à l’entrée à l’école et les dépistages dentaires.

Les opérations managées libèrent des ressources

L’enseignement central concerne la responsabilité. Un service managé ne décharge pas une administration de ses décisions d’architecture ni de ses obligations en matière de protection des données. Il concentre cependant l’expertise spécialisée pour l’exploitation de la plateforme, les mises à jour et la maintenance quotidienne. Les équipes métiers peuvent ainsi consacrer leur temps aux processus dont elles ont réellement la charge.

Cela est plus réaliste pour de nombreuses équipes publiques qu’un déploiement interne de Kubernetes. La question n’est pas de savoir si les conteneurs sont techniquement maîtrisables. Elle porte sur les compétences qui doivent rester durablement sur place et celles qu’il est plus judicieux d’externaliser sous forme de service d’exploitation clairement encadré.

Impact avec une référence claire aux sources

VSHN indique que les applications de GA-Lotse prennent en charge chaque année 7 000 bilans de santé à l’entrée à l’école et 45 000 dépistages dentaires. Ces chiffres décrivent les processus soutenus, et non un indicateur de productivité mesuré de manière indépendante. Cette distinction est importante : le cas présente une histoire d’exploitation crédible, mais ne constitue pas un benchmark universel pour chaque administration.

La plateforme remplace des étapes papier dans les applications mentionnées. Il n’est pas possible de déduire de manière fiable, à partir des sources disponibles, le temps que les différents services économisent grâce à cette solution.

Un code ouvert évite le prochain redémarrage

GA-Lotse a été publié sur openCode.de. Ainsi, la solution peut être vérifiée et réutilisée au-delà de Francfort. Un code ouvert ne résout pas à lui seul les questions d’acquisition ou d’exploitation. Il modifie cependant la donne : les autres services de santé ne doivent pas repartir de zéro pour chaque idée de plateforme.

Ce cas reste une étude de cas constructeur et partenaire, et non une mesure comparative indépendante. En tant qu’histoire de Reboot-Germany, il porte néanmoins son message, car il rend visible la répartition opérationnelle : expertise métier, exploitation de la plateforme et réutilisation s’imbriquent. L’étude de cas Red Hat décrit le cadre technique.

Pour les autres administrations, cela donne lieu à une séquence d’examen pragmatique. Premièrement : quelles données et rôles métiers doivent être représentés dans la plateforme ? Deuxièmement : quels services d’exploitation peuvent être confiés de manière contraignante à un partenaire spécialisé ? Troisièmement : quelles parties du code et des interfaces doivent rester réutilisables au-delà du propre projet ? Celui qui répond à ces questions avant l’attribution intègre moins de dépendances dans le quotidien.

L’avantage d’un Managed Service ne réside pas dans un allègement global. Il réside dans des responsabilités transparentes. Le côté métier conserve le savoir-faire et les priorités. L’exploitation de la plateforme prend en charge le travail technique récurrent. Les deux parties ont besoin pour cela de transferts clairs et d’une escalade fiable lorsqu’une application s’écarte de sa fonction attendue sous charge ou lors d’une mise à jour.

Foire aux questions

Coups de cœur de la rédaction

• CADA : quand la souveraineté cloud devient une obligation d’achat
• BSI C3A : la souveraineté cloud devient vérifiable
• Soofi S : souverain ne signifie pas vainqueur

Plus d’articles du réseau MBF Media

Source de l’image : générée par IA (juillet 2026)