Comment tester et déployer une modification avec HubSpot Sandbox ?

Chaque modification doit être soigneusement pesée et vérifiée. Un changement sur une propriété, un workflow ou un pipeline peut avoir des conséquences sur plusieurs outils, tableaux de bord et équipes.

C’est dans cette logique que HubSpot met à disposition de ses clients disposant d’abonnements avancés un environnement de test séparé : la Sandbox. Elle permet d’expérimenter, de valider les évolutions et de préparer leur déploiement avant d’intervenir sur le compte principal.

Pourquoi encadrer les modifications réalisées dans HubSpot ?

Lorsqu’une entreprise commence à utiliser HubSpot, son fonctionnement reste généralement simple. Quelques utilisateurs enregistrent des contacts, suivent des transactions et envoient des campagnes marketing.

Progressivement, de nouvelles fonctionnalités sont ajoutées :

• attribution automatique des prospects ;
• scoring des contacts ;
• workflows marketing ;
• pipelines commerciaux ;
• création automatique de tâches ;
• synchronisation avec d’autres logiciels ;
• tableaux de bord destinés à la direction ;
• gestion des tickets clients.

Chaque nouvelle automatisation crée des dépendances. Une propriété utilisée à l’origine pour qualifier les prospects peut ensuite servir à déterminer leur commercial, leur campagne marketing ou leur niveau de priorité.

Pour en savoir plus, allez consulter :  Suivi des utilisateurs et automatisation : HubSpot à l’épreuve du terrain

Une modification réalisée sans analyse préalable peut alors entraîner plusieurs conséquences : des prospects affectés au mauvais commercial, des opportunités absentes des prévisions, des e-mails envoyés à un segment incorrect ou des données écrasées par une intégration.

La sandbox limite ainsi le risque en permettant de tester les changements sans agir directement sur les utilisateurs et les données du compte principal. HubSpot recommande d’ailleurs de définir clairement l’objectif de chaque sandbox, les personnes autorisées à y accéder et les usages auxquels elle est destinée.

Quelles sont les questions à se poser ?

Cette organisation doit être proportionnée à la taille de l’entreprise. Une PME n’a pas nécessairement besoin d’un processus informatique complexe. Elle doit toutefois pouvoir répondre à quatre questions avant chaque changement important :

1. Que souhaite-t-on modifier ?
2. Quels processus risquent d’être affectés ?
3. Qui doit vérifier le résultat ?
4. Comment revenir à une situation stable en cas de problème ?

Quelles modifications doivent être testées dans la sandbox ?

Toutes les modifications ne présentent pas le même niveau de risque. Imposer un passage dans la sandbox pour chaque changement de libellé ralentirait inutilement les équipes.

L’entreprise peut classer ses modifications selon trois niveaux.

Niveau	Exemples de modifications	Procédure recommandée
Risque faible	Correction d’un libellé, ajout d’une vue, modification d’un texte interne	Contrôle simple avant publication
Risque moyen	Nouvelle propriété, formulaire, liste, étape de pipeline ou tableau de bord	Test par l’administrateur et un utilisateur métier
Risque élevé	Workflow, scoring, intégration, migration, nouvelle structure de données	Test complet dans la sandbox et validation formelle

Les modifications à faible risque

Les changements facilement réversibles peuvent souvent être réalisés directement dans le compte de production.

Il peut s’agir de corriger le nom d’une vue, de créer un rapport destiné à un seul utilisateur ou d’ajouter une description à une propriété.

Même pour ces changements, l’administrateur doit vérifier que l’élément n’est pas utilisé par une automatisation ou une intégration. Une propriété apparemment secondaire peut avoir un rôle plus important qu’il n’y paraît.

Les modifications à risque intermédiaire

La création d’une propriété, d’un formulaire ou d’une nouvelle étape commerciale doit généralement être testée.

Prenons l’exemple d’une entreprise qui ajoute l’étape « Proposition envoyée » dans son pipeline. Cette évolution peut avoir une incidence sur les probabilités de signature, les prévisions de chiffre d’affaires, les workflows et les rapports de performance.

Le fonctionnement technique doit donc être vérifié, mais également sa compréhension par les commerciaux.

Les modifications à risque élevé

Les workflows, les intégrations et les migrations doivent presque systématiquement être testés dans un environnement séparé.

Le risque augmente lorsque la modification :

• agit sur un grand nombre de fiches ;
• déclenche des communications externes ;
• modifie des données existantes ;
• dépend de plusieurs outils ;
• affecte les prévisions financières ;
• est difficilement réversible.

