Avant, j’acceptais 80 % des missions proposées. Taux de succès : 60 %. Maintenant j’en accepte 40 %. Taux de succès : 95 %.
La différence tient en trois questions posées au premier appel.
(Aucune des trois ne porte sur la technique. C’est le point.)
Ce que je cherchais avant
Un problème intéressant. C’était mon seul filtre, et c’est le pire qui soit : les missions les plus intéressantes techniquement sont souvent celles où l’organisation est la plus bloquée, donc celles où rien ne se produira.
Blair Enns formule le principe mieux que moi : la compétence centrale d’un indépendant n’est pas de savoir vendre, c’est de savoir refuser. Tant qu’on ne peut pas se permettre de refuser, on ne choisit pas ses missions — on les subit, et le travail s’en ressent.
→ Enns, B. — “The Win Without Pitching Manifesto”
Question 1 : êtes-vous prêt à changer ?
Pas « avez-vous un problème » — tout le monde a un problème, et tout le monde le décrit volontiers pendant quarante minutes.
Ce que je cherche : ont-ils déjà essayé de le résoudre seuls ? Le budget est-il validé ou espéré ? Savent-ils qui portera les décisions après mon départ ?
La réponse qui doit alerter est celle qui décrit un problème avec beaucoup de précision et aucune tentative. Elle signale une organisation qui a appris à vivre avec, et pour qui l’intervention extérieure est une manière de continuer.
Si c’est flou → ils veulent un audit, pas une transformation. Je facture cinq jours maximum, je livre le diagnostic, et je pars. C’est honnête pour tout le monde.
Question 2 : y a-t-il un décideur unique ?
Le pire contexte n’est pas l’entreprise en difficulté. C’est le comité.
Ce que je cherche : qui signe le contrat, et cette personne peut-elle trancher seule sur un arbitrage qui engage à la fois la technique et le budget ?
Le signal se lit dans la formulation. « Il faudra qu’on en discute » et « je vais valider » ne décrivent pas la même organisation.
Si c’est non → chaque décision prendra trois semaines, la mission fera le tiers de ce qu’elle devait faire, et le client conclura que ça n’a pas marché. Je refuse, ou j’exige un décideur unique nommé au contrat.
Question 3 : avez-vous le budget d’exécuter les recommandations ?
C’est la question qui met le plus mal à l’aise, et celle qui économise le plus de temps aux deux parties.
L’ordre de grandeur : si je facture 30 k€ pour trois mois, il faut environ 90 k€ de budget total. Recommander une refonte de CI, un recrutement ou un arrêt de produit à quelqu’un qui n’a les moyens d’aucun des trois, c’est produire un document.
Si c’est non → la mission ne peut pas réussir, quelle que soit la qualité du travail. Autant le dire au premier appel qu’au troisième mois.
flowchart TD
CALL["Premier appel
30 min, gratuit"]
CALL --> Q1["Prêt à changer ?"]
CALL --> Q2["Décideur unique ?"]
CALL --> Q3["Budget pour exécuter ?"]
Q1 -->|"Flou"| AUDIT["Audit court 5j"]
Q2 -->|"Non"| REFUSE["Refus poli"]
Q3 -->|"< 3× mon intervention"| REFUSE
Q1 -->|"Oui"| GO
Q2 -->|"Oui"| GO
Q3 -->|"Oui"| GO["Mission acceptée"]
class REFUSE alerte
class GO okCe que refuser a changé
Le taux de succès n’est pas monté parce que je suis devenu meilleur. Il est monté parce que j’ai arrêté d’accepter des missions qui ne pouvaient pas réussir.
L’effet secondaire compte autant : sur une mission bien qualifiée, on gagne les deux premières semaines. Pas de négociation du périmètre, pas de recherche du décideur, pas de découverte au deuxième mois que le budget d’exécution n’existe pas. On commence à travailler le premier jour.
Et refuser proprement ne coûte pas le contact. La moitié des gens à qui j’ai dit non sont revenus plus tard, ou m’ont recommandé à quelqu’un d’autre. Un refus argumenté est la meilleure démonstration de jugement qu’on puisse faire gratuitement.
Un fractionné n’est pas un prestataire. C’est un partenaire stratégique. Si le client n’est pas prêt, mieux vaut refuser — pour lui autant que pour soi.
Sources
- Enns, B. — The Win Without Pitching Manifesto
- Observations terrain — qualification de missions CTO fractionné
Glossaire
- CI : Continuous Integration — chaîne automatique qui construit et vérifie le code à chaque modification.
- CTO : Chief Technology Officer — directeur technique.