Pourquoi le solutionnisme s’installe

Plusieurs raisons expliquent cette logique :

• La pression des clients : une demande qui “doit partir vite”
• Le stress business : la peur de perdre un deal ou une relation
• La culture du delivery : ce qui compte, c’est livrer quelque chose
• L’absence de cadre produit : le besoin du client devient la roadmap
• Le manque de médiation : les PO ou chefs de projet font passer la pression brute aux développeurs

Dans ce contexte, proposer une “solution” devient un réflexe défensif. Pas une démarche structurée.

Ce que coûte le solutionnisme

Livrer vite une mauvaise solution, c’est :

• Créer des cas spécifiques qui cassent la logique générale
• Multiplier les correctifs sans recul
• Complexifier le code jusqu’à le rendre instable
• Revenir plus tard sur des choix bâclés, avec un coût plus élevé
• Saturer les équipes qui passent leur temps à réparer ce qu’elles ont été
  contraintes de livrer

Résultat : une vélocité apparente… mais une lenteur réelle sur les projets complexes.

Comment casser cette dynamique

1. Poser un cadre clair

Un bon PO ou tech lead ne demande pas : “Quelle solution peut-on coder ?”
Il demande : “Quel est le vrai problème ? Qui est concerné ? Quelles sont les contraintes ?”

Structurer la réflexion avec un template de cadrage ou un atelier de 5 Whys change la donne.
Comprendre avant d’agir devient la norme.

2. Donner de la visibilité au coût réel

Chiffrez les conséquences du solutionnisme :
– bugs créés par des quick fixes
– correctifs à refaire
– perte de temps en QA
– stress accumulé

Des données comme celles proposées dans cet article sur la dette technique sont utiles pour alerter le management.

3. Refuser de livrer “par défaut”

Une demande ne doit pas immédiatement déboucher sur un dev. Le rôle d’un lead ou d’un CTO, c’est aussi de savoir dire non, ou pas tout
de suite.

Et si ça coince : demander un arbitrage écrit, une validation par le produit, un chiffrage, un test utilisateur. Tout ce qui transforme une “envie client” en décision assumée.

Adapter son discours selon l’audience

Tu ne convaincras pas un CEO avec un argument de code propre. Tu ne convaincras pas un dev avec une logique marketing.

Il faut parler le langage de chacun :

• Décision → Coût, ROI, dette invisible
• Produit → Cohérence UX, gestion des priorités
• Dev → Maintenabilité, sérénité, ownership

C’est ce que rappelle aussi cet article de Basecamp.

La qualité demande du courage

Résister au solutionnisme, ce n’est pas ralentir.
C’est assumer une posture exigeante, structurée, cohérente.
C’est construire une culture produit-tech où comprendre vaut mieux que réagir.
Et où livrer vite n’est pas un objectif en soi.