Dématérialisation et gestion de la paie

Fin novembre 2013, le Ministère de la Défense a annoncé qu’il abandonnait sa solution de gestion de paie, dite « LOgiciel Unique à VOcation Interarmées de la Solde » (« Louvois »), destiné à centraliser la gestion des paies des militaires français tous corps d’armée confondus, après plusieurs années de difficultés et de déconvenues.Un projet ambitieux…

media_file_296

Projet de rationalisation du secteur public militaire engagé il y a plus de 10 ans, le projet « Louvois », initialement sous maîtrise d’œuvre de SOPRA, avait connu un premier échec en 2005, faute d’uniformisation des systèmes de gestion RH et d’une réglementation adaptée. Déjà à l’époque, l’impréparation du contexte semble avoir joué un rôle dans les problèmes rencontrés.Un nouvel appel d’offres fut lancé, et remporté par STERIA en 2007, pour assurer la maîtrise d’œuvre. Mais dans tous les cas, le calculateur « Louvois » à proprement parler, était programmé et développé par l’Armée elle-même (personnel technique interarmées basé à Tours).La solution logicielle Louvois a été mise en production progressivement à partir de 2010. L’entreprise était de taille : « Louvois » devait permettre de traiter les soldes de centaines de milliers de militaires, dont la rémunération présente une grande complexité en raison des diverses primes et régimes applicables. « Louvois » remplaçait ainsi une quinzaine de logiciels préexistants et devait dialoguer avec 5 systèmes de gestion RH différents (un par corps d’armée : Marine, Terre, Air, Santé et Gendarmerie). On imagine le volume des spécifications de la solution, et la complexité des règles de gestion du produit…

… qui tourne au fiasco.

Dans la presse aujourd’hui, au sujet de la solution Louvois, les mots utilisés témoignent de ce qu’une entreprise ou une administration peut vivre en cas de dérive d’un projet informatique : « fiasco », « catastrophe budgétaire », « désastre humain », « cauchemar »… et ce sont en effet ces termes qui reviennent souvent dans le cadre des contentieux liés aux échecs de projets informatiques, parce qu’aux yeux du client et souvent aussi du prestataire, ces projets se transforment en gouffres financiers et entraînent un rejet des utilisateurs qui en vivent parfois douloureusement les conséquences.

En l’espèce, les conséquences de l’échec Louvois sont gravissimes sur les caisses de l’Etat, mais aussi plus directement sur de nombreuses familles de militaires qui ont été poussées au surendettement à cause des impayés dont ils ont été victimes. Les erreurs ont pris des proportions très graves moment du raccordement au SIRH de l’Armée de Terre, plus complexe que les autres corps d’armée, à partir de l’année 2011. Et, comble de l’ironie, les palliatifs mis en œuvre pour tenter de limiter l’hémorragie et de corriger les conséquences des erreurs de calcul finissent par contredire l’intention initiale de convergence de tous les systèmes vers un centre de paie unique.

Un contexte très complexe

Un premier réflexe est alors de se tourner vers l’intégrateur maître d’œuvre, dont la responsabilité semble bien engagée. Toutefois, un compte-rendu de l’audition du chef du contrôle général des armées (CCGA) par la Commission de la Défense Nationale et des Forces Armées, en date de juin 2013, fait apparaître que le projet « Louvois » était soumis à trop de circonstances contradictoires (création du Service du Commissariat des Armées, fermeture des centres payeurs précédents, mutualisation des services RH, pression de l’Opérateur National de Paie, etc.), dans le détail desquelles nous n’entrerons pas ici, mais qui font apparaître un défaut de planification générale qui ne relevait pas de la responsabilité de STERIA.

En effet il ne s’agit pas là du pilotage attendu d’un intégrateur maître d’œuvre, mais plutôt de la planification du contexte organisationnel, économique et législatif du projet. Rappelons que le projet Louvois de convergence technologique s’inscrivait dans un contexte de restructuration profonde du Ministère impliquant 54.000 suppressions de postes sur 6 ans, soit une véritable révolution administrative.

