Une loi pour le partage de code gouvernemental

Un billet de Janet Worthington (Forrester) attire mon attention sur une loi américaine – promulguée avant l'arrivée de l'administration en place aujourd'hui – imposant aux agences fédérales de partager le code des applications développées par leurs soins. Une bonne idée… qui risque hélas de se heurter aux dures réalités des « vieilles » organisations.

Si Janet rapproche l'initiative de la devise écologique de « réduction, réutilisation, recyclage », je préfère, pour ma part, m'en tenir à l'analogie du modèle du logiciel libre. En l'occurrence, l'objectif du législateur est, à travers l'obligation de distribution des composants créés en interne, de promouvoir leur adoption par d'autres entités dans le but d'optimiser le rendement des investissements associés (représentant 12 milliards de dollars annuels) et améliorer l'efficacité de l'informatique gouvernementale.

Dans cette perspective, le texte exige que tous les artefacts produits par les équipes – non seulement le code mais également la documentation, les modèles de données, les schémas d'architecture, les scripts de configuration, les scénarios de test… – soient mis à disposition sur au moins un dépôt, privé ou public, accessible à l'ensemble du personnel fédéral, et restent activement gérés par l'administration d'origine. Sur l'autre versant, les « clients » potentiels sont encouragés à s'approprier les éléments qui répondent à leurs besoins, en les faisant évoluer à leur convenance si nécessaire.

Sur le principe, on comprend la logique de la démarche : avant de dépenser des fortunes et de longs mois (voire des années) dans la recherche de solutions sur le marché ou la conception et la réalisation d'une nouvelle application, en partant de rien, il est préférable de commencer par regarder ce qui est disponible dans un environnement voisin, et ainsi économiser de l'argent, du temps et quelques frustrations.

Cependant, alors que l'analyste de Forrester enchaîne sur diverses règles à respecter pour la fiabilité du système, du point de vue de ceux qui vont publier leurs travaux de la sorte, je m'interroge d'abord sur les chances de concrétisation de la promesse, sous l'angle des utilisateurs potentiels. En effet, l'accès aux sources des outils exploités dans la structure est un premier pas vers une mutualisation des ressources mais il ne constitue certainement pas l'étape la plus complexe sur ce chemin.

La principale difficulté à résoudre est culturelle : dans des départements informatiques habitués à mettre au point leurs propres logiciels, en général avec le soutien inconditionnel de leurs donneurs d'ordres, le syndrome NIH (pour « Not Invented Here ») de rejet de tout ce qui vient de l'extérieur (aussi proche soit-il), sous prétexte de différences de contexte, par exemple, agit comme un puissant mécanisme de défense immunitaire visant, plus ou moins inconsciemment, à protéger son périmètre.

Des grands groupes privés, entre autres du secteur financier, se sont depuis longtemps essayés à mettre en place des stratégies de distribution libre des logiciels produits en vue de stimuler la réutilisation. Tous ont maintenant compris que ces efforts n'aboutissent qu'à la condition expresse que, en parallèle, un programme pédagogique au long cours soit déployés afin que le premier réflexe dans les nouveaux projets ne soit plus d'énumérer les particularités qui justifient une approche ad hoc et devienne de prendre de la hauteur pour repérer des solutions existantes à des problématiques similaires, puis identifier les adaptations éventuellement nécessaires.