On reçoit un message. Le ton est cordial, le projet semble clair, le budget est mentionné. Tout indique qu'il faut dire oui. Et pourtant, dans la grande majorité des cas, on dit non.
Ce n'est pas une posture destinée à paraître exclusif. Ce n'est pas non plus une stratégie de rareté calculée pour faire monter les prix. C'est le résultat d'un calcul simple, appris à nos dépens : les projets qu'on aurait dû refuser ont coûté beaucoup plus qu'ils n'ont rapporté, en temps, en énergie, et parfois en réputation.
Alors on s'est donné quatre questions. Pas un formulaire de qualification, pas un processus en quinze étapes. Quatre questions qu'on se pose en lisant la demande, dans l'ordre, et qui permettent d'aboutir à une réponse honnête.
Quatre questions, pas une
La première : est-ce faisable, dans le contexte précis de ce client ? Pas faisable en théorie, pas faisable pour quelqu'un d'autre. Faisable pour cette personne, avec ses outils actuels, son niveau de compétence, ses contraintes opérationnelles. Un système de notification automatique est techniquement simple. Mais si le client n'a pas de fichier client structuré, pas de CRM, pas même un tableur à jour, livrer ce système ne résoudra rien. Il créera une dépendance à un outil qui s'alimentera de données inexistantes.
La deuxième : est-ce utile, vraiment, maintenant ? On a appris à distinguer ce dont quelqu'un a besoin de ce qui l'attire. Beaucoup de projets nous arrivent parce que la personne a lu un article, vu une démo, entendu un concurrent parler d'un outil. L'envie est réelle. Le besoin, parfois moins. Quand on ne trouve pas de réponse précise à la question "quel problème quotidien est-ce que ça résout", on pose la question directement. La réponse oriente presque toujours la décision.
La troisième : est-ce éthique ? Cette question arrive moins souvent qu'on ne le craindrait, mais elle arrive. On a refusé des demandes d'automatisation de messages qui simulaient une relation humaine. On a refusé des systèmes de relance conçus pour épuiser la résistance plutôt que pour informer. On a refusé un outil de surveillance du comportement employé qui n'avait pas été mentionné dans les contrats de travail concernés. Chaque fois, la réponse a été non, sans discussion.
La quatrième : est-ce soutenable pour l'atelier ? On est un artisan, pas une agence. Si une pièce qu'on livre nécessite un accompagnement de six mois pour fonctionner, si elle repose sur une architecture que personne d'autre ne peut maintenir, si son support va mobiliser trois heures par semaine indéfiniment, il faut en tenir compte avant de dire oui. Pas pour refuser systématiquement les projets complexes, mais pour les facturer et les cadrer correctement.
Des exemples qui parlent mieux que des règles
Un gérant de boutique de prêt-à-porter nous a contactés en mars pour automatiser la mise à jour de son catalogue produit. Il avait vu un concurrent utiliser un outil similaire, et voulait "la même chose". En lisant sa demande, on a posé quelques questions sur son flux de travail actuel. Il s'est avéré que ses références produits changeaient deux à trois fois par semaine, que ses descriptions étaient rédigées dans trois formats différents selon qui les avait écrites, et que son équipe n'avait ni le temps ni l'envie de maintenir une base de données cohérente. On aurait pu livrer un outil parfait pour un catalogue structuré. Ça aurait donné un outil parfait appliqué à du chaos. On a refusé, et on lui a conseillé de commencer par un tableur partagé bien tenu pendant deux mois, avant de parler d'automatisation.
Un consultant indépendant voulait "un CRM complet" à 39 euros. Il avait vu notre Carnet Forge, avait trouvé que c'était "exactement ce qu'il cherchait", et voulait "juste" qu'on y ajoute la gestion des devis, le suivi des paiements, un pipeline de relance et une intégration avec son calendrier. Le Carnet Forge est une pièce. Il fait une chose, bien. Ce que le consultant décrivait, c'est une infrastructure. On ne fait pas ça. On lui a dit non, et on lui a indiqué deux outils open source qui correspondaient mieux à ce qu'il cherchait.
Le troisième exemple est le plus simple à résumer. Un commerçant voulait un système automatisé de relance pour impayés, avec un ton qu'il qualifiait d'insistant. Il avait réfléchi à la séquence, au rythme, aux formulations. Tout ça était légal. Rien de tout ça n'était quelque chose qu'on était prêts à construire et à signer. On a refusé.
Ce que ça change pour les clients qui restent
Quand on accepte un projet, le client qui nous l'a confié sait que les quatre questions ont trouvé une réponse positive. Ça ne garantit pas que tout se passera sans friction. Mais ça garantit qu'on a regardé son contexte en face avant de promettre quoi que ce soit.
Les clients qu'on a orientés ailleurs en leur disant non reviennent souvent, quelques semaines ou quelques mois plus tard, avec un projet qui correspond mieux à ce qu'on sait faire. Ou ils nous envoient quelqu'un d'autre. Dans les deux cas, le refus d'origine a fait son travail.
On fabrique des pièces, pas des projets en vrac. Chaque pièce résout quelque chose de précis, pour quelqu'un qui en a vraiment besoin. Ça contraint le volume. C'est exactement pour ça qu'on peut maintenir la qualité.