HubSpot propose une fonctionnalité permettant de simuler le parcours d’une fiche dans un workflow. Elle vérifie les critères d’inscription, prédit les branches suivies et affiche les actions attendues sans les exécuter réellement.

Cette simulation est utile, mais elle ne remplace pas les tests complets réalisés dans la sandbox, notamment lorsque plusieurs workflows ou logiciels interagissent.

Qui doit participer aux tests ?

Une configuration peut être parfaitement construite tout en étant incompatible avec les habitudes ou les besoins des équipes.

Un processus de validation efficace réunit plusieurs rôles.

Le demandeur du changement

Il s’agit généralement d’un responsable marketing, commercial ou service client. Il exprime le problème à résoudre et décrit le résultat attendu.

Son rôle n’est pas nécessairement de construire la solution. Il doit surtout expliquer le fonctionnement métier recherché.

Par exemple, le responsable commercial peut demander que les prospects provenant de partenaires soient affectés à une équipe spécifique. Il doit alors préciser les partenaires concernés, les commerciaux éligibles et la manière de traiter les exceptions.

L’administrateur HubSpot

L’administrateur traduit le besoin dans HubSpot. Il identifie les propriétés, workflows, listes, pipelines ou intégrations concernés.

Il prépare également les scénarios de test et vérifie les dépendances. Ce rôle peut être occupé par un salarié, un responsable RevOps ou un prestataire externe.

Les droits de super administrateur étant nécessaires pour créer une sandbox standard et déployer des ressources vers la production, ces autorisations doivent rester attribuées à un nombre limité de personnes.

Les utilisateurs métier

Les utilisateurs finaux doivent tester le futur processus. Un commercial peut vérifier qu’il reçoit la bonne tâche, qu’il comprend le nouveau pipeline et qu’il trouve facilement les informations demandées.

Cette étape permet de détecter des problèmes que l’administrateur ne verra pas forcément : intitulé ambigu, saisie trop longue, notification peu claire ou multiplication inutile des champs.

Le responsable de la validation

Une personne doit prendre la décision finale de déployer ou de reporter le changement.

Pour une modification commerciale, ce rôle peut revenir au directeur commercial. Pour une automatisation marketing, la validation peut être confiée au responsable marketing.

Le dirigeant n’a pas besoin d’approuver chaque changement. Il doit intervenir lorsque le projet affecte plusieurs services, les données stratégiques, l’expérience client ou les indicateurs utilisés pour piloter l’entreprise.

Comment construire un scénario de test efficace ?

Un test ne consiste pas simplement à cliquer sur quelques boutons pour vérifier qu’aucune erreur ne s’affiche. Il doit reproduire une situation réelle et comparer le résultat obtenu au résultat attendu.

Chaque scénario peut être présenté sous la forme suivante :

Étant donné une situation de départ, lorsqu’une action précise est réalisée, le système doit produire un résultat déterminé.

Exemple de scénario commercial

Situation de départ : un nouveau prospect provenant du formulaire « Demande de démonstration » est situé en Île-de-France.

Action : le prospect valide le formulaire.

Résultats attendus :

• le contact est créé ou mis à jour ;
• la source du prospect est correctement renseignée ;
• le contact est attribué au bon commercial ;
• une tâche de rappel est créée ;
• le commercial reçoit une notification ;
• le prospect rejoint la bonne liste ;
• aucun doublon n’est généré.

Cette présentation oblige l’entreprise à définir ce qu’elle attend réellement de son automatisation.

Tester le parcours principal

Le premier test doit couvrir le cas le plus fréquent : un prospect correctement renseigné, une transaction classique ou un ticket traité selon le processus normal.

Ce scénario permet de vérifier que le fonctionnement général correspond au besoin.

Tester les cas particuliers

Les erreurs apparaissent souvent dans les situations moins courantes. Il faut donc tester plusieurs variantes :

• un contact sans numéro de téléphone ;
• une entreprise déjà présente dans le CRM ;
• un prospect situé hors de la zone commerciale ;
• une fiche sans propriétaire ;
• une transaction réouverte après avoir été perdue ;
• un contact déjà passé dans le workflow ;
• une donnée reçue dans un format inattendu.

Le test intégré aux workflows HubSpot permet notamment de vérifier les critères d’inscription et de simuler les différentes branches à partir de l’état actuel d’une fiche. Il faut néanmoins tenir compte des paramètres de réinscription, des temporisations et de la version exacte du workflow lorsqu’un incident passé est analysé.

