Kareem Amin Explique L’Essor Du Gtm Engineer Chez Clay

Il y a encore deux ans, presque aucune entreprise ne savait nommer le poste. Les équipes commerciales empilaient les onglets, les exports et les relances manuelles, pendant que le marketing cherchait le bon message dans un autre outil. Puis un intitulé est apparu sur les offres d’emploi, d’abord chez quelques startups obsédées par la donnée, ensuite chez des noms que tout le monde cite. Le GTM engineer n’est pas un commercial déguisé en développeur, ni un growth hacker rebaptisé. C’est quelqu’un qui construit des systèmes de revenu plutôt que d’exécuter, une à une, les tâches qui faisaient tenir l’ancien stack. Et c’est précisément ce virage que Kareem Amin, cofondateur et dirigeant de Clay, vient défendre sur la scène IA de TechCrunch Disrupt 2026.

La session porte un titre sans ambiguïté : The GTM Engineer: How AI Created Tech’s Next Big Job Category. Derrière la formule, une question très concrète pour les fondateurs. Faut-il recruter davantage de personnes pour faire tourner le processus actuel, ou construire des systèmes qui permettent aux équipes déjà en place d’opérer autrement ? Clay a forgé le nom du métier en 2023. Depuis, le cabinet affirme voir environ cent annonces mensuelles liées à cette discipline, y compris chez des sociétés comme Cursor, Lovable ou Webflow. Le chiffre, à lui seul, ne prouve pas une révolution. Il indique en revanche qu’un vocabulaire nouveau s’installe dans les organigrammes.

Pourquoi Ce Métier Apparaît Maintenant

Le go-to-market classique ressemble souvent à une chaîne de relais. Quelqu’un recherche le compte. Quelqu’un d’autre nettoie la base. Un troisième qualifie. Un quatrième prépare le message. Un cinquième pousse l’information d’un logiciel vers le suivant. Chaque maillon est justifiable. L’ensemble, lui, coûte du temps, de la cohérence et parfois de la vérité sur le prospect. L’intelligence artificielle n’a pas inventé le besoin de trouver des clients. Elle a rendu possible de transformer une partie de ce travail en enchaînements répétables, à condition que quelqu’un sache les concevoir.

C’est là que le rôle se distingue d’un simple usage d’assistants. Un commercial peut demander à un modèle de réécrire un e-mail. Un ingénieur GTM assemble recherche, enrichissement, règles de qualification et déclenchement de campagne dans un flux que l’équipe peut rejouer. La différence n’est pas cosmétique. Elle change le coût marginal d’une nouvelle séquence, d’un nouveau segment, d’un nouveau marché. Quand la recherche de comptes prenait des heures, on priorisait peu de cibles. Quand elle devient un système, on peut tester plus d’angles sans embaucher une armée d’analystes.

Amin ne débarque pas sur cette scène en simple observateur. Clay est née à Brooklyn en 2017 avec une ambition plus large que la vente : mettre des capacités de programmation entre les mains de personnes qui n’écrivent pas de code au quotidien. Le tableur d’origine reliait des informations et automatisait des tâches. Les commerciaux, les équipes growth et les agences s’en sont emparés pour trouver et atteindre des clients. L’entreprise a suivi ce usage, plutôt que de le combattre. Le produit d’aujourd’hui se présente comme une infrastructure : accès à la donnée, workflows agentiques, lancement de campagnes. L’agent Claygent, adossé aux modèles d’OpenAI, prend en charge une partie de la recherche et de la prise de contact pour la vente, le marketing et le recrutement.

Un nom inventé, un problème ancien

Inventer un intitulé ne crée pas un métier. Encore faut-il qu’il décrive un travail que les entreprises paient déjà, souvent sans le voir. Avant le label, ce travail était éclaté. Un ops commercial bricolait des formules. Un revops nettoyait le CRM. Un growth montait des séquences. Un freelance enrichissait des fichiers. Le GTM engineering rassemble ces gestes sous une responsabilité : faire en sorte que le revenu ne dépende plus d’une succession de manipulations manuelles. Clay décrit ses praticiens comme des gens qui bâtissent des workflows de revenu automatisés, plutôt que d’exécuter à la main chaque tâche commerciale.

