Chaque fondateur à qui je parle cette année me pose une variante de la même question : dois-je recruter un GTM engineer ou un RevOps ? Ils ont lu les mêmes articles que vous. Le GTM engineer est le rôle du moment, celui qui branche Clay à HubSpot, construit l’outbound piloté par l’IA et livre en une semaine ce qui prenait un trimestre. Le RevOps sonne comme la chose plus ancienne et plus lente, alors on veut le sauter. Le problème, c’est que ce ne sont pas deux noms pour le même poste, et recruter le mauvais seul est la façon dont une équipe revenue rapide décroche silencieusement de son propre CRM.
Pourquoi c’est une question de 2026
Si c’est d’actualité maintenant, c’est que l’organisation go-to-market devient à la fois plus légère et plus technique. La lecture d’ICONIQ Growth de l’organisation GTM moderne en 2026 montre que l’entreprise médiane prévoit zéro croissance d’effectif RevOps cette année, tout en réservant environ un dixième du temps RevOps à l’expérimentation IA qui n’existait pas il y a dix-huit mois. Les entreprises où l’IA est pleinement intégrée génèrent environ deux fois plus de revenu net nouveau par tête. La pression est donc réelle : faire plus, à effectif constant, avec de meilleurs outils. Un intitulé qui promet exactement cela, le GTM engineer, tombe en plein milieu.
Ce qu’est vraiment un GTM engineer
Un GTM engineer est un builder. Il vient de la donnée et de l’automatisation, il maîtrise l’outillage, et son instinct est de câbler les systèmes et de livrer. Comme l’a formulé First Round en décrivant la montée en charge de Clay, l’idée est de prendre la discipline d’ingénierie et l’amener dans le go-to-market. C’est une vraie valeur. Une personne capable de bâtir la pre-call research, le lead scoring et une motion d’outbound remplace ce qui était autrefois trois rôles et un backlog. Dans une ville comme Berlin, les GTM engineers du marché arrivent avec ce focus ingénierie et cette vitesse. Ce qu’ils n’apportent généralement pas, ce sont les bonnes pratiques de revenue operations.
Ce que possède vraiment le RevOps
Le RevOps n’est pas un GTM engineer plus lent. Il possède autre chose : le système de référence, et la question de savoir s’il dit encore la vérité. Cela signifie le customer journey, les définitions derrière chaque stage et chaque champ, le reporting sur lequel repose votre forecast, et la discipline de tout aligner sur la façon dont l’entreprise vend réellement. Le test que j’utilise est simple. Un GTM engineer fait faire plus à la machine. Le RevOps s’assure que la machine correspond encore à la réalité. Ce sont des métiers différents, et dans la plupart des équipes de moins de quelques centaines de personnes, une personne est vraiment meilleure dans l’un que dans l’autre.
Le mode d’échec : l’automatisation sans système de référence
Nous avons récemment travaillé avec une équipe B2B SaaS en Series B dans la région DACH qui avait fait le choix moderne et recruté d’abord un solide GTM engineer. Six mois plus tard, l’automatisation était impressionnante : signups enrichis, deals créés, séquences qui se déclenchent, des dashboards partout. Le problème, c’est que l’activité avait bougé en silence et le CRM non. De nouvelles motions de vente tournaient dans le chat et des tableurs parce qu’elles étaient plus rapides à monter qu’à modéliser proprement, les stages ne voulaient pas dire la même chose pour chaque commercial, et le forecast reposait sur des champs que personne ne possédait. Rien de tout cela n’était la faute de l’ingénieur. Personne ne lui avait confié l’autre métier. Quand les actions métier et le CRM cessent d’être alignés, et que personne n’a pour mission de les aligner, l’écart se creuse chaque semaine, et il se creuse le plus vite chez les équipes qui automatisent le plus.
Qui possède quoi
La réponse pour la plupart des équipes en croissance n’est donc pas l’un ou l’autre. C’est les deux, avec une ligne nette entre eux. La ligne que je tracerais :
- Le RevOps possède le système de référence : le customer journey, les définitions de stages et de champs, la qualité de la donnée et le revenue reporting. C’est le rôle qui doit être stable et ne doit pas tourner.
- Le GTM engineer possède la vitesse : les automatisations, les workflows IA, les intégrations et les expériences qui doivent passer en production cette semaine.
- Le RevOps pose les garde-fous à l’intérieur desquels l’ingénieur construit, pour que la vitesse ne devienne pas de la dérive.
Quand vous n’avez de budget que pour un recrutement, dimensionnez-le selon votre problème. Si votre CRM est un chaos et votre forecast une fiction, vous avez d’abord besoin de l’owner RevOps, car il ne sert à rien d’automatiser sur un système auquel vous ne pouvez pas vous fier. Si vos données sont propres mais que vous êtes lent et manuel, le GTM engineer est le recrutement le plus à effet de levier. Ne compliquez pas : réparez ce qui est vraiment cassé.
Il existe une troisième option que de plus en plus de nos clients choisissent, et je serai honnête : c’est l’une de nos offres de service. Gardez le GTM engineer en interne, là où doit vivre la construction rapide et spécifique au produit, et louez la responsabilité RevOps en fractionné jusqu’à être assez grand pour la recruter. La configuration que nous voyons fonctionner, c’est un owner RevOps fractionné qui tient le système de référence et le reporting, avec un GTM engineer interne qui construit vite à l’intérieur de ces garde-fous. Vous continuez d’innover vite sans laisser le système dériver, et vous ne payez pas un salaire plein temps pour un rôle qui s’allège une fois le premier nettoyage fait.
Ce que je ferais
- Nommez le métier, pas le titre. Écrivez lequel des deux vous manque réellement : quelqu’un pour faire faire plus à la machine, ou quelqu’un pour garder la machine honnête. La plupart des équipes le savent en une phrase.
- Auditez avant d’automatiser. Faites d’abord une vraie discovery sur le CRM et le customer journey. Si les actions métier et le système sont déjà désalignés, plus d’automatisation creuse l’écart, ne le réduit pas.
- Séparez les rôles : RevOps pour le système de référence, GTM engineering pour la vitesse, et ne mélangez jamais les deux. Le rôle stable et le rôle rapide ont des tempéraments différents ; ne demandez pas à une seule personne d’être les deux, sauf si elle a vraiment fait les deux.
- Si vous ne pouvez en financer qu’un, dimensionnez selon la casse. Données cassées et forecast fictif : RevOps d’abord. Données propres, exécution lente : GTM engineer d’abord.
- Envisagez de louer le rôle que vous ne pouvez pas encore justifier de recruter. Un owner RevOps fractionné plus un GTM engineer interne est la configuration qui tient le mieux, chez nous, entre Series A et Series C.
Le GTM engineer est l’une des meilleures choses arrivées aux équipes revenue depuis des années, et vous devriez sans doute en recruter un. Ne confondez simplement pas la construction avec le système qui la porte. Les équipes qui se brûleront en 2026 ne seront pas celles qui ont avancé trop lentement ; ce seront celles qui ont automatisé le plus vite sur un CRM que personne ne possédait. Si vous voulez une seconde paire de mains sur le système de référence pendant que votre ingénieur continue de livrer, c’est exactement à cela que sert notre travail revenue operations, ou vous pouvez prendre contact et nous commencerons par ce qui dérive le plus. Pour la question connexe d’où le revenu fuit en silence une fois le système en place, lisez l’article compagnon sur les deux passations que personne ne possède.
Sources
- SaaStr, synthétisant le rapport ICONIQ Growth sur l’organisation GTM 2026. « The Modern GTM Org in 2026: 20-30% Leaner, 9x Flatter, ~2x More Net New Revenue Per Rep. » Mai 2026. saastr.com
- First Round Review. « The GTM Inflection Points That Powered Clay to a $1B+ Valuation. » firstround.com
- SaaStr. « How Owner.com’s CRO Is Closing $2M+ in ARR Per Rep With AI. » 2026. saastr.com