Laurent Robillard (AIFE) : « 10 % des utilisateurs ont consacré cinq mois à la recette de Chorus »

Pouvez-vous, tout d’abord, nous rappeler ce qu’est l’AIFE et ses missions ?

L’Agence pour l’Informatique Financière de l’État est un service à compétence nationale ayant pour objet de faire fonctionner le système d’information financier de l’État. Chorus Coeur constitue le socle de ce SI financier. Il s’agit d’une implémentation de SAP avec plus de 24 000 utilisateurs. Chorus Formulaires, un développement en Java, est destiné à plus de 42 000 utilisateurs différents et sert à des saisies métier qui vont être déversées dans Chorus Coeur.

Désormais, beaucoup connaissent aussi Chorus Pro qui permet d’adresser ses factures au secteur public. Chorus DT (Déplacements Temporaires) gère les déplacements et frais de mission ainsi que les déménagements. C’est un produit spécifique dérivé d’un produit Concur mais nous allons en reparler.

Nous avons d’autres produits plus périphériques comme Place (la plateforme des achats de l’État), Piste (API management), etc.

En cumulé sans dédoublonnage, nos différents produits ont 1,5 million d’utilisateurs.

Précisément, Chorus Coeur est donc l’une des plus importantes implémentations de SAP dans le monde. Quelle était son architecture initiale ?

Le début du déploiement de Chorus Coeur date de juillet 2008, la fin de janvier 2012 et la première certification des comptes publics sur Chorus a été réalisée par la Cour des Comptes en 2012.

Chorus Coeur était donc un SAP ECC 6 avec une base de données Oracle, le tout hébergé sur une paire de fermes d’une vingtaine de serveurs Linux dans nos propres datacenters (en région parisienne et près de Toulouse). En non-compressé, nos données représentent 65 To (30 To compressés dans Oracle).

Pourquoi avoir choisi de migrer d’ECC 6 vers S/4Hana ?

Bien évidemment, le premier motif est la fin de la maintenance d’ECC 6 en 2027. La plate-forme technique était également en voie d’obsolescence et méritait une refonte et une remise à niveau.

Mais ce n’était pas les seules raisons. Dans l’enquête annuelle de satisfaction auprès des utilisateurs, il y avait trois critiques récurrentes : l’ergonomie obsolète, le temps de montée en compétence sur le produit lors d’un changement de poste (ce qui est lié à l’ergonomie) et, enfin, les performances techniques (temps de réponse des restitutions principalement…).

La migration S/4Hana répondait bien à ces points. L’interface Fiori facilite la création d’une ergonomie moderne, la base de données Hana apporte un vrai gain de performances et le module SAP Enable Now apporte une aide en ligne intégrée et interactive qui peut aussi assurer un certain e-learning.

Comment se fait-il que l’AIFE n’a pas procédé à un nouvel appel d’offres comme lors de la création de la première version de Chorus ?

En 2018, nous avons lancé une étude de marché et, en 2019, une opération de sourcing pour vérifier la pertinence de l’offre SAP sur des critères techniques, financiers, opérationnels… Nous avons étudié de manière plus approfondie trois offres : SAP S/4Hana bien sûr mais aussi des offres de deux autres prestataires. Les trois ont été invités à produire un démonstrateur et un planning du projet ainsi qu’une estimation de coût. Evidemment, les ministères utilisateurs ont été sollicités pour participer à l’étude et ont été destinataires de ses conclusions.

Début 2020, au regard des analyses fonctionnelle, technique et financière, S/4Hana a été retenu. Nous disposions des licences SAP. L’évolution ECC 6 vers S/4 est intégrée dans la maintenance. Aucun achat nouveau de licences n’était nécessaire spécifiquement pour ce projet.

Comment a été mené le projet ?

Le projet, sa trajectoire et ses modalités ont été validés fin 2021 après un décalage lié à la situation sanitaire. Les travaux ont démarré dès le début de l’année 2022. Dans le cadre d’un appel d’offres Accenture a été retenu pour accompagner les travaux de migration..

