Votre lead dev vous dit qu'il faut migrer vers le cloud. Votre prestataire propose une réécriture complète du module de facturation. Un candidat CTO vous explique que votre architecture "ne tient pas la route". Vous écoutez, vous posez quelques questions, et vous signez — à l'instinct. Ce n'est pas de la négligence. C'est simplement le résultat d'une asymétrie d'information que personne ne vous a donné les outils pour réduire. Voici 4 questions concrètes pour reprendre la main.
Pourquoi "faire confiance à votre équipe" ne suffit pas
Faire confiance à votre équipe technique est nécessaire. Lui déléguer toutes les décisions sans aucun mécanisme de vérification est une autre affaire. Ce n'est pas une question de méfiance — c'est une question de gouvernance.
Votre lead dev ou votre prestataire peut être compétent, honnête et bien intentionné, et recommander quand même une solution qui ne correspond pas à vos intérêts — parce qu'il a un biais vers sa technologie de prédilection, parce qu'il sous-estime les contraintes business, ou simplement parce que la solution la plus simple pour lui n'est pas la plus adaptée à votre situation.
Sans outil pour challenger ces recommandations, vous avez deux options : valider systématiquement (vous perdez la main) ou refuser systématiquement (vous créez des conflits). Les 4 questions ci-dessous vous donnent une troisième voie : challenger de façon structurée, indépendamment de votre niveau technique.
L'objectif n'est pas de devenir un expert technique. C'est de rester un dirigeant qui comprend les conséquences de ses décisions — et qui sait quand il a besoin d'un regard externe pour les évaluer correctement.
Les 4 questions à poser face à n'importe quelle recommandation technique
Ces questions sont formulées pour être posées sans expertise technique. Elles ne demandent pas une réponse technique — elles demandent une réponse claire. Si votre interlocuteur ne peut pas y répondre simplement, c'est en soi une information.
Une bonne recommandation technique est toujours le résultat d'un choix entre plusieurs options. Si votre interlocuteur arrive avec une seule solution sans avoir exploré les alternatives, soit il n'a pas fait le travail d'analyse, soit il vous présente la solution qui l'arrange sans vous montrer le comparatif complet.
"On a regardé trois options — A, B et C. A a été écarté parce que ça dépassait notre budget de 3x. C parce que ça nécessitait une migration de données risquée. On propose B parce que c'est le meilleur équilibre risque/coût pour votre contexte."
"C'est la meilleure solution du marché" — sans comparaison avec d'autres options dans votre contexte spécifique. Ou une réponse technique qui ne répond pas à la question des alternatives.
Toute décision technique comporte un risque. Un interlocuteur honnête et préparé connaît les risques de sa recommandation et peut vous dire ce qui se passe si les hypothèses ne se vérifient pas. L'absence de réponse à cette question signifie soit que les risques n'ont pas été analysés, soit qu'ils sont trop importants pour être présentés confortablement.
"Le risque principal est X. Si ça arrive, on a un plan de rollback qui prend 48h. On a prévu une phase de tests en parallèle avant de couper l'ancien système pour limiter ce risque."
"Ça va bien se passer, on a l'habitude." Ou une réponse qui minimise les risques sans plan de contingence concret.
Les décisions techniques ne se prennent pas dans le vide. Elles ont un coût d'opportunité : le temps passé sur la migration ou la refonte est du temps qui n'est pas passé sur les fonctionnalités que vos clients attendent. Un interlocuteur qui n'intègre pas cette dimension dans sa recommandation vous présente une solution technique, pas une solution business.
"Pendant 6 semaines, l'équipe sera mobilisée à 70% sur la migration. On peut livrer les fonctionnalités prioritaires A et B, mais C sera décalée. Voici comment on a priorisé pour minimiser l'impact client."
Une réponse qui ignore la question business et revient sur les bénéfices techniques. Ou une estimation d'impact qui semble optimiste sans justification.
Cette question vous donne la mesure de l'urgence réelle. Certaines décisions techniques sont urgentes — ne pas agir coûte cher chaque semaine qui passe. D'autres peuvent attendre — la recommandation est valide mais pas critique. Faire la distinction change radicalement la priorité que vous devez donner à la décision et le budget que vous devez y allouer.
"Dans 6 mois, si on ne résout pas ce problème, les temps de chargement vont continuer à augmenter et on va commencer à perdre des conversions. On estime l'impact à environ X€/mois à partir du trimestre prochain."
"Ça va devenir un vrai problème" sans chiffre ni conséquence business concrète. L'urgence fabriquée est l'un des outils les plus courants pour court-circuiter votre analyse.
Les 4 signaux que ces questions ne suffisent plus
Ces 4 questions vous donnent un premier niveau de contrôle. Mais il y a des situations où challenger ne suffit pas — où vous avez besoin d'un regard technique indépendant avant de décider.
À ce niveau d'investissement, l'asymétrie d'information entre vous et votre équipe technique crée un risque trop important pour être géré avec des questions seules. Le coût d'un regard externe est marginal par rapport au coût d'une mauvaise décision.
Migration de base de données, changement d'architecture principal, choix de stack pour un nouveau produit — certaines décisions engagent votre infrastructure pour 3 à 5 ans. La réversibilité d'une décision est inversement proportionnelle à l'exigence de validation externe.
Un prestataire en situation de lock-in, un lead dev qui pousse sa technologie de prédilection, un candidat CTO qui valorise sa propre expertise — ce ne sont pas des gens de mauvaise foi, ce sont des gens avec des biais légitimes. Un regard neutre est précisément fait pour corriger ces biais.
Si votre interlocuteur répond bien aux 4 questions mais que vous n'avez aucun moyen de savoir si ses réponses sont réalistes — si les chiffres sont plausibles, si le plan de contingence est solide — vous avez atteint la limite de ce que vous pouvez faire seul. C'est là qu'un tiers technique devient nécessaire, pas avant.
Ce que "reprendre la main" signifie concrètement
Reprendre la main sur vos décisions techniques ne signifie pas devenir développeur. Ça signifie trois choses précises :
Comprendre les conséquences, pas les mécanismes. Vous n'avez pas besoin de savoir comment fonctionne un reverse proxy. Vous avez besoin de savoir ce qui se passe pour vos clients si celui-ci tombe. La distinction est importante et souvent ignorée dans les conversations avec les équipes techniques.
Poser les bonnes questions au bon moment. Les 4 questions de cet article fonctionnent parce qu'elles parlent la langue du business — alternatives, risques, impact, urgence. Pas la langue de la tech. Elles ne demandent pas à votre interlocuteur de se justifier techniquement, elles lui demandent de traduire en termes de conséquences.
Savoir quand vous avez besoin d'aide. Un dirigeant qui sait identifier les limites de son propre jugement est un dirigeant qui prend de meilleures décisions. L'objectif n'est pas de tout décider seul — c'est de décider avec la bonne information, au bon niveau de risque.