SolutionScience #034 | Power Map : un outil indispensable pour naviguer la politique interne d'un prospect

C'était un très grand compte du luxe français. Le classique à ne pas perdre : beau logo, bel enjeu business (et technologique), bref, une belle opportunité. Le CTO avait une présence dans la pièce difficile à ignorer, le genre de personnage qui parle fort, qui coupe la parole avec le sourire, et qui te regarde d'une façon qui te signifie clairement qu'il est l'homme le plus important de la réunion. Il se présentait comme le décideur sur le sujet expérience client, et il le disait avec une conviction qui ne laissait pas vraiment de place au doute.

On l'avait cru.

Le deal pataugeait : des réunions qui n'aboutissaient à rien, des discussions avec des gens importants sur le papier, des relances dans le vide. Il n'y avait pas de blocage explicite mais pourtant, on avait cette impression de plus en plus nette que notre interlocuteur principal n'avait pas vraiment la main sur ce qu'il prétendait contrôler.

Ce qu'on a compris plus tard, en grattant un peu, en récupérant des « on dit que » qui circulaient discrètement sur le marché, c'est que ce CTO avait une façon très particulière d'exercer le pouvoir : il aimait que tout semble reposer sur lui, et cultivait une forme de dépendance chez ses propres équipes, qui avaient appris à ne rien décider sans son aval. La peur était devenue le principal mode de management. Paradoxalement, cet homme qui se présentait comme le centre de gravité de toutes les décisions n'avait en réalité aucun pouvoir réel sur l'expérience client et sa dimension business / marketing. Dans les écosystèmes tech français, tout finit par se savoir ! Les éditeurs se croisent, les consultants parlent, les anciens collaborateurs déjeunent. La réputation d'un CTO difficile circule souvent bien avant que tu ne le rencontres, à condition d'avoir pensé à poser la question.

Bref, plusieurs semaines perdues, et une leçon que je n'ai jamais oubliée : un interlocuteur qui occupe tout l'espace le fait rarement par accident.

C'est la construction d'une power map fine qui a tout changé pour ce deal : en cartographiant très précisément tous les acteurs impliqués dans le cycle d'achat, et en identifiant leurs relations, leurs influences réelles et leurs agendas, on a compris que le vrai décideur sur l'expérience client n'était pas le CTO mais un directeur IT, son bras droit, que nous avions à peine croisé, dans une réunion de cadrage au tout début du cycle. Nous ne lui avions pas accordé suffisamment d'attention, parce qu'un autre personnage avait bouffé tout l'espace.