Cette définition mérite d’être prise au sérieux, et aussi avec prudence. Automatiser n’est pas synonyme de mieux vendre. Un flux mal conçu propage plus vite une mauvaise hypothèse. Un message personnalisé à grande échelle peut rester creux s’il ne repose que sur deux champs de données. Le métier a donc une face technique et une face de jugement. Il faut savoir ce qu’on cherche chez un compte, ce qu’on a le droit d’inférer, et ce qu’il vaut mieux laisser à un humain. Sans ce jugement, l’ingénierie GTM n’est qu’une tuyauterie plus rapide.

Ce que fait concrètement un GTM engineer

Sur le papier, la journée type mêle trois familles de gestes. D’abord la recherche : identifier des comptes, croiser des signaux, comprendre un contexte que le CRM ne contient pas. Ensuite la donnée : nettoyer, enrichir, dédupliquer, décider quelle source fait foi. Enfin l’orchestration : préparer une prise de contact, déclencher une séquence, faire circuler l’information vers les outils déjà en place. Rien de tout cela n’est nouveau. Ce qui change, c’est le degré auquel ces gestes deviennent des briques réutilisables plutôt que des exploits individuels.

Dans une petite équipe, la même personne peut porter les trois familles. Dans une organisation plus grande, le rôle se spécialise. Certains construisent les connecteurs et les règles. D’autres conçoivent les agents de recherche. D’autres encore mesurent ce qui sort vraiment du pipeline. Le point commun reste la responsabilité de système. On ne juge plus seulement le nombre d’e-mails envoyés. On juge si le flux tient, si la donnée reste fiable, si l’équipe commerciale reçoit des opportunités qu’elle peut traiter sans tout recommencer à la main.

• Rechercher des comptes et des signaux sans ouvrir vingt onglets à chaque fois.
• Relier des sources de données qui vivaient jusque-là dans des exports séparés.
• Qualifier selon des règles explicites, plutôt que selon la mémoire d’un commercial.
• Préparer une prise de contact contextualisée, puis la faire circuler dans le bon outil.
• Mesurer ce qui casse dans le flux, pas seulement ce qui convertit en bout de chaîne.

Cette liste ne remplace pas un cahier des charges. Elle montre surtout ce que les entreprises achetaient déjà en fragments. Le GTM engineer est la personne chargée de cesser de racheter le même fragment chaque semaine. C’est aussi pour cela que le rôle inquiète autant qu’il séduit. S’il réussit, une partie des tâches d’exécution disparaît. S’il échoue, l’entreprise a simplement ajouté une couche d’outils à une organisation qui ne savait déjà pas qui possédait la donnée.

Le stack d’hier et le système d’aujourd’hui

Pendant des années, le stack go-to-market s’est construit par addition. Un outil pour trouver des e-mails. Un autre pour les séquences. Un troisième pour le CRM. Un quatrième pour l’intention d’achat. Chaque éditeur résolvait un maillon. Peu assumaient la couture. Les équipes passaient leur temps à déplacer l’information, à réconcilier des identifiants, à expliquer pourquoi le même compte apparaissait trois fois. L’IA n’efface pas ces logiciels d’un coup. Elle change le centre de gravité. La valeur se déplace vers celui qui sait faire travailler ensemble recherche, donnée et action.

Clay s’est positionnée sur cette couture. Au départ, l’idée tenait dans un tableur capable de connecter des informations et d’automatiser sans écrire de code. Le geste est familier pour quiconque a déjà bricolé une croissance avec des cellules et des formules. La suite est moins banale. Quand les utilisateurs commerciaux ont tiré le produit vers la prospection, l’entreprise a accepté de devenir une infrastructure GTM plutôt que de rester un tableur généraliste. Aujourd’hui, le discours porte sur l’accès à la donnée, les workflows agentiques et le lancement de campagnes. Claygent incarne la partie agent : recherche et outreach pour des équipes de vente, de marketing et de recrutement.

