Franck Denié (France Travail) : « sortir du mainframe n’est pas simple »

Pouvez-vous nous rappeler ce qu’est France Travail ?

La transformation de Pôle Emploi en France Travail a fait que nous avons pris une position centrale au sein des organisations intervenant sur l’emploi. Ses missions consistent donc à assurer l’indemnisation des demandeurs d’emploi, leur accompagnement vers le retour à l’emploi et l’accompagnement des entreprises dans leurs besoins de recrutement.

La direction générale est un établissement public, chaque direction régionale également, tout comme la DGA Tech.

La DGA Tech compte environ 1600 agents internes, 3000 avec les externes.

Comment est organisée votre IT ?

La DGA Tech regroupe toutes les fonctions IT : production, développement, cybersécurité, data, IA… La transformation de Pôle Emploi en France Travail a amené une ouverture du SI. Nos partenaires peuvent désormais utiliser nos systèmes clé en main ou bien connecter leurs propres SI au nôtre via des API. Pour tous ces partenaires, nous devenons, en quelques sorte, un éditeur Saas.

La DGA Tech intègre ses propres fonctions support (RH, finances…).

Un point est important pour notre organisation : nous avons évolué en mode produit avec une forte dimension plateforme. Notre patrimoine évolue et il faut que les responsables gèrent le cycle de vie complet de chaque produit au-delà du stade de projet. Les métiers sont bien sûr intégrés dans la gouvernance de ce mode produit. Nous nous sommes organisés en chaînes de valeur (accompagner les demandeurs d’emploi, indemniser les chômeurs, accompagner les entreprises…) similaires côté Tech et côté métiers.

La DGA Tech a une direction en charge de l’exposition de notre plateforme aux partenaires et de la « relation clients » pour s’assurer que nos produits sont adoptés et adaptés.

Côté infrastructures, nous sommes essentiellement en cloud privé PaaS. Quelques verticaux métiers (par exemple la GPEC) utilisent des SaaS : la paie ADP, Talentsoft, ServiceNow…

Une autre direction a en charge l’expérience utilisateurs.

Côté développement, nous avons une organisation en « pôles de compétences ». Chaque « chef de produit » va donc « recruter » dans ses pôles en fonction de ses besoins à un instant donné. Cette organisation constitue également un levier en matière de gestion des ressources humaines pour gérer des parcours collaborateurs. Même s’il y a, de fait, une certaine complexité dans cette organisation, nous avons d’évidents avantages à y recourir.

Vous venez d’achever une importante migration mais quelle était l’architecture initiale de votre SI ?

Notre patrimoine IT est pluriel et comporte plusieurs générations de logiciels.

Sur mainframes zOS, nous avions des applicatifs Cobol datant des années 1990 couvrant autant l’indemnisation que l’accompagnement avec des bases de données DB2 ou DL1. Même avant la fusion de l’ANPE et des Assedic en Pôle Emploi, les SI fonctionnaient ensemble. Il y avait déjà eu des modifications côté front-office. Ce patrimoine a toujours été très vivant : ce n’était pas une momie dans un sarcophage ! Toute évolution (réglementaire ou autre) avait un impact sur le système mainframe.

Une deuxième génération datant des années 2000 était à base de Java avec des SGBDR. Les infrastructures ont beaucoup évolué au fil du temps avec l’adoption du cloud privé par exemple.

Depuis 2020, nous avons une troisième génération avec des conteneurs, Kubernetes, Java (toujours), une architecture micro-services…

Quel était votre objectif en matière d’architecture ?

Nos applicatifs mainframe sont connectés avec de nombreuses applications. Le mainframe est donc exposé.

Ne nous cachons pas qu’il s’agissait aussi de contenir un peu la facture et donc d’abandonner progressivement le zOS. Mais il s’agissait avant tout de permettre l’évolution applicative avec un niveau que ne permettaient plus les anciennes architectures. La structure même du système n’était plus adaptée. Il fallait donc réécrire. La sortie du mainframe par une démarche de portage technique doit être vue comme une étape dans cette trajectoire de réécriture.

