Faut-il une équipe growth dédiée ?

Les licornes ont un Head of Growth, donc il vous en faut un. C'est, en résumé, le raisonnement qui pousse la plupart des PME et des scale-ups françaises à créer un poste growth. Le problème n'est pas l'ambition : c'est que la question « faut-il une équipe growth dédiée » se tranche presque toujours par imitation, jamais par diagnostic.

Il existe deux modèles d'organisation growth qui fonctionnent, et un troisième qui échoue avec une régularité déprimante. Voici comment les distinguer, les trois critères qui vous disent lequel s'applique à votre entreprise aujourd'hui, et ce qu'il faut écrire avant même de rédiger une fiche de poste.

Équipe growth dédiée : de quoi parle-t-on vraiment ?

Une équipe growth dédiée est un groupe pluridisciplinaire (marketing, produit, data, développement) dont le mandat unique est de faire progresser une métrique de croissance par l'expérimentation continue, avec son propre backlog de tests, son propre rituel et un accès direct au produit.

Ce n'est donc ni un service marketing rebaptisé, ni une personne seule à qui l'on a collé un titre. La distinction n'est pas cosmétique : elle détermine si la structure produit des résultats ou des présentations.

La vraie question n'est d'ailleurs pas « faut-il une équipe growth ». Elle est : quel volume d'expérimentation votre organisation doit-elle absorber, et votre structure actuelle en est-elle capable ? Répondre à celle-là vous évite de recruter pour combler un doute stratégique.

Deux modèles répondent sérieusement à cette question, et les deux sont légitimes :

• Le growth distribué : pas d'équipe séparée. Chaque fonction porte un bout de la mesure et de l'expérimentation, un référent tient le fil et le rythme.
• Le pod growth dédié : une petite équipe pluridisciplinaire, avec accès dev et data, dont c'est le seul travail.

Le mauvais modèle n'est aucun des deux. Le mauvais modèle, c'est le troisième : une personne isolée, sans mandat ni accès, coincée entre le marketing et le produit. Nous y revenons plus bas, parce que c'est celui que la moitié des entreprises choisit sans le savoir.

Le growth distribué : la croissance comme responsabilité partagée

Dans le modèle distribué, la croissance n'est pas un département : c'est une discipline que chaque fonction pratique sur son périmètre. Concrètement, la répartition ressemble à ceci :

• Le commerce porte l'acquisition et la conversion : messages, séquences, taux de réponse, qualité des rendez-vous.
• Le produit porte l'activation et la rétention : premier usage, moment de bascule, réengagement des comptes dormants.
• Le service client porte la recommandation : demandes récurrentes, signaux de churn, occasions de parrainage.
• Un référent growth (souvent le dirigeant, le responsable marketing ou le fondateur technique) tient le backlog commun, arbitre les priorités et anime le rituel.

Ce modèle demande une seule chose pour tenir : un rituel hebdomadaire d'une heure, non négociable, où l'on revoit les tests en cours, ce qu'ils ont appris et ce que l'on lance ensuite. Sans ce rendez-vous, « la croissance est l'affaire de tous » devient très vite « la croissance n'est l'affaire de personne ».

Ses forces sont réelles : zéro silo, zéro coût de structure, un apprentissage qui se diffuse dans toute l'entreprise. Les personnes qui exécutent sont celles qui voient les résultats, et c'est le meilleur moteur d'adoption qui existe. C'est aussi le modèle qui épouse naturellement le cadre AARRR : chaque étape a un propriétaire identifiable.

Ses limites sont tout aussi nettes. La croissance est la première chose sacrifiée quand le trimestre chauffe : un commercial en retard sur son objectif ne lancera pas de test. Personne ne tient le temps long. Et surtout, toute expérience qui dépend d'une ligne de code reste au fond du backlog produit, indéfiniment.

Le pod growth dédié : une métrique, une équipe, un accès au produit

Le pod growth répond exactement à ces limites. C'est une équipe volontairement petite, réunie autour d'une métrique et non d'un canal. Sa composition minimale viable, en PME ou en scale-up :

• Un lead growth : tient l'hypothèse, l'arbitrage et le rythme.
• Un profil data ou analytics, même à mi-temps : garantit que les résultats mesurés existent réellement.
• Un développeur ou un demi-développeur : c'est le point qui change tout.
• Un renfort design et copy mobilisable à la demande.