Quelle est l’architecture actuelle de Chorus Coeur ?

Comme il nous fallait des serveurs capables de gérer la base de données en mémoire Hana avec nos volumes (60 To bruts, environ 15 To compressés dans Hana, soit à peu près deux fois moins qu’avec Oracle), les choix étaient limités. Nous avons choisi les IBM P9 sous Linux. Ces volumes sont multipliés par le nombre d’environnements (développement, test, pré-prod…). Ces serveurs sont toujours hébergés dans nos datacenters.

Pourquoi ne pas avoir adopté le cloud alors que l’État a une doctrine « Cloud au centre » ?

Quand le dossier a été déposé auprès de la DINUM, qui contrôle tous les grands projets informatiques de l’État, la question s’est effectivement posée, mais il n’existait pas, à date, de cloud SecNumCloud capable d’héberger du S/4Hana.

Les clouds internes de l’État (Nubo et Pi) ne sont pas du tout dimensionnés pour ce genre de projet avec nos exigences de SLA.

Pourquoi avoir coupé Chorus Coeur durant quinze jours et comment cela a-t-il été géré d’un point de vue métier ?

La principale raison est bien sûr la migration des 60 To de données. Le processus est très long car il y a, en fait, une double opération : d’abord la migration d’Oracle vers Hana puis le changement de schéma de la base de données (nouvelle table ACDOCA). C’est donc beaucoup plus lourd qu’une montée de version ECC 6.

Les premières répétitions, réalisées très en amont, ont montré que la durée de la migration serait bien plus importante que nous ne l’escomptions au départ. En plus, il était nécessaire d’effectuer quelques remises à niveau des données pour être conforme aux attentes de S/4.

Une coupure de service sur deux semaines est donc apparue nécessaire. Elle a été programmée sur une période intégrant les ponts de mai, ce qui cela ne correspondait en fait qu’à sept jours ouvrés. Cela permettait d’en atténuer l’impact pour les utilisateurs, même si l’équipe projet a travaillé non stop durant ces quinze jours.

Comme nous avions travaillé sur l’optimisation du processus, la migration n’a, au final, pris que dix jours.

Nous avons mis à profit cette période de jours fériés pour intégrer le stock de flux issu des systèmes tiers (notamment Chorus Formulaires) qui, eux, continuaient de fonctionner sans déverser dans Chorus Coeur au fur et à mesure.

L’ensemble des parties prenantes avait été prévenu en amont afin que chacun s’organise. Les paiements dont l’échéance arrivait durant la coupure ont été anticipés afin d’éviter tout retard de paiement. Il y en avait pour 24 milliards d’euros la dernière semaine avant migration… Au final, nous n’avons eu aucune plainte ni de fournisseurs ni d’utilisateurs.

Une migration de cette ampleur n’est pas si fréquente ! Comment avez-vous garanti le succès de l’opération et quel bilan en tirez-vous ?

Tout s’est bien passé : les délais comme le budget ont été tenus. A l’heure prévue, les utilisateurs se sont connectés et ont pu reprendre normalement leur travail. 15 000 utilisateurs distincts se sont connectés sans souci dès la première semaine de reprise, soit 65 % des utilisateurs de Chorus. Les quelques rares anomalies détectées ont été rapidement corrigées. Tous les flux bloqués à cause de la fermeture ont été rattrapés en une semaine.

Evidemment, ce succès est lié à ce qui a précédé la migration finale. Quand nous avons fabriqué le nouveau Chorus Coeur, nous y avons intégré les données 2023. Et 10 % des utilisateurs ont consacré cinq mois à la recette de ce nouveau Chorus. Nous avons même simulé les processus de paiement. Par la même occasion, nous avons validé le processus technique de migration. De ce fait, nous n’avons pas eu besoin de revalider les données lors de la migration finale : s’il y avait eu un incident technique, il aurait été repéré.

