Aucun projet ne devrait être immortel

En tant qu’innovateur public, vous avez forcément déjà rencontré cette situation : une personne a identifié un irritant au sein de votre administration et propose une solution numérique pour le résoudre. Comme d’habitude, vous proposez de commencer petit, montrer que vous apportez de la valeur avant de faire grossir le projet pour résoudre d’autres irritants. Pas con.

À ce moment-là, quelqu’un vous lance :

« Pas la peine de lancer votre petit projet ! On a déjà lancé le projet [insérez un acronyme illisible, un prénom féminin ou une référence mythologique] qui fait tout ça, et bien plus encore ! On ne va quand même pas faire deux fois la même chose. »

Cela peut paraître louable de ne pas vouloir créer de doublons. C’est une utilisation vertueuse des deniers publics, comme dirait la Cour des comptes. Sauf qu’il est plus sain d’avoir des projets en doublons, sous réserve que les projets puissent mourir aussi (voire plus) facilement qu’ils ont été lancés.

Pourquoi ? Parce que : le darwinisme. Dans une espèce, les individus les moins adaptés à l’environnement disparaissent avant de transmettre leurs gènes et les plus adaptés survivent. Cela devrait être la même chose pour les projets informatiques : il doivent être mortels, sinon les moins aptes survivent également et placent la barre de plus en plus bas.

Dans un environnement imprévisible (comme l’est le monde réel), avoir plusieurs projets avec des fonctionnalités similaires est une bonne chose, sous réserve qu’on interrompe les projets les moins bons. Mais à cause du sunk cost fallacy, on a tendance à continuer à mettre de l’argent dans un projet qui coule pour essayer de le sauver plutôt que d’arrêter les frais le plus rapidement possible.

C’est pour ça que le modèle des startups d’État est si intéressant : en commençant petit et pas cher, on a moins mal au coeur quand il faut tuer un projet qui ne marche pas.

Nos projets sont donc mortels, CQFD.

Article publié à l’origine sur Medium.