Systèmes d’information de l’état : un cap, un ligne, reste à revoir les méthodes

Après la série d’échecs qui a frappé plusieurs grands programmes de systèmes d’information, le temps est venu pour l’État de tirer avec les professionnels du secteur, les enseignements.

La gouvernance des systèmes d’information de l’état a été renforcée cet été, avec notamment un rattachement direct au premier ministre. Un cap est assigné : un système d’information unique mettant fin à la politique de tuyaux d’orgues issue de  la suprématie de chaque ministère sur son système d’information. La finalité est définie : rationalisation des coûts d’investissement et de fonctionnement, avec  comme objectif  une baisse de 25 à 40% sur les coûts en prestations. Un élan nouveau semble ainsi naitre à l’initiative de Jacques Marzin, son directeur, dont l’efficacité et la détermination, sont connues. Tout cela était nécessaire, encore fallait- il s’y atteler.

Sans vouloir ajouter aux comportements d’auto-flagellation si fréquents actuellement, ne devrait on pas néanmoins s’interroger, ne serait ce que pour mieux tourner la page, sur les causes de la série d’échecs qui a frappé les grands programmes de transformation des SI de l’état (Chorus, DMP, ONP, Louvois,…), et tenter de comprendre pourquoi plus d’un tiers de grands projet de SI n’aboutissent jamais et pourquoi, lorsque ils aboutissent, c’est pour moitié hors délais, hors budget  ou  avec une qualité moindre que prévue.

La moisson des causes de désordre relatées par les nombreux rapports  officiels à la suite de cette série noire est impressionnante. Pour ne citer que les plus saillantes : gouvernance défaillante, mauvaise synchronisation des acteurs étatiques et industriels, donneurs d’ordre multiples, architectures trop ambitieuses, mauvaise évaluation de la complexité, niveau d’intégration mal maîtrisé, données trop hétérogènes, manque de concertation avec les agents et les usagers de préparation et de formation, insuffisance du cadre contractuel, rigidité des marchés publics, etc. Au delà de ces constats, on ne voit pas venir une concertation entre l’état et les professionnels des systèmes d’information, qui permettrait d’identifier les axes d’améliorations, d’ajuster les méthodes, de perfectionner le cadre juridique de ces projets  et donner corps à une sorte d’aggiornamento méthodologique qui pourrait utilement compléter le cadre stratégique commun des SI de l’état  initialisé en 2012.

Les thèmes suivants, dont plusieurs sont identifiés depuis longtemps, devraient au minimum figurer dans cette concertation :

La sécurisation des transitions métiers

Les programmes de transformation de la gestion de l’État pêchent actuellement plus par un défaut de maitrise des transitions métier, humaines, organisationnelles et règlementaires, disons de la composante organique des systèmes d’information, que par des défauts de construction de la composante technique que constituent le logiciel et son environnement technique. Cette dernière semble avoir atteint un état stable, probablement temporaire, sous l’effet de la normalisation internationale, des progrès du génie logiciel et des ERP. Preuve semble en être le faible taux de mise en cause des  SSII dans les échecs récents précédemment cités (!). En revanche la composante « métier »  des programmes de transformation du secteur public porte les  transitions les plus fortes, particulièrement dans les projets interministériels. Il est vrai que la tâche n’est pas simple ; qu’il s’agisse de simplifier, mutualiser, d’externaliser, il faut mettre en place de nouvelles façons de travailler, réorchestrer l’interaction de chaînes métier, le cas échéant redéfinir les services à l’usager, mettre en convergence des usages de gestion imprégnés de l’histoire et de la culture de chaque  Ministère, modifier en conséquence l’organisation administrative sans la dénaturer, adapter les processus de travail sans forcement pouvoir les unifier, remodeler les comportements tout en tenant compte de leurs spécificités,  aligner des données hétérogènes, faire converger des règles de gestion aussi variées que le sont les  corps, simplifier au passage  le substrat réglementaire.  Il faut aussi réaliser ce parcours de transition dans la concertation avec les agents pour  que l’acceptation et l’adhésion soient au rendez-vous lors de la mise en opération. Il faut enfin veiller à ce que les inévitables secousses sociales provoquées par ces transformations, ne puissent servir de prétexte à exister aux organisations dites de « l’interaction ». Belle gageure !.