Les organes décisionnaires, au sein de l’Armée, étaient trop nombreux, contradictoires et ont changé dans le temps. Les experts militaires de la gestion de la solde ont également été déplacés, dans le cadre de la Revue Générale des Politiques Publiques (RGPP). Sans pouvoir entrer dans le détail des différentes autorités qui sont intervenues, il est en tout cas certain que le projet « Louvois » n’a pas fait l’objet d’un pilotage cohérent et pérenne. Mais l’Armée elle-même était tributaire de la Loi de Programmation Militaire et de la RGPP, réformes dont la cadence ne tenait tout simplement pas compte des réalités du terrain.

Des responsabilités multiples…

Dans son audition de juin 2013, le CCGA indiquait : « Les principales déficiences sont aujourd’hui pour la plupart identifiées : une gouvernance trop complexe, la difficulté récurrente à constituer les équipes nécessaires à la mise en œuvre du projet ; un défaut d’information sur la situation exacte de l’armée de terre au moment du raccordement à Louvois ; l’absence de simplification et d’harmonisation des régimes indemnitaires préalables à ce raccordement, ceux-ci étant source de complications techniques ; l’insuffisante préparation des services chargés d’introduire les informations sur les ressources humaines nécessaires au calculateur ; et les défaillances du contrôle interne ».

En septembre 2013, un rapport parlementaire (Rapport n° 1353 « La réorganisation du ministère de la Défense : d’une LPM à l’autre ») rappelait les dysfonctionnements nombreux du calculateur de paies Louvois, conduisant – dès lors qu’il était en production – à de très nombreuses erreurs de calcul. Ces erreurs ont pris des proportions phénoménales puisqu’entre décembre 2012 et novembre 2013, le manque-à-gagner global des militaires était de 68 millions d’euros, et le trop-perçu s’élevait à 184 millions (bien que ces chiffres varient d’un article à l’autre).

Et il ne s’agit là que des conséquences comptables des dysfonctionnements, qui n’incluent pas les coûts faramineux que le Ministère doit exposer pour corriger ces erreurs, ni le coût de la future migration vers une solution de rechange. L’un des députés auteur du rapport chiffre aux environs de 200 millions par an le coût subi par l’Armée – et donc l’Etat, et même 213 millions en 2012.

… mais pas formellement établies

Aucun contentieux judiciaire n’étant apparemment introduit pour l’heure, il serait hasardeux de prétendre se prononcer sur les responsabilités de cet échec final de Louvois. Il est d’autant moins possible de risquer une analyse que la physionomie des contrats conclus par le Ministère avec les prestataires, ainsi que leur degré d’engagement, sont également inconnus. Mais il s’agit d’une illustration saisissante des conséquences que peut avoir l’échec d’un projet informatique.

Toujours selon les observations parlementaires, l’origine du désastre Louvois est plurielle. Le logiciel présentait de nombreuses anomalies de fonctionnement, et les corrections apportées par les prestataires en charge du projet ne faisaient apparemment qu’entraîner de nouvelles erreurs. L’existence d’anomalies de programmation semble incontestable.

Mais les députés ont souligné que STERIA ne devait pas être le bouc-émissaire de ce fiasco, dans la mesure où ils ont plutôt identifié un grave problème de pilotage du projet ab initio. Ces problèmes semblent imputables à une « dilution des responsabilités » au sein de la chaîne décisionnaire, à une certaine « précipitation » dans la mise en œuvre du produit (il était question de réduire drastiquement les coûts de gestion des soldes dans le cadre de la RGPP), et à des tests peu rigoureux – qui ont donc pu conduire à mettre en production des fonctionnalités défaillantes.

Lassé d’être cité dans la presse et présenté à mots couverts comme responsable de ce gâchis, l’intégrateur STERIA a précisé qu’il n’était pas à l’origine du développement du calculateur de soldes original qu’il lui incombait d’adapter, qu’il n’est intervenu que deux ans après la mise en production du logiciel Louvois, et qu’il avait justement pour mission « d’aider à mettre fin aux dysfonctionnements de cette solution développée par un tiers ». (STERIA va d’ailleurs continuer à assurer la maintenance de la solution jusqu’à migration vers une alternative).

L’intégrateur a apporté des précisions sur l’origine des difficultés, apparemment liées à une programmation initiale indigente rendant le produit perméable aux erreurs éventuellement chargées par les utilisateurs, sans contrôle. Il peut alors être extrêmement difficile de remédier à cette fragilité native en ajoutant des couches de correctifs.

