Où va la transformation numérique de l’État ? On voit beaucoup de têtes changer en ce moment – par exemple à la tête des directions ou services du numérique ministériels. Une succession est imminente à la tête de la Dinum. Et bien sûr, en cette année électorale, un renouvellement plus ou moins important du personnel politique et administratif s’annonce. Mais quelle est la réalité de la stratégie mise en oeuvre ?
L’éclairage que je souhaite apporter à cette question est celui d’un expert des démarches dites agiles de conduite de projets numériques et de développement logiciel, d’un “agiliste” depuis plus de vingt ans. Après les avoir moi-même pratiquées, j'ai contribué de façon substantielle à l’implantation du sujet en France dans ses jeunes années, en organisant des rencontres (la première, c'était dans ma salle à manger), des conférences, des formations… et en accompagnant de nombreuses entreprises.
C’est pour ces compétences que j’ai été recruté au sein de l’État. J’y étais, à ma connaissance, le seul expert avec un profil comparable – un agiliste de la première heure à la fois doté d’une expérience de terrain mais également rompu aux missions de conseil et d’accompagnement.
Il fallait faire différemment, plus petit, plus “orienté usagers”, plus moderne techniquement et sur le plan managérial
J'ai passé six ans de ma carrière professionnelle au service de cette transformation numérique, période qui a pris fin l’an dernier sur fond de controverses quant à la “politique systématique de non-CDIsation” concomitante avec l’externalisation du métier de coach agile à des cabinets de conseil. C’était avant qu’une commission d’enquête sénatoriale se penche sur le sujet et que l’exécutif n’annonce une nouvelle doctrine en la matière… Mais au-delà de mon cas, peut-être singulier, que peut-on dire sur la prise en compte dans l’État de ces démarches agiles et de leur place dans sa stratégie numérique ?
En 2015, au tout début de mon parcours, l’apport potentiel des démarches agiles aux initiatives numériques de l’État me semblait évident, comme il semblait évident à mes deux premiers patrons, Jacques Marzin (“L’État plateforme sera agile ou ne sera pas”) et Henri Verdier (“Il faudrait apprendre une informatique plus frugale, plus agile.”).
Cette conviction prenait source dans un constat partagé, celui de l’allongement, d’année en année, de la litanie des baleines étatiques échouées sur la grève des illusions perdues et des dizaines ou centaines de millions d’argent public envolés : Louvois, DMP, PNIJ, APB, Sirhen, Scribe… Les rapports successifs de la Cour des Comptes* sur les dérives de l’informatique publique en donnaient la cadence.
Les remèdes à y apporter n’allaient cependant pas de soi. Il était clair qu’il fallait faire différemment, très probablement plus petit, plus “orienté usagers”, plus moderne techniquement et sur le plan managérial… mais en partant de si loin que le champ des possibles restait très vaste.
L’attention continue et déterminée aux usagers, les démarches pour assurer la qualité du code source fourni…
Les dernières années auront été à cet égard une période riche en expérimentation. En 2016, le terme “agile” faisait une première (et timide) apparition dans le rapport annuel de la Cour qui saluait entre autres “l’impulsion donnée par le SGMAP”, en regrettant cependant une diffusion incomplète et inégale de nouvelles pratiques telles que la prise en compte de l’avis des usagers. En 2018, elle saluait les apports des “startups d’État”, incarnées par l’incubateur beta.gouv.fr fort d’une communauté de quelques dizaines de personnes, tout en persistant à noter “la lenteur de la diffusion de ces nouvelles méthodes auprès des administrations de l’État”. En 2020, la Cour consacrait aux “méthodes agiles” une part beaucoup plus conséquente (en sacrifiant à l’inévitable comparaison avec le schéma du fameux “cycle en V”), en constatait une application beaucoup plus généralisée et appelait à systématiser l’adoption d’une doctrine “Pensons grand et avançons petit”.
Entre temps, la communauté beta.gouv.fr dénombrait un effectif dépassant de plus du double celui de toute la Dinum, et qui allait encore doubler avant 2022. Il me semblait assister à l’éclosion prometteuse d’un nouveau mode d’action dont l’ADN, marqué par les démarches agiles, s’hybridait également avec les pratiques de l’open source, de la donnée ouverte, des “communs numériques”…
De 2019 à 2021, cependant, la Dinum a perdu les personnes qui avaient été le moteur de cette transformation. Ce qui y avait été initié s’est poursuivi, certes, et il convient de saluer l’énergie déployée par mes ex-collègues notamment aux premiers temps de la crise sanitaire. Une énergie mise sous cloche, au nom d’une politique interne à la Dinum qui décourageait toute prise d’initiative ne naissant pas d’une commande politique, et qui conduisit par exemple à confier le développement de l’application StopCovid à un consortium privé, prétendument à titre “gracieux” mais avec au final une facture non négligable pour le contribuable; ou encore à laisser le champ entièrement libre à des acteurs privés pour le développement des outils de suivi de la pandémie, la Dinum ayant préféré ne pas soutenir ses propres agents mobilisés dans le collectif OpenCovid.
Or dans une administration très sensible au principe hiérarchique, ces initiatives interministérielles avaient valeur de modèle, et leur essoufflement ne pouvait qu’induire un recul des pratiques inspirées du mouvement agile. Voici qu’en 2022 ce retournement se confirme à la lecture du rapport peu amène que la Cour consacre à la modernisation numérique du Ministère de la Justice. Une phrase en particulier interpelle : “La méthode de développement retenue est celle du « cycle en V », mais le rassemblement des équipes sous la responsabilité d’une même direction permet de bénéficier des avantages de la méthode agile, sans en reprendre forcément pour autant le ritualisme.” C’est un peu comme si l’on disait “pour perdre du poids, le régime retenu consiste à manger des chips devant les jeux Olympiques, ce qui permet de bénéficier des avantages du sport sans en subir forcément les inconvénients”.
Le “ritualisme” de la “méthode agile” qu’on aimerait bien pouvoir évacuer, c’est en l’occurrence tout ce qui en fait l’intérêt : l’attention continue et déterminée aux usagers, les démarches pour assurer la qualité du code source fourni… Quant aux soit-disant bénéfices, il faut bien les comprendre comme des bénéfices d’image. À l’exemple du framework SAFe (“agile à l’échelle”) qui dans bien des cas consiste aussi à faire exactement ce que l’on faisait avant, mais en remplaçant les étiquettes (une MOA devient un “product owner”, etc.). Toute réflexion sur les compétences et les perspectives de carrière qu’il convient d’offrir est par contre évacuée.
Il existe bien un “ritualisme” légitimement critiquable, mais c’est précisément celui qui est facilement adopté dans les administrations. Quand l’État se dit “ça arrangerait bien nos affaires que les administrés utilisent FranceConnect ou Mon Espace Santé”, il ne suffit pas de coller des post-its au mur ou de tenir des “réunions debout”. L’important, c’est bien de se mettre réellement à la place de l’usager et se demander quels bénéfices tangibles de ces initiatives pourraient l’y faire adhérer. C’est cela qui demande un effort, et mène à faire les choses différemment. (Ou pas, ce qui explique notamment le fiasco que fut le DMP, et dont Mon Espace Santé ne me semble pas démontrablement à l’abri.)
Il a bien fallu que le mouvement agile soit autre chose qu’un cahier des charges externalisable, qu’il s’applique à lui-même un esprit de critique et d’invention, pour que naissent par exemple le lean startup ou le devops, deux mouvements dont j’ai également accompagné l’essor en France. Le premier outille les équipes avec l’idée d’un apprentissage continu en soumettant le produit à l’épreuve de ses usagers le plus rapidement et fréquemment possible, et on lui doit l’idée même de “startup d’État” qui a permis à la Dinsic, avant d’être Dinum, de séduire nombre de profils très pointus dans le numérique. Le second vise à effacer la frontière entre les personnes qui écrivent les lignes de code et celles qui sont responsables de leur fonctionnement, et sans lui le cloud tel que nous le connaissons n’existerait pas.
La démarche agile ne consiste pas en l’application mécanique (et donc externalisable) de recettes prédéfinies. Elle exige un regard critique, une capacité à se rebeller contre le statu quo, et donc nécessairement une compétence interne, mais également une culture managériale différente. Le sujet a d’ailleurs été abordé dans ces colonnes, à la suite d’alertes dans différents secteurs de l’administration, et je souscris à l’idée selon laquelle “les nouvelles générations n’acceptent plus ce que les précédentes ont toléré”.
J’irais même plus loin que lui, estimant qu’une “remise en cause du principe hiérarchique” est au contraire une impérieuse nécessité. Je ne parle pas de l’abolir purement et simplement, car il est parfois nécessaire – en situation d’urgence ou de crise, par exemple, et pour appliquer un plan préparé à l’avance. Mais il me semble indispensable de reconnaître que dans un monde qui désormais fonctionne en réseau, des alternatives (hétérarchie, misarchie, panarchie) peuvent utilement avoir droit de cité dans nos réflexions stratégiques. N’en déplaise à certains, cette réflexion critique sur le pouvoir et son exercice s’incarne dans le mouvement agile depuis ses débuts.
L’État fait face à un trilemme – rejeter purement et simplement la démarche agile, l’assimiler en la vidant de sa substance… ou accepter sincèrement le défi qu’elle pose. Cette troisième branche est la moins explorée. Les nominations, mais surtout les comportements, aux postes clés de la “transformation numérique” sont autant d’occasions, en la privilégiant, de faire un choix porteur de possibilités et d’espoir.
*Laurent Bossavit se dit lui-même “agiliste depuis l’époque où ça ne s’appelait pas encore agile, développeur depuis l’époque où l’Internet s’appelait encore Minitel”. Avant de rejoindre l’incubateur de start-up d’Etat, il a notamment dirigé l’Institut Agile et est actuellement Technical Advisor au sein de l’entreprise CodeWorks.
*https://www.ccomptes.fr/sites/default/files/EzPublish/20160204-rapport-relations-usagers-modernisation-Etat.pdf
https://www.ccomptes.fr/sites/default/files/2018-01/04-Amplifier-modernisation-numerique-Etat-Tome-1.pdf
https://www.ccomptes.fr/system/files/2020-10/20201014-58-2-conduite-grands-projets-numeriques-Etat.pdf
