La pensée structurée : le véritable atout du consultant

La pensée structurée, c'est ce qui permet à un consultant de passer d'un problème client flou et confus à une recommandation que la salle peut suivre et contester. Vous cadrez la décision, vous découpez le problème en parties qui ne se recoupent pas, vous testez d'abord la réponse la plus probable, puis vous rassemblez les constats en une recommandation claire.

Ce texte s'adresse aux consultants et aux analystes qui veulent une méthode reproductible pour y arriver sous pression. Il présente les quatre outils sur lesquels je m'appuie, une fiche d'une page à utiliser dans votre prochaine mission, et ce que l'IA a changé à cette compétence.

J'ai vu des gens se figer en réunion client. Pas parce qu'ils manquaient d'idées. Parce qu'ils ne savaient pas par où commencer.

Le cadre est familier. Un problème complexe, une salle de décideurs seniors, un périmètre vague et une attente de clarté. La réaction non structurée consiste à se mettre à parler en espérant que la réponse finira par émerger. Parfois, elle émerge. Plus souvent, on tourne en rond pendant vingt minutes et personne ne repart satisfait.

C'est la pratique qui consiste à découper un problème ambigu en parties, à traiter chaque partie dans l'ordre, puis à rassembler les constats en une recommandation.

Ce n'est pas remplir un modèle et appeler cela une analyse. Ce n'est pas plaquer un cadre sur un problème auquel il ne convient pas. Un consultant qui applique une matrice 2x2 à toutes les situations reconnaît des motifs, il ne réfléchit pas.

Ce que vous construisez, c'est une poignée de capacités :

1. Repérer le vrai problème, souvent différent de celui qui est présenté
2. Le découper en parties que l'on peut analyser séparément
3. Savoir quelles informations comptent et lesquelles non
4. Construire un argumentaire cohérent à partir de ce que vous trouvez
5. Le dire clairement quand la salle est tendue

Les cadres sont un échafaudage pendant que ces capacités se développent. Si vous voulez la boîte à outils plus large, je présente les plus courants dans les cadres de conseil simples expliqués.

La question de cadrage

Avant tout cadre, posez une question. Quelle décision faut-il prendre, et quelle information changerait cette décision ?

Elle fait plus pour la qualité de l'analyse que n'importe quel outil de structure. Elle oblige à préciser ce que doit être le livrable et vous empêche de faire un travail minutieux sur une question dont personne n'avait besoin de la réponse. La HBR défendait la même idée il y a des années dans Are You Solving the Right Problem? : l'essentiel des efforts gaspillés commence par un problème mal défini.

Dans un contexte SAP, « quel modèle de déploiement convient à cette organisation » est une décision. « Qu'est-ce que S/4HANA » est une description. La première demande de l'analyse. La seconde demande de la documentation. Savoir laquelle des deux vous faites décide de la façon dont vous passez la semaine.

MECE

MECE signifie Mutually Exclusive, Collectively Exhaustive : mutuellement exclusif, collectivement exhaustif. Quand vous découpez un problème en parties, chaque partie doit être distincte (pas de recoupement) et l'ensemble doit couvrir tout le problème (pas de lacune).

Les catégories qui se recoupent comptent en double. Les lacunes font manquer des éléments. La plupart des consultants connaissent le sigle. Peu l'appliquent avec rigueur.

Deux tests permettent de rester honnête. Premier test : un élément pourrait-il se trouver dans deux branches à la fois ? Alors les branches se recoupent. Second test : si chaque branche recevait une réponse, la question centrale en aurait-elle une aussi ? Sinon, il y a une lacune. Un MECE parfait est rare. Ce qui compte, c'est de poser ces deux questions à chaque fois.

Les arbres de problèmes

Un arbre de problèmes place la question centrale à la racine et les sous-questions sur les branches. Chaque branche peut être analysée séparément.

Prenons « Pourquoi ce go-live SAP a-t-il dépassé de 40 % le budget prévu ? » Le premier découpage pourrait être : changements de périmètre, coûts de ressources, allongements de calendrier et remédiation non prévue. Les changements de périmètre se subdivisent ensuite en demandes de changement formelles, ajouts informels et lacunes découvertes tard. Chaque feuille peut être mesurée.

Les arbres de problèmes font leurs preuves au début d'une mission, avant toute analyse. Ils vous empêchent de passer trois semaines sur une branche pendant qu'une autre reste intacte.

L'analyse pilotée par les hypothèses

Au lieu de rassembler toutes les données puis de conclure, vous partez de la réponse la plus probable et vous la testez. Les cabinets de stratégie ont bâti leur réputation sur cette approche.

Avec un temps limité et un problème complexe, une analyse exhaustive est impossible. Une bonne hypothèse vous dit ce qu'il faut regarder en premier. Si elle tient, vous avez votre réponse. Si elle échoue, les éléments qui l'ont fait tomber pointent généralement vers quelque chose d'utile.