Nous avons profité de cette évolution pour faire quelque chose que nous n’avions jamais fait : archiver les données métiers que nous n’avions plus besoin de conserver en ligne. Avec la DGFiP, nous avons travaillé à mettre en place une automatisation de cet archivage pour les années à venir.

Et puis, en passant de ECC 6 à S/4, nous avons aussi nettoyé les développements spécifiques obsolètes ou inutiles. C’est évidemment une démarche habituelle dans ce type de projet.

Une des grandes difficultés a été d’avoir les bonnes expertises sur l’interface Fiori en évitant autant que possible les spécifiques.

Enfin, nous avons réalisé un travail préparatoire sur le plan métier en bonne intelligence avec la DGFiP (impacts sur la comptabilité) et les ministères utilisateurs, notamment ceux ayant à traiter des difficultés particulières comme le Ministère des Armées (gestion des immobilisations et comptabilité des projets). Le succès, c’est aussi le fruit du travail collectif réalisé ensemble.

Comment avez-vous accompagné les 24 000 utilisateurs sur ce nouvel environnement à l’ergonomie refondue ?

Un avantage au fait de demander à 10 % des utilisateurs d’effectuer la recette du nouvel environnement, c’est qu’une partie de l’accompagnement est réalisé par ces pionniers parlant à leurs collègues. Une fois la recette effectuée, l’environnement dédié a été ouvert à tous les utilisateurs pour qu’ils puissent découvrir la nouvelle interface.

Nous avons réalisé soixante-dix webinaires pour expliquer les nouvelles fonctionnalités et l’évolution de l’ergonomie. Plus de 20 000 utilisateurs les ont suivis. A cela nous avons ajouté des lettres d’information sur le projet avec des témoignages d’utilisateurs.

Quelles sont les nouvelles fonctionnalités dont vous parlez ? De l’intelligence artificielle ?

Pour l’intelligence artificielle, nous n’avons pas attendu S/4 !

Nous avons surtout mis l’accent sur l’ergonomie avec une forte simplification des menus pour les orienter process (un menu par type de process) plutôt que profil (un menu par type de profil). C’est plus intuitif.

L’essentiel de la migration ECC6 vers S/4 est isofonctionnel. Mais nous avons déjà ajouté des fonctions comme la vision flux des dépenses. Et, toujours en lien avec les ministères et les métiers, nous avons défini un plan de développements sur la période 2024-2025 pour faire évoluer l’interface et profiter de S/4 pour créer de nouvelles fonctions liées aux processus opérationnels. Les bénéfices métiers vont donc être progressifs et croissants.

Au delà de Chorus et de la Facturation Electronique Obligatoire dont nous avons déjà largement parlé sur Républik IT, quels sont les prochains défis de l’AIFE ?

Comme je l’expliquais au début de notre entretien, Chorus DT (Déplacements Temporaires) gère les déplacements et frais de mission ainsi que les déménagements. C’est un produit spécifique dérivé d’un produit SAP Concur qui est en voie d’abandon par l’éditeur. Nous avons décidé d’internaliser le produit d’ici 2026. Ce type de démarche constitue une première et sans aucun doute un défi.

Nous avons longuement parlé de Chorus Coeur. La prochaine étape, encore en phase exploratoire, c’est une refonte de Chorus Formulaires. Il s’agit en effet de le faire évoluer autant sur le plan de l’ergonomie que fonctionnellement et techniquement. Nous procéderons sans doute par modules. L’intégration à Chorus Coeur pourra et devra être améliorée avec une APIsation totale : ECC 6 n’était pas full API alors que c’est le cas de S/4.

Enfin, Républik a déjà parlé de l’IAG Albert de la DINUM. Nous sommes, via un groupe de travail du Ministère des Finances, en train de travailler sur des idées de cas d’usage avec Albert.