Les méthodes pour  maîtriser ces écueils existent pourtant. Elles permettent  de bâtir rapidement la cible « théorique » du système souhaité ; Mais très souvent la « carte » n’est pas conforme au « territoire » et lors du passage en opération, lorsque l’homme entre dans le jeu, se saisit de ces théories pour en faire son quotidien, le système se grippe. Insuffisance des méthodes d’intégration de systèmes qui tendrait à se pencher sur la théorie de l’émergence, selon laquelle un système intégré aura toujours des propriétés nouvelles, dites « émergentes » qui ne peuvent pas facilement se déduire de l’analyse des briques de base ? Mise en œuvre dévoyée des méthodes de conduite du changement, dont il faut bien constater qu’elles sont souvent réduites à un exercice de communication lors duquel, des bataillons de jeunes consultants tentent de convaincre l’utilisateur avec force visuels, des beautés du système qui a été concocté pour eux mais le plus souvent sans eux,  sans réelle recherche d’une dynamique  de co-construction?

 La professionnalisation de  la  conduite de projets ?

Le calcul et  le pilotage des trajectoires de transformation est, il faut bien le dire, le lieu de tous les dangers pour un grand projet du fait de la diversité des paramètres à intégrer, paramètres qui ne sont pas tous quantifiables. Là encore les méthodes existent, d’ordonnancement des tâches, de synchronisation des chantiers, de  gestion de chemin critique, de positionnement des jalons, de détection anticipée  des risques, de calcul du coût objectif. La fonction de « pilote », ne se résume pas à la collection de ces savoir-faire. Le pilotage simultané de l’ensemble de ces composantes, l’identification des options et combinatoires que suggère l’évolution de leurs paramètres, l’intégration dans cette réflexion d’une juste appréciation du facteur humain, requiert une capacité à percevoir simultanément l’état réel des transformations organisationnelles, le niveau d’adhésion et de préparation des agents, la réalité de l’engagement des hiérarchies. Il impose d’imaginer des stratégies de contournement, ou de compromis, de disposer d’une forte capacité de conviction, d’empathie et de leadership pour les faire valider. La capacité à piloter ce type de projet est un métier en soi qui agrège la maîtrise de ces savoir faire, mais surtout d’une solide expérience et de pas mal d’intuition. On retrouve en définitive assez rarement ce profil sur nos grands projets, où on lui a souvent préféré celui de gourou « métier» ou d’expert technologique chevronné. Un progrès réel serait de systématiser  de telles compétences au sein des programmes de transformation et pour ce faire, de renforcer les filières de sélection, de formation et d’apprentissage des chefs de projets de transformation.

 La répartition des rôles respectifs de la MOE et de la MOA  au sein des structures  de projet

La distinction entre maître d’ouvrage  (MOA) maîtrise d’œuvre (MOE) est essentielle mais, mal interprétée, est devenue la cause de dysfonctionnements fatals pour  de nombreux projets. Le sujet est un peu technique mais mérite une réelle prise de conscience. La distinction MOE / MOA permet d’isoler nettement les responsabilités des deux entités : la maîtrise d’ouvrage, d’une part, seule responsable de la fixation des objectifs du projet, de l’expression des besoins, de la définition des exigences et de la mise en place des moyens, le maître d’œuvre d’autre part, à qui reviennent  les responsabilités de conception, de réalisation et de livraison opérationnelle de la solution dans les conditions de délais, de qualité et de coût fixées par le maître d’ouvrage. Nul besoin de revenir sur cette répartition qui fonde pour bonne part, notre droit des marchés publics. En revanche une interprétation « erronée » » de ce texte, qui consiste notamment à assimiler la « direction informatique »  à la maîtrise d’œuvre, est très probablement la cause de nombreux désordres observables sur les grands projets. Cette confusion, parfois volontaire, a pollué la gouvernance de nombreux projets. D’une part elle a conduit à annihiler l’organisation en « mode projet » que l’on peut voir comme le corollaire de la distinction MOE MOA, d’autre part elle créé un rupture de responsabilité  préjudiciable à la bonne fin des projets.

L’organisation en mode projet, est la condition clé de la réussite des programmes de transformation. Elle consiste à concentrer au sein d’une structure dédiée  les ressources nécessaires à la conception et à la réalisation de la solution. Ces ressources issues des directions concernées, métiers, logistique, informatique, gestion, finance,… doivent pouvoir agir en suspension de l’autorité hiérarchique et fonctionnelle des directions desquelles elles sont détachées, au profit de celle des  responsables et  instances de pilotage du projet , sous l’autorité spécifique d’un chef de projet, exclusivement dédié au succès du projet, doté par les services pourvoyeurs des moyens techniques et d’un budget, appliquant les directives d’un comité de pilotage et fonctionnant sous son autorité et son contrôle. La difficulté est de maintenir cet écosystème dans un équilibre  productif, or, l’assimilation erronée de la maîtrise d’ouvrage au métier et de la maitrise d’œuvre à la direction informatique provoque systématiquement des tiraillements qui finissent par désorienter l’équipe de projet, annihiler sa capacité créatrice, altérer son budget  et en définitive confisquer l’autorité qui lui est nécessaire pour mener le projet à bon terme.