Il serait facile d’y voir une simple mode des agents. Le parcours de la société raconte autre chose. L’automatisation précède ici le vocabulaire de l’agent. Le tableur était déjà une manière de programmer sans se déclarer développeur. L’IA a donné à cette idée une application plus nette : permettre à des équipes commerciales de bâtir des systèmes de recherche, d’enrichissement et de prise de contact sans dépendre, pour chaque flux, d’une équipe engineering classique. C’est le fil que Amin peut tirer sur scène, parce qu’il est aussi le fil de la société.

De Frame au Wall Street Journal, puis à Clay

Le parcours d’Amin éclaire le produit mieux qu’un slogan. Avant Clay, il a été vice-président produit au Wall Street Journal. Il a aussi cofondé Frame, une startup de collaboration rachetée par Sailthru en 2012. On y retrouve deux obsessions utiles pour comprendre la suite. D’un côté, le produit comme métier, avec la contrainte de faire tenir une expérience entre les mains de gens pressés. De l’autre, la collaboration et la circulation de l’information, sujets que la presse et les outils marketing connaissent sous des formes différentes. Clay, lancée en 2017, prolonge l’idée de mettre des capacités de programmation à la portée de davantage de personnes.

Ce n’est pas un détail de biographie. Les outils qui réussissent auprès des équipes non techniques échouent souvent quand ils exigent un développeur pour chaque ajustement. Les outils trop simples échouent dès que le cas réel dépasse le modèle prévu. Le pari de Clay a été de rester proche d’une grille, familière, tout en ouvrant des connexions que l’on n’attend pas d’un tableur ordinaire. Quand l’IA est arrivée à maturité commerciale, ce pari a trouvé un terrain : les équipes qui veulent automatiser sans ouvrir un ticket engineering à chaque campagne.

On peut discuter la part de vision et la part d’opportunité. Les deux comptent. Une société qui aurait ignoré l’usage commercial de son tableur serait restée à côté du mouvement. Une société qui n’avait aucun rapport avec l’automatisation accessible n’aurait pas eu de légitimité à nommer un métier. Clay revendique les deux : avoir suivi les utilisateurs, puis avoir mis un nom sur ce qu’ils faisaient déjà avec le produit. Le fonds de bourses d’un million de dollars annoncé en septembre pour former des GTM engineers prolonge ce geste. On ne finance pas une catégorie que l’on se contente de commenter.

Une croissance qui donne du poids au discours

Les thèses sur les nouveaux métiers circulent facilement. Elles pèsent davantage quand la société qui les porte affiche une trajectoire lisible. En février, TechCrunch rapportait que Clay avait triplé son revenu récurrent annuel pour atteindre 100 millions de dollars en un an, et qu’une offre de rachat d’actions salariés était annoncée sur une valorisation de 5 milliards de dollars. En septembre, une série D de 115 millions de dollars a été annoncée sur une valorisation de 7,1 milliards. Entre les deux jalons, la société a continué de croître. Ces chiffres ne valident pas chaque promesse sur le métier. Ils indiquent que des clients paient, à grande échelle, une infrastructure liée à ce discours.

La lecture prudente s’impose. Une valorisation n’est pas un marché de l’emploi. Un revenu récurrent n’est pas la preuve que chaque workflow remplace trois postes. En revanche, il devient difficile de traiter le GTM engineer comme une lubie de conférence quand l’éditeur qui a popularisé le terme lève, recrute autour de la catégorie et cite des annonces chez d’autres sociétés technologiques. Le marché teste l’idée avec de l’argent et des fiches de poste. C’est un test plus rude qu’un fil de discussion.

Cent annonces par mois, et après

Le volume d’environ cent offres mensuelles mérite d’être lu comme un signal, pas comme un recensement exhaustif. Les intitulés bougent. Certaines entreprises cherchent un revops, d’autres un growth engineer, d’autres un GTM engineer, pour des périmètres qui se recouvrent. La présence de Cursor, Lovable et Webflow dans les exemples cités par Clay montre surtout que le terme sort du cercle de l’éditeur qui l’a forgé. Quand des sociétés de produits très différentes ouvrent ce type de poste, le métier cesse d’être un artefact marketing d’un seul vendeur d’outils.

