Dire non, c'est rare mais assumé
Je ne refuse pas souvent des projets. La majorité des personnes qui me contactent ont une idée sérieuse, un besoin réel, et une volonté de bien faire. Mais il m'arrive de décliner, et je préfère l'expliquer ouvertement plutôt que de le masquer derrière une excuse de planning.
Quand je refuse, c'est pour une raison précise. Et cette raison, je la donne toujours au prospect. Le refus n'est pas une fin de conversation, c'est parfois le début d'un échange plus utile.
Le budget décorrélé de la réalité du besoin
Le cas le plus fréquent. Un commerce veut une application mobile sur iOS et Android, avec espace client, paiement intégré, système de fidélité et tableau de bord admin, pour 500 EUR. Ce n'est pas de la mauvaise foi de leur part : c'est souvent ce qu'un prestataire précédent leur a promis pour ce budget.
Je ne peux pas livrer ce qui n'est pas livrable dans ce cadre. Accepter ce projet signifie soit bâcler le travail, soit déborder sur le budget prévu sans prévenir, soit livrer quelque chose d'incomplet. Les trois options nuisent au client et à moi.
Ce que je fais dans ce cas : j'explique ce qui est réellement faisable dans l'enveloppe disponible, je propose un périmètre réduit mais utilisable, et si ça ne convient pas, je laisse le prospect chercher ailleurs sans rancune.
Le projet pas encore mûr
Certains projets arrivent trop tôt. L'idée est bonne, mais le porteur n'a pas encore validé son marché, n'a pas de premiers clients, ne sait pas encore si le besoin est réel à grande échelle.
Dans ces cas, je déconseille de lancer le développement immédiatement. Construire une application sans avoir testé le besoin, c'est souvent gaspiller un budget qu'on ne récupère pas. Je préfère orienter vers une démarche de validation : formulaire Google, prototype Figma cliquable, ou une page de vente test avant l'investissement technique.
Ce n'est pas de la pusillanimité. C'est du respect pour le budget du porteur.
Le mauvais fit humain
Il m'arrive de sentir, dès les premières échanges, que la collaboration sera difficile. Un prospect qui ignore les délais convenus, qui repose les mêmes questions plusieurs fois sans tenir compte des réponses, qui remet en cause chaque estimation sans contre-proposition constructive.
Ce type de relation est mauvais pour les deux parties. Le client sera frustré de ne pas obtenir ce qu'il imaginait. Moi, je travaillerai dans des conditions qui nuisent à la qualité du livrable.
Je préfère décliner proprement plutôt que d'entrer dans une relation qui se terminera mal. C'est une décision commerciale, pas personnelle.
Quand un projet demande des compétences que je n'ai pas
Je ne suis pas omniscient. Si un projet requiert une expertise que je n'ai pas (sécurité bancaire de niveau PCI-DSS, intégration avec des systèmes industriels legacy, développement iOS natif Swift sur une codebase existante complexe), je le dis clairement.
Je peux parfois orienter vers un partenaire compétent. Mais je ne prends pas un projet en espérant "apprendre en chemin" aux frais du client.
Ce que ce refus coûte et ce qu'il rapporte
À court terme, refuser un projet, c'est refuser du chiffre d'affaires. C'est une décision inconfortable.
À long terme, c'est ce qui préserve la qualité des livrables et la réputation de Nine Technologies. Les projets que j'accepte, je les mène jusqu'au bout. Les clients que j'accompagne obtiennent ce qui a été promis, dans les délais discutés, avec un suivi après livraison.
C'est ce positionnement qui amène des recommandations sérieuses, pas le fait d'accepter tout ce qui se présente.