Tester les conséquences indirectes

Une modification ne doit pas être analysée uniquement dans l’outil qui l’a déclenchée.

Lorsqu’une propriété est mise à jour, il faut vérifier :

• les workflows qui l’utilisent ;
• les listes auxquelles elle participe ;
• les rapports qu’elle alimente ;
• les intégrations qui la synchronisent ;
• les règles d’accès qui la concernent.

Cette vérification évite de résoudre un problème local tout en en créant un autre ailleurs.

Conserver une preuve des tests

L’entreprise peut tenir un document simple comprenant le nom du testeur, la date, le scénario, le résultat obtenu et les éventuelles anomalies.

Cette documentation devient particulièrement utile lorsque plusieurs personnes interviennent ou lorsque le changement doit être expliqué quelques mois plus tard.

Comment préparer le passage en production ?

Une fois les tests validés, le changement doit être préparé pour son déploiement dans le compte principal.

Les deux environnements peuvent donc s’être éloignés depuis la création de la sandbox.

Vérifier l’écart entre les deux environnements

Avant le déploiement, l’administrateur doit s’assurer qu’aucune modification récente réalisée en production ne crée de conflit.

Si le projet a duré plusieurs semaines, une propriété ou un workflow peut avoir évolué entre-temps.

HubSpot recommande d’ailleurs de supprimer et de recréer régulièrement les sandboxes destinées au développement actif afin qu’elles reflètent plus fidèlement les ressources du compte principal.

Identifier ce qui peut réellement être déployé

Le déploiement depuis la sandbox ne copie pas automatiquement tous les changements.

La documentation HubSpot indique que seules les nouvelles ressources prises en charge peuvent être déployées. Les modifications apportées dans la sandbox à une ressource déjà présente dans le compte de production ne sont généralement pas éligibles au déploiement automatique.

Cette distinction est essentielle.

Il peut alors être nécessaire de reproduire manuellement certaines modifications dans le compte principal.

Parmi les ressources nouvellement créées pouvant être prises en charge figurent notamment certains workflows, propriétés personnalisées, pipelines, formulaires, segments et e-mails marketing automatisés. Les paramètres d’accès, certains réglages, les dossiers ou les associations avec des campagnes peuvent toutefois nécessiter une configuration manuelle après le déploiement.

Vérifier les dépendances

Une automatisation dépend rarement d’une seule ressource.

Un workflow peut utiliser une nouvelle propriété, une liste, un formulaire et un e-mail automatisé. Si l’un de ces éléments manque, le workflow ne pourra pas fonctionner correctement.

Lors de la préparation du déploiement, HubSpot affiche les ressources connectées nécessaires et détecte certains conflits. La plateforme permet de déployer jusqu’à 300 modifications dans une même opération.

Même si cette limite autorise des déploiements importants, il reste préférable de procéder par ensembles cohérents. Une publication comprenant uniquement les éléments d’un même processus sera plus simple à contrôler qu’un déploiement mêlant plusieurs projets indépendants.

Choisir le bon moment

Les changements importants doivent être déployés lorsque les personnes capables d’intervenir sont disponibles.

Une mise en production le vendredi soir peut sembler pratique parce que peu d’utilisateurs sont connectés. Elle devient problématique si aucun administrateur ou prestataire n’est disponible le week-end pour corriger une anomalie.

Le meilleur moment est généralement une période de faible activité suivie de quelques heures pendant lesquelles les équipes peuvent surveiller le fonctionnement.

Informer les utilisateurs

Les collaborateurs doivent être prévenus lorsque la modification change leur manière de travailler.

Le message peut indiquer :

• la date du changement ;
• les fonctionnalités concernées ;
• les nouvelles actions attendues ;
• les personnes à contacter en cas de problème.

Une courte démonstration peut être plus efficace qu’un long document, notamment pour un nouveau pipeline ou une nouvelle procédure de qualification.

Que faire en cas d’erreur après le déploiement ?

La sandbox réduit les risques, mais elle ne garantit pas qu’aucun problème n’apparaisse en production.

Les données, les utilisateurs et les intégrations ne sont pas nécessairement identiques dans les deux environnements. Les identifiants internes des contacts, entreprises, transactions, tickets et objets personnalisés diffèrent notamment entre la sandbox et la production. Les intégrations du compte principal ne sont pas non plus reconnectées automatiquement dans la sandbox.

Il faut donc préparer un plan de retour à une situation stable.

Documenter l’ancienne configuration