Reste à savoir ce que ces annonces demandent vraiment. Certaines veulent un profil capable de brancher des sources et d’écrire des règles. D’autres veulent quelqu’un qui comprend le cycle de vente et sait dire non à une automatisation inutile. Les meilleures fiches mélangent les deux. Les plus faibles se contentent de demander « de l’IA » et « de la data » sans propriétaire clair du résultat. Pour un candidat, la question utile n’est pas le prestige du titre. C’est de savoir qui décide de la qualité d’une opportunité une fois le flux lancé.

Pour un fondateur, la même question se pose à l’envers. Embaucher un GTM engineer sans lui donner le droit de toucher au CRM, aux séquences et aux sources de données, c’est recruter un commentateur. Le rôle n’a de sens que s’il peut modifier le système. Cela implique des accès, une définition de la donnée de référence, et une règle simple : ce qui est automatisé doit pouvoir être expliqué à l’équipe qui reçoit le lead. Sinon, la méfiance revient, et l’on retombe dans les exports manuels.

Personnaliser sans noyer le prospect

L’argument le plus séduisant du go-to-market assisté par IA est la personnalisation. Recherche de contexte, formulation adaptée, envoi au bon moment. L’argument le plus fragile est le même. Une personnalisation superficielle se voit. Citer le dernier poste LinkedIn d’un dirigeant ne constitue pas une raison d’acheter. Le travail utile consiste à relier un signal à une hypothèse de problème, puis à laisser un humain décider si l’hypothèse tient. Le système prépare. Il ne devrait pas confisquer le jugement sur les comptes qui comptent vraiment.

C’est un point que les équipes sous-estiment quand elles découvrent les agents. La vitesse crée une tentation de volume. Or le volume mal ciblé abîme le domaine d’envoi, fatigue les listes et apprend aux prospects à ignorer la marque. Un bon flux GTM réduit parfois le nombre de messages. Il augmente la part de ceux qui reposent sur un fait vérifiable. Claygent et les workflows du même genre sont des leviers, pas une permission d’écrire à tout le monde. La discipline du métier se joue là, dans le refus d’automatiser ce qui ne mérite pas de l’être.

Les entreprises qui s’en sortent le mieux traitent la prise de contact comme une conséquence de la recherche, pas comme l’objectif unique. Elles définissent d’abord ce qu’est un compte pertinent. Elles documentent les signaux acceptés. Elles gardent une trace de ce que l’agent a inféré et de ce qu’une source a confirmé. Cette hygiène paraît ennuyeuse. Elle est pourtant ce qui sépare une infrastructure de revenu d’une machine à spam légèrement plus intelligente. Disrupt peut mettre en scène la nouveauté du rôle. La tenue dans le temps dépendra de cette hygiène.

Recruter ou systématiser : le dilemme du prochain dollar

Amin s’adresse, à Disrupt, à des fondateurs et à des responsables GTM qui doivent placer leur prochain dollar. L’alternative est formulée sans détour. Ajouter des personnes pour exécuter le processus actuel, ou construire des systèmes qui permettent aux personnes déjà là d’exécuter autrement. Les deux réponses peuvent être justes. Une équipe qui n’a aucun processus clair n’a pas besoin d’un agent. Elle a besoin d’une définition du client. Une équipe qui répète les mêmes recherches chaque lundi a sans doute besoin d’un système avant d’ouvrir un cinquième poste de prospection.

Le piège consiste à croire que l’outil choisit à la place du dirigeant. Un tableur enrichi, un agent de recherche, une séquence : rien de cela ne sait quel segment mérite l’effort. Le GTM engineering rend le choix plus visible, parce qu’il faut l’écrire dans des règles. C’est un avantage caché. Ce qui restait dans la tête d’un commercial senior devient inspectable. On peut le contredire. On peut le versionner. On peut voir qu’une règle exclut un pays, un secteur, une taille d’entreprise. La transparence du système vaut parfois plus que son débit.

• Si le processus n’est pas nommé, l’automatisation fige le désordre.
• Si la donnée de référence n’existe pas, chaque outil invente la sienne.
• Si personne ne possède le flux, les exceptions reviennent au manuel.
• Si le volume prime sur le signal, la marque paie le prix à moyen terme.
• Si le rôle n’a pas d’accès, il commente au lieu de construire.

