Caugia, c’est Tom Meijer, opérateur GTM fractionnel pour le SaaS B2B. Une mission fait ce que décrit cet article : les premières semaines servent à lire la motion avec votre équipe sur les quatre dimensions structurelles, où le revenu se fait et se perd, ce qui manque, ce qui est cassé. Ensuite le plan, avec des responsables, que Tom mène avec vous. Caugia est une pratique d’opérateur, pas un logiciel.
Dans cet article
Pourquoi les playbooks cassent à l’échelle. Tactiques vs architecture. Les trois phases de maturité GTM. Comment évaluer votre architecture de revenu sur quatre dimensions structurelles. Et la séquence de contraintes qui détermine ce qu’il faut corriger en premier.
Pourquoi les playbooks GTM cassent à l’échelle
Chaque SaaS B2B qui marche passe par la même transition. Au début, le fondateur vend. L’ICP est évident parce qu’il parle aux prospects tous les jours. Le pricing est flexible, chaque deal est négocié à la main. La « stratégie », c’est ce qui marche cette semaine.
Puis la boîte grandit. Le fondateur recrute des commerciaux. Le marketing commence à générer des leads. Le Customer Success devient une fonction, plus un projet secondaire. Et quelque chose casse sans bruit : le système qui marchait sur l’intuition du fondateur ne marche plus en exécution organisationnelle.
Réponse classique : on écrit un playbook. On codifie ce que le fondateur faisait. On forme l’équipe. On standardise le processus. Et ça marche, un temps. Jusqu’au moment où ça ne marche plus.
Les playbooks cassent à l’échelle parce qu’ils encodent des tactiques, pas de l’architecture. Ils décrivent ce qu’il faut faire dans un contexte précis, mais pas comment le système fonctionne dans son ensemble. Quand le marché bouge, que le produit évolue, que l’équipe double, le playbook devient une contrainte au lieu d’un levier.
L’alternative : évaluer le système GTM de façon structurelle. Pas par fonction (marketing, sales, CS), mais par dimension : la direction est-elle claire, les ressources sont-elles suffisantes, l’exécution est-elle cohérente, les résultats se cumulent-ils. Ces quatre dimensions forment la base du framework GRIP (Guidance, Resources, Implementation, Performance), exploré plus loin dans cet article et en profondeur dans le sien.
Des tactiques à l’architecture
Passer de la croissance fondateur à la croissance système, c’est changer de mode de pensée. Pas « qu’est-ce qu’on fait ensuite », mais « comment fonctionne vraiment notre système de revenu ».
L’architecture de revenu, c’est la conception structurelle par laquelle une boîte convertit l’opportunité de marché en revenu récurrent. Elle couvre stratégie, ressources, exécution et résultats. Ce n’est pas un département. Ce n’est pas un outil. C’est le système lui-même.
Quand vous pensez en architecte, vous arrêtez de demander « pourquoi le pipeline baisse » et vous commencez à demander « quelle contrainte structurelle étouffe le pipeline ». La différence, c’est la profondeur diagnostique. La première question mène à une tactique (lancer plus de campagnes). La seconde mène à une cause profonde (votre ICP n’est pas validé, donc la demand gen cible le mauvais segment, donc la qualité du pipeline est faible, donc la conversion décroche, donc il vous faut plus de pipeline pour atteindre le même chiffre).
Les trois phases de maturité GTM
Phase 1 : fondateur. Le revenu dépend d’une ou deux personnes qui comprennent le marché d’instinct. Pas de système parce que pas besoin. La contrainte, c’est la capacité, pas la compétence.
Phase 2 : équipe. Le revenu dépend d’une équipe qui exécute un playbook. L’intuition du fondateur est codifiée en processus. Ça tient jusqu’à ce que le marché évolue ou que l’équipe grandisse au-delà de ce que le playbook couvre. La contrainte passe de la capacité à la cohérence.
Phase 3 : système. Le revenu dépend d’une architecture qui produit des résultats cohérents indépendamment de la performance individuelle. Le système est observable, mesurable, adaptable. La contrainte n’est plus les personnes ou les process. Elle est structurelle : quelle partie de l’architecture plafonne l’ensemble.
La plupart des boîtes sont coincées entre la Phase 2 et la Phase 3. Elles ont des équipes et des playbooks, mais pas de visibilité architecturale. Elles ne peuvent pas répondre à la question : où le système est-il structurellement contraint ?
Évaluer votre architecture GTM
Une architecture GTM s’évalue sur quatre dimensions. Pas des domaines fonctionnels (marketing, sales, CS). Des couches structurelles dont chaque système de revenu dépend, quel que soit l’organigramme.
Guidance : la direction est-elle claire ? L’équipe sait-elle qui cibler, comment positionner, quoi prioriser ? Guidance faible : chaque fonction optimise un objectif différent.
Resources : le système est-il équipé ? L’équipe a-t-elle le bon pricing, les bonnes capacités produit, les bonnes compétences ? Resources insuffisant : l’exécution plafonne, l’effort ne franchit pas le plafond.
Implementation : l’exécution est-elle cohérente ? Les deals avancent-ils de façon prévisible ? Le pipeline arrive-t-il de façon fiable ? Implementation faible : la boîte a une stratégie mais ne la convertit pas en revenu.
Performance : les résultats se cumulent-ils ? Le revenu est-il retenu ? Les données sont-elles fiables ? Performance faible : la boîte génère du revenu mais ne le garde pas.
Ce modèle à quatre dimensions, c’est le framework GRIP. Les quatre dimensions se déclinent en douze domaines : Guidance (stratégie GTM et leadership, intelligence marché, product marketing), Resources (pricing et packaging, product readiness, enablement), Implementation (génération de demande, exécution commerciale, revenue operations et systèmes), Performance (customer success et expansion, données et insights, alignement et gouvernance). C’est la grille de lecture avec laquelle Tom lit une motion dans les premières semaines d’une mission, pas un logiciel, et elle pointe rarement une seule chose : le plus souvent, il y a quelque chose à construire.
Deux exemples en pratique. Une boîte avec une demand gen forte mais un Guidance faible verra le pipeline grossir sans que le revenu suive : le pipeline vise le mauvais segment, la conversion reste basse, peu importe le volume. Une boîte avec une Implementation forte mais une Performance faible conclura les deals efficacement puis perdra des clients derrière : le produit a été bien vendu, mais rétention et expansion n’ont jamais été architecturées.
La séquence de contraintes
Une fois que vous voyez le déséquilibre architectural, question suivante : qu’est-ce que vous corrigez en premier ?
La réponse, ce n’est pas « tout corriger ». Ce n’est pas « corriger le domaine le plus faible ». C’est : corriger la contrainte qui, une fois résolue, débloque la plus grande amélioration en aval.
C’est la séquence de contraintes : l’ordre dans lequel il faut appliquer les interventions pour produire l’amélioration système maximale avec l’investissement minimum.
Exemple. Guidance solide, Implementation faible : tentation d’investir dans l’exécution commerciale. Mais si l’écart d’Implementation vient d’un déficit d’Enablement (les commerciaux n’ont pas les compétences pour exécuter la stratégie), la bonne première intervention est dans Resources, pas dans Implementation.
Se tromper de séquence ne coûte pas juste de l’argent. Ça aggrave le problème. Un investissement dans la mauvaise couche crée l’illusion de progrès pendant que la vraie contrainte s’approfondit.
Du framework à l’action
Un framework sans action, c’est un exercice intellectuel. Comment l’appliquer opérationnellement :
Étape 1 : cartographier votre architecture actuelle
Pour chaque dimension, posez-vous la question : quelle est la solidité de cette couche chez nous ? Pas « on a une stratégie », mais « l’équipe exécute contre une stratégie partagée avec des priorités claires et des résultats mesurables ». Soyez honnête sur les écarts. La lecture ne vaut que ce que valent les entrées.
Étape 2 : isoler ce qui bride la croissance
Quelle dimension est structurellement la plus faible ? Pas la fonction la plus bruyante, la couche qui, renforcée, débloquerait le plus d’amélioration dans tout le système.
Étape 3 : tracer la propagation
Comment la contrainte se propage ? Une contrainte dans Resources (pricing déséquilibré) peut se manifester en problème commercial (discounting pour gagner les deals) qui remonte en problème Performance (NRR faible parce que les clients ont acheté le mauvais package). Tracez la chaîne pour confirmer la cause profonde.
Étape 4 : séquencer les interventions
Démarrez par la cause profonde. Définissez la première action. Puis la deuxième, qui s’attaque au premier effet en aval. Construisez une séquence à 90 jours qui résout la chaîne, de l’origine à l’impact.
Ce que ça veut dire pour votre équipe
Si vous êtes CRO ou CEO, l’implication pratique est simple : avant votre prochain investissement de croissance, diagnostiquez le système. N’ajoutez pas de headcount tant que vous ne savez pas si la contrainte est la capacité ou l’architecture. Ne lancez pas un nouveau canal tant que vous ne savez pas si le problème est la demand gen ou le positionnement. Ne réorganisez pas le CS tant que vous ne savez pas si le churn est un problème de rétention ou de product readiness.
La plupart des stratégies GTM échouent non pas parce que les équipes exécutent mal, mais parce qu’elles interviennent sur la mauvaise partie du système. Les boîtes qui grandissent efficacement sont celles qui diagnostiquent l’architecture avant d’investir dans l’intervention.
Questions fréquentes
Qu’est-ce qu’un framework de stratégie GTM ?
Un modèle structuré pour évaluer comment un SaaS B2B convertit l’opportunité de marché en revenu. Il dépasse les playbooks tactiques pour évaluer les couches structurelles qui déterminent si la croissance monte en charge ou stagne.
Pourquoi les playbooks GTM cassent à l’échelle ?
Les playbooks encodent des tactiques, pas de l’architecture. Ils disent quoi faire dans un contexte précis, pas comment le système fonctionne dans son ensemble. Quand le marché bouge, que le produit évolue ou que l’équipe double, le playbook devient une contrainte au lieu d’un levier.
Quelle est la différence entre croissance fondateur et croissance système ?
En croissance fondateur, le revenu dépend des relations personnelles et de l’intuition du fondateur. En croissance système, le revenu dépend d’une architecture qui produit des résultats cohérents indépendamment de la performance individuelle. La plupart des boîtes restent coincées entre les deux.
Qu’est-ce qu’une séquence de contraintes en GTM ?
L’ordre dans lequel il faut appliquer les interventions pour produire l’amélioration système maximale avec l’investissement minimum. Se tromper de séquence gaspille de l’argent et aggrave le problème : ça crée l’illusion de progrès pendant que la vraie contrainte s’approfondit.
Comment évaluer mon architecture GTM ?
Sur quatre dimensions structurelles : Guidance (direction claire ?), Resources (système équipé ?), Implementation (exécution cohérente ?), Performance (résultats qui se cumulent ?). Le framework GRIP offre une méthode structurée pour cette évaluation.
Trouvez ce qui bride la croissance dans votre architecture GTM
Les premières semaines d’une mission servent à lire la motion avec votre équipe sur les quatre dimensions : où le revenu se fait et se perd, ce qui manque, ce qui est cassé. Ensuite le plan, avec des responsables, que Tom mène avec vous. Commencez par une conversation.
