En tant que développeur, quand on démarre une tâche ou un projet, on pense facilement au framework que l’on va utiliser, à la base de données, aux patterns que l’on va pouvoir mettre en place. Et si c’était une erreur ?
Car en réfléchissant de la sorte, on prend déjà des décisions avant même que le problème ne soit posé. On choisit une solution, une architecture, un outil, et ensuite on cherche la justification. N’est-ce pas penser à l’envers ?
Penser problème avant de penser solution, c’est d’abord clarifier le besoin auquel on doit répondre. Quelle est la douleur, pour qui, et dans quel but ? Ce n’est pas en pensant technique, à la manière dont on va l’implémenter dans le code et dans le produit, que l’on trouvera ces réponses.
L’IA amplifie aujourd’hui ce phénomène. Elle produit une implémentation pour n’importe quelle demande. Le coût de mise en place d’une solution a drastiquement diminué, mais celui de se tromper de problème n’a pas bougé.
Poser le problème, c’est déjà la moitié du chemin de fait. C’est du problème que découle la solution, et de la solution que découlent les outils à mettre en place. Pas l’inverse.