Trois attributs séparent un vrai pod d'une équipe de façade :

1. Une métrique unique, pas un tableau de bord entier. Une seule ligne à faire bouger sur le trimestre (voir comment choisir sa North Star Metric).
2. Un droit de modifier. Le pod peut pousser une variante en production, changer une page, activer un drapeau de fonctionnalité, sans attendre un arbitrage de roadmap à six semaines.
3. Un budget de tests, même modeste. Un pod qui doit justifier trois cents euros d'achat média à chaque expérience n'expérimente pas, il négocie.

Le pod ne remplace ni le marketing ni le produit. Il travaille sur les zones que personne ne possède spontanément : les frontières. L'onboarding entre l'inscription et le premier usage. Le passage du contenu au rendez-vous commercial. La réactivation d'un compte inactif. Ce sont, dans la plupart des organisations, les endroits où se logent les gains les plus rapides, et ce sont précisément ceux que le modèle distribué laisse orphelins.

Sur les profils à viser, tout est dans les qualités d'un bon growth hacker : la curiosité méthodique et l'autonomie technique pèsent bien plus lourd que la liste d'outils du CV.

Les trois critères qui font basculer d'un modèle à l'autre

Trois critères, un verdict simple : si deux sur trois sont au vert, montez un pod. Sinon, restez distribué et renforcez le rituel.

Critère 1 : le volume d'expériences menées en parallèle. En dessous de deux ou trois tests simultanés, le modèle distribué suffit largement. Au-delà, les choses cassent mécaniquement : plus personne ne tient le backlog à jour, deux tests se polluent (une campagne d'acquisition qui change le mix de trafic fausse le test d'onboarding en cours), et les apprentissages ne sont plus consignés nulle part. Le symptôme à guetter : vous n'êtes plus capable de dire ce que vous avez testé le trimestre dernier.

Critère 2 : la dépendance technique de vos tests. Posez la question à votre backlog : combien de vos dix meilleures hypothèses exigent une modification du produit ? Si la réponse est une ou deux, un modèle distribué tient. Si c'est six ou plus, votre backlog restera théorique tant que le growth n'aura pas d'accès dev. C'est la raison la plus fréquente pour laquelle une équipe dédiée se justifie dans un éditeur de logiciel, et beaucoup moins dans une activité de services.

Critère 3 : l'existence d'un rituel d'expérimentation déjà tenu. Celui-là est un critère de disqualification. Si vous n'avez pas encore de rendez-vous hebdomadaire où l'on décide, mesure et documente, créer une équipe ne créera pas la culture d'expérimentation : elle l'externalisera. Vous obtiendrez une équipe qui teste pendant que le reste de l'entreprise regarde. Tenez le rituel un trimestre entier, avec les gens que vous avez déjà. Ensuite seulement, décidez.

Un quatrième signal, plus discret : la fiabilité de votre mesure. Si vos tests se concluent au doigt mouillé, une équipe dédiée produira surtout des conclusions fausses plus vite. À lire avant de vous lancer : pourquoi la plupart des A/B tests ne prouvent rien.

Le piège numéro un : le poste growth isolé, sans mandat ni accès

Voici le scénario que l'on croise le plus souvent, et il ne finit jamais bien.

Une entreprise décide qu'il lui faut du growth. Elle recrute un profil senior, seul. Elle ne lui donne ni développeur, ni accès aux données produit, ni autorité sur une page. Elle le place administrativement entre le marketing et le produit, ce qui revient à le placer nulle part. Six mois plus tard, la personne produit des audits, des recommandations et des présentations que personne n'exécute, parce que l'exécution appartient à d'autres équipes qui ont déjà leurs propres objectifs.

Un poste growth sans mandat ni accès ne devient pas une fonction : il devient un silo que personne n'écoute.

Les symptômes apparaissent presque toujours dans cet ordre :

• La personne demande des données au lieu de les lire elle-même.
• Ses tests attendent dans le backlog d'une autre équipe.
• Ses réunions deviennent des réunions de conviction, plus des réunions de décision.
• On lui reproche l'absence de résultats, alors qu'elle n'a jamais disposé d'un levier.
• Elle part au bout d'un an ou deux, et l'entreprise conclut que « le growth, ça ne marche pas chez nous ».

