Contexte

Thiga est l’une des références françaises du product management. En dix ans, l’entreprise a construit une position de leader sur son marché : un pôle consulting qui place des product managers et product designers en régie chez ses clients, et une Academy qui forme des professionnels en reconversion vers les métiers du produit. La Product Conf, l’événement de référence du secteur, complète ce dispositif en ancrant la légitimité de Thiga dans l’écosystème product. Deux géographies, France et Espagne. Un seul CRM HubSpot, en production depuis 2019.

Ce que Thiga a construit en une décennie est rare : une marque forte, une offre diversifiée, une présence internationale. C’est précisément cette trajectoire qui crée le problème. Quand une entreprise grandit vite, les outils s’accumulent en même temps que les équipes se succèdent. Chacune laisse ses workflows, ses propriétés, ses configurations. Sans protocole de gouvernance, sans propriétaire CRM clairement identifié, l’instance accumule des couches. Ce n’est pas de la négligence, c’est ce qui arrive inévitablement en hypercroissance.

Le point de départ : En début d’année 2025, Thiga sollicite Yuzu Corp pour une reconfiguration HubSpot. Le diagnostic initial est juste : la plateforme est sous-exploitée. Les équipes ont reproduit les process de Salesforce, leur CRM précédent, sans tirer parti des fonctionnalités propres à HubSpot. Les tableaux de bord se sont multipliés, la donnée désordonnée ne délivre pas la valeur stratégique attendue par la direction. Mais ce cadrage passait à côté du problème structurant. Reconfigurer HubSpot suppose qu’il existe un modèle commercial unique à organiser. 

Reconfigurer HubSpot suppose qu'il existe un modèle commercial unique à organiser.

Chez Thiga, il y en a deux. Un modèle B2B, où les cycles sont longs, les décisions se prennent au niveau de l’entreprise cliente, et la relation commerciale s’inscrit dans la durée. Et un modèle B2C, où l’unité est l’individu, les cycles sont courts, et la logique est celle de l’inscription et de la conversion. Ces deux modèles ont des cycles de vie différents, des critères de qualification différents, des logiques de scoring différentes. Les faire cohabiter dans une même instance HubSpot sans architecture dédiée, c’est accepter que la donnée d’un modèle interfère avec l’autre. C’est précisément ce qui s’était produit, progressivement, sur cinq ans.

Le déclencheur : L’audit technique réalisé en mars 2025 pose un état des lieux précis. La propriété « phase du cycle de vie » est la propriété pivot de tout CRM : c’est elle qui dit au système comment traiter chaque contact à chaque étape du parcours commercial.

Dans l’instance de Thiga, cette propriété était modifiée par au moins sept workflows concurrents, auxquels s’ajoutait une synchronisation native HubSpot entre entreprises et contacts, active en arrière-plan. L’instance HubSpot n’est pas isolée : l’audit Zapier réalisé en parallèle a révélé 122 automatisations, dont 112 déconnectées. Le CRM compromis avait contaminé toute la stack.

En pratique : lorsqu’une entreprise accédait au statut Client dans le CRM, la synchronisation native promouvait automatiquement tous les contacts associés à cette entreprise au même statut, y compris des prospects en cours de travail actif chez d’autres organisations. Un contact pouvait apparaître simultanément comme opportunité commerciale dans un pipeline et comme Client dans le cycle de vie. Les workflows de nurturing conçus pour les prospects passaient à côté de contacts que le système avait silencieusement reclassifiés.

Par ailleurs, un formulaire de contact sur le site de Thiga avait été configuré pour attribuer directement le statut SQL à toute soumission. Des contacts ayant simplement rempli un formulaire de prise de contact étaient classés comme Sales Qualified Leads, sans jamais passer par l’étape MQL. Chaque rapport mesurant la conversion MQL-vers-SQL reposait sur une base de départ faussée. À cela s’ajoutaient des automatisations obsolètes, toujours actives sur des contacts en production. Enfin, Dendreo, l’intégration connectant le LMS de l’Academy à HubSpot, était entièrement rompue.

