Une Startup d’État est « une équipe de 2 à 4 personnes financée par une administration et totalement autonome »… Mais qu’entend-on exactement par « autonome », et pourquoi est-ce important ?
Pour l’illustrer, un bref détour est nécessaire. Les débats autours de la manière de mener les projets de développement informatiques s’organisent souvent autour de la notion de « méthode » : c’est ainsi qu’on parle de « méthode agile », en l’opposant à d’autres dénommées « cycle en V ». L’une s’appuierait sur la notion de « backlog », un découpage des tâches à effectuer souvent réifié sous la forme de Post-Its, l’autre sur le « cahier des charges », un classique document Word. L’une mobilise un rôle de « scrum master » alors que l’autre confère des responsabilités similaires à un « chef de projet ».
Le problème est que des différences superficielles de méthode, tout en suscitant quantité de débats, de formations, de conférences… peuvent masquer le plus important : jusqu’ici, nous observons très peu de changement dans la doctrine appliquée à la conduite des projets informatiques, au sens d’une doctrine militaire ou de commandement.
Cette doctrine encore quasi-universelle est la suivante : la réflexion et la planification sont le domaine exclusif des décideurs et des métiers qui leur sont associés (généralement « maîtrise d’ouvrage »). Tels des généraux, ils étudient le terrain sur lequel on livrera bataille, et fournissent aux fantassins un ordre de mission précis que ces derniers n’ont plus qu’à exécuter. L’exécution compétente des ordres transmis garantira le succès de l’opération.
Dans le domaine militaire, cette doctrine fut pourtant remise en cause dès le 19ème siècle par le maréchal prussien Helmuth von Moltke « l’Ancien », qui lui préféra celle connue sous le nom Auftragstaktik en allemand (Mission Style tactics en anglais). On la résume souvent par un aphorisme : « Aucun plan ne survit au premier contact avec l’ennemi. »
La clé de cette doctrine est l’observation suivante : des troupes sur le terrain auront toujours une information tactique plus complète et plus récente que les généraux qui ont rédigé leurs ordres de mission.
Imaginez une escouade (15 soldats), dépêchée sur le terrain avec l’intention d’empêcher un ennemi d’investir un village qui constitue une position stratégique. Un pont qui permet de franchir une rivière donne accès au village. L’escouade prend position ; en longeant la rivière, assez loin en amont, elle repère une barge sur la berge…
Dans un premier scénario, qui correspond à la doctrine ancienne en vigueur à l’époque de Moltke, l’escouade a reçu l’ordre explicite « prenez position sur le pont, repoussez l’ennemi ». La barge n’est pas de leur ressort : c’est un élément de décor.
La doctrine de Moltke consiste à donner un ordre plus proche de « empêchez l’ennemi d’accéder au village, par tous les moyens ». L’escouade repère la barge, qui prend alors un autre sens : un moyen alternatif d’accéder au village. Elle saborde l’embarcation avant de prendre position.
C’est pour ces motifs, notamment, qu’une équipe autonome est réputée plus efficace. Ce n’est pas parce qu’elle n’a pas de plan; ce n’est pas parce que les personnes qui la composent « font ce qu’elles veulent » et que c’est plus amusant comme ça. C’est tout simplement parce qu’entre la planification et l’exécution sur le terrain, la réalité peut avoir changé - ou des circonstances similaires à la barge vont se présenter - et que ceux qui en sont les plus proches ont en main les informations pour prendre les bonnes décisions.
Transposons cette distinction aux projets numériques de l’administration : on profitera à donner, non pas des directives tactiques détaillées (« Implémentez une application Web dotée d’une fonction d’identification, du choix d’un établissement scolaire et permettant de joindre à une demande un justificatif fiscal ») mais un énoncé succinct de l’enjeu stratégique : « Il s’agit de faciliter l’accès des collégiens aux bourses des collèges ». Sous-entendu : « et peu importent les moyens, débrouillez-vous ».
Une équipe vraiment autonome pourra ainsi explorer le terrain – rencontrer les usagers concernés, par exemple – et anticiper ce qui peut faciliter ou au contraire saborder la mission.
Le « cahier des charges » détaillé (et coûteux à établir) n’a rien à envier à un « backlog » constitué à l’avance par une « maîtrise d’ouvrage » qui ne verra jamais le terrain : tous deux représentent une doctrine projet obsolète. Il est temps de le reconnaitre, et de les remplacer par des escouades autonomes et efficaces.
