La plupart des implémentations HubSpot qui tournent mal ne tournent pas mal parce que l'équipe a choisi le mauvais outil ou le mauvais consultant. Elles tournent mal parce que quelqu'un a compressé une phase. L'arc d'implémentation en a cinq, Discovery, Design, Build, Launch, Optimize, et chacune se termine par un artefact que l'équipe défendra. Sautez l'artefact et la phase suivante repose sur la conversation plutôt que sur l'engagement. Le coût se voit deux mois plus tard, quand Build rouvre des décisions qui auraient dû se fermer en deuxième semaine.
Pourquoi cela compte maintenant
Le brief HBR sur les raisons pour lesquelles les investissements digitaux échouent à créer de la valeur posait la chose simplement : le mode de défaillance n'est pas l'outillage, c'est l'incapacité à repenser comment l'organisation commerciale génère de l'insight, prend des décisions et coordonne ses actions. Une implémentation HubSpot est l'un des rares moments à l'intérieur d'une entreprise B2B SaaS où cette refonte est forcée à découvert, schéma, Pipelines, ownership, reporting, tout sur la table en même temps. La méthodologie en cinq phases existe parce que la refonte est le travail. La configuration de la plateforme est l'artefact à la fin.
Discovery
Discovery est la phase que les équipes compressent le plus souvent, et où la compression coûte le plus cher. Le job n'est pas de parler aux gens. Le job est de repartir avec un artefact écrit que toute l'équipe a validé , définitions de Pipeline, owners nommés pour chaque objet, carte d'intégration, cas d'usage in-scope et out-of-scope, et les critères de succès contre lesquels l'implémentation sera mesurée. Deux semaines, c'est un budget juste. Une semaine produit une phase Design qu'il faut refaire.
À quoi ressemble le mauvais , un deck Discovery qui liste les outils en usage, quelques citations d'interview, et un set vague d'objectifs. Personne n'est en désaccord parce que rien n'est assez spécifique pour l'être. Design découvre ensuite les désaccords un par un, devant un développeur qui attend une direction.
Design
Design est la phase où les décisions de schéma vivent. Chaque objet qui existera dans le portail de production: Contact, Company, Deal, l'objet d'abonnement custom, l'objet portfolio s'il y en a un, est défini ici, par écrit, avant qu'on ne construise quoi que ce soit. Les propriétés reçoivent un type de donnée, une picklist si pertinent, un owner et une définition d'une phrase. Les stages de Pipeline reçoivent des critères d'entrée, de sortie et une définition de ce que le stage signifie réellement. Les labels d'association sont écrits. Le livrable à la fin de Design est un document de schéma plus un inventaire des workflows que l'équipe peut lire de bout en bout sans poser de questions.
À quoi ressemble le mauvais , du Design qui se passe à l'intérieur de l'UI HubSpot en cliquant. Les propriétés sont ajoutées en live. Les stages de Pipeline sont renommés trois fois. Le document de schéma, s'il existe, retarde le build d'une semaine. Trois mois plus tard, personne ne se souvient pourquoi le stage Deal « Verbal » existe, et la seule personne qui pourrait répondre est partie.
Build
Build est la phase de sprint. Bien fait, c'est une séquence de deux à six semaines de petits livrables scopés et relisables : schéma déployé en sandbox, workflows câblés, intégrations connectées, rapports montés, sets de permissions configurés. La cadence qui tient est hebdomadaire , une working session pour confirmer la prochaine tranche, un sprint de build en milieu de semaine, une démo à la fin. La cadence qui ne tient pas est le check-in toutes les deux semaines où l'équipe de build disparaît et réapparaît avec un portail fini que personne n'a vu.
Build ne marche que si Discovery et Design ont tenu. Si oui, Build est de l'exécution contre une liste. Si non, Build est des disputes habillées en standups. Le test diagnostique , dans une semaine de Build donnée, combien de décisions sont rouvertes ? Si la réponse est plus d'une ou deux, le travail amont n'était pas fini.
Launch
Launch est cutover, formation et les dix premiers jours. Le cutover est un vendredi, de préférence avant une semaine calme, et il est répété en sandbox avant d'avoir lieu en production. La formation est délivrée contre le système post-build, pas contre le legacy, et elle est délivrée aux gens qui utiliseront réellement le système, pas seulement aux leaders qui l'ont scopé. Les dix premiers jours sont une fenêtre d'hypercare , l'équipe de build est on-call, les problèmes utilisateur sont triés en heures plutôt qu'en jours, et les petits correctifs qui apparaissent dans l'usage réel atterrissent avant que l'équipe ne forme une mémoire musculaire autour de workarounds.
À quoi ressemble le mauvais , un Launch qui se passe un mercredi parce que le calendrier l'a dit, un deck de formation enregistré une fois et diffusé en vidéo, et une équipe de build qui démobilise le lendemain du cutover. En troisième semaine les workarounds sont des habitudes, les workarounds sont maintenant le système, et la phase Optimize les défera plutôt que de les améliorer.
Optimize
Optimize est la phase pour laquelle personne ne planifie de budget. L'implémentation est scopée jusqu'à Launch ; Optimize est traité comme le travail admin à temps partiel de quelqu'un. C'est l'erreur. Chaque instance HubSpot accumule , de nouvelles propriétés sont demandées, les workflows attrapent des cas limites, les besoins de reporting évoluent, l'équipe apprend ce qu'elle veut vraiment voir versus ce qu'elle pensait vouloir voir. Optimize est la phase où ces signaux sont triés sur une cadence, mensuelle convient à la plupart des entreprises, plutôt qu'absorbés dans le bruit quotidien.
À quoi ressemble le mauvais , Optimize est ce que la personne ops senior peut traiter entre deux incendies. Six mois plus tard, le système a dérivé du schéma documenté, personne n'a audité les workflows depuis le launch, et la prochaine personne à rejoindre l'équipe hérite d'une instance qui est aux deux tiers du design d'origine et un tiers d'improvisation. Le budget d'optimisation que personne n'avait planifié est maintenant le projet de migration que personne ne voulait.
Cas observé sur le terrain
Une équipe B2B SaaS en fin de Series A est venue pour une implémentation HubSpot sur un calendrier de six semaines. Discovery était scopé sur quatre jours. Nous avons poussé en arrière et l'avons fait tourner deux semaines. L'artefact était un document couvrant les définitions de Pipeline, l'ownership, le périmètre d'intégration, les critères de succès, et une liste de cas d'usage que l'équipe a accepté de mettre out-of-scope pour la v1. Design a pris trois semaines et produit un document de schéma plus un inventaire de workflows. Build a été un sprint propre de quatre semaines: démos hebdomadaires, aucune décision rouverte. Launch a été un cutover du vendredi avec une fenêtre d'hypercare d'une semaine staffée par l'équipe de build. Optimize a démarré trente jours après launch sur une cadence mensuelle et tourne toujours. La pièce qui mérite d'être nommée , la première business review trimestrielle de l'équipe sur le nouveau système n'a pas exigé de nettoyage manuel des données. C'est ce que vous achète une Discovery non compressée, dix mois plus tard.
Résolution , choisir le modèle d'engagement qui mappe à chaque phase
Les cinq phases n'ont pas à vivre dans un seul type d'engagement. Différentes phases récompensent différentes formes de support. Le mapping qui tient sur la plupart des missions B2B SaaS :
- Discovery est un workshop ou un projet étroitement scopé. Il a besoin d'attention senior, d'une perspective extérieure, et d'un livrable que l'équipe interne validera. Pas besoin d'un retainer long.
- Design est un projet. Le livrable est un document de schéma et workflows, le budget est fixe, le calendrier deux à quatre semaines. Traitez-le comme tel.
- Build est un projet ou une mission embarquée, selon la part de configuration que l'équipe interne peut absorber. Si vous avez un admin HubSpot en poste, la forme projet marche. Sinon, embarquez quelqu'un pour la durée.
- Launch est un projet avec une queue d'hypercare. Scopez le cutover, la formation et les dix premiers jours comme un seul bloc. Ne dépendez pas de la bonne volonté de l'équipe de build pour staffer la queue.
- Optimize est là où le retainer ou le support fractionnel rentabilise sa place. Cadence mensuelle, heures scopées, backlog défini. L'erreur est d'acheter un retainer avant que Discovery ne soit finie ; l'autre erreur est de le laisser expirer le lendemain de Launch.
- Cross-phase : si l'équipe interne n'a pas encore de fonction RevOps senior, un rôle fractionnel embarqué sur Discovery, Design et Optimize est souvent la bonne forme. Build reste un projet.
- Check de stade : en seed et pré-Series A, la forme projet est presque toujours juste, l'équipe interne n'est pas encore prête à absorber un retainer. À partir de Series B, le modèle retainer ou fractionnel se rembourse généralement en deux trimestres, parce qu'Optimize cesse d'être l'activité secondaire de quelqu'un.
Là où Checkpoint intervient
La méthodologie en cinq phases est l'épine dorsale de chaque mission HubSpot et CRM que nous menons chez Checkpoint. Les implémentations greenfield enchaînent les phases dans l'ordre. Les migrations brownfield démarrent Discovery par l'audit. Les redesigns rallongent Design et raccourcissent Build. Les phases restent ; les proportions changent. Si vous scopez une implémentation maintenant et que le calendrier ne nomme pas les cinq, parlez-nous avant le kickoff. Nous faisons ce travail comme implémentation HubSpot, dans le cadre de la GTM strategy, et comme support RevOps embarqué sur l'ensemble de la stack.
Sources
- Sinha, Shastri, Lorimer. « Why Your Digital Investments Aren't Creating Value. » Harvard Business Review, 16 février 2026. hbr.org
- Lemkin, Jason. « Which CRM Should You Use in 2026/2027? Follow the Agents. » SaaStr, 6 avril 2026. saastr.com