Aussi grave est la rupture de responsabilité qu’elle induit : En effet  si on persiste à attribuer à la maitrise d’œuvre la responsabilité de seule composante technique du projet de transformation, qui portera  la responsabilité  de la transformation du métier ? Ce ne peut être maîtrise d’ouvrage  dont rôle n’est pas  d’opérer la transformation métier mais d’en définir les exigences. C’est donc le rôle de la maîtrise d’œuvre de s’organiser de telle sorte que l’ensemble des dimensions du projet et les ressources correspondantes tant « métier » que « technologique » soient regroupées en son sein. Ainsi la maîtrise d’œuvre portera, comme il se doit, la pleine responsabilité de la conception de la réalisation et de livraison d’une solution opérationnelle complète, cohérente, conforme, dans toutes ses dimensions, à l’expression de besoin de la maitrise d’ouvrage et ne pourra, en cas de dysfonctionnement du système, se défausser, comme c’est souvent le cas sur celle-ci  au prétexte que la transformation des métiers, tâches comme nous l’avons vu éminemment  délicate, n’est parfois  pas au rendez-vous.

Le renforcement du pouvoir des utilisateurs

Personne ne nie l’importance de la prise en compte des besoins comme des pratiques propres à l’utilisateur final dans la création d’un nouveau système d’information impliquant une transformation sociale, en revanche sa mise en œuvre reste souvent délicate. Alors pourquoi ne l’institutionnalise t on pas ? La  mise en place d’une maîtrise d’usage au sein d’une nouvelle trilogie MOU/ MOE / MUS, permettrait de palier ces  difficultés en institutionnalisant la présence de l’utilisateur tant aux cotés de la MOU pour définir le besoin et s’assurer qu’il est satisfait  qu’à ceux de la MEU pour concevoir la solution. La réflexion devrait ici se faire sur la portée de ce nouveau rôle, sur ses procédures de travail, le caractère consultatif ou contraignant de ses avis, sa représentation.

Enfin, cette réflexion en forme d’aggiornamento, devra prendre en compte plusieurs facteurs émergents qui, opportunément combinés,  devraient favoriser la transformation digitale du secteur public, atténuer les lourdeurs de mise en place, augmenter la réactivité  et partant, la proximité avec l’usager citoyen. Les « nouveaux paradigmes issus du numérique » ([1]), des technologies Cloud, des objets connectés, de la robotisation ; elles donnent un tour nouveau aux politiques publiques en  instillant un regain de productivité  dans les processus de production et en favorisant l’émergence de nouveaux types de service. D’autant que tout s’accélère depuis que l’immédiateté et plasticité des interfaces permettent aux utilisateurs et aux agents d’appréhender concrètement la finalité des systèmes et de prendre ainsi conscience de leur capacité à modeler leurs capacités fonctionnelles au plus près des besoins et à suggérer des solutions souvent plus simples et plus frugales. Cela renforce leur position de personnage clé de la construction de SI, ce que l’on a souvent dit et trop peu souvent fait. De ce fait  les « méthodes agiles » de construction de systèmes, qui instrumentalisent  l’approche collaborative et misent sur l’interaction et la réactivité regagnent du terrain ; les statistiques montrant même qu’elle sont un facteur de réduction du taux d’échec des projets par leur aspect itératif et incrémental. Autre paramètre encore peu pris en compte, l’ « engagement citoyen », c’est à dire la volonté de mettre sa pensée, sa parole et son action au service d’une cause collective, citoyenne, peut s’avérer un vecteur particulièrement fort pour la transformation digitale du service public. Enfin le « design de service », qui s’appuyant sur l’expérience des utilisateurs, permet de modeler l’interaction, la navigation, la relation de l’usager au service proposé en anticipant le déroulement d’actions et de résultats pour assurer l’utilisation optimale d’un service.


[1]  Des recherches récentes de Cisco situe à 5,4 $ billions  la valeur  en jeu  sur l’apport du numérique au le secteur public , dans les dix prochaines années, en terme de nouveaux revenues , d’amélioration de productivité, sans compter les retombées annexe sur le service rendu a l’utilisateur et la meilleur  utilisation des actifs

Share Button