Les agents de Pôle emploi s’approprient les données

Etablissement public à caractère administratif (EPA), Pôle emploi est issu de la fusion, suite à une loi de 2008, entre l’Agence nationale pour l’emploi (ANPE) et l’Association pour l’emploi dans l’industrie et le commerce (Assédic). Parfois soumis à des règles de droit privé, il est en charge d’une mission de service public autour de l’emploi. Celle-ci se décline en six items : l’accueil de tous les actifs et l’inscription des demandeurs d’emploi ; le versement des allocations destinées aux demandeurs d’emploi ; l’accompagnement des demandeurs d’emploi dans leur recherche d’emploi ; l’aide aux entreprises pour leurs recrutements ; le partage des connaissances sur le marché du travail ; et être le relais des politiques publiques de l’emploi. Pôle emploi comprend environ 60 000 agents répartis sur un millier de sites propres sur tout le territoire national (y compris les DOM/COM) et sur environ 2000 maisons France Services. Par la nature de ses missions, Pôle emploi manipule de nombreuses données sur l’emploi, les demandeurs d’emplois et les entreprises. Et les services de la DSI constataient une explosion des demandes des métiers, en particulier à des fins de pilotage opérationnel et stratégique.

Le système d’information de Pôle emploi est très urbanisé avec une architecture SOA. L’établissement a été parmi les pionniers de l’approche agile SAFe en France. Malgré tout, même s’il existe une trajectoire de sortie, le coeur du SI comporte toujours un Legacy Mainframe. L’essentiel du parc applicatif est cependant aujourd’hui écrit en Java et utilise des bases de données relationnelles classiques (PostgreSQL, Oracle…) comme d’autres types (MongoDB, Neo4J…). La gestion interne comme le paiement des allocations reposent quant à eux sur l’ERP de SAP, actuellement encore largement en version ECC 6 mais en cours de migration vers S/4Hana, la fin de ce chantier étant prévue pour 2025. Si on excepte des outils périphériques SaaS (Microsoft Office 365…), le système d’information de Pôle emploi est hébergé principalement en interne. La DSI, sous l’autorité d’un DGA SI, est divisée en plusieurs services dont la Direction Fonctions d’Appui qui est en charge notamment des systèmes financiers, d’une partie du SI RH, de la maîtrise des risques et de la lutte contre la fraude.

De nombreux cas d’usages à traiter

« Il y a une vraie appétence des métiers à s’emparer de la data » constate Michaël Mornet, adjoint de la Direction Produits Fonctions d’Appui de la DGASI de Pôle emploi. La data est en effet essentielle pour répondre aux besoins des différentes directions métiers, qu’il s’agisse d’explorer le patrimoine de données, de répondre aux attentes des commissaires aux comptes qui certifient la comptabilité de l’établissement, d’intégrer la data dans des process variés… Il existe trois grands types de tableaux de bord : à des fins de pilotage, d’exploration ou bien encore de communication, de distribution de la donnée (y compris aux tiers comme les commissaires aux comptes).

Pour Frédérick Legeay, responsable Data chez Pôle emploi, « avant, les métiers commandaient et la DSI réalisait la visualisation. Maintenant, ils veulent avoir la main et travailler eux-mêmes sur les données. » Mais, malgré tout, l’accès à la data doit être au maximum « sans couture ». « Beaucoup d’outils exigent de sortir de l’application courante pour accéder à la donnée, par exemple un tableau de bord, un graphique… » regrette Frédérick Legeay. Or il est évidemment nettement plus ergonomique d’intégrer les composants graphiques dans les applications métiers.

Une problématique technique à résoudre

Mais cette volonté se heurte à des difficultés techniques évidentes. Michaël Mornet souligne : « pour certains logiciels, on a développé des tableaux de bord en Java, intégrés de ce fait aux applications réalisées dans le même langage, mais c’est tout simplement immaintenable ». Et, de plus, une solution de ce type est complexe à développer et guère agile. Pouvoir intégrer des composants décisionnels dans les applications développées en Java est évidement une bien meilleure solution. C’est l’une des raisons essentielles du choix de DigDash qui permet une telle intégration tout en conservant sa richesse fonctionnelle propre.

