Questions d'entretien Consultant en management

Je commencerais par structurer le problème avant de toucher aux données. Le bénéfice est la différence entre le chiffre d'affaires et les coûts, donc je diviserais mon hypothèse initiale en deux branches : s'agit-il d'un problème de chiffre d'affaires, de coûts, ou des deux ? Pour le chiffre d'affaires, j'examinerais le volume, le prix et le mix. Pour les coûts, je séparerais les fixes des variables et vérifierais si les coûts unitaires ont évolué. Je demanderais ensuite les données les plus susceptibles de confirmer ou d'écarter chaque branche rapidement. Dans un vrai projet, je construirais cet arbre de problèmes dès le premier jour et m'alignerais avec le client avant d'approfondir un seul domaine. Une structure claire au départ évite des semaines d'analyses inutiles.

Je commence par la recommandation, pas par l'analyse. Les dirigeants veulent savoir quoi faire et pourquoi c'est important avant de comprendre comment je suis arrivé à cette conclusion. En pratique, ma première diapositive énonce clairement la recommandation, la deuxième couvre les trois arguments les plus solides, et la troisième répond aux objections les plus probables. Je garde les graphiques simples : un message par graphique, avec une légende qui rend la conclusion visible sans lire le corps du texte. J'anticipe aussi les questions que posera le DG ou le DAF et prépare une diapositive d'annexe par objection clé pour pouvoir répondre immédiatement. Je m'entraîne à formuler la recommandation en une phrase avant toute présentation importante.

Je considère cela comme le moment le plus précieux de l'analyse. Si les données contredisent l'hypothèse, soit l'hypothèse est fausse, soit les données ont un problème de qualité. Mon premier réflexe est de vérifier les données : source, date, méthode de collecte, cohérence interne. Si les données sont fiables, je mets à jour l'hypothèse et communique le changement clairement à l'équipe et au client. Je ne m'accroche pas à une hypothèse par attachement. Sur un projet, j'avais construit un modèle de taille de marché montrant un fort potentiel de croissance, mais les données de transaction du client montraient la tendance inverse. En creusant, j'ai découvert que les données de marché excluaient un canal de distribution majeur. Ce constat a modifié toute la recommandation stratégique.

Dans mon cabinet précédent, je travaillais avec un directeur financier ouvertement sceptique sur le projet et qui contestait chaque résultat intermédiaire. Plutôt que d'escalader, j'ai demandé un entretien individuel dès la deuxième semaine pour comprendre ses préoccupations directement. Il m'a expliqué que le dernier cabinet avait fait des promesses non tenues et laissé l'équipe avec plus de travail. J'ai reconnu cet historique et proposé de partager un document de travail de nos conclusions chaque vendredi plutôt qu'attendre un livrable formel. En trois semaines, la dynamique a changé : il a commencé à signaler proactivement des sources de données et a même soutenu notre recommandation lors de la présentation finale au conseil. La résistance du client vient souvent d'expériences passées, pas du travail en cours.

Lors d'un projet de transformation des coûts, mon analyse a montré que l'unité la plus rentable du client subventionnait trois divisions sous-performantes. Le PDG s'était publiquement engagé à développer les quatre divisions. Je savais que le constat serait difficile à entendre. J'ai préparé un résumé d'une page avec les preuves, l'impact financier quantifié clairement et deux options stratégiques plutôt qu'une diapositive unique exposant le problème. J'ai informé la directrice de projet en privé avant le conseil pour qu'elle ne soit pas surprise, et j'ai présenté les conclusions comme des choix que l'équipe dirigeante pouvait désormais prendre en connaissance de cause, pas comme un verdict sur les décisions passées. La directrice a dit que cette approche expliquait pourquoi le conseil avait réagi de façon constructive.

Sur un projet d'intégration post-fusion, les équipes opérations et commercial avaient des visions fondamentalement différentes sur les systèmes à consolider en premier. Les opérations voulaient prioriser l'ERP pour réduire les coûts rapidement. Le commercial souhaitait préserver le CRM intact pour protéger les relations clients pendant la transition. J'ai cartographié la préoccupation centrale de chaque groupe et le risque qu'il cherchait à éviter, puis conçu une proposition de séquençage qui préservait le CRM pendant les six premiers mois tout en lançant la consolidation ERP sur les fonctions back-office sans exposition client. Je l'ai présenté comme un chemin de gestion des risques plutôt qu'un compromis. Les deux équipes ont accepté. La clé était que chaque groupe sente que sa préoccupation principale avait été entendue et reflétée dans le plan.

Je travaille en commençant par l'hypothèse. Avant de demander des données, j'écris ce que je m'attends à trouver et ce qui me ferait changer d'avis. Cette discipline maintient l'analyse ciblée : je teste des affirmations précises plutôt que de chercher quelque chose d'intéressant. Pour l'analyse quantitative, je construis généralement un modèle Excel qui trace le chemin depuis les données primaires jusqu'à la conclusion finale, avec chaque hypothèse documentée et soumise à une analyse de sensibilité. Pour les données qualitatives, j'utilise des entretiens structurés avec un questionnaire cohérent afin d'identifier des tendances plutôt que de m'appuyer sur des anecdotes individuelles. Je triangule toujours : une source confirme une hypothèse, deux sources indépendantes me donnent de la confiance, trois me donnent une recommandation que je suis prêt à défendre.

Je structure un business case autour de trois questions : quelle est l'opportunité, quel est le coût pour la saisir, et quels sont les risques. Pour l'opportunité, je quantifie la valeur adressable à partir des données de marché, des benchmarks internes ou des études de cas comparables selon ce qui est disponible. Pour les coûts, je sépare les dépenses d'investissement des charges d'exploitation et distingue les coûts d'implémentation uniques des coûts de fonctionnement récurrents. Pour le modèle financier, je projette les flux de trésorerie sur trois à cinq ans, calcule la VAN et le TRI, et inclus un délai de récupération car c'est souvent la métrique sur laquelle les dirigeants se concentrent en premier. La section risques couvre les deux ou trois hypothèses sur lesquelles repose tout le business case et l'impact sur les rendements si ces hypothèses sont fausses à 20 %.

MECE, mutuellement exclusif et collectivement exhaustif, est la discipline que j'applique pour construire un arbre de problèmes. L'objectif est de décomposer un problème en parties qui ne se chevauchent pas et qui couvrent ensemble toutes les causes possibles. En pratique, je commence par identifier les une ou deux dimensions qui séparent le plus clairement l'espace du problème. Pour un problème de chiffre d'affaires, cela pourrait être les nouveaux clients par rapport aux clients existants. Je teste ensuite chaque branche : si je traitais cette branche complètement, aurais-je expliqué une part significative du problème ? Si des branches se chevauchent, je redessine l'arbre. Je surveille aussi les branches qui semblent MECE sur le papier mais s'effondrent en pratique parce que les données sous-jacentes ne se séparent pas proprement. L'arbre de problèmes est un outil de réflexion, pas un modèle de présentation.