Ces garde-fous ne sont pas un rejet du métier. Ils en sont la condition. Les sociétés qui traitent le GTM engineer comme un magicien de l’IA découvrent vite que la magie s’arrête au premier champ vide. Celles qui le traitent comme un architecte de flux, avec un mandat et des limites, obtiennent quelque chose de plus durable : une manière de grandir qui ne repose pas uniquement sur l’embauche linéaire. C’est le cœur du message que la session de Disrupt cherche à rendre tangible.

Ce que l’IA change vraiment dans la recherche de comptes

La recherche de prospects a longtemps été un travail de compilation. Sites, actualités, organigrammes, offres d’emploi, levées, changements d’outils. Un bon analyste savait où regarder. Il ne pouvait pas le faire pour cent comptes dans la matinée. Les modèles et les agents déplacent cette contrainte. Ils peuvent parcourir des sources, résumer un contexte, proposer une accroche. Ils peuvent aussi se tromper avec aplomb. Le métier nouveau consiste moins à « faire de la recherche avec l’IA » qu’à décider quelles sources sont autorisées, quels résumés doivent être vérifiés, et à quel moment un humain reprend la main.

Claygent s’inscrit dans cette logique d’agent appliqué à la recherche et à l’outreach. L’intérêt pour une équipe n’est pas le nom de l’agent. C’est la possibilité de lancer une investigation répétée sans ouvrir un projet data à chaque fois. Une agence peut préparer un segment pour un client. Une équipe recrutement peut croiser des signaux d’embauche. Une équipe marketing peut nourrir une campagne avec un contexte que le CRM ne stockait pas. Le risque symétrique est la dépendance à une couche que personne ne sait auditer. D’où l’importance de garder des traces : quelle source, quelle règle, quelle version du flux.

Les entreprises qui viennent du tableur comprennent souvent mieux ce point. Une cellule affiche sa formule. Un agent, non, sauf si on le contraint. Le héritage de Clay, celui d’une grille qui connecte des informations, reste utile comme métaphore de gouvernance. On devrait pouvoir montrer à un responsable commercial pourquoi un compte est sorti du flux. Si l’on ne peut pas, le système n’est pas prêt pour des enjeux de revenu. La scène IA de Disrupt parlera de nouveauté. Les opérateurs, eux, demanderont la formule.

Agences, scale-ups et produits : trois usages distincts

Le même intitulé cache des usages très différents. Une agence qui gère plusieurs clients a besoin de répliquer des flux sans mélanger les données. Une scale-up qui attaque un nouveau pays a besoin d’enrichir vite un segment encore mal connu. Un éditeur de logiciel qui vend à des équipes techniques a besoin de signaux d’usage et d’embauche plus fins qu’une simple liste de titres. Clay a été tirée vers le go-to-market par ces publics, pas par un plan unique. C’est une force, et une source de confusion. Le métier ne se copie pas tel quel d’une agence vers une entreprise de produit.

Chez une agence, le GTM engineer est souvent un multiplicateur. Il construit une fois, il décline. La marge se joue sur la réutilisation. Chez un éditeur, il est plus proche d’un propriétaire de système interne. Il doit vivre avec le CRM, le produit, le cycle de vente réel. Les annonces citées chez Cursor, Lovable ou Webflow suggèrent ce second monde : des sociétés de produit qui internalisent la capacité à construire leurs propres workflows de revenu. Ce n’est pas la même fiche de poste qu’un consultant qui livre une séquence clé en main.

Pour un lecteur qui hésite à créer le poste, le bon réflexe est de décrire le flux avant de décrire la personne. Quels comptes ? Quelles sources ? Quelle main-off vers le commercial ? Quelle mesure de qualité à trente jours, pas seulement à l’envoi ? Si ces réponses tiennent en une page, le rôle a un contour. S’il faut trois ateliers pour les formuler, l’embauche peut attendre. L’outil, lui, peut déjà servir à rendre le désordre visible. C’est parfois le premier bénéfice, avant toute promesse de productivité.

