Le provisoire finit souvent dans le produit final

« On fait comme ça pour l’instant. »

La phrase est parfaitement raisonnable.

En R&D, il faut pouvoir avancer sans résoudre immédiatement tous les problèmes. On utilise un composant disponible, on écrit rapidement une interface, on fixe une valeur en dur, on fabrique une pièce temporaire.

L’objectif n’est pas encore de construire le produit définitif.

Seulement de vérifier une hypothèse.

Le problème commence lorsque le provisoire fonctionne suffisamment bien pour qu’on arrête de le considérer comme provisoire.

Un prototype accumule des raccourcis #

Un prototype n’est pas un mauvais produit.

C’est un objet construit avec un objectif différent.

Pour répondre rapidement à une question, il est parfaitement logique d’accepter certaines choses que l’on n’accepterait pas dans un produit final.

Une alimentation surdimensionnée.
Un ordinateur externe pour effectuer un traitement.
Une pièce usinée alors qu’elle devra probablement être injectée.
Un paramètre réglé manuellement.
Une bibliothèque choisie parce qu’elle permet de tester une idée en quelques heures.

Pris séparément, chacun de ces choix peut être parfaitement justifié.

Le danger apparaît lorsque leur caractère temporaire disparaît de la mémoire du projet.

Ce qui fonctionne acquiert rapidement un statut particulier #

Une fois qu’un élément fonctionne, le modifier devient plus difficile.

Pas nécessairement techniquement.

Psychologiquement et organisationnellement.

Pourquoi toucher à quelque chose qui fonctionne ?

Une nouvelle fonctionnalité arrive. Puis une autre. Elles sont construites autour de l’existant.

Des essais sont réalisés avec cette architecture.

Des outils internes commencent à en dépendre.

La documentation la décrit.

Quelques mois plus tard, le petit choix effectué « juste pour le prototype » se retrouve au centre du système.

Il est toujours théoriquement remplaçable.

Mais son remplacement coûte désormais beaucoup plus cher.

La dette technique n’est pas toujours une erreur #

On parle souvent de dette technique comme du résultat d’un mauvais développement.

Ce n’est pas nécessairement le cas.

En R&D, prendre un raccourci peut être une excellente décision.

Dépenser trois semaines pour construire proprement une partie du système dont on ne sait même pas si elle existera dans trois mois serait parfois absurde.

Le problème n’est donc pas de créer de la dette.

Le problème est de ne plus savoir où elle se trouve.

Un compromis temporaire documenté reste une décision.

Un compromis temporaire oublié devient progressivement une contrainte du système.

Il faut donner une date de péremption au provisoire #

Lorsqu’un raccourci est volontaire, trois informations suffisent souvent :

Pourquoi avons-nous fait ce choix ?
Dans quelles conditions est-il acceptable ?
À quel moment devons-nous le réexaminer ?

Ce dernier point est probablement le plus important.

« À remplacer plus tard » n’est pas une échéance.

En revanche, ces formulations définissent un événement observable :

« à réévaluer avant les essais de validation »,
« à remplacer si nous dépassons 100 unités »,
« à reconsidérer lorsque l’architecture électronique sera figée ».

Le projet possède alors un mécanisme pour se souvenir de sa propre décision.

Un prototype doit pouvoir raconter son histoire #

Lorsqu’on reprend un projet plusieurs mois plus tard, il devrait être possible de distinguer deux choses : ce qui a été conçu ainsi parce que c’était le bon choix, et ce qui a été conçu ainsi parce que c’était le choix suffisant à ce moment-là.

La différence est fondamentale.

Sans elle, l’équipe suivante risque d’interpréter chaque élément existant comme le résultat d’une décision mûrement réfléchie.

Et de construire autour.

C’est ainsi qu’un bout de code écrit en une heure, une pièce mécanique temporaire ou un composant choisi dans un tiroir peuvent finir par définir l’architecture d’un produit plusieurs années plus tard.

Pas parce que quelqu’un a décidé de les conserver.

Simplement parce que personne n’a décidé de les remplacer.