Refuser une mission protège autant le client que moi. Un projet pris par complaisance coûte plus cher à tout le monde qu'un non dit tôt et clairement.
Un non bien placé est un acte de direction technique. J'ai refusé des projets qui auraient été rentables à court terme, parce qu'ils ne tenaient pas à l'examen. En voici un, anonymisé, parce qu'il résume bien ce que je regarde.
Ce qui clochait
Un fondateur voulait reconstruire sa plateforme de zéro. Budget réuni, échéance posée, stack déjà choisie. Sur le papier, une mission idéale. En creusant, le vrai problème n'était pas technique : personne ne savait dire quelle décision la réécriture devait servir. On voulait du neuf, pas résoudre un manque précis.
La difficulté n'était pas la réécriture. C'était l'ambiguïté de la décision en dessous. Construire sur cette base, c'était garantir une deuxième réécriture deux ans plus tard, pour les mêmes raisons non nommées.
Pourquoi refuser servait le client
Prendre ce projet m'aurait payé et lui aurait coûté un an pour réapprendre ce qu'un cadrage honnête pouvait lui dire en deux semaines. Je l'ai orienté vers un audit court avant tout engagement de build. Identifier la contrainte réelle d'abord, décider de réécrire ensuite, si c'est encore la bonne réponse.
Refuser n'est pas se défausser. C'est rendre au décideur une lecture claire de son propre problème. Un fournisseur qui dit oui à tout ne protège personne. La valeur d'une direction technique se mesure aussi aux projets qu'elle empêche.