« J’ai une idée, lançons un nouveau projet ! » - rien ne suscite en moi plus de consternation que d’entendre une telle déclaration. Or donc, mobiliser des moyens pour atteindre un objectif précis dans un calendrier déterminé à l’avance pourrait être une bonne idée dans le domaine du numérique ? Si bonne que l’on continue, année après année, à multiplier les nouveaux projets, et à les laisser monopoliser l’essentiel de nos ressources en qualité (chefs de projet, architectes, etc.) et quantité (budget), focaliser l’attention de la gouvernance et heurter les opérations des processus métiers concernés, tout cela pour rendre un service à la valeur discutable a posteriori, énerver les utilisateurs que l’on prétendait aider (dans l’indifférence la plus totale car, après tout, le projet est terminé), et conclure dix ans plus tard qu’il vaut mieux tout refaire (en général en patientant dix ans de plus que ce soit effectivement fait) ?

Bien entendu, il est pris de nombreuses précautions pour se prémunir contre ces écueils : méthodes agiles, comités utilisateurs, conduite du changement, approches budgétaires prenant en compte le coût de fonctionnement et de maintenance du futur système, etc. Mais toutes ces précautions ne sont que des pansements sur une jambe de bois, tant que la racine du mal n’est pas identifiée, à savoir le concept même de projet : objectif, ressources, calendrier.

Pas d’objectif, des orientations

L’objectif d’un projet est paradoxalement sa plus grande faiblesse. Malgré des technologies évoluant sans cesse, un écosystème mouvant, des processus métier adaptés en permanence et, surtout, un besoin que l’on va en réalité découvrir en grande partie « à l’usage », on prétend fixer un cap à suivre pendant plus de quelques semaines ou mois ? L’approche agile, lorsqu’elle est correctement mise en œuvre, permet de réorienter au fur et à mesure le projet, mais on garde l’idée d’un objectif qu’il faudrait approcher, quitte à le redéfinir tous les mois. Plutôt que de (re)concevoir tout un chemin dont on ne parcourra que les premiers mètres avant de changer d’objectif, pourquoi ne pas se fonder à tout instant sur un ensemble de finalités pérennes (simplifier le travail de telle catégorie d’utilisateurs, faire des économies dans tel domaine métier, faciliter l’application de telle réglementation, etc.), dont les pondérations vont évoluer avec le temps, et sans idée figée sur la manière dont elle sera finalement approchée ?

« J’AI UNE IDÉE, LANÇONS UN NOUVEAU PROJET ! »

Au Ministère de l’Education Nationale (MEN), j’ai été stupéfait de voir des maitres d’ouvrage définir à l’avance les versions V2 et V3 de produits qui n’existaient pas encore, entérinant par avance qu’on ne consacrerait aucune ressource significative à recadrer la V1 en fonction du retour des utilisateurs, y compris pour des projets comme ONDE (gestion de la scolarité du 1er degré), théoriquement développé en mode agile.

Pas de ressources dédiées au projet

Historiquement, les organisations projet ont été mises en place parce que les équipes responsables de l’exploitation et du soutien (les « opérations ») arrivent difficilement à dégager des ressources pour faire évoluer les systèmes. Il semble que, au fil des années, le remède soit devenu pire que le mal en menant à des évolutions déconnectées des préoccupations tant techniques que fonctionnelles du terrain. Les récents efforts pour rapprocher les équipes projets et de production sont louables mais le bénéfice espéré reste limité, souvent au prix d’une grande complexité des organisations qui tentent de marier au mieux des principes contraires. Plutôt que de séparer des activités pour ensuite mettre en place des couches de coordination entre elles, pourquoi ne pas revenir sur cette séparation ?

Lorsque je travaillais en start-up, les développeurs contribuaient régulièrement au support des utilisateurs, même de bas niveau – vous pouvez imaginer leur motivation pour mener les petites évolutions permettant de limiter le besoin des utilisateurs à solliciter leur assistance !

Pas de calendrier recalé sans cesse