Produit initial inadéquat, pilotage incohérent, précipitation induite par des facteurs extrinsèques, semblent donc avoir participé à cet échec, et il est intéressant de s’interroger sur les responsabilités qu’une expertise informatique aurait permis d’établir, entre l’éditeur du calculateur de paie Louvois, l’intégrateur en charge de la maîtrise d’œuvre, le client responsable du pilotage du projet, et les tiers intervenants. On note que jamais « l’éditeur » du logiciel ne s’est prononcé sur l’échec du projet Louvois : il semble que ce sont les militaires eux-mêmes qui ont développé la version initiale du calculateur, qui ne peuvent donc pas s’exprimer publiquement. A défaut d’une véritable action judiciaire, l’étendue et le partage des responsabilités ne seront donc peut-être jamais mesurés en dépit des pertes subies.

De plus, c’est à l’aune des engagements contractuels des protagonistes qu’il faut mesurer la réalité et la gravité de leurs manquements. En l’absence de précisions sur les contours exacts de la mission de STERIA, et étant rappelé qu’elle n’avait pas développé le calculateur, il n’est pas possible d’en tirer de conclusion sur son éventuelle responsabilité. Tout au plus peut-on dire que si les difficultés étaient relatives à la programmation du module, il devait être possible d’en venir à bout ; en revanche si c’est au stade des spécifications fonctionnelles et techniques initiales que des erreurs ont été commises, il faut alors rechercher qui a procédé à leur rédaction et pourquoi elles ont été validées par le maître d’ouvrage alors qu’elles présentaient des vices…

Certes, STERIA était annoncé en tant que maître d’œuvre de la solution et responsable de la correction des bugs, ce qui va au-delà d’une simple assistance à la maîtrise d’ouvrage. A première vue, il semble difficile d’exonérer totalement de toute responsabilité l’entité en charge de corriger les anomalies, si celles-ci réapparaissent ou se multiplient régulièrement. Certains articles semblaient accabler l’intégrateur, d’autres évoquaient au contraire l’indemnisation de ses pertes par le Ministère…

Mais l’expérience des contentieux informatiques prouve que les causes d’un dysfonctionnement logiciel peuvent être diverses : il peut s’agir d’erreurs de programmation, d’erreurs dans l’intégration ou l’interfaçage, mais aussi d’erreurs dans les spécifications initiales, voire des incohérences dans l’expression des besoins ou, comme il est établi ici, dans le pilotage global du projet et de son contexte.

Le premier enseignement à tirer de cet échec retentissant est donc, face à la multiplication d’articles contradictoires dans la presse, de ne pas tirer de conclusion sur des responsabilités juridiques à défaut d’avoir pris connaissance d’une décision de justice, ou au moins des engagements contractuels de chaque protagoniste.

Le deuxième enseignement, détaillé ci-dessous, est de savoir planifier un projet d’envergure à l’avance, et également de savoir y mettre un terme lorsqu’il devient clair qu’il ne peut plus être mené conformément aux prévisions contractuelles.

Quand mettre fin à un projet informatique qui dérive ?

Nous avons évoqué à plusieurs reprises les précautions à prendre dans la gestion d’un projet informatique d’envergure. Plus le projet est complexe, et/ou critique, plus il est crucial de le concevoir et de le représenter au préalable. Les contrats de cadrage, notamment, permettent avant de commander quelque solution que ce soit, de demander à un professionnel de prendre connaissance de l’existant et des objectifs, et d’apporter ses préconisations pour optimiser les chances d’atteindre lesdits objectifs.

Un tel travail préparatoire permet en particulier de figer des hypothèses de travail (et donc de budget) à périmètre fonctionnel et contexte métier constant. Une fois le projet pensé jusqu’à son terme, il devient plus facile d’identifier ensuite tout facteur de dérive lorsqu’il apparaît, et d’en recalculer les conséquences rapidement. Et surtout, il est possible pour le maître d’ouvrage de s’engager dans un projet de longue haleine en disposant d’une visibilité réelle.

Mais même en concevant à l’avance le projet dans toutes ses dimensions, un projet informatique n’est jamais à l’abri de difficultés et d’imprévus, que ceux-ci émanent de la faute d’un des contractants, ou du contexte économique, marché ou réglementaire du projet. Si l’on écarte le cas des Méthodes Agiles, qui doivent justement permettre d’appréhender le changement sans remettre en cause le déroulement d’un projet informatique, force est de reconnaître qu’il faut savoir mettre un terme à un projet et donc identifier à partir de quand il n’est plus viable.

