Le métier en une ligne
Le growth engineer, c'est la personne qui rend le growth mesurable. Il instrumente le produit pour que chaque action utile devienne un événement, tient un tracking plan qui nomme ces événements de façon cohérente, et corrige les fuites du funnel que les données révèlent. Sur les huit rôles, il se tient à côté du Growth PM : le PM décide quoi tester, l'engineer rend le test mesurable. Son code sert les expériences, pas la roadmap produit.
Ce qu'il livre vraiment
L'essentiel du travail, c'est de la plomberie que le reste de l'équipe ne voit jamais. L'équipe de PostHog présente le growth engineer comme quelqu'un qui écrit du code pour bouger les métriques business plutôt que pour construire des fonctionnalités — l'échafaudage des A/B tests, les corrections de funnel, le tracking qui dit si quelque chose a marché.
- Cartographier un funnel — inscription, activation, upgrade — et instrumenter chaque étape pour rendre la fuite visible.
- Ajouter l'événement manquant. L'exemple classique : un `subscription_started` que personne n'a câblé, donc le revenu est invisible dans le funnel.
- Auditer le tracking plan : supprimer les événements en double, corriger les noms incohérents, documenter ce que chaque propriété signifie.
- Construire les outils internes et les intégrations — webhooks, synchros, tableaux de bord — qui permettent aux autres rôles d'agir sur les données.
Le tracking plan, c'est le livrable
Tout l'aval dépend d'événements propres. Amplitude présente la taxonomie d'événements comme le socle d'une bonne analytique : une convention de nommage cohérente, des propriétés convenues, une seule source de vérité. Segment décrit le tracking plan comme un document vivant de ce qu'on suit et pourquoi. Faites-le bien et profils, segments et journeys lisent tous le même flux fiable. Faites-le mal et chaque rapport ment en silence.
Pourquoi le rôle est du pur levier
Un growth engineer possède rarement une métrique à lui. Son résultat, c'est la capacité même de l'équipe à bouger des métriques. Quand le Performance Marketer veut synchroniser un segment à fort LTV vers une plateforme publicitaire, ou que le Data Analyst a besoin d'un rapport de cohortes qui ne repose pas sur des suppositions, c'est l'engineer qui fait exister ces données et les rend fiables. Instrumenter une fois, et chaque rôle lit les mêmes événements. Ce multiplicateur, c'est ce qui fait du rôle une pièce d'une équipe de growth IA, pas un confort optionnel.
Growth engineer contre product engineer
Les deux écrivent du code ; la question à laquelle ils répondent diffère. Un product engineer demande si la fonctionnalité marche. Un growth engineer demande si la fonctionnalité bouge le chiffre — et instrumente le produit pour qu'on puisse le dire. Il livre plus vite et plus scrappy, car une correction de tracking qui sort le trimestre prochain est une correction qui n'a rien appris.
Comment fromHello fait tourner ce rôle
fromHello fait tourner le growth engineer comme l'un des huit agents IA d'une équipe de growth IA. L'agent cartographie votre funnel, propose les événements qui vous manquent et rédige le tracking plan — puis vous approuvez, modifiez ou renvoyez. Rien ne part tout seul ; l'agent propose et vous gardez la main. Si vous le pesez face à un outil que vous devriez encore opérer vous-même, fromHello contre Customer.io mesure l'écart entre louer la plateforme et obtenir l'équipe qui la fait tourner.