Innovation gouvernementale : l'ère de la PoC a sonné!

Opinion populaire : Entre les comités d’étude et les projets multi-millions, il manque une étape cruciale dans les initiatives de transformation numérique gouvernementale : la validation par l’expérimentation, la Preuve de Concept (PoC).

S’il y a quelque chose que j’ai appris à la dure dans les dernières années c’est que les meilleures décisions naissent des bonnes questions ET des données. Un sans l’autre n’est qu’un jeu de prédiction. C’est parce que les bonnes questions se posent quand nous avons des données ou du savoir. Ce savoir et ces données se découvrent seulment en testant et en apprenant de nos test.

Si nos données sont déjà bonne, c’est que quelqu’un les a testé pour nous. Reste que cette boucle, ce feedback loop en bon français, est encore mis en cause sur sa valeur dans le cadre de grand projet.

Pourtant, force est d’admettre que cette méthode est la seule que j’ai observé qui était capable de livrer des projets. Je ne dis pas qu’elle garantie la livraison, mais je suis d’avis que les projets qui sont qualifiés de succès se sont appuyer sur cette manière de fonctionner.

Alors, je me permet d’offrir un distillat de ce que j’ai appris dans le dernier cycle technologique et vais tenter de l’expliquer de la manière la moins technique afin que les gens qui ont vraiment besoin de gérer des projets technos aient une manière simple de penser à ces aspects complexes du biens public.

L’étape manquante ?

Les grandes organisations —gouvernementales ou autre— excellent à planifier, mais échouent à valider. Les preuves de concept (PoC) aident à gérer cet angle mort en comblant ce vide par l’introdution les contraintes rééelles plus tôt dans le processus. On évite la paralysie d’analyse, les questions mal formulées, les optimisations prématurées et la gestion de risques floues.

Une implantation réussi d’un système de mission est un travail ingras. Personne ne donnera de médaille, il n’y a pas de comission parlementaire pour un travail réussi. C’est donc normal de gérer les projets pour éviter le pire au lieu de réussir le mieux. C’est normal de vouloir se déresponsabiliser des problèmes parce que le risque individuel est trop grand quand nos risques sont mal compris. Alors, la gestion du rsique par la preuve de concept permet : a) augmenter l’efficacité de la gestion de risques, b) maximiser les chances de succès et c) diminuer notre exposition aux risques individuels démesurés.

Pendant que les comités débattent en théorie, une PoC expose déjà les incompatibilités système et les défis d’intégration. Les inconnues les plus dommageables sont confrontées en semaines et non en années.

Quantifier l’inquantifiable

Une PoC transforme l’incertitude en données :

“Probablement risqué” devient “La solution est fonctionnelle dans 23% des cas”;
Au lieu d’alimenter les hypothèses avec l’argent public, on augmente nos certitudes;
Les hypothèses deviennent des faits.

La beauté des questions sans réponses

Les meilleures PoC révèlent les problèmes cachés. Terminer avec de nouvelles questions comme “Pourquoi l’intégration prend-elle 3x plus de temps?” vaut son pesant d’or - ces découvertes évitent des catastrophes à grande échelle.

C’était une promesse de la méthodologie Agile, elle ne s’est pas matérialisée. Pouvons-nous essayer d’atteindre cet objectif même si la méthode s’est avérée inadéquate pour le problème?

Le paradoxe des équipes projet

Les équipes projet traditionnelles, qui livrent des projets dans le cadre gouvernemental, opèrent dans un cadre inadapté à l’expérimentation. Il ne faut pas attaquer cette méthode car elle opère dans une complexité importante. Je veux simplement souligner qu’elle n’ont pas les bons motivateurs pour rendre l’idée de Preuves de Concept pratique ou réaliste :

Gouvernance rigide VS dextérité nécessaire
Culture du livrable parfait vs échec rapide valorisé
Cycles budgétaires fixes vs exploration flexible
Adapté à gérer 10M$ au lieu de 100k$ de budget

Ce n’est pas un défaut des équipes - c’est une inadéquation structurelle.

La règle du pouce

Si une PoC semble trop risquée ou coûteuse, c’est le projet qui pose problème. Je n’ai jamais vu un projet qui a coûté moins que 10x le coût de la preuve de concept. Alors :

Option A : 4 PoC × 100K$ = 400K$ = Apprentissage = Éviter l’erreur, projet d’au moins 4M$. Perte potentielle de 400k$

Option B : Méthode Agile ou Trad, sans PoC 1 projet × 10M$ = Solution inutilisable = Perte potentielle de 10M$.

Qu’est-ce qui est plus raisonnable ?

L’engagement par la démonstration

Les équipes se fatiguent des projets interminables. Un PoC de 4 semaines qui fonctionne génère plus d’enthousiasme que 6 mois de planification. Les développeurs voient leur code en action, les erreurs deviennent des leçons, l’innovation s’accélère, l’incertitude diminue.

Comment rendre le tout contret ?

Si le savoir est le pouvoir, demandez-vous : Qu’est-ce qu’on pourrait savoir dans les 30 prochains jours ?”

Une pruve de concept demande des gens avec du savoir technique profond, une compréhension des objectifs et assez de lattitude pour faire des essaies et apprendre des erreur.

La prochaine fois qu’un projet majeur se profile, une petite équipe qui bouge rapidement, est technos comptente et parle un langage que vous comprennez est probablement votre meilleur allié. Point bonis si elle n’a pas d’intérêt a réaliser le gros projet qui découlra de vos Preuves de Concept.