Pourquoi nous commençons toujours par le problème
La plupart des projets échouent avant la première ligne de code, au moment où l'on décide de ce qu'on construit.
Il existe une phrase qu'on entend dans presque toutes les premières réunions de projet : « On sait ce qu'on veut construire. »
C'est presque toujours faux. Ce que l'on sait, à ce stade, c'est ce qu'on imagine que la solution devrait ressembler. C'est différent, et cette différence coûte cher.
La solution arrive trop tôt
Quand une organisation formule un besoin, elle a déjà fait un long chemin mental. Elle a constaté une gêne, l'a interprétée, a imaginé une réponse, et c'est cette réponse qu'elle présente. Le problème d'origine, lui, n'a jamais été énoncé à voix haute.
Le résultat est un cahier des charges qui décrit une solution avec beaucoup de précision et le problème avec aucune. On construit alors exactement ce qui était demandé — et personne ne s'en sert.
Ce n'est pas un défaut de rigueur. C'est la manière dont fonctionne l'esprit humain : nous sautons au diagnostic parce que l'incertitude est inconfortable. Un problème mal défini reste ouvert ; une solution, même mauvaise, referme la question.
Ce que change l'ordre inverse
Nous imposons une contrainte simple : avant toute discussion sur ce qui sera construit, nous devons être capables d'écrire le problème en une phrase que la personne concernée reconnaît comme sienne.
Pas une phrase qui sonne bien en réunion. Une phrase qui décrit une situation précise, vécue par quelqu'un d'identifiable, à un moment identifiable.
Cet exercice a un effet inattendu : dans une partie significative des cas, la solution imaginée au départ n'est plus la bonne. Parfois elle est trop grosse — le problème réel concernait une étape, pas tout le processus. Parfois elle est trop petite — la gêne visible n'était qu'un symptôme. Parfois il n'y a rien à construire du tout, et une règle interne suffit.
Chacun de ces trois cas représente un projet évité, réduit ou redirigé. C'est de l'argent qui n'a pas été dépensé pour rien.
Comment nous procédons
Trois habitudes, sans méthodologie compliquée :
Nous parlons à ceux qui vivent le problème, pas à ceux qui le décrivent. Ce sont rarement les mêmes personnes. La personne qui commande un projet a une vue d'ensemble ; celle qui exécute la tâche connaît les contournements. Les contournements sont l'information la plus précieuse qui existe — ce sont des solutions déjà inventées par les utilisateurs.
Nous cherchons ce qui invalide. Si toutes nos observations confirment notre intuition, c'est que nous avons mal cherché. Nous demandons explicitement : dans quel cas ce que nous croyons serait-il faux ?
Nous écrivons le problème avant d'écrire la solution. Un document court, daté, partagé. S'il est difficile à écrire, c'est que nous n'avons pas compris — et ce n'est pas au développement de le découvrir.
L'exigence réelle
Cette approche demande d'accepter un moment inconfortable : celui où l'on ne peut pas encore répondre à la question « alors, on construit quoi ? ».
Ce moment est court. Deux à trois semaines, dans notre expérience. Mais il est le seul qui détermine si le reste servira à quelque chose.
Un problème bien compris est déjà à moitié résolu. Le reste est une affaire de rigueur.
Catégorie THINK · Temps de lecture 6 minutes