L’impact sur le pilotage et la prise de décision

La direction générale de Thiga comprend HubSpot et cherche à s’appuyer sur les données pour piloter. Mais lorsque le modèle de données sous-jacent est structurellement incohérent, la maîtrise de l’outil ne change pas grand-chose. Les dashboards affichaient des chiffres calculés à partir de phases du cycle de vie qui ne reflétaient pas la réalité commerciale.

La question « combien de MQL ont été convertis en SQL ce trimestre ? » est le diagnostic de base d’un tunnel marketing B2B. Lors de l’audit du cycle de vie, Yuzu Corp a constaté que la majorité des contacts dans les listes d’analyse MQL étaient déjà classés SQL ou Client. L’analyse partait d’une donnée de départ corrompue. 

Côté marketing, 354 workflows actifs simultanément, dont 200 sans documentation, rendaient illisibles les chaînes d’automatisation. Les listes d’exclusion manquaient sur les envois email, ce qui dégradait les taux de délivrabilité. Les campagnes marketing produisaient de l’activité, mais leur impact sur les revenus restait flou.

Un problème d’architecture commerciale

Le problème de Thiga était un problème d’architecture commerciale sans précédent chez Yuzu Corp. Deux modèles aux logiques fondamentalement différentes partageaient le même espace de données, les mêmes propriétés, les mêmes workflows, les mêmes tableaux de bord. Dans ce contexte, les signaux produits par le CRM ne sont pas fiables : ils agrègent des logiques qui ne devraient pas l’être.

Un score de lead qui mélange des signaux B2B (fréquentation d’un événement entreprise, contact commercial senior) et des signaux B2C (inscription à une formation individuelle, participation à un webinaire Academy) n’est pas fiable. Un lifecycle stage qui suit le même chemin pour un candidat à la formation Academy et pour un directeur commercial en phase de deal consulting ne décrit pas la même réalité.

Ce schéma est rare, parce que peu d’entreprises font réellement coexister deux modèles commerciaux complets dans une même instance. Yuzu Corp ne recommande pas cette architecture comme point de départ. Mais elle devient de plus en plus fréquente au fur et à mesure que les sociétés de conseil, les éditeurs de logiciels et les plateformes de formation ajoutent des offres B2C à leurs activités B2B historiques. La question architecturale se pose alors avec une acuité particulière : comment séparer les données, les cycles de vie et les logiques de qualification sans perdre la vision unifiée du client ?

Thiga a posé cette question. Yuzu Corp y a répondu par une intervention en trois couches.

Étape 1 : Diagnostic structurel avant toute action

Avant de toucher une seule propriété ou de modifier un workflow, Yuzu Corp a cartographié l’état complet de l’instance : modèle de données, couche d’automatisation, structure de gouvernance, dépendances d’intégration. L’audit a produit une évaluation scorée sur huit dimensions et identifié trois projets prioritaires. Pas des tâches de nettoyage : des projets architecturaux impliquant des décisions explicites sur la structure du CRM.

Étape 2 : Architecture du cycle de vie comme intervention centrale

Le travail le plus déterminant a été la reconstruction de la logique du cycle de vie : centralisation de l’autorité de modification sur cette propriété, suppression des workflows concurrents, désactivation de la synchronisation entreprise-contact non maîtrisée, et établissement d’une source de vérité unique pour le parcours de chaque contact. Le framework MEDDIC a été déployé pour discipliner les données à chaque étape du pipeline commercial, y compris l’introduction de propriétés obligatoires à chaque transition d’étape.

Étape 3 : Gouvernance pour prévenir la rechute

• Les superadministrateurs sont passés de 18 à 8. 

• La création de propriétés a été encadrée. 

• Les 53 tableaux de bord commerciaux ont été remplacés par 4 vues synthétiques. 

• 34 tableaux de bord marketing ont été supprimés. 

