François Bodin, SAP : « GBCP, une occasion perdue de mutualiser les SI »

Suite à notre article paru début octobre sur la mise en œuvre de GBCP – soit la Gestion Budgétaire et Comptable Publique –, François Bodin, directeur du secteur public chez SAP France, revient sur cette réforme qu’il considère comme une occasion ratée de mutualiser les systèmes d’information.

Rappelons que GBCP revient à étendre les principes de la LOLF (loi organique relative aux lois de finances) à environ 700 opérateurs de l’Etat. Un chantier mené au travers quasiment autant de projets, opérateur par opérateur. Alors que ces principes de gestion budgétaire et comptable ont été déployés au sein de l’administration centrale via une solution unique, mutualisée : Chorus, un progiciel sur base SAP administré par l’AIFE (Agence pour l’informatique financière de l’Etat).

Silicon.fr : Pourquoi une forme de mutualisation n’a-t-elle pas été davantage étudiée pour GBCP ?

François Bodin : La mutualisation pouvait prendre deux formes complémentaires : une forme organisationnelle, par exemple via le regroupement d’agences entre elles comme en Grande-Bretagne, et une forme technique, liée aux systèmes d’information. La première dépend d’une volonté politique. Concernant la seconde, une volonté d’examiner le sujet a existé, mais je ne suis pas sûr qu’elle ait été suffisamment forte pour explorer totalement le modèle. Ailleurs dans le monde, il existe pourtant des formes de mutualisation dont on pourrait s’inspirer, notamment dans les pays nordiques (avec l’exemple de KMD, qui a construit une plate-forme mutualisée fournissant aux agences de Suède des fonctions sous forme de services, NDLR) ou en Grande-Bretagne. GBCP est un sujet permettant d’engager une trajectoire de mutualisation des systèmes d’information entre les opérateurs de l’Etat. Et une opportunité permettant à des agences de mutualiser leurs activités sur des plates-formes innovantes allant vers plus de simplification et d’efficience.

Chaque réforme budgétaire coûte cher du fait de son impact sur les systèmes d’information. Et la volonté politique de simplifier, de mutualiser, d’harmoniser et de limiter les budgets, est clairement exprimée. La conjonction de ces deux éléments aurait dû justifier des investigations plus poussées autour d’une ou plusieurs plates-formes de mutualisation. Passer à côté, c’est un échec car on était face à un volume d’acteurs suffisamment important pour absorber ce type d’approche. Malheureusement, entre l’écosystème IT et les volontés d’indépendance des établissements publics, les freins sont encore trop importants.

La Disic dit avoir étudié ces trajectoires de mutualisation et parle de budgets pharaoniques…

Les expériences dans d’autres pays montrent pourtant que ces projets peuvent être conduits dans des budgets très raisonnables, avec à la clef de vraies économies. Je ne comprends donc pas pourquoi ces projets auraient été pharaoniques. Ils l’auraient été seulement s’ils ne s’accompagnaient pas d’une logique de transformation des métiers de back-office au sein des agences, par exemple via la création de services facturiers pour plusieurs établissements. L’intérêt de ces projets est d’apporter de la simplification, de l’harmonisation, ce qui permet de s’inscrire dans des trajectoires budgétaires raisonnables, tout en respectant les spécificités métiers de chaque établissement.

L’une des voies possibles aurait été de réexploiter Chorus, dans une version light et hébergée…

Oui et la construction d’une plate-forme de ce type a été étudiée par l’AIFE. La vraie difficulté émanait du nombre d’agences minimum qu’il fallait réunir pour rendre le projet viable. L’enjeu ne résidait donc pas dans le coût du projet à proprement parler. SAP avait d’ailleurs la volonté de faire bénéficier aux agences concernées de l’ensemble des conditions obtenues par l’Etat dans le cadre du projet Chorus.

Nous avons l’absolue certitude qu’une solution Chorus Light mutualisée sur un certain nombre d’agences aurait été bien moins chère qu’un déploiement unitaire, établissement par établissement. Pour peu, par exemple, que les 30 premières agences basculent dans ce système, au moins sur les processus de la chaîne de la dépense et de la recette.

Est-ce que ce projet d’un Chorus Light est aujourd’hui définitivement abandonné ?

Pour moi, ce projet est aujourd’hui mis au placard, mais pas définitivement abandonné. Il peut être relancé très vite s’il est appuyé par une impulsion politique, qui pour l’instant fait défaut. Chorus Light ferait gagner du temps – sur un chantier où les délais sont tendus – et de l’argent, tout en offrant une sécurité aux organismes de contrôle quant à la capacité des agences à respecter le nouveau cadre réglementaire.

Chorus n’est-il pas trop gros et trop riche pour de petits établissements ?

Chorus respecte un cadre réglementaire. C’est la même base logicielle qui est utilisée à l’EFS (Etablissement Français du Sang), à l’Agence de biomédecine, au CNRS mais également dans des PME de 20 personnes. Certains processus ne sont probablement pas nécessaires pour les plus petits de ces établissements ; il suffit alors de ne pas les activer. GBCP n’est ni plus ni moins que la reprise d’un certain nombre de composants de la LOLF. Et SAP répond aujourd’hui à ce cadre réglementaire.

Par contre, déployer un produit de cette nature pour une agence de 4 personnes n’a économiquement pas de sens. Tout simplement parce que déployer un système d’information, quel qu’il soit, pour un établissement de cette taille ne peut pas en avoir. C’est pourquoi la logique de mutualisation doit être une nécessité, et non une simple ambition. Avec un modèle qui se dégage : celui d’une plate-forme de services en mode Saas dans laquelle les agences viennent piocher des processus qu’elles payent à l’usage.

© bensliman hassan – shutterstock

A lire aussi :
GBCP : comment l’Etat a lancé 700 mini projets Chorus en parallèle
Jacques Marzin, DSI de l’Etat : « pour économiser, l’Etat a besoin d’un SI unifié »