Il est évident que certains éléments d’un projet numérique sont soumis à des contraintes calendaires (liées à un besoin métier ou un lien avec un autre système) qu’il est nécessaire de surveiller au plus près, sous peine de mener à des conséquences métier disproportionnées. Néanmoins, ces éléments, même s’ils sont parfois critiques, restent le plus souvent peu nombreux. Pour autant, on continue de suivre en détail, pour l’ensemble d’un projet, l’évolution par rapport à un calendrier dit « initial », dans l’espoir d’identifier facilement des activités inefficaces, alors même que l’écrasante majorité des glissements sont liés à un défaut de planification, une évolution des objectifs (cf. ci-dessus) ou des obstacles initialement inconnus, et non à un défaut de réalisation. Pourquoi ne pas gérer les contraintes calendaires comme n’importe quelle autre contrainte (sécurité, respect d’une norme, respect d’une interface, etc.), et fonder sur d’autres indicateurs la supervision du projet - valeur apportée par unité de temps et de ressource, par exemple ?

« FACIALEMENT EN GRAND RETARD CAR GÉRÉ DE MANIÈRE AGILE, LE PROJET CYCLADES A EN RÉALITÉ ÉTÉ À L’HEURE DE TOUTES LES RÉFORMES ! »

Le calendrier du projet Cyclades, refonte du S.I. de gestion des examens et concours du MEN, a été recalé tous les trois mois pendant plusieurs années, alors que ces modifications de calendrier étaient simplement le signe que le projet était géré de manière agile en intégrant au fur et à mesure tous les besoins nouveaux, dont la correction dématérialisée des copies et l’attestation numérique de diplôme. Facialement en grand retard, ce projet a en réalité été à l’heure de toutes les réformes successives (réforme du brevet, du bac, etc.). 

La difficulté principale à la mise en place d’une approche produit est que, encore bien plus que l’agilité, elle mène à revoir complètement l’organisation et la gouvernance des activités, ce qui nécessite un partage et un consensus très large autour de cette vision. Quelle que soit l’entité, en particulier dans des organisations publiques hors de la DGA, l’ingénieur de l’armement peut avoir un rôle clef dans cette transformation. En effet, acteur reconnu du pilotage de projet (au-delà du numérique), l’ingénieur de l’armement est parfaitement outillé pour diagnostiquer les écueils du mode projet dans le domaine du numérique, et proposer son dépassement.

La refonte d’un système : la solution de (fausse) facilité

Les projets de refonte sont souvent issus de deux idées préconçues :

-  Il serait impossible de remplacer progressivement les technologies obsolètes d’un système par des technologies récentes,

-  Il serait plus facile de développer à partir de rien.

Or, un système existant depuis 10 ou 20 ans a évolué pour répondre à un ensemble de problèmes de plus en plus large, que personne ne sera jamais capable de formaliser. Pire : les utilisateurs ont capitalisé sur certains défauts du produit. La mise en place d’un nouveau produit conduit donc inévitablement à des régressions dont il est impossible d’anticiper les conséquences. Il est donc préférable, si on ne peut faire évoluer progressivement le produit, de le refondre par parties, de manière à éviter l’épreuve du feu de la mise en production sous forme de big bang, même en limitant le périmètre des « cobayes ». Et c’est possible grâce à des méthodes d’encapsulation, applicables même aux technologies.

« COMMENÇONS DONC À FAIRE UN SYSTÈME QUI N’APPORTE PRESQUE RIEN, ET CONSTRUISONS PEU À PEU DESSUS »

Le produit minimum viable, cet inconnu

Un obstacle fréquent à l’approche produit est que le projet peut paraître nécessaire pour mettre en place une première version utilisable d’un nouveau système. Or, ce « produit minimum viable » est souvent exagéré. Il faut bien se rendre compte que pour mettre en place les synergies de l’approche produit, il peut suffire d’un système dont les fonctionnalités vont n’intéresser qu’une faible portion des futurs utilisateurs. Commençons donc à faire un système qui n’apporte presque rien, voire rien du tout, et qu’une fraction infime des futurs utilisateurs (les 0,1% un peu technophiles par exemple ou des utilisateurs face à une difficulté de niche) va consentir à utiliser, et construisons peu à peu dessus. Le produit minimum viable n’est même parfois pas un nouveau système, mais une configuration particulière d’un système existant ou un lien entre deux systèmes existants.