Au-delà d'actions de nettoyage, Yuzu Corp a accompagné Thiga sur des décisions politiques. Le nettoyage traite les symptômes, tandis que la politique traite le système qui les produit. Ce niveau d'intervention n'est possible que si le partenaire comprend ce qu'il y a derrière l'outil. Thiga a choisi Yuzu Corp car l’équipe qui connaît le métier du conseil, ses cycles commerciaux, la logique de placement en régie et qui maîtrise HubSpot profondément pour en être owner, pas seulement exécutant. Sur un projet comme celui-ci, où chaque décision de configuration a des conséquences sur la façon dont la direction lit son business, cette différence n'est pas accessoire. Elle est centrale.

Impact sur le plan opérationnel

→ 12 pipelines réduits à 8.
→ 16 600 leads supprimés et entièrement reconfigurés avec une nouvelle logique de scoring.
→ 4 700 doublons traités.
→ 248 propriétés contacts réduites de 93,
→ 90 propriétés deals réduites de 19,
→ 30 propriétés entreprises réduites de 10.
→ Les 53 tableaux de bord commerciaux consolidés en 4 vues stratégiques.
→ 34 tableaux de bord marketing supprimés.
→ Framework MEDDIC déployé sur l'ensemble de l'équipe commerciale.

Impact sur le plan stratégique

L'enseignement principal du projet Thiga n'est pas technique, il porte sur la relation entre la croissance de l'entreprise et la gouvernance des données. Le CRM HubSpot était en place depuis 2019, plusieurs équipes s'étaient succédé. Chacune avait laissé des workflows, des propriétés, des configurations pensées pour des contextes qui n'existaient plus. Il n'existait aucun protocole pour décommissionner un administrateur CRM à son départ. 

L'entropie accumulée était le résultat naturel d'une croissance sans gouvernance explicite.

Ce n’est pas une spécificité de Thiga. C’est ce qui arrive à toutes les entreprises qui grandissent vite sans se retourner sur leurs outils. La vitesse est un avantage, mais elle a un coût : la dette technique qui s'accumule en silence.
Ce que ça révèle pour les entreprises B2B qui ajoutent une dimension B2C

Pour toute entreprise de conseil qui lance une Academy, une offre de formation ou un modèle d’abonnement B2C en parallèle de son activité historique, le risque est structurel. Chaque modèle a sa propre logique de cycle de vie, ses propres critères de qualification, ses propres métriques de conversion. HubSpot peut absorber cette complexité, à condition que l’architecture soit délibérée. Sans architecture délibérée, l’instance accumule des contradictions. Le scoring mélange des signaux incompatibles. Les tableaux de bord agrègent des données qui ne devraient pas l’être. Le lifecycle stage devient un champ contesté, réécrit par le dernier workflow exécuté. Le signal d’alerte est presque toujours le même : des tableaux de bord qui semblent remplis, mais dont les chiffres sont difficiles à croire. Des analyses de funnel dont les résultats ne correspondent pas à ce que les équipes observent sur le terrain. C’est un problème d’architecture, qui se résout par une décision sur qui possède la donnée, qui peut la modifier, et selon quelles règles métier.

Yuzu Corp ne recommande pas la cohabitation B2B / B2C dans une même instance comme choix de départ, mais lorsque cette configuration existe, elle se traite par une intervention architecturale, pas par du nettoyage.

L’Academy : un chantier structurant en phase active

À la clôture de la phase de build, le périmètre Academy représentait encore environ 20 % du CRM non traité, avec 43 workflows dédiés, une soixantaine de formulaires marketing, et une connexion avec le LMS pédagogique à reconstruire sur le modèle de données cible. Ce n’est pas un échec du projet : c’est une mesure honnête de la complexité réelle qu’implique la cohabitation de deux modèles commerciaux dans une même instance. L’architecture Academy fait l’objet d’un chantier dédié dans la phase Maintenance & Évolution (MCO), en cours avec les équipes Thiga.