La bourse d’un million : former une catégorie

Annoncer un fonds de bourses d’un million de dollars pour former des GTM engineers est un geste de catégorie, pas seulement de marque employeur. Les métiers nouveaux souffrent d’un manque de référentiel. Les candidats viennent du revops, du no-code, du conseil, parfois du développement. Les entreprises ne savent pas quoi évaluer. Un programme de formation, même modeste à l’échelle d’une valorisation de plusieurs milliards, envoie un signal : le savoir-faire peut s’apprendre, il ne se résume pas à « être à l’aise avec l’IA ». Le contenu exact de ces bourses comptera plus que le montant. Un intitulé sans exercices concrets ne crée pas de praticiens.

On peut y voir aussi une stratégie classique d’écosystème. Plus il y a de personnes formées au geste, plus l’infrastructure qui porte ce geste devient naturelle. Ce n’est pas illégitime. Tous les éditeurs qui ont réussi un métier — admin Salesforce, growth, data analyst — ont financé des communautés et des certifications. La question pour le candidat est de distinguer la compétence transférable du réflexe propre à un outil. Savoir modéliser un flux de revenu reste utile si l’on change de stack. Savoir uniquement cliquer dans un produit unique l’est moins.

Amin a un intérêt évident à ce que la catégorie existe en dehors de Clay. Une scène comme Disrupt sert à cela : parler à des fondateurs qui ne sont pas encore clients, et à des opérateurs qui cherchent un langage pour leur prochain recrutement. Le risque, symétrique, est de surpromettre. Un métier ne devient pas « la prochaine grande catégorie » parce qu’une keynote le dit. Il le devient si, dans dix-huit mois, les équipes qui l’ont créé peuvent montrer un pipeline plus propre, pas seulement une démo plus fluide.

Disrupt 2026 comme théâtre, pas comme preuve

La session s’inscrit dans un événement plus large. TechCrunch Disrupt se tient du 13 au 15 octobre à Moscone West, à San Francisco. L’organisateur annonce plus de deux cents sessions sur six scènes industrielles, des tables rondes et des ateliers, plus de dix mille fondateurs, investisseurs, opérateurs et responsables tech attendus, plus de deux cent cinquante intervenants et plus de trois cents startups exposantes. Le matchmaking et les rencontres font partie du format. Dans ce décor, une prise de parole sur un métier nouveau bénéficie d’une audience déjà occupée par la croissance, les levées et les outils.

Il faut garder la hiérarchie. Une conférence montre un cadre. Elle ne remplace pas un pilote sur ses propres données. Les participants qui sortiront de la session avec une question précise en tireront plus que ceux qui sortiront avec un intitulé à coller sur une fiche de poste. La question précise peut être simple. Quel flux, chez nous, est encore une suite de copier-coller ? Qui le possède ? Que se passerait-il si on le rendait rejouable sans ajouter une personne ? C’est exactement l’alternative que Amin met sur la table.

Le lieu compte aussi comme symbole. San Francisco reste le théâtre où les catégories tech se nomment avant d’être adoptées ailleurs. Cela ne les rend ni vraies ni fausses. Cela accélère le vocabulaire. Les équipes européennes ou francophones qui liront le compte rendu devront traduire, au sens propre. Go-to-market et GTM engineer circulent déjà dans les startups. Les PME industrielles, elles, parleront plutôt d’outillage commercial et de qualité de fichier. Le fond du problème reste identique : trouver les bons comptes sans empiler indéfiniment les gens et les logiciels.

Ce que les équipes marketing et vente doivent négocier

Le rôle touche une frontière sensible. Le marketing veut des messages et des segments. La vente veut des opportunités qu’elle peut appeler. Les ops veulent un CRM qui ne se dégrade pas. L’ingénierie produit ne veut pas devenir le helpdesk de chaque campagne. Le GTM engineer se tient au milieu, avec le risque d’être tiré de tous les côtés. La négociation utile porte sur le mandat. Est-il là pour livrer des listes, ou pour modifier la manière dont les listes naissent ? Est-il jugé sur le volume, ou sur la part d’opportunités que les commerciaux acceptent de traiter ?

