Pourquoi « Ce n'est pas possible » est rarement vrai dans le développement logiciel
Une brève réflexion sur la façon dont un état d'esprit clair et le bon sens permettent de désamorcer presque tous les problèmes techniques.
Il y a presque toujours une solution
Dans ma carrière de développeur de logiciels et de consultant IT, j'ai appris : l'affirmation « Ce n'est pas possible » est presque toujours le signe qu'une condition préalable importante manque – et non que l'objectif est inatteignable. Lorsqu'un microservice ne passe prétendument pas à l'échelle, c'est souvent la vision sur la backpressure, la mise en cache ou les pools de connexions qui fait défaut. Lorsqu'une API est « trop lente », c'est souvent le regard dans l'outil de profilage qui manque.
Trois questions que je me pose toujours
- Est-ce que je comprends vraiment le problème ? Symptôme ≠ Cause.
- Quelles hypothèses est-ce que je formule ? Les hypothèses sont les bugs les plus coûteux.
- Qui a besoin de la solution et quand ? Le time-to-impact l'emporte sur la perfection.
Pratique : du « Non » à la proposition de solution
Après un Non, il doit toujours y avoir chez moi une proposition de solution. Ce n'est pas une formule vide – c'est une éthique de travail que je transmets aux équipes. Elle transforme les réunions, accélère les décisions et fait redevenir l'ingénierie ce qu'elle devrait être : la résolution créative de problèmes.
« Ce n'est pas sorcier. » – la plupart du temps, non.