C'est aussi l'approche la plus souvent mal utilisée. Des consultants formulent une hypothèse puis ne cherchent que les preuves qui la confirment. Demandez-vous quelle preuve montrerait que vous avez tort, et allez d'abord la chercher.

Voici la séquence que je remettrais à un nouveau consultant avant son premier diagnostic. Remplissez-la avant d'ouvrir le moindre tableur.

1. 01CadrerLa décision, en une phrase
2. 02DécomposerTrois à cinq questions MECE
3. 03Formuler une hypothèseUne ligne par branche
4. 04RéfuterLes preuves qui montreraient que vous avez tort
5. 05TesterConstats par branche, avec les sources
6. 06SynthétiserLa recommandation d'abord, puis les éléments à l'appui
7. 07ÉprouverObjections traitées avant que la salle ne les soulève

Une recommandation qui survit au comité de pilotage

Étape	Question à laquelle répondre	Livrable	Qui valide
1. Cadrer	Quelle décision le client doit-il prendre, et pour quand ?	Une phrase	Le sponsor côté client
2. Décomposer	Quelles trois à cinq questions, une fois traitées ensemble, permettent de trancher cette décision ?	Arbre de problèmes de premier niveau, testé MECE	Le responsable de mission
3. Formuler une hypothèse	Que crois-je aujourd'hui être la réponse, et pourquoi ?	Une hypothèse d'une ligne par branche	Le responsable de mission
4. Réfuter	Quelles preuves montreraient que chaque hypothèse est fausse ?	Liste de demandes de données, classée par priorité	Les propriétaires de données côté client acceptent de les fournir
5. Tester	Que disent les preuves ?	Constats par branche, avec les sources	Les responsables de branche dans l'équipe
6. Synthétiser	Alors, que doit faire le client ?	La recommandation d'abord, puis les points d'appui	Le responsable de mission
7. Éprouver	Qui, dans la salle, ne sera pas d'accord, et sur quoi ?	Objections et réponses, préparées	Un collègue qui n'a pas travaillé sur le dossier

L'étape 7 est celle que les gens sautent. C'est aussi celle qui décide si la recommandation survit au comité de pilotage.

Un client SAP, un grand groupe industriel, exploitait un paysage ECC très personnalisé. Le responsable IT l'a dit sans détour : « Il faut réduire nos coûts d'exploitation, mais nous ne pouvons pas nous permettre de casser quoi que ce soit. »

L'instinct est de se mettre à lister des idées d'économies. On obtient une longue liste, beaucoup de gens inquiets et aucune priorité.

Nous avons organisé l'analyse des coûts en trois branches : maintenance applicative, infrastructure et licences. Nous y avons ensuite ajouté une analyse du code spécifique. Combien de modifications étaient réellement utilisées ? Plus de la moitié ne l'étaient pas. Des interfaces redondantes, des rapports spécifiques inutilisés, des workflows qui se chevauchaient.

Cette structure nous a permis de désigner des économies qui paraissaient sûres, comme l'archivage des objets spécifiques inutilisés et la consolidation des environnements de développement. La clarté a réduit les frictions politiques et elle a installé la confiance. Sans l'arbre, ce n'aurait été qu'une liste de coupes que personne ne voulait signer.

La même méthode fonctionne sur des briefs plus vagues. Un éditeur de logiciels d'entreprise nous a un jour demandé « une stratégie de lancement régional » pour les ETI saoudiennes. Nous avons réparti le travail entre demande du marché, position concurrentielle et préparation des partenaires. Sous la préparation des partenaires, nous avons constaté que leur réseau de revendeurs avait peu d'expérience de SAP S/4HANA Cloud. Ce point de blocage aurait enrayé l'exécution, aussi attrayant que paraisse le marché, et la structure l'a fait apparaître avant qu'ils ne dépensent le budget de la campagne.

Les cadres n'ont pas changé. Deux autres choses, si.

Le premier jet est désormais bon marché. Joule, ChatGPT et Claude produisent un arbre de problèmes ou un arbre d'hypothèses en quelques secondes. Les jeunes consultants qui passaient autrefois une soirée sur un premier jet le génèrent maintenant en une demi-minute et consacrent la soirée à ce que le modèle ne sait pas faire : vérifier que la structure correspond au problème, trouver ce qu'elle a oublié et remettre en cause les hypothèses contenues dans le prompt.

La prime au jugement a augmenté. Quand tout le monde peut générer un découpage MECE, la question n'est plus « avez-vous décomposé le problème ». Elle devient « avez-vous remarqué que le problème énoncé par le client est un autre problème, et avez-vous repéré l'hypothèse que le modèle a acceptée par défaut ». Les consultants qui ont forgé leur jugement sur de vraies missions ont aujourd'hui une avance plus large qu'en 2024.

La compétence s'est donc déplacée. Ce n'est plus « savez-vous construire un arbre de problèmes ». C'est « savez-vous repérer quand l'arbre rédigé par l'IA est faux, et le corriger dans une salle client ».