Sans cette négociation, le poste devient un sas de frustration. Le marketing demande plus de personnalisation. La vente se plaint du bruit. L’ingénieur GTM passe ses journées à corriger des exceptions. Le système n’apprend rien. À l’inverse, une règle partagée — par exemple, aucun envoi sans signal daté de moins de quatre-vingt-dix jours, ou aucune création de compte sans identifiant stable — réduit les disputes. Elle donne aussi au rôle quelque chose à défendre. On ne défend pas une mode. On défend une règle que l’équipe a acceptée.

Les outils comme Clay rendent cette négociation plus concrète, parce qu’ils obligent à brancher des colonnes et des actions. Ce qui était un débat d’opinion devient un flux visible. C’est inconfortable. C’est aussi le seul moyen de sortir des guerres de territoire entre « mon export » et « ton séquence ». Les entreprises qui réussissent ce passage traitent le flux comme un produit interne, avec un propriétaire, des utilisateurs et une dette. Les autres continuent d’acheter des licences en espérant que l’alignement viendra avec le logiciel.

Limites, données et responsabilité

Automatiser la recherche de personnes et d’entreprises n’est pas un sujet neutre. Les sources ont des conditions d’usage. Les messages ont des cadres légaux selon les pays. Les modèles infèrent parfois un rôle ou une intention que la source ne contient pas. Un métier qui se veut ingénierie doit inclure ces limites dans le système, pas dans une note de bas de page. Qui a le droit d’être contacté ? Quelle donnée est conservée ? Que fait-on d’un champ incertain ? Ces questions ne font pas une keynote spectaculaire. Elles font la différence entre une croissance tenable et une croissance qui se retourne contre la marque.

Il est tentant de les déléguer au juridique en bout de chaîne. C’est trop tard. Si le flux est déjà conçu pour maximiser le volume, le cadrage arrivera comme un frein, et les équipes le contourneront. Mieux vaut l’écrire dans les règles dès le premier prototype. Le GTM engineer n’a pas à être juriste. Il a à savoir quelles questions poser avant de brancher une source. Les sociétés qui forment la catégorie, Clay comprise, auront intérêt à montrer cet aspect, sinon le métier sera associé aux dérives les plus visibles de la prospection automatisée.

La donnée interne pose un problème cousin. Enrichir un CRM avec des signaux externes peut l’améliorer ou le polluer. Une mauvaise fusion de comptes se propage dans les reportings, les commissions, les prévisions. Le rôle doit donc avoir une doctrine de qualité, pas seulement une doctrine de vitesse. Combien d’erreurs tolère-t-on sur un échantillon avant de généraliser un flux ? Qui peut revenir en arrière ? Ces réflexes viennent du monde data. Ils manquent souvent au monde commercial. Les rapprocher est peut-être la part la plus durable de la nouvelle discipline.

Comment reconnaître un flux qui tient

Un flux GTM sérieux se reconnaît à des signes peu spectaculaires. L’équipe peut expliquer d’où vient un compte. Elle peut rejouer la recherche sans repartir de zéro. Elle sait quel pourcentage d’opportunités a été refusé par les commerciaux, et pourquoi. Elle a une liste courte de sources autorisées. Elle versionne ses messages. Elle n’a pas besoin d’un héros le vendredi pour « sortir la liste ». Ces signes valent mieux qu’une capture d’écran d’agent. Ils indiquent que le système appartient à l’entreprise, pas à la personne qui l’a bricolé.

À l’opposé, certains signaux d’alerte reviennent souvent. Personne ne sait quelle colonne fait foi. Les séquences partent depuis trois outils. Les commerciaux recoivent des fiches qu’ils réécrivent entièrement. Le taux d’ouverture est brandi comme preuve, alors que le pipeline n’a pas bougé. L’agent est relancé « pour voir » sans critère d’arrêt. Dans ce décor, ajouter un intitulé de poste ne change rien. Il faut d’abord arrêter les flux qui mentent. Ensuite seulement, on peut parler d’ingénierie.