Mais de nombreux systèmes piochaient dans le mainframe. Il a donc fallu modifier tout l’écosystème pour qu’il puisse se connecter à la nouvelle architecture. Pour tous les applicatifs de l’écosystème, il fallu développer des « Y ». Il fallait que chacun soit capable d’interagir avec l’ancienne architecture comme avec la nouvelle. Le système est très complexe et il fallait s’assurer que l’ancien système pouvait continuer de fonctionner tant que tout n’était pas prêt.

Le nouveau système coeur est sur un OS Linux Suse avec des bases de données Oracle et Tuxedo en moniteur transactionnel. Pour l’heure, les applicatifs restent sous Cobol (avec Microfocus). Le tout est en isofonctionnalités du point de vue métiers.

Tous les batchs ont dû être convertis. Nos bases de données ont été déployées sur du bare metal interne mais le reste est sur le cloud interne, ce qui garantit la performance du système.

Au final, nous réalisons d’importantes économies d’un point de vue financier. Nous avons éliminé notre dette technique en adoptant un SGBD-R moderne. Mais sortir du mainframe n’est pas simple.

Baptisé Zenit, le programme était risqué car, en cas de bascule ratée, c’était le paiement des allocations qui pouvait être impacté. Malgré tout nous avons décidé de réaliser cette opération de portage technique, sans quoi la réécriture serait très complexe.

Comment cette bascule a-t-elle été gérée ?

Un enjeu fort était de conduire le programme Zenit en même temps que les évolutions du SI attendues par notre plan stratégique. Et dans la période, les attentes métier étaient très nombreuses puisque nous devions mettre en place la loi pour le plein emploi (inscription de 1,7 nouveaux bénéficiaires, ouverture de notre SI vers les partenaires).

Le programme Zenit en tant que tel était structuré en plusieurs chantiers. Il y a la migration technique en tant que telle (données et code), l’adaptation des applications de l’écosystème (les fameux « Y »), les chantiers de tests (performances, techniques, fonctionnels, sur le transactionnel et le batch), l’adaptation de la production (nouvelle ordonnanceur sur Linux), l’adaptation des outils et processus de développement et le chantier bascule en tant que tel.

C’était un programme risqué par définition.

Malgré tout, quand j’ai appuyé sur le bouton de la bascule, j’étais serein. En effet, nous avions eu une double production (ancien et nouveau systèmes) afin de vérifier que tout fonctionnait. Cette double production a été un facteur clé de succès car, à cause de l’intrication des systèmes, il était impossible d’avoir un pilote isolé. Nous avons pu nous appuyer sur deux partenaires : Inetum pour les outils et Capgemini pour le pilotage et les tests.

La bascule elle-même a été opérée sur un week-end de quatre jours autour du 11 novembre. Et dès le dimanche soir, il y avait le premier traitement des actualisations.

Et tout s’est admirablement bien passé ! Et cela parce que nous avons eu une approche avec de nombreux tests, une répétition des gestes à opérer et la double production.

Quelles sont les prochaines étapes ?

Sortir du mainframe nous a permis de réaliser quelques économies. Le patrimoine Cobol a été modifié techniquement pour permettre la migration de plateforme mais les applicatifs sont toujours globalement les mêmes. Maintenant que la migration a été opérée, nous pouvons lancer le chantier de réécriture et de simplification du patrimoine applicatif.

D’ores et déjà, nous constatons des gains grâce à la simplification d’architecture, en particulier sur la rapidité d’exécution des applicatifs. Pour poursuivre et réécrire ces applicatifs comme prévu, nous regardons beaucoup les capacités que nous apporterait l’IAG.

Dans notre trajectoire en mode produit, nous avons toujours un Legacy mais celui-ci est désormais plus facile à manipuler.