La cause racine est presque invariablement la même : le recrutement a servi de substitut à une décision d'organisation. Embaucher est plus confortable que d'admettre que la croissance dépend d'arbitrages que la direction n'a pas encore tranchés, à savoir quelle métrique compte, quel périmètre d'autorité on cède, et comment on arbitre avec la roadmap produit. La logique est la même que pour le recrutement d'un premier commercial B2B : avant de regarder le marché des profils, regardez ce que vous êtes réellement prêt à confier.

Écrire le mandat avant d'écrire la fiche de poste

Règle simple : si vous ne savez pas écrire le mandat en quatre lignes, vous n'êtes pas prêt à recruter. Le mandat, c'est le contrat qui rend un poste ou un pod exécutable plutôt que décoratif.

Les quatre lignes à remplir, dans cet ordre :

1. La métrique. Une seule, chiffrée, sur un horizon donné. Formulation type : « faire passer le taux d'activation à quatorze jours de X à Y d'ici la fin du trimestre ».
2. Le périmètre d'autorité. La liste explicite de ce qui peut être modifié sans demander la permission : landing pages, séquences email, onboarding dans le produit, page tarifs, campagnes payantes. Ce qui n'est pas dans la liste demande un arbitrage, et vous devez nommer qui arbitre.
3. Les ressources. Combien de jours de développement par sprint, quel budget de test mensuel, quels accès aux données. Un chiffre, pas une intention.
4. Le rituel et le sponsor. Quel rendez-vous hebdomadaire, qui y participe, et quel membre du comité de direction porte la décision quand ça coince.

Ce mandat vaut aussi bien pour un pod complet que pour un référent growth interne à temps partiel. Il tient sur une page, il se relit chaque trimestre, et il transforme un débat d'organigramme en engagement mesurable.

Il vous protège au passage d'un travers très répandu : évaluer l'équipe growth au nombre de tests lancés plutôt qu'à l'apprentissage produit et à l'impact réel. Les indicateurs à suivre sont détaillés dans les KPI essentiels d'un dashboard growth.

Quel modèle choisir selon votre taille et votre stade ?

Il n'existe pas de seuil magique en nombre de salariés, mais des configurations qui reviennent. Chez Growth Consult, nous avons accompagné 280 entreprises depuis 2012 et formé 2 750 professionnels : les schémas suivants se répètent avec une constance frappante.

• TPE et équipes de moins de dix personnes. Growth distribué, sans discussion. Le référent, c'est le dirigeant. Un rituel hebdomadaire de quarante-cinq minutes, un backlog partagé, deux tests en cours au maximum. Recruter un profil growth isolé à ce stade revient à payer un salaire pour un rituel que vous pouvez tenir vous-même.
• PME de dix à cinquante personnes, croissance portée par le commerce. Growth distribué renforcé : un référent identifié avec du temps protégé (une journée par semaine inscrite au planning, pas « quand il peut »), et une mesure propre. Le pod ne se justifie que le jour où vos tests deviennent majoritairement techniques.
• Scale-up ou éditeur de logiciel avec un produit en libre-service. Pod dédié. Vos leviers sont dans le produit, vos tests demandent du code, votre volume d'expériences dépasse ce qu'un référent peut absorber. C'est le seul cas où l'équipe dédiée est la réponse par défaut.
• Entreprise à plusieurs lignes de produit. Un pod par ligne, ou un pod central qui outille les autres équipes. Le pire choix reste un pod unique censé servir tout le monde : il devient un guichet, et un guichet n'expérimente pas, il traite des demandes.

Dans tous les cas, commencez par le plus petit engagement qui produit de la preuve. Un trimestre de rituel réellement tenu vaut mieux qu'un organigramme repensé. Pour voir ce que produit un cycle court et discipliné, regardez le cas 180 leads B2B en 7 jours.

La règle à retenir : une équipe growth dédiée amplifie une culture d'expérimentation existante, elle ne la crée pas. Montez le rituel d'abord, avec les gens que vous avez déjà. Structurez ensuite, quand le volume de tests et leur dépendance technique l'exigent vraiment.