La différence, et lequel vous faut-il.

Build vs Run

La façon la plus nette de tenir la frontière tient en deux mots : build et run.

Les deux sont utiles. Ils n'arrivent simplement pas au même moment.

« Le GTM engineer, ce n'est pas juste du RevOps rebrandé ? »

C'est l'objection la plus fréquente, et elle est légitime. Elle mérite une réponse honnête plutôt qu'un haussement d'épaules.

Ce qui est vrai dans l'objection : les deux manipulent les mêmes objets. Un CRM, de la donnée, des outils, des automatisations. Vu de loin, deux personnes devant le même écran. Et il est exact qu'une partie du marché a renommé des postes de RevOps en « GTM engineer » sans rien changer au travail, parce que le titre est plus vendeur. Ça existe, et ça pollue le débat.

Ce qui est faux : conclure que c'est le même métier. La différence n'est pas dans les outils, elle est dans la finalité, et elle produit des comportements opposés.

Mettez les deux devant le même problème : « on ne signe pas assez ».

Les deux ont raison, selon le problème. Mais si votre problème est qu'il n'y a rien dans le tuyau, mesurer sa fuite ne vous aidera pas.

Le test simple : demandez à la personne en face ce qu'elle a construit ces six derniers mois. Si elle répond avec des process, de la gouvernance et des tableaux de bord, c'est un RevOps, et c'est très bien. Si elle répond avec un système qui tourne et qu'elle peut vous montrer, c'est un GTM engineer.

Pourquoi le conseil anglophone ne marche pas en France

Vous lirez partout, dans les articles américains, une règle qui a l'air sage : recrutez un RevOps d'abord, ajoutez du GTM engineering plus tard. Cette règle est cohérente... dans son contexte d'origine. Elle est écrite pour des entreprises qui ont déjà plusieurs millions de revenu récurrent, une équipe marketing, une équipe commerciale, un service client, et donc un vrai problème de silos. Dans ce monde-là, mettre de l'ordre avant de construire a du sens.

Le tissu français est différent. La structure typique qui se pose la question ici a entre 10 et 50 personnes. Le marketing, la vente et le service client, ce sont souvent trois personnes qui déjeunent ensemble. Il n'y a pas de silo à casser : il y a une absence de système.

En France, sur cette taille d'entreprise, l'ordre s'inverse presque toujours : on construit la machine d'abord, on met de la gouvernance quand il y a assez de monde et assez de flux pour que ça devienne un problème. Le détail sur le métier de RevOps et ses conditions d'existence est sur la page RevOps. Et la comparaison voisine, plus proche du terrain commercial, est sur GTM engineer vs Sales Ops.

Peut-on être les deux ?

Sur le papier oui, dans les faits rarement, et c'est une question d'appétence plus que de compétence.

Ce sont deux tempéraments opposés. Le bon RevOps aime que les choses soient justes, cohérentes et documentées. Le bon GTM engineer aime que les choses existent et produisent, quitte à les casser trois fois. Le premier est gardien, le second est bâtisseur.

Dans une petite structure, la même personne porte souvent les deux casquettes, faute de choix. Ça marche un temps, jusqu'au moment où l'une des deux prend toute la place. En général, c'est le run qui mange le build : entretenir l'existant est urgent, construire ne l'est jamais. C'est exactement pour ça que beaucoup d'entreprises ont un CRM impeccable et pas de pipeline.

Le versant construction, c'est la prospection par signaux et sa mise en œuvre sur automatiser sa prospection. Le métier qui l'incarne est détaillé sur GTM engineer.