À force de garder toutes les options ouvertes, on finit par ne plus avancer

« On garde les deux pour l’instant. »

La phrase est plutôt rassurante.

Elle évite de trancher trop vite, laisse une porte ouverte et permet de continuer à avancer tant qu’on ne dispose pas de toutes les informations.

En R&D, c’est souvent une bonne décision.

Le problème, c’est que toutes les informations n’arriveront jamais.

À un moment, garder plusieurs solutions en parallèle ne protège plus le projet d’une mauvaise décision. Cela commence simplement à lui coûter du temps.

Explorer est nécessaire #

Au début d’un projet, il serait dangereux de décider trop vite.

On ne sait pas encore quel capteur donnera les meilleurs résultats. Deux architectures semblent possibles. Plusieurs algorithmes méritent d’être testés. Une technologie paraît prometteuse, mais une autre est plus simple à intégrer.

C’est normal.

Cette période d’exploration permet justement de confronter les idées au réel avant de s’engager dans une direction. On teste. On mesure. On élimine certaines pistes. On en découvre parfois d’autres auxquelles personne n’avait pensé au départ.

Vouloir supprimer cette incertitude dès le début reviendrait à décider avant d’avoir appris.

Mais l’exploration n’a de valeur que si elle permet, tôt ou tard, de réduire le nombre d’options.

Garder une option ouverte n’est pas gratuit #

Deux solutions restent envisageables. Alors on conserve les deux.

Le code est prévu pour supporter les deux architectures. Les tests doivent fonctionner avec les deux. La documentation décrit les deux possibilités. Les discussions techniques continuent de comparer leurs avantages.

Et chaque nouvelle décision doit désormais tenir compte des deux scénarios.

Puis une troisième possibilité apparaît. On pourrait l’écarter, mais elle possède un avantage intéressant. Alors on l’ajoute elle aussi « pour l’instant ».

Le projet devient progressivement capable de tout faire. Sauf avancer simplement.

Car une option que l’on conserve a un coût, même lorsqu’elle n’est jamais utilisée. Elle ajoute du code, des interfaces, des cas de test, des conditions, de la documentation. Mais surtout, elle ajoute quelque chose de beaucoup moins visible : elle augmente le nombre de décisions futures qui dépendent encore d’une décision que l’on n’a pas prise.

Attendre la certitude est une décision #

Il y a une raison assez naturelle à cette situation : personne n’aime choisir la mauvaise solution.

Alors on attend une information supplémentaire.

• Un test.
• Un benchmark.
• Un retour utilisateur.
• Une nouvelle version du composant.
• Une mesure plus précise.

Et parfois cette information mérite réellement d’être attendue. Mais il faut aussi se demander ce qu’elle pourrait changer.

Si le prochain test peut réellement inverser la décision, faisons-le. S’il ne fera probablement que confirmer avec un peu plus de précision ce que l’on sait déjà, continuer à attendre n’apporte peut-être plus grand-chose.

C’est là que la recherche de certitude devient trompeuse. On peut toujours faire un test supplémentaire. Il y aura toujours un cas particulier que nous n’avons pas essayé, une donnée supplémentaire à mesurer ou une hypothèse que nous pourrions approfondir.

La question n’est donc pas de savoir si nous savons tout. La question est de savoir si ce que nous ne savons pas encore justifie de retarder la décision.

Toutes les incertitudes ne méritent pas d’être levées #

Prenons deux solutions techniques.

La première fonctionne bien, répond aux contraintes connues et repose sur une technologie maîtrisée.

La seconde pourrait être légèrement meilleure, mais demanderait encore plusieurs semaines de travail pour le démontrer.

Il est tentant de poursuivre. Après tout, pourquoi choisir aujourd’hui si l’on peut peut-être trouver mieux demain ?

Parce que ces semaines ont elles aussi une valeur. Et surtout parce que la différence éventuelle entre les deux solutions n’a peut-être aucune conséquence réelle sur le produit.

C’est assez facile de tomber dans ce piège en R&D. Un problème techniquement intéressant apparaît et l’on continue à creuser parce qu’il reste quelque chose à comprendre. Ce n’est plus forcément le projet qui l’exige. C’est parfois simplement l’ingénieur qui aimerait connaître la réponse.

Je connais bien la tentation. Mais à un moment, il faut accepter qu’une question puisse rester ouverte sans empêcher le projet de continuer.

Décider ne veut pas dire être certain #

Une décision technique est rarement prise avec 100 % des informations souhaitées. Elle est prise avec suffisamment d’informations pour considérer que le risque restant est acceptable.

C’est très différent.

On peut choisir une architecture tout en sachant qu’une autre aurait peut-être donné de meilleurs résultats. On peut sélectionner un composant sans avoir testé tous ses concurrents. On peut arrêter d’optimiser un algorithme alors qu’on sait parfaitement qu’on pourrait encore gagner quelques millisecondes.

Ce n’est pas renoncer à la rigueur. C’est reconnaître que l’objectif n’est pas de trouver la meilleure solution imaginable. L’objectif est de trouver une solution suffisamment bonne pour répondre au problème, aux contraintes et au niveau de risque que l’on accepte.

Et continuer.

Il faut aussi savoir fermer les portes #

Il y a quelque chose d’assez confortable à garder toutes les options ouvertes. Tant qu’aucune décision définitive n’est prise, aucune décision ne peut vraiment être mauvaise.

Mais un projet technique se construit aussi avec les portes que l’on accepte de fermer.

• Nous utiliserons ce composant.
• Nous partons sur cette architecture.
• Cette piste est abandonnée.
• Cette performance est suffisante.
• Ce cas d’usage ne sera pas traité dans cette version.

À partir de là, beaucoup d’autres décisions deviennent soudainement plus simples. L’équipe peut arrêter de concevoir pour plusieurs futurs possibles et commencer à construire pour celui qui a été choisi.

Évidemment, certaines décisions pourront être révisées plus tard si le contexte change. Mais ce n’est pas une raison pour les repousser aujourd’hui.

Savoir quand on a suffisamment appris #

C’est probablement l’une des frontières les plus difficiles à trouver en R&D.

Arrêter trop tôt, c’est prendre le risque de passer à côté d’une meilleure solution. Continuer trop longtemps, c’est prendre celui de transformer l’exploration en immobilisme.

Il n’existe pas de seuil universel pour décider. Mais une question aide souvent : qu’est-ce que la prochaine expérience peut encore changer dans notre décision ?

Si la réponse est claire, l’expérience mérite probablement d’être menée. Si personne ne sait vraiment répondre, peut-être que le projet n’a plus besoin d’une nouvelle expérience.

Il a besoin d’une décision.

En R&D, avancer ne consiste pas à tout savoir avant de choisir. Il faut parfois simplement savoir quand on en sait assez pour décider.