Avant une modification sensible, l’administrateur doit conserver les informations nécessaires pour reconstituer le fonctionnement précédent :

• captures d’écran ;
• export des données concernées ;
• valeurs des propriétés ;
• critères d’inscription ;
• étapes du pipeline ;
• paramètres des workflows ;
• liste des ressources dépendantes.

Cette documentation n’est pas une sauvegarde complète, mais elle accélère les corrections.

Prévoir une procédure d’arrêt

Pour une automatisation, l’entreprise doit savoir comment désactiver rapidement le workflow, interrompre une synchronisation ou suspendre un envoi.

Lorsqu’une erreur est détectée, l’objectif prioritaire n’est pas de comprendre immédiatement toutes ses causes. Il faut d’abord empêcher le problème de continuer à produire des effets.

Ne pas compter sur une annulation automatique

Une fois qu’un déploiement vers la production est lancé, HubSpot indique qu’il ne peut plus être annulé. Les erreurs doivent ensuite être corrigées directement dans le compte principal ou au moyen d’une nouvelle intervention.

Cette limite renforce l’importance de déployer progressivement et de vérifier une dernière fois les ressources sélectionnées.

Contrôler les données déjà modifiées

Désactiver un workflow arrête les prochaines actions, mais ne corrige pas nécessairement les fiches déjà modifiées.

Il faut identifier :

• les contacts inscrits ;
• les propriétés mises à jour ;
• les tâches créées ;
• les notifications envoyées ;
• les données transmises à d’autres logiciels.

L’entreprise pourra ensuite décider si une correction automatique est possible ou si certaines fiches doivent être traitées manuellement.

Quels indicateurs suivre après une mise en production ?

Le suivi ne doit pas se limiter à vérifier que le déploiement affiche le statut « terminé ». Plusieurs indicateurs permettent d’évaluer la réussite du changement.

Le nombre d’erreurs techniques

Il faut surveiller les erreurs de workflows, les échecs de synchronisation, les ressources non déployées et les anomalies visibles dans le journal d’activité.

HubSpot permet de consulter l’historique de création des sandboxes, les déploiements réalisés et les éventuels échecs de ressources.

Le volume de fiches traitées

Le nombre de contacts, transactions ou tickets concernés doit rester cohérent avec les prévisions.

Un workflow qui inscrit soudainement 20 000 contacts alors que l’entreprise en attendait 200 signale probablement un critère trop large.

La qualité des données

Après le déploiement, l’entreprise peut mesurer :

• le taux de propriétés complétées ;
• le nombre de valeurs incohérentes ;
• l’apparition de doublons ;
• le nombre de fiches sans propriétaire ;
• les écarts entre HubSpot et les logiciels connectés.

L’adoption par les utilisateurs

Une évolution techniquement réussie peut échouer si les collaborateurs ne l’utilisent pas.

L’entreprise peut donc observer le nombre de fiches réellement complétées, le respect des nouvelles étapes et les questions adressées à l’administrateur.

L’impact sur le processus métier

Le changement doit enfin produire le résultat qui avait justifié le projet.

Selon le cas, l’entreprise pourra suivre le délai d’attribution des prospects, la vitesse de traitement des tickets, le taux de conversion ou la fiabilité des prévisions commerciales.

La checklist avant de déployer une modification HubSpot

Avant chaque mise en production importante, l’administrateur peut vérifier les points suivants :

• le besoin métier est clairement défini ;
• les ressources concernées ont été identifiées ;
• les dépendances ont été analysées ;
• le scénario principal a été testé ;
• les principaux cas d’erreur ont été simulés ;
• un utilisateur métier a validé le fonctionnement ;
• les différences entre la sandbox et la production ont été contrôlées ;
• les éléments non déployables automatiquement sont connus ;
• une procédure d’arrêt ou de correction a été préparée ;
• les collaborateurs concernés ont été informés ;
• une personne est disponible pour surveiller le déploiement.

Conclusion

HubSpot Sandbox ne sécurise pas à elle seule les modifications du CRM. Son efficacité dépend de la méthode utilisée pour sélectionner les changements à tester, répartir les responsabilités et contrôler le passage en production.

Pour une PME, cette organisation peut rester simple : un responsable, quelques scénarios documentés et une validation par les utilisateurs concernés. Lorsque HubSpot devient central dans l’acquisition, la vente ou le service client, cette discipline permet d’éviter que chaque évolution du CRM ne se transforme en risque opérationnel.

FAQ sur la sécurisation des modifications via HubSpot Sandbox

FAQ sur les tests dans HubSpot Sandbox