Clay, dans son guide interne du métier, insiste sur la construction de workflows plutôt que sur l’exécution manuelle. C’est le bon axe, à condition de mesurer le workflow sur le revenu et sur la qualité, pas sur le nombre d’actions déclenchées. Une action déclenchée n’est pas un client. Un client n’est pas non plus la seule métrique : un système qui ne trouve que des comptes déjà connus ne justifie pas son coût. Le bon tableau de bord mélange couverture, précision et temps rendu aux équipes. Sans ce mélange, on optimise le bruit.

Ce que les fondateurs peuvent tester sans attendre la scène

Inutile d’attendre une keynote pour mener un essai modeste. Choisir un segment étroit. Écrire en une page les signaux qui rendent un compte pertinent. Brancher deux sources au maximum. Préparer une prise de contact que l’équipe accepte de relire. Mesurer, sur trente comptes, combien survivent au regard d’un commercial. Comparer au processus manuel sur le même segment. Si le système ne gagne ni en temps ni en précision, il n’est pas prêt à être généralisé. S’il gagne sur l’un des deux axes sans dégrader l’autre, il mérite un propriétaire.

Cet essai révèle souvent que le blocage n’est pas l’IA. C’est l’absence de définition du bon compte. Ou l’impossibilité d’accéder au CRM. Ou la peur de toucher aux séquences existantes. Le GTM engineer devient alors utile comme traducteur entre ces blocages et un flux minimal. Il n’a pas besoin, au départ, d’un agent spectaculaire. Il a besoin du droit de remplacer un copier-coller par une règle. Les outils qui partent d’une grille, comme l’a fait Clay, facilitent ce premier remplacement. Les agents viennent ensuite, quand la règle tient.

Les équipes qui sautent l’étape de la règle se racontent une histoire d’automatisation. Elles obtiennent des démos. Elles n’obtiennent pas un système. La session d’Amin vaudra d’être écoutée si elle montre des flux réels, avec leurs exceptions, plutôt qu’une promesse générale sur l’IA. Le public de Disrupt est habitué aux promesses. Il est plus rare qu’on lui montre ce que l’on a choisi de ne pas automatiser. Cette retenue, si elle est au programme, sera le moment le plus utile de l’intervention.

Un métier de jonction, pas une mode de titre

Au fond, le GTM engineer est un métier de jonction. Il relie la donnée au message, le message au canal, le canal au jugement commercial. Il existe parce que ces jonctions étaient devenues trop chères à faire à la main, et trop fragiles pour être laissées à une pile d’outils qui ne se parlent pas. Clay a mis un nom dessus en 2023, après avoir été entraînée hors de son tableur d’origine par des utilisateurs qui cherchaient des clients. La croissance annoncée depuis — 100 millions de revenu récurrent, puis une série D à 7,1 milliards — donne à ce nom une caisse de résonance. Elle ne dispense pas de vérifier, entreprise par entreprise, que le système tient.

Kareem Amin arrive à Disrupt avec une thèse simple et une trajectoire qui la rend audible. L’IA n’a pas seulement accéléré des tâches. Elle a rendu imaginable une discipline où l’on construit le revenu comme on construit un produit : avec des règles, des versions, des propriétaires. Que l’on adopte le titre ou non, la question survivra à la conférence. Préférez-vous ajouter des personnes au processus que vous avez déjà, ou donner à ces personnes un système qui change leur façon d’exécuter ? La réponse ne se trouve pas dans une valorisation. Elle se trouve dans le prochain flux que votre équipe acceptera de ne plus refaire à la main.

Pour les opérateurs qui suivront la session du 13 au 15 octobre, le bénéfice concret sera peut-être moins le vocabulaire que la permission de réorganiser le travail. Nommer un rôle autorise parfois à cesser de disperser la responsabilité. Encore faut-il que le nom décrive un mandat. Recherche, donnée, orchestration, mesure, limites. Cinq mots suffisent à cadrer un poste. Le reste — agents, campagnes, enrichissement — n’est que la matière avec laquelle ce mandat s’exerce. Clay a choisi d’en faire une infrastructure. D’autres choisiront un assemblage différent. Le métier, s’il dure, sera celui qui reste quand l’outil change.