Si vous cherchez où cela vous place dans votre propre carrière, les parcours de carrière de SAPopedia cartographient les filières du conseil, et le pack carrière ERPCV vous aide à montrer ce type de jugement dans un CV plutôt que de simplement lister des cadres.

Partir d'une solution. Le client ou le consultant a une réponse en tête avant que le problème soit cadré. L'analyse devient une confirmation.

Trop de structure. Certains problèmes simples méritent une réponse directe, pas une décomposition MECE. Savoir quand ne pas utiliser de structure compte autant que savoir comment en utiliser une.

Décomposer à la mauvaise profondeur. Des arbres trop profonds trop tôt produisent de la paralysie. Des arbres qui restent en surface produisent des recommandations que personne ne peut appliquer. Adaptez la profondeur à la décision et au temps disponible.

Analyser sans synthétiser. Un arbre rigoureux qui finit en déversement de données. La structure aide à réfléchir. Le jugement produit la recommandation.

Confondre structure de communication et structure de pensée. Présenter la conclusion d'abord, comme dans le Pyramid Principle de Barbara Minto, est une technique de communication. Elle ne dit rien de la solidité de la réflexion sous-jacente. Bien communiquer une mauvaise analyse, cela reste une mauvaise analyse.

C'est une compétence, pas un trait de caractère. Elle vient avec la pratique.

Après chaque échange client important, notez le problème tel que vous le comprenez, votre décomposition, votre hypothèse et les preuves qui la testeraient. Faites-le avant de regarder la moindre donnée. Écrire impose une clarté que penser dans sa tête n'impose pas.

Entraînez-vous à la synthèse, pas seulement à l'analyse. Prendre un tas de preuves et en tirer une recommandation défendable est la moitié la plus difficile. La plupart des jeunes consultants sont corrects en analyse et peu développés en synthèse. Cet écart est l'endroit où se joue la prochaine promotion, et c'est une grande part de ce que font vraiment les consultants une fois les buzzwords retirés.

Qu'est-ce que la pensée structurée en conseil ?

C'est découper un problème complexe et ambigu en parties, traiter chaque partie dans l'ordre et combiner les constats en une recommandation claire. Elle rend les problèmes difficiles abordables et rend le raisonnement visible : le client peut le suivre et le contester au lieu d'accepter une conclusion sur parole.

Les principaux outils sont la question de cadrage, les arbres de problèmes, le MECE et l'analyse pilotée par les hypothèses. Aucun ne remplace le jugement.

Que signifie MECE et comment l'utilise-t-on ?

Mutually Exclusive, Collectively Exhaustive : mutuellement exclusif, collectivement exhaustif. Les parties d'un découpage ne doivent pas se recouper, et ensemble elles doivent couvrir tout le problème.

Test de recoupement : un élément pourrait-il se trouver dans deux branches ? Test de lacune : si chaque branche recevait une réponse, la question centrale en aurait-elle une aussi ? Appliquez-le quand vous construisez l'arbre de problèmes. L'appliquer à une analyse terminée arrive généralement trop tard.

Comment fonctionne l'analyse pilotée par les hypothèses ?

Vous énoncez tôt la réponse la plus probable, vous listez les preuves qui la confirmeraient ou la réfuteraient, puis vous allez la tester. C'est plus rapide que de tout rassembler d'abord, parce que cela vous dit où regarder.

Le risque est le biais de confirmation. Cherchez d'abord les preuves qui pourraient vous donner tort.

Comment cadrer correctement un problème de conseil ?

Demandez quelle décision doit être prise et quelle information la changerait. Testez ensuite l'énoncé du problème du client avant de l'accepter.

Un client qui demande « quel module SAP faut-il mettre en œuvre en premier ? » est peut-être en train de décider « est-ce le bon moment pour lancer un programme SAP ? » Répondre à la question posée sans tester le cadrage donne une analyse techniquement correcte et commercialement fausse.

Quelle est la différence entre analyse et synthèse en conseil ?

L'analyse découpe un problème ou un jeu de données en parties pour les comprendre. La synthèse combine les constats en une recommandation.

L'échec de livrable le plus courant, c'est beaucoup d'analyse et pas de synthèse : le client reçoit une pile de constats et aucune réponse à la question pour laquelle il vous a engagé. Écrire d'abord la conclusion force la synthèse à avoir lieu.

Comment la pensée structurée s'applique-t-elle aux mises en œuvre ERP ?

Au démarrage d'un programme, elle empêche les équipes de configurer avant d'avoir compris le vrai problème. Une organisation qui dit « il nous faut SAP » doit peut-être d'abord corriger un processus ou un problème de données que SAP ne fera que rendre plus visible.

Dans un travail de fit-gap, un découpage MECE des processus métier garantit que chaque processus est examiné, pas seulement ceux qui ont été soulevés en atelier. Après un go-live difficile, cadrer la décision (stabiliser, redresser ou remplacer) et tester une hypothèse sur la cause principale mène à une recommandation défendable plus vite que lister des symptômes.