Ministère du Travail — France Travail — Secteur public
Plateforme de gestion à l’échelle nationale
Conception et développement de la plateforme France Travail : demandeurs d’emploi et conseillers, sur tout le territoire. Contrainte dominante : la charge de pointe et l’obligation de service public. Architecture robuste et scalable sur Kubernetes / OpenShift.
100 k+
utilisateurs actifs, 99,9 % de disponibilité
Le contexte
Une plateforme de service public ne choisit pas ses utilisateurs. Demandeurs d’emploi et conseillers accèdent au même système sur tout le territoire, avec des usages opposés : d’un côté des connexions ponctuelles, depuis des équipements hétérogènes, à des moments qui comptent pour la personne ; de l’autre un usage professionnel quotidien et intensif.
La contrainte dominante était la charge de pointe. À l’échelle nationale, l’affluence n’est pas lissée : elle se concentre sur les mêmes créneaux, autour des mêmes échéances. Dimensionner sur la moyenne, c’est tomber au pic ; dimensionner en permanence sur le pic, c’est payer toute l’année une capacité inutilisée.
S’y ajoute l’obligation de service public, qui change la nature de l’indisponibilité. Une panne n’est pas un incident commercial que l’on rattrape : c’est une démarche qu’une personne ne peut pas accomplir, sans autre guichet vers qui se tourner.
Notre intervention
Kubernetes et OpenShift ont été retenus pour que la capacité suive la demande au lieu d’être provisionnée pour le pire cas. En contexte public, OpenShift apporte en plus une distribution cadrée, avec des règles d’exécution et de sécurité explicites, pensée pour être opérée par des équipes internes, pas seulement par ceux qui l’ont installée.
Cette élasticité ne vaut que si les services l’acceptent. Les services Java et Spring Boot ont donc été conçus sans état local : aucune affinité de session, aucune donnée retenue dans un processus, de sorte qu’ajouter ou retirer une instance reste une opération neutre. C’est cette propriété, et non l’orchestrateur, qui rend la montée en charge effective.
L’état, lui, ne se duplique pas en ajoutant un pod. PostgreSQL concentrait donc l’essentiel de l’effort de conception, et c’est là que se joue le temps de traitement : ce qui doit rester synchrone, ce qui peut être différé, ce qui doit être lu et écrit en une seule fois plutôt qu’en cascade.
Le front Angular sert les deux populations sur une même base, avec des parcours distincts. L’exploitabilité a été traitée comme une exigence de conception, pas comme une phase de fin : une administration ne reconduit pas un prestataire pour maintenir un service en fonctionnement.
Résultats
- Temps de traitement réduit de 60 %
- Architecture scalable Kubernetes / OpenShift
- Exploitabilité par les équipes internes
Technologies & outils
La plateforme sert plus de 100 000 utilisateurs actifs avec 99,9 % de disponibilité. L’énoncé est modeste, l’exigence ne l’est pas : cela laisse moins d’une heure d’indisponibilité par mois, mesurée et non arrondie, sur un service dont les pics sont précisément les moments où l’on ne peut pas être absent.
La réduction de 60 % du temps de traitement se lit des deux côtés du guichet : pour l’usager, une démarche qui aboutit dans la session où elle a été commencée ; pour le conseiller, du temps rendu à l’accompagnement. Et les équipes internes exploitent la plateforme — c’est le critère de fin de mission, pas un bonus.
06 — Contact
45 minutes.
Sans engagement.
Décrivez la décision technique devant vous. Nous vous disons ce que nous ferions, si c’est pour nous, et ce que ça coûte. Réponse sous 24 h ouvrées, par un associé.