« Nous étudions la possibilité de faire la même chose dans les interfaces Fiori de SAP et, au-delà de la continuité ergonomique, nous y avons un véritable intérêt économique : les coûts de développements d’états décisionnels (non  »Temps Réel«  ) et de maintenance sous Digdash étant nettement plus faible que sous Fiori (un facteur entre 3 et 5 dans notre contexte) » relève Frédérick Legeay. La simplicité d’usage de DigDash pour réaliser les visualisations est en effet l’un des points forts du produit. Antoine Buat, président de l’éditeur DigDash, a expliqué : « la plupart des outils décisionnels du marché ont été construits comme des super-Excel en partant des données, nous, nous avons au contraire conçu notre produit en partant de ce dont l’utilisateur final a besoin. » La préparation de la data se fait en amont, la visualisation ensuite, sans mélanger les deux étapes. « Avant, j’utilisais Qliksense et DigDash est, pour moi, nettement plus fluide en plus de proposer des composants directement intégrables » note Frédérick Legeay.

Résoudre la complexité de la collecte des données

Mais la complexité du système d’information et la masse de données traitées par Pôle emploi rendent difficiles la mise à disposition des données dans DigDash. « DigDash possède des outils de type ETL intégrés mais il n’a pas vocation à remplacer un véritable ETL dans un cas comme le nôtre » juge Frédérick Legeay. A Pôle emploi, il s’agissait en effet de connecter des dizaines de sources de données, dans des technologies variées, avec des cycles de vie techniques différents. Pôle emploi a donc décidé, pour connecter toutes ses données, de recourir à la solution de Dataiku.

Cette solution se connecte à toutes les sources disponibles et génère un datalake. Celui-ci est un simple stockage interne au format S3. Ce choix a été fait pour sa simplicité, son agilité et son adaptabilité. C’est à partir du stockage S3 que travaille DigDash. « Tout ce qui peut être calculé dans Dataiku doit l’être, pour des raisons de performance, mais sans aucune agrégation : nous ne devons pas perdre en granularité » insiste Frédérick Legeay. Les agrégats et les calculs associés (moyennes, sommes…) sont, eux, réalisés dans DigDash.

Les objectifs sont atteints

Au final, les objectifs sont atteints. Toute la donnée existante est bien disponible et accessible aux métiers. Les collaborateurs peuvent bien sûr se contenter d’utiliser des tableaux de bord créés par la DSI. Mais ils peuvent aussi créer les leur ou, simplement, personnaliser les rapports créés par la DSI. Par exemple, en Alsace ou en Savoie, les données sur les frontaliers seront nécessaires. A Brest, ces données n’auront pas d’importance mais, par contre, un suivi spécifique des pêcheurs aura, lui, du sens. Michaël Mornet se réjouit : « les utilisateurs finaux ont bien la main ». « Les utilisateurs ne sont jamais bloqués et l’outil est simple à intégrer, y compris à notre SSO » complète Frédérick Legeay.

Parmi les réalisation récentes dont Pôle emploi est fier, il y a la récupération automatisée de données déposées sous forme de fichier à plat (cvs, xls…) dans Teams. Il peut s’agir, par exemple, de listes blanches établies manuellement pour un outil de détection de profils frauduleux. Et, dans les évolutions prévues, outre les états financiers, il y a la création de data visualisation (Tableaux de bord produit) pour accompagner la bascule de la DSI de Pôle emploi en mode produit. Cette évolution suppose en effet de mesurer clairement la valeur générée par chaque produit et divers indicateurs clés de performance (valeur délivrée, nombre d’incidents, indisponibilités, satisfaction des utilisateurs…).

Sur la photo

De gauche à droite :

- Frédérick Legeay, responsable Data chez Pôle emploi

- Michaël Mornet, adjoint de la Direction Produits Fonctions d’Appui de la DGASI de Pôle emploi.