En France, le vrai décideur ne se présente jamais comme tel : il arrive souvent en combo jean + veste formelle (please don't...) dans une réunion de COMEX, parle très peu, pose une question au mauvais moment. Tu l'as raté la première fois ? C'est normal.

Une power map n'est pas un organigramme : c'est la première confusion à dissiper, parce qu'elle est fréquente et généralement coûteuse.

L'organigramme, c'est la version LinkedIn d'une organisation : il décrit le pouvoir formel : les titres, les lignes hiérarchiques, les responsabilités « officielles ». La power map, elle, décrit le pouvoir réel : qui influence qui et quoi, qui a un droit de veto sans le dire, qui est le prescripteur clé derrière le décideur « apparent », et qui va silencieusement (ou pas) saboter une décision qu'il n'a pas été invité à prendre.

Dans une organisation Enterprise, le pouvoir formel et le pouvoir réel sont souvent deux choses très distinctes, et parfois complètement décorrélées. Un VP avec un titre ronflant peut n'avoir aucun pouvoir réel sur la décision d'achat. Par contre, un responsable terrain peut avoir l'oreille du COMEX sur tout ce qui touche à son domaine.

Les rôles clés à identifier dans une power map sont au minimum les suivants :

• Le décideur réel (pas celui qui se présente comme tel), mais celui qui signe ou bloque en dernier ressort,
• Le prescripteur, qui influence la décision sans la prendre,
• Le négociateur, qui gère les conditions contractuelles et commerciales,
• Le champion, qui porte le projet en interne et dont tu dois impérativement renforcer la position,
• L'influenceur, qu'on ne voit pas tout le temps en réunion, mais dont l'avis compte beaucoup,
• Et le détracteur... on y revient.

Il y a une illusion assez confortable dans laquelle beaucoup d'équipes commerciales vivent : l'idée que le deal se gagne sur la qualité du produit, la bonne démo, ainsi que la solidité du discours business.

C'est vrai... mais c'est vraiment insuffisant.

La réalité d'un cycle de vente Enterprise, c'est que chaque organisation du prospect est un écosystème politique : il y a des alliances entre équipes qui datent de Louis XIV, des rivalités entre managers qui utilisent parfois ton projet comme terrain de jeu pour leurs guerres de territoire, des agendas personnels qui n'ont strictement rien à voir avec les besoins exprimés en réunion.

Ce que tes interlocuteurs te disent en face à face n'est qu'un point de départ. Ce qu'ils ne disent pas, ce qu'ils font vraiment en interne quand tu n'es plus dans le coin, c'est là que se joue vraiment la décision.

Comprendre cette dimension politique ne rend pas cynique : ça rend lucide (enfin, c'est ma conviction). La lucidité sur le terrain d'un deal Enterprise, donc complexe par nature, est une compétence commerciale / presales à part entière, aussi importante que la qualité de ta démo ou la puissance de ton discours orienté valeur.

Dans la plupart des cycles de vente, on passe l'essentiel du temps à convaincre les convaincus et à séduire les neutres. C'est plutôt confortable. Le détracteur, lui, est souvent ignoré : soit parce qu'on ne l'a pas identifié, soit parce qu'on serre les fesses et qu'on espère collectivement qu'il ne sera pas trop décisif.

C'est une erreur structurelle qui coûte très très très cher.

Un détracteur n'a pas besoin d'être décideur pour torpiller une opportunité : il lui suffit d'avoir l'oreille du décideur, de semer le doute (voire la peur) au bon moment, ou de créer suffisamment d'inertie en interne pour que la décision soit repoussée jusqu'à ce que le projet meure de sa belle mort administrative.

Le détracteur peut être n'importe qui :

• Un profil technique qui perçoit ta solution comme une menace directe à ses compétences. Si ce que tu automatises, c'est ce qu'il fait manuellement depuis cinq ans, sa résistance est parfaitement rationnelle de son point de vue.
• Un manager métier qui n'a pas été impliqué assez tôt dans le cycle et qui vit le projet comme quelque chose qui lui a été imposé plutôt que co-construit.
• Un utilisateur clé qui a peur du changement et qui va influencer discrètement ses collègues dans le mauvais sens.
• Un directeur qui est copain copain avec un autre éditeur, accessoirement concurrent.

Le détracteur français est difficile à identifier car il ne dit jamais non : il fronce les sourcils avec un sourire qui signifie en fait la même chose. D'ailleurs, il a lu Descartes : il pratique la litote et il va te tuer avec des formules inversées.

La source de la résistance change la stratégie à adopter ! Un détracteur qui protège son territoire technique a besoin qu'on lui montre que sa valeur est préservée (voire renforcée) par la solution. Un manager non impliqué a besoin d'être intégré au projet suffisamment tôt pour en devenir partie prenante plutôt qu'opposant. Un utilisateur anxieux a besoin de preuves concrètes, de pairs qui ont vécu la transition, bref, de réassurance.

SE : — On a regardé votre architecture actuelle avec votre équipe Data Engineering. Il y a quelques points qu'on aimerait comprendre mieux sur les temps de traitement.

Tech (menacé) : — Oui, vous parlez de Falcon, je pense.

— Falcon, c'est... le projet interne ?

— Falcon, c'est notre moteur interne de traitement temps réel. Architecture microservices, pipeline event-driven. On l'a construit en dix-huit mois. C'est du sur-mesure total. Un bijou technologique.

— D'accord. Et quand vous dites temps réel, vous êtes sur quelle fenêtre de traitement concrètement ?

— Alors, « temps réel » c'est un terme large. Chez nous on est sur un modèle de near real-time. Quelques minutes selon les flux.

— Quelques minutes, ça veut dire combien ?

— (léger flottement) Ça dépend de la charge. Entre cinq et vingt minutes en général. Parfois un peu plus aux heures de pointe.

Falcon fait du temps réel. Dans le sens où tout finit par arriver, un jour ou l'autre.

— Donc pas vraiment sous la millisecondes pour les cas d'usage critiques ?

— La milliseconde c'est notre cible d'architecture. On s'en approche sur certains cas d'usage.

— Lesquels ?

— (silence) On a une roadmap sur ce sujet. Et les incidents de la semaine dernière, c'était un cas limite. Un volume atypique.

— Le volume de prod normal ?

— Falcon est optimisé pour notre charge standard. Les pics extrêmes nécessitent quelques ajustements.

— Combien de fois par mois vous avez ces pics ? Cela vous coûte combien ?

— (autre silence) Falcon a une roadmap. On adresse ça au prochain sprint.

— Vous avez une date de release sur ce sujet ?

— Falcon est un actif stratégique. Ce n'est pas comparable à une solution du marché. Vous ne pouvez pas comprendre la complexité de ce qu'on a construit.

— Absolument. C'est pour ça qu'on vous pose ces questions.

Falcon, c'est le Minitel de l'architecture interne. Tout le monde sait que c'est dépassé mais personne ne le dit à voix haute parce que quelqu'un dans la pièce a passé presque deux ans de sa vie à le construire et porte encore le t-shirt du hackathon où l'idée est née.

Comment construire une power map : les bases pour commencer !

La première règle est aussi la plus contre-intutitive : commencer le plus tôt possible. La tentation est de construire la power map quand le deal se complique un peu, quand ça n'avance plus et quand les signaux sont confus. C'est trop tard, et c'est dommage, parce qu'à ce stade on est sur une logique de rattrapage plutôt qu'une logique d'anticipation.

Dès le premier call, tu as déjà des informations ! Qui a été convié à la réunion et qui n'a pas été invité mais dont le nom est mentionné ? Comment les participants se parlent entre eux ? Qui prend la parole librement ? Qui attend une validation implicite avant de s'exprimer ? Bref, ce que les questions posées révèlent sur les préoccupations réelles de chaque interlocuteur.

La power map est un document vivant : elle s'enrichit à chaque information glanée dans une conversation informelle ou non. Ce n'est pas un exercice qu'on fait une fois en début de cycle et qu'on range dans un coin, c'est une cartographie qu'on met à jour en permanence, parce que les dynamiques politiques d'une organisation évoluent, et parfois très rapidement.

Pour les comptes Enterprise avec de nombreuses parties prenantes, la représentation en mind map est particulièrement efficace (c'est ce que je fais le plus souvent). Elle permet de visualiser les relations et les influences d'un coup d'œil, de repérer les zones d'ombre (les acteurs qu'on n'a pas encore cartographiés) et d'identifier les connexions entre personnes qui ne sont pas visibles sur un organigramme classique.

Les questions à se poser systématiquement à chaque nouvelle interaction : qui prend vraiment les décisions sur ce type de projet dans cette organisation ? Qui a intérêt à ce que ça avance et qui a intérêt à ce que ça ne débouche sur rien ? Qui n'est pas encore invité et qui devrait pourtant l'être ? Qui influence notre champion potentiel sans que nous le voyions ?

AE et SE : un exercice conjoint (mais porté par l'AE)

La power map n'est ni un outil SE ni un outil AE : c'est un outil commercial qui appartient au duo... et cette nuance a son importance.

L'AE gère la relation commerciale globale : il a la vision la plus complète des dynamiques politiques du compte, des conversations en coulisses, des signaux faibles. C'est lui qui doit porter la power map, la maintenir, et en faire le fil directeur de la stratégie de deal.

Le SE, lui, apporte une lecture complémentaire et souvent très différente. Il interagit avec des profils techniques et fonctionnels que l'AE ne voit pas toujours en profondeur : les architectes, les équipes IT, les utilisateurs métiers. Il capte des signaux que la relation commerciale classique ne capte jamais : qui pose les vraies questions techniques, qui freine sur des aspects d'intégration qui n'ont rien de technique, qui s'enthousiasme pour des raisons qui vont bizarrement au-delà du besoin exprimé.

Cette complémentarité est précieuse, à condition qu'elle soit formalisée et partagée. La power map doit être un document commun, revu ensemble à chaque étape clé, et pas un exercice que chacun fait dans son coin en espérant que l'autre a capté plus ou moins les mêmes choses.

Dans ma pratique, c'est souvent quand un deal n'avance plus que les AEs comprennent vraiment la valeur de cet exercice. Quand on ouvre la power map ensemble et qu'on réalise qu'il y a trois acteurs clés qu'on n'a jamais vraiment analysés, là, la conversation change.

Ce que tu peux faire dès maintenant :

1. Commence ta power map dès le premier call, même très incomplète à ce stade. Une carte avec trois noms et deux relations identifiées vaut mieux que pas de carte du tout. Elle s'enrichira. Ce qui ne s'enrichit jamais par contre, c'est ce qu'on n'a jamais commencé.
2. Ne prends jamais pour acquis ce qu'un interlocuteur dit de son propre pouvoir. Le CTO qui se présente comme décideur l'est peut-être. Peut-être pas. Ton job est de le vérifier, pas de le contester frontalement, mais de poser les questions qui te permettront de comprendre où se prend vraiment la décision.
3. Identifie ton détracteur potentiel avant qu'il s'active et décide d'une stratégie. L'adresser directement, l'intégrer au projet, le contourner en construisant une coalition suffisamment forte autour de lui... les options existent. Ce qui n'est pas une option, c'est de l'ignorer en espérant qu'il ne sera pas impactant.
4. Fais de la power map un document partagé et vivant avec ton AE. Revoyez-la ensemble à chaque étape clé du cycle de vente, comme un rituel.

Un deal Enterprise sans power map n'est pas un deal qu'on drive : c'est un deal qu'on subit ! On répond aux sollicitations, on gère les objections au fil de l'eau, on espère que la relation construite avec notre interlocuteur principal sera suffisante pour emporter la décision. Parfois ça marche, mais souvent, ça ne marche pas du tout.

La politique interne d'une organisation prospect n'est pas un obstacle à contourner : c'est le terrain réel sur lequel se gagne ou se perd une opportunité. Il est essentiel de la cartographier précisément, de la comprendre en profondeur, et de construire une stratégie qui tient compte de ses dynamiques.

Et toi… tu as déjà perdu un deal en découvrant trop tard que tu parlais à la mauvaise personne depuis le début ?

SolutionScience arrive dans ta boîte chaque vendredi ! Si tu n'es pas encore abonné, c'est le moment. Et si tu connais un AE qui pense encore que l'organigramme suffit à comprendre qui décide : envoie-lui ce numéro. Tu lui rendras service avant qu'il l'apprenne à ses dépens.

À vendredi prochain.

Philippe