En l’espèce, c’est lorsque l’administration a acquis la conviction que « le logiciel ne fonctionnera jamais correctement », qu’elle a finalement décidé de l’abandonner. D’aucuns pourraient trouver cette décision extrêmement tardive, au regard du temps écoulé depuis les premières difficultés, et compte tenu surtout de la gravité des conséquences…

Ceci éclaire l’une des questions qui se pose très souvent dans le cadre des expertises informatiques menées sur les solutions logicielles défaillantes en cas de litige : : le client met-il un terme au projet trop tôt, ou trop tard ? Quelle décision doit-il prendre lorsque les dérives constatées ne semblent plus pouvoir être résorbées et partant, lorsque les objectifs qu’il poursuivait en commandant le produit ne peuvent définitivement plus être atteints ?

L’échec de « Louvois » est peut-être avant tout la démonstration que lorsqu’un projet est engagé sur de mauvaises bases ou dans un contexte trop mouvant, et que les besoins fonctionnels ainsi que les règles de gestion du produit ne sont pas parfaitement établis – et validés – ab initio, il peut être assez illusoire de prétendre y remédier dans un second temps. La décision de mettre un terme à un projet en dérive est donc particulièrement critique, car elle peut tout autant arrêter une hémorragie qui ne peut plus que s’aggraver, ou au contraire supprimer les dernières chances qui restaient de rentabiliser les investissements réalisés par les parties.

En l’espèce, l’interfaçage avec les SIRH de la Marine et de l’Armée de l’Air avait déjà causé des difficultés, mais elles semblaient à peu près maîtrisées. C’est lorsque la paie de l’Armée de Terre a été intégrée que le projet est véritablement parti à la dérive. Trop de données à gérer, présentant trop de particularités par rapport aux règles de gestion ? Trop de règles de gestion, non implémentables dans le calculateur tel qu’il avait été développé ?

En toute hypothèse, cet échec rappelle, pêle-mêle, l’importance capitale de la transition avec les anciens systèmes ; la nécessaire prise en compte des facteurs extrinsèques, y compris par le prestataire (modification du contexte économique, réglementaire ou organisationnel dans le cadre duquel se déroule le projet) : un projet informatique ne se mène pas ex nihilo : il s’inscrit nécessairement dans un contexte métier, et doit prendre en compte des contraintes tirées notamment de l’ensemble des autres systèmes avec lesquels il doit interagir, et des données qui doivent alimenter son fonctionnement. Il appartient au client de les inclure dans sa réflexion, de même qu’il appartient au prestataire de les prendre en compte – ou du moins d’interroger et conseiller le client à cet égard.

Cet échec illustre également la nécessité d’une planification à l’avance (comme indiqué ci-avant), et la nécessité d’une direction de projet pérenne, unique et cohérente (qu’elle soit assumée par un prestataire ou par le client).

* * *

En septembre, le rapport parlementaire explorait deux pistes : continuer avec le logiciel en redoublant d’efforts pour résorber les anomalies constatées, ou l’abandonner finalement et préparer la migration vers un autre produit, « dont le déploiement nécessiterait probablement un délai de trois ans » selon les députés. Aujourd’hui, la décision a été prise : arrêt définitif du projet « Louvois ». Selon les prévisions du Ministère, les calculs vont devoir se poursuivre encore pendant 2 ans sur « Louvois », avec la maintenance de STERIA qui s’efforcera de corriger les erreurs de calcul constatées, et le personnel alloué en renfort qui continuera de régulariser manuellement les conséquences sur les soldes des militaires.

Les commentateurs parlent finalement de « responsabilité collective », ce qui semble confirmer qu’en dépit du formidable gaspillage d’argent public provoqué par cet échec, les responsabilités ne seront peut-être pas recherchées.

Il est donc probable qu’à ce stade, les militaires – comme les contribuables – vont continuer à pâtir d’un échec qui aurait dû être anticipé et contrôlé plus tôt, mais qu’un singulier cumul d’erreurs et de contradictions a transformé en naufrage durable.