Quand une boîte passe d'à peu près zéro revenu pendant 5 ans à 100 M$ ARR en moins de 3 ans, ce n'est pas le produit seul qui explique l'accélération. C'est ce qu'ils ont mis autour. Et chez Clay, ce qu'ils ont mis autour s'appelle l'équipe de GTM Engineering. Un nom qu'ils ont en partie inventé. Un rôle dont les offres d'emploi ont bondi de plus de 5 000 % en un an. Un modèle organisationnel à deux équipes qui n'existe presque nulle part ailleurs.
Cet article décortique précisément ce modèle. Pas la fiche métier générique, pour ça il y a le guide complet sur le rôle de GTM Engineer. Ici on regarde Clay sous le capot : la trajectoire produit, la définition opérationnelle du rôle vue de l'intérieur, les deux équipes qui se renvoient la balle, et ce qui rend le système reproductible (ou pas) chez vous.
Si vous dirigez une boîte B2B, si vous structurez une équipe revenue, ou si vous êtes vous-même en train de réfléchir à devenir GTM Engineer, vous allez repartir avec un framework actionnable.
De zéro à 5 milliards de valorisation : la trajectoire Clay
Avant de comprendre pourquoi le rôle existe chez Clay, il faut comprendre comment la boîte est arrivée là. Parce que le rôle n'est pas tombé du ciel. Il est sorti d'une frustration très précise : un produit complexe à expliquer, des prospects techniques, et l'impossibilité de vendre comme une boîte SaaS classique.
Les cinq années plates (2017 à 2022)
Clay est fondée en 2017. Pendant les cinq premières années, à peu près rien. Quelques utilisateurs, des essais produit, pas de courbe de revenu qui décolle. Beaucoup de boîtes meurent à ce stade. Clay survit parce que les fondateurs continuent d'itérer sur une intuition simple : et si une feuille de calcul pouvait extraire des données de n'importe où sur Internet ?
Pas un CRM. Pas un outil de prospection clé en main. Une feuille de calcul augmentée, qui agrège des sources de données et permet de construire ses propres workflows commerciaux.
L'idée ne décolle pas tout de suite. Le marché ne sait pas encore quoi en faire.
Le pivot Product Hunt et la découverte du vrai utilisateur (février 2022)
Février 2022. Clay lance le produit sur Product Hunt. Et là, surprise : ce ne sont pas les marketers traditionnels qui adoptent l'outil. Ce sont des profils techniques débrouillards, capables de connecter trois APIs, d'écrire du JSON, de manipuler des données. Des gens qui voient dans Clay autre chose qu'un outil : un terrain de jeu pour automatiser tout le travail commercial qu'ils faisaient à la main.
Cette observation change tout. L'équipe arrête de chercher à plaire aux directeurs marketing et commence à parler à ces utilisateurs power. Ce sont eux qui vont définir la roadmap. Ce sont eux qui vont devenir, sans le savoir encore, les premiers GTM Engineers.
Le déclic AI et le premier million (fin 2022 à mars 2023)
Fin 2022, l'arrivée des LLMs grand public booste tout. Désormais, Clay ne sert plus seulement à trouver les bonnes personnes. L'outil peut aussi générer automatiquement des messages personnalisés à grande échelle. Le pitch produit devient brutal d'efficacité : trouver, qualifier, contacter, le tout dans une seule interface, en quelques heures au lieu de plusieurs semaines de travail manuel.
Mars 2023, un client change la donne. Une scale-up américaine signe un contrat significatif. Clay dépasse le million de dollars d'ARR. La courbe commence à décoller pour de bon.
Le passage enterprise et l'invention du rôle (2024 à 2025)
2024 arrive avec un nouveau problème. Les startups adorent Clay. Les grandes entreprises, beaucoup moins. Pas parce que le produit ne leur conviendrait pas, mais parce qu'elles ont besoin d'être accompagnées. Le produit est trop puissant et trop ouvert pour être adopté seul par une équipe enterprise.
C'est là que les fondateurs prennent une décision contre-intuitive : pas de sales traditionnels. Le produit est trop complexe, trop technique, trop spécifique à chaque cas d'usage. Au lieu de recruter des account executives qui auraient appris Clay, ils font l'inverse. Ils recrutent des utilisateurs avancés de Clay, déjà actifs dans la communauté, et leur demandent de vendre.
Un de ces premiers recrutés finit par poser la question explicite : "Est-ce que je suis un sales ?" Réponse du fondateur : "Non. Tu fais du GTM Engineering."
Le nom est posé. L'équipe a une identité. Fin 2024, Clay signe Figma, OpenAI, AWS. En 2025, la barre des 100 M$ d'ARR est franchie. Aujourd'hui, plus de 16 000 clients, dont des centaines d'équipes enterprise, et une valorisation à 5 milliards de dollars.
Vidéo source : 24 heures complètes passées avec l'équipe GTM Engineering de Clay (~45 min, en anglais). Le head of GTM Engineering, plusieurs membres de l'équipe interne et un des co-fondateurs y détaillent le modèle.
La leçon n'est pas que Clay a eu de la chance. La leçon, c'est que la trajectoire produit a forcé un rôle qui n'existait pas, et que ce rôle est devenu le moteur de la croissance enterprise. Sans ce rôle, Clay aurait peut-être plafonné à 20 ou 30 M$. Avec, ils ont passé 100 M$ en moins de 18 mois.
GTM Engineer : la définition opérationnelle (au-delà du buzz)
Le mot "GTM Engineer" est partout sur LinkedIn depuis 18 mois. Ça en fait un terme flou, utilisé pour décrire à peu près n'importe quel profil un peu technique dans une équipe revenue. Ce n'est pas ça. Ce n'est pas un growth marketer qui sait coder, ni un RevOps un peu débrouillard. C'est un rôle distinct avec des missions précises.
Ce que fait vraiment un GTM Engineer au quotidien
Au lieu d'écrire du code qui finit dans une application, un GTM Engineer écrit des systèmes qui finissent dans une pipeline de revenu. Concrètement, le quotidien d'un bon GTME ressemble à ça :
- Construction de pipeline ops : workflows qui scannent en continu les bases de données publiques, les signaux d'intent (visites site, levées de fonds, embauches, technologies détectées) et matchent avec l'ICP de la boîte
- Modélisation de l'ICP : transformer une intuition commerciale en règles automatisables ("entreprise B2B SaaS, 50 à 500 employés, qui vient d'embaucher un VP Sales et qui utilise HubSpot")
- Génération automatique de messages : briefs structurés, templates avec variables dynamiques, génération via LLM avec garde-fous, scoring de qualité
- Suivi automatisé multi-canal : séquences email + LinkedIn + appels qui s'adaptent au comportement du prospect
- Reporting opérationnel : tableaux de bord en temps réel sur les conversions, les goulots d'étranglement, les sources qui marchent
Chaque tâche prise isolément pourrait être faite par un growth, un RevOps ou un AE technique. Ce qui distingue le GTM Engineer, c'est l'angle système. Il ne fait pas une campagne. Il construit l'infrastructure qui permet à 50 campagnes de tourner en parallèle sans intervention.
L'analogie des cornichons (la pédagogie qui marque)
Pour expliquer le rôle simplement, un des GTM Engineers de Clay utilise une analogie qui colle à la mémoire. Imaginez que vous fabriquez des cornichons à New York et que vous voulez les vendre aux épiceries fines de la ville.
Étape une : lister toutes les épiceries de New York. Vous ne pouvez pas vendre à des gens dont vous ignorez l'existence.
Étape deux : identifier qui achète déjà des cornichons, qui n'en achète pas, et de quelle marque. Cette donnée transforme la liste brute en cible qualifiée.
Étape trois : pour chaque épicerie, trouver le décideur. Le propriétaire, le gérant, l'acheteur. Pas le vendeur en caisse.
Étape quatre : envoyer le bon message au bon décideur, au bon moment. Pas un email générique copié-collé.
Étape cinq : suivre, relancer, mesurer ce qui marche, ajuster.
Faire ça à la main pour 200 épiceries, c'est faisable. Pour 10 000 entreprises B2B partout dans un pays, ça ne tient pas. Le GTM Engineer construit la machine qui fait les cinq étapes en automatique, à grande échelle, et qui s'améliore en boucle.
GTM Engineer vs RevOps vs Sales : la matrice qui clarifie
Ces trois rôles travaillent côte à côte et leurs périmètres se chevauchent. Mais leurs outputs principaux sont différents.
| Critère | GTM Engineer | RevOps | Sales / AE |
|---|---|---|---|
| Output principal | Systèmes automatisés de prospection et qualification | Process, data hygiene, alignement des équipes | Deals signés |
| Outils centraux | Clay, n8n, Make, APIs, LLMs | CRM (HubSpot, Salesforce), BI, dashboards | CRM, outils de vente, calls |
| Compétences clés | Logique workflow, JSON, SQL léger, prompt engineering | Process design, analytics, change management | Discovery, négociation, closing |
| Horizon | Construction long terme, infrastructure | Optimisation continue, gouvernance | Court terme, par deal |
| Métrique principale | Pipeline généré, qualité de la donnée | Vélocité du pipeline, attribution propre | Revenu signé |
| Profil typique | Ex-growth, ex-engineer, ex-product ops | Ex-consulting, ex-finance, ex-sales | Background commercial pur |
Là où ça devient intéressant, c'est que dans une boîte mature, les trois rôles existent et se complètent. Le GTME alimente le pipeline, le RevOps garantit la propreté de la donnée et l'alignement, le Sales conclut. Dans une boîte early-stage, un même profil peut tenir les trois casquettes en partie. C'est typiquement ce que je fais en Fractional GTM Engineer freelance.
Pourquoi pas juste l'appeler "salesperson" ou "growth" ?
C'est la question que tout le monde pose, et la réponse vient d'un GTM Engineer de Clay : "Je suis ingénieur d'abord. Sales, c'est dégoûtant." Provocation à part, le fond est sérieux.
Le mot "sales" porte un héritage. Cold calling agressif, scripts identiques, métriques de volume, transactions ponctuelles. Le mot "growth" porte aussi son lot d'images : hacks, tools, expérimentations marketing à courte vue. Aucun des deux ne décrit ce que fait un GTM Engineer.
Le rôle existe précisément parce qu'il fallait un nom neuf pour un travail neuf. Construire l'infrastructure qui rend le revenue prévisible, à grande échelle, sans armée de commerciaux. Un travail qui ressemble plus à de l'engineering qu'à du sales, même si le résultat final est commercial.
Le modèle à 2 équipes de Clay (la vraie innovation)
Voilà ce qui rend Clay unique, et ce que la plupart des articles sur le sujet manquent. Ce n'est pas le rôle de GTM Engineer en soi qui a fait passer la boîte à 5 milliards. C'est leur découpage organisationnel à deux équipes, qui se renvoient l'apprentissage en boucle.
L'équipe in-house : revenue engineering interne
Première équipe, celle qui ressemble le plus à ce qu'on imagine quand on parle de "GTM Engineering". Une dizaine de personnes basées au siège, dont la mission est de construire le moteur de revenue de Clay lui-même.
Concrètement, ils font tourner des systèmes qui :
- Scannent en continu les comptes B2B mondiaux pour identifier ceux qui matchent l'ICP de Clay
- Détectent les signaux d'intent (recherches sur des termes liés à la prospection, embauche d'un GTM Engineer, levée de fonds, changement de stack outbound)
- Enrichissent les données avec des sources publiques et propriétaires
- Génèrent automatiquement des séquences de messages personnalisés
- Qualifient les leads en temps réel et les routent vers la bonne équipe sales
Ce n'est pas du marketing. Ce n'est pas du RevOps. C'est de l'engineering appliqué au revenue. Les outputs ne sont pas des présentations PowerPoint, ce sont des workflows qui tournent 24/7, des dashboards qui décident, des règles qui priorisent automatiquement.
Sans cette équipe, Clay aurait besoin de cinq fois plus de SDRs et de marketers pour générer le même pipeline. C'est un effet de levier brut.
L'équipe forward-deployed : consultant + builder chez le client
Deuxième équipe, et c'est là que ça devient rare. Le forward-deployed GTME est l'invention vraiment singulière de Clay. Le concept est emprunté à des boîtes comme Palantir, qui déploient des engineers directement chez leurs clients pour résoudre des problèmes complexes sur le terrain. Clay l'applique à la vente.
Quand un prospect enterprise sérieux arrive (Figma, OpenAI, AWS), il n'est pas pris en charge par un account executive classique. Il est pris en charge par un GTM Engineer forward-deployed. Le déroulé ressemble à ça :
- Discovery technique : compréhension fine du stack actuel, des équipes en place, des cas d'usage prioritaires, des goulots d'étranglement précis
- Identification de la cause racine : ce n'est pas "vous avez besoin de Clay", c'est "voici précisément où votre process actuel casse, et voici comment Clay reconstruit cette partie"
- Démo sur-mesure construite en direct : pas une démo de produit générique, un workflow concret construit avec un échantillon de leurs vraies données
- Plan d'implémentation cadré : par cas d'usage, avec une roadmap d'expansion ABM, outbound, inbound, expansion CRM
- Closing technique : la signature passe par la conviction que le système marche, pas par un script de négociation
Ce profil est payé en partie sur les deals signés, mais surtout évalué sur la qualité technique de l'implémentation. Un forward-deployed GTME qui ferait un mauvais cadrage de démo mais signerait un gros contrat n'est pas considéré comme performant. À l'inverse, un cadrage solide qui débouche sur une expansion à six chiffres l'année suivante vaut bien plus que la signature initiale.
Le flywheel qui les connecte
Ce qui rend le modèle puissant, c'est que les deux équipes ne sont pas isolées. Elles forment un flywheel d'apprentissage permanent.
L'équipe in-house génère et qualifie les leads. Quand un lead atteint un seuil de qualification, il bascule vers l'équipe forward-deployed, qui prend le relais. L'équipe forward-deployed signe, déploie, et surtout apprend. Apprend ce que les vrais clients font avec Clay, quels cas d'usage marchent, quelles intégrations posent problème, quels nouveaux signaux d'intent émergent.
Tous ces apprentissages remontent vers l'équipe in-house, qui les transforme en nouveaux workflows internes, en nouveaux signaux à scanner, en nouveaux templates de messages. Le pipeline généré devient meilleur. La qualification devient plus précise. Les forward-deployed reçoivent de meilleurs leads. Les deals deviennent plus gros. Les apprentissages deviennent plus riches.
Voilà comment on passe de 1 M$ ARR à 100 M$ ARR en moins de deux ans. Pas par la magie. Par un flywheel d'engineering appliqué au revenue, avec deux équipes qui se nourrissent mutuellement.
| Équipe | Mission | Outputs typiques | Profil dominant |
|---|---|---|---|
| In-house | Revenue engineering interne | Pipeline ops, intent signals, génération de messages, qualification automatisée, reporting | Engineering-leaning, infrastructure |
| Forward-deployed | Consultant + builder chez le client enterprise | Discovery technique, démo sur-mesure, construction client, closing technique, retour terrain | Client-facing, démo, présentation |
Le flywheel : l'in-house qualifie les leads, les passe au forward-deployed, qui close puis apprend, et réinjecte les apprentissages dans l'in-house. Sans ce flywheel, le modèle perd 80 % de sa valeur.
Pourquoi ce modèle marche (et pourquoi la plupart des boîtes le rateraient)
Le modèle Clay est élégant, mais il n'est pas reproductible n'importe où. Trois conditions le rendent viable. Si vous en manquez une, ne perdez pas votre temps à le copier tel quel.
Condition 1 : les vendeurs sont les mêmes profils que les acheteurs
C'est la condition la plus importante, et celle que la plupart des boîtes ratent. Chez Clay, les forward-deployed GTMEs sont littéralement des anciens utilisateurs de Clay. Ils ont construit leurs propres workflows. Ils ont galéré sur les mêmes intégrations. Ils ont les mêmes réflexes que leurs prospects.
Quand un prospect enterprise dit "j'ai un problème de matching d'identité multi-source", le forward-deployed ne lit pas un wiki interne pour comprendre. Il a vécu le problème. Il sait quelle est la solution exacte dans Clay. Il peut la construire en direct dans la démo.
Cette superposition vendeur-acheteur crée une confiance instantanée et un cycle de vente raccourci. Aucun script ne peut produire le même effet.
Condition 2 : un produit où la complexité justifie un consultant-builder
Le modèle forward-deployed est cher. Plus cher qu'un AE classique. Plus long à former. Plus exigeant à recruter. Ça ne se justifie que si le produit est suffisamment complexe pour que le client ait besoin d'être accompagné dès l'avant-vente.
Clay coche la case. C'est un outil quasi infiniment configurable, qui permet de construire des centaines de cas d'usage différents. Sans accompagnement, un prospect enterprise voit une coquille vide et se décourage. Avec un forward-deployed qui construit un cas d'usage en direct, il voit le ROI dans la première heure.
Si votre produit est plug-and-play, ce modèle est un gaspillage. Vous n'avez pas besoin de consultants-builders, vous avez besoin d'AEs qui scalent.
Condition 3 : une culture d'engineering au cœur de la GTM
Troisième condition, plus culturelle. Le modèle Clay marche parce que le management considère le revenue comme un problème d'engineering. Pas comme une boîte noire qu'on confie aux sales. Pas comme une responsabilité diluée entre marketing et commerciaux.
C'est une équipe avec des objectifs précis, des outputs mesurables, une roadmap, des reviews techniques, des post-mortems quand un workflow casse. Comme une équipe produit, mais pour le revenue.
Si votre direction commerciale est encore dans le mindset "on a recruté trois SDRs et on attend de voir", le modèle Clay ne s'implantera pas. Vous installerez les outils, vous embaucherez quelqu'un avec le titre, mais le système ne fonctionnera pas.
Le modèle Clay n'est pas un template à copier. C'est une conséquence d'une vision où le revenue est un système qu'on construit, pas une activité qu'on délègue. Sans ce préalable, les deux équipes ne se forment pas.
Le routing par appétence : engineering-leaning vs client-facing
Petit détail important pour ceux qui structurent l'équipe. Chez Clay, le recrutement ne distingue pas les deux équipes en amont. Les deux équipes recrutent les mêmes profils techniques. Le routage se fait en interne, après quelques mois, en fonction de l'appétence personnelle.
Les profils plus introvertis, plus orientés infrastructure, plus à l'aise avec les data pipelines vont vers l'équipe in-house. Les profils plus à l'aise en démo, en discovery client, en présentation, basculent vers le forward-deployed. Mêmes compétences techniques de base, exposition différente.
Cette flexibilité de routing est précieuse. Elle permet aussi de faire bouger les gens entre les deux équipes au fil du temps, ce qui renforce le flywheel d'apprentissage.
3 systèmes que les GTM Engineers Clay construisent vraiment
Pour rendre le rôle concret, voici trois exemples de systèmes que les GTM Engineers de Clay font tourner. Ce sont des compositions assez classiques, mais leur exécution à grande échelle est ce qui fait la différence.
Système 1 : pipeline ops avec intent signals multi-sources
L'idée est simple, l'implémentation est exigeante. Au lieu d'attendre qu'un prospect remplisse un formulaire ou demande une démo, le système scanne en permanence des signaux qui indiquent que la boîte est probablement en marché.
Sources de signaux typiques :
- Embauche récente d'un poste lié au use case (ex : embauche d'un Head of Sales ou d'un GTM Engineer)
- Levée de fonds récente avec montant
- Lancement d'un nouveau produit
- Apparition dans une stack technologique cible (détection de tags sur le site web)
- Pic d'activité sur le site web Clay (visite de pages produit ou pricing)
- Mention dans un podcast ou une newsletter sectorielle
- Recherches de mots-clés liés au use case (via outils SEO inverse)
Chaque signal est pondéré. Un compte qui cumule trois signaux devient une priorité absolue et est routé immédiatement vers un forward-deployed. Un compte avec un seul signal entre dans une séquence de nurturing automatisée.
Ce n'est pas de la magie. C'est de l'orchestration patiente entre une dizaine d'API publiques et propriétaires, avec des règles métier précises et un scoring dynamique.
Système 2 : génération de messages personnalisés à grande échelle
Deuxième système, celui qui a explosé avec l'arrivée des LLMs. L'objectif : envoyer 1 000 messages dans une semaine, dont chacun donne l'impression d'avoir été écrit individuellement.
La recette type :
- Pour chaque prospect, agréger 8 à 12 points de contexte (entreprise, secteur, taille, stack, actualité récente, parcours du contact, contenu publié, signaux d'intent détectés)
- Construire un prompt structuré qui combine ces points avec un template de message ayant fait ses preuves
- Générer le message via LLM avec des garde-fous (longueur, ton, structure, mention obligatoire ou interdite)
- Scorer la qualité du message généré (cohérence, personnalisation perçue, absence de hallucination)
- Envoyer uniquement les messages qui passent le score, router le reste vers une revue humaine
Un GTM Engineer qui maîtrise ce système peut produire en une heure ce qu'un SDR junior met une semaine à faire à la main, avec une qualité comparable ou supérieure.
Système 3 : le système "dîner du fondateur" (cas concret)
Voici un exemple précis, directement inspiré de ce que l'équipe Clay fait pour ses propres événements. Le scénario : le CEO se déplace à San Francisco. On veut organiser un dîner avec 20 personnes choisies pour maximiser l'impact business.
Construire ça à la main prend deux semaines. Avec un système Clay, ça se fait en deux heures. Voici les quatre étapes du workflow type.
Étape 1 — Sourcing. Construction d'une table dynamique avec des filtres multi-critères : ville (SF, Bay Area), seniorité (C-level, VP+), secteur cible, taille d'entreprise, signal d'intérêt récent. La table est live, elle se met à jour seule.
Étape 2 — Enrichissement. Pour chaque profil retenu, le système agrège email vérifié, parcours, dernier contenu publié, connexion mutuelle avec le CEO. On ne garde que les profils complets.
Étape 3 — Invitation. Génération d'une invitation personnalisée par profil, avec un hook spécifique (publication, actualité, point commun). Envoi depuis l'adresse email réelle du CEO, jamais en mass mailing.
Étape 4 — Tracking. Réponses captées automatiquement, RSVP enregistrés, relances ciblées sur les non-répondants. Tableau de bord en temps réel pour le CEO et l'équipe événement.
Ce système a deux propriétés clés. Première propriété : il tourne en autonomie une fois construit. La prochaine fois que le CEO va à Austin, on change deux paramètres et le workflow se redéploie. Deuxième propriété : il est dupliquable pour les clients enterprise. Un forward-deployed peut construire le même système chez un client, qui n'a même plus besoin de Clay pour ses événements internes après ça.
C'est exactement ce niveau d'output que produit un GTM Engineer compétent. Pas une campagne. Une infrastructure.
Comment recruter et structurer une équipe GTM Engineering chez vous
Le modèle Clay est inspirant, mais transposable seulement avec discernement. Voici comment l'adapter à une boîte qui n'a pas les ressources de Clay.
Profil à recruter : ni dev pur, ni sales pur
Le piège classique consiste à recruter soit un développeur, soit un sales, en pensant les transformer en GTM Engineer. Les deux options sont mauvaises.
Un développeur pur s'ennuie. Le boulot d'un GTME, c'est 60 % logique métier, 30 % intégration d'outils existants, 10 % scripting léger. Pas de quoi nourrir un profil qui veut faire du backend distribué. Au bout de six mois, il part ou s'éteint.
Un sales pur n'est pas équipé. La courbe d'apprentissage technique est trop raide. Apprendre à manipuler des APIs, du JSON, des workflows conditionnels, des prompts structurés, ça prend un an minimum si la base technique n'est pas déjà là.
Le bon profil est entre les deux. Un growth opérationnel qui a déjà bricolé des automatisations. Un RevOps qui code un peu. Un product manager qui a touché à la donnée. Un consultant ex-tech qui a switché vers le commercial.
| Profil de départ | Avantage | Risque | Adaptation nécessaire |
|---|---|---|---|
| Growth opérationnel | Mindset expérimentation, rapide à prendre les outils | Peut manquer de rigueur système | Formation sur la documentation et les bonnes pratiques |
| RevOps | Excellente compréhension data et CRM | Souvent moins à l'aise avec l'automatisation hors CRM | Apprentissage Clay, n8n, Make |
| Ex-product / data analyst | Logique métier solide, lecture de données | Moins d'exposition au commercial | Coaching sur l'ICP et le pitch |
| Ex-AE technique | Comprend le client, sait pitcher | Peut être trop sales-driven | Discipline sur la construction système |
Premiers signaux d'embauche : à quel stade ça vaut le coup
Inutile de recruter un GTM Engineer trop tôt. Les signaux qui indiquent que c'est le bon moment :
- L'équipe sales atteint 5 à 10 personnes et le pipeline manuel coince
- Le CRM devient un dépotoir parce que personne ne maintient les automatisations existantes
- Les SDRs passent plus de temps à chercher des contacts qu'à les contacter
- Les fondateurs construisent eux-mêmes des workflows Clay le soir parce que l'équipe ne sait pas faire
- L'ARR dépasse 1 à 2 M€ et la croissance plafonne sans raison produit claire
Avant ces signaux, le rôle peut être tenu en partie par un fondateur ou par un growth polyvalent. Ou, plus malin, externalisé en Fractional GTM Engineer le temps de poser l'infrastructure et de transmettre la méthode.
Outils de référence pour démarrer
Pas la peine de réinventer la roue. La stack standard d'un GTME aujourd'hui ressemble à ça :
- Cœur de workflow : Clay pour la prospection, l'enrichissement et l'orchestration
- Automatisation transverse : n8n ou Make pour les connexions hors Clay
- CRM : HubSpot, Salesforce ou Attio selon la taille
- Enrichissement complémentaire : un outil B2B comme Cognism, Apollo ou Pharow (à ce sujet, le comparatif Cognism vs Pharow détaille les différences)
- Email & multicanal : un outil de séquences cold (Smartlead, Lemlist, Instantly)
- Données comportementales : Mixpanel ou Amplitude pour les signaux produit
- LLM API : OpenAI ou Anthropic pour la génération de messages
- Slack : interface principale, alerts en temps réel
Pas la peine d'avoir tout ça dès le premier jour. Clay + n8n + HubSpot + Smartlead + une API LLM, ça suffit pour 80 % des besoins en early-stage.
Les pièges à éviter quand vous montez l'équipe
Le modèle Clay est séduisant. Trop séduisant, parfois. Voici les trois pièges les plus fréquents quand des boîtes essaient de le copier.
Piège 1 : "On prend des sales et on les forme à Clay"
C'est la pire idée. Un sales motivé peut apprendre à utiliser Clay basique en quelques semaines. Construire un système qui tourne en autonomie sur dix sources de données, avec des règles de scoring dynamique et des garde-fous LLM, demande des compétences techniques qui ne s'apprennent pas en formation accélérée. Vous obtiendrez un sales qui sait cliquer sur quelques boutons, pas un GTM Engineer.
Piège 2 : Le sous-investissement infrastructure
Embaucher un GTME et lui demander de produire des résultats sales sans lui donner le temps de poser une infrastructure propre, c'est garantir l'échec. Un vrai GTME passe ses trois premiers mois à construire des fondations : data clean, intégrations stables, monitoring en place, documentation. Si on lui met la pression sur le pipeline immédiat, il ne pose pas les fondations et le système s'effondre dès la première campagne d'envergure.
Piège 3 : Le forward-deployed sans flywheel retour
Si vous adoptez le modèle à deux équipes mais que les apprentissages des forward-deployed ne remontent jamais à l'équipe in-house, le système ne marche pas. Vous avez juste deux équipes parallèles. Le flywheel d'apprentissage est ce qui fait que le pipeline s'améliore mois après mois. Sans rituels formels (revues hebdomadaires, capture systématique des cas d'usage clients, intégration dans la roadmap), vous perdez 80 % de la valeur du modèle.
Ce que le modèle Clay change pour les freelances et les boîtes B2B
Au-delà de Clay elle-même, l'émergence du rôle de GTM Engineer redessine la manière dont les boîtes B2B construisent leur revenue. Et ouvre des opportunités précises pour ceux qui veulent se positionner.
L'opportunité freelance forward-deployed
Le modèle forward-deployed se prête remarquablement bien à une exécution en freelance ou en fractional. Une boîte en early-stage n'a pas besoin d'un GTME à temps plein pendant 18 mois. Elle a besoin de quelqu'un qui pose l'infrastructure, transmet la méthode, et reste en support pendant que l'équipe interne grandit.
C'est exactement le format que je propose en Fractional GTM Engineer. Trois à six mois sur place, à temps partagé, pour construire les fondations puis transmettre. Au bout du parcours, la boîte a son équipe interne autonome et un système qui tourne. Le coût est divisé par trois ou quatre par rapport à un recrutement plein temps qui mettrait six mois à atteindre le même niveau.
Pour les freelances qui hésitent à se positionner sur le rôle, le moment est bon. La demande explose, l'offre qualifiée reste limitée, et le modèle Clay sert de référence partagée pour expliquer le métier en deux minutes.
Pourquoi les agences traditionnelles ne suffisent plus
Les agences de growth marketing classiques savent faire des campagnes. Elles ne savent pas construire des systèmes. La différence est radicale.
Une campagne tourne pendant trois mois et s'arrête. Un système tourne en autonomie et s'améliore. Une campagne dépend d'une équipe externe pour fonctionner. Un système est documenté et transmis à l'équipe interne. Une campagne produit des leads. Un système produit du pipeline prévisible et en croissance.
Les boîtes qui découvrent le modèle GTM Engineering ne reviennent pas aux agences classiques. Elles internalisent ou elles travaillent avec des freelances spécialisés. C'est un mouvement de fond qui va continuer à structurer le marché des prochaines années.
Réservez un audit GTM Engineering
Si vous dirigez une boîte B2B et que vous vous demandez si le modèle GTM Engineering peut s'appliquer chez vous, le plus rapide est de regarder votre situation concrète. Pas un audit générique, un diagnostic ciblé sur vos goulots d'étranglement actuels et l'infrastructure manquante.
Audit GTM Engineering offert (45 min) — On regarde ensemble votre stack actuelle, votre pipeline, ce qui coince, et on identifie 2 à 3 systèmes qui pourraient débloquer la croissance dans les 90 prochains jours. Réserver un créneau →