Un sandbox CRM est-il gratuit ?

Cela dépend de l'éditeur. HubSpot propose des comptes de test développeur gratuits (jusqu'à 10 par compte standard), mais le sandbox standard exige un abonnement Enterprise. Pipedrive fournit un compte sandbox développeur sur inscription.

Peut-on tester avec une copie des vraies données du client ?

Il vaut mieux l'éviter : des données réelles dans un environnement de test élargissent le nombre de personnes et d'outils qui y accèdent. Utilisez des données fictives, et copiez la structure du compte plutôt que son contenu.

Un compte de test peut-il disparaître ?

Oui. HubSpot indique qu'un compte de test développeur expire après 90 jours sans appel API ; Pipedrive supprime les comptes sandbox développeur inactifs. Prévoyez de pouvoir recréer l'environnement par script.

Sandbox CRM : tester une intégration sans risque

Tester une intégration sur le CRM de production d'un client, c'est risquer de créer des affaires en double, d'écrire sur de vraies fiches ou d'envoyer un message à un vrai contact. Un environnement de test (sandbox, « bac à sable ») sert à éviter cela : un compte séparé où l'on peut se tromper. Tous les CRM n'en offrent pas le même, et les conditions changent d'un éditeur à l'autre. Voici la méthode générale, ce que disent les documentations de HubSpot, Pipedrive et Zoho lues le 15/11/2026, et une checklist de recette.

Test et production : ce qui doit différer

Un bon environnement de test sépare trois choses :

les identifiants : application, secrets et jetons propres à l'environnement de test, jamais ceux de la production (la mise en place d'OAuth est décrite dans Connexion OAuth à un CRM) ;
les adresses : l'assistant de test appelle le compte de test, et ses webhooks pointent vers un serveur de test ;
les données : fictives, voir plus bas.

Gardez la même configuration de champs, de pipelines et de droits que chez le client : une intégration qui marche sur un compte vide peut échouer sur un champ obligatoire de la production.

Ce que proposent réellement les CRM

CRM	Ce que dit la documentation lue
HubSpot	Compte de test développeur : compte gratuit, essai de 90 jours de nombreuses fonctions Enterprise, jusqu'à 10 par compte HubSpot standard. Sandbox standard : abonnement Enterprise requis ; il copie la structure du compte standard. Sandbox de développement : abonnement Enterprise, créé et géré uniquement par la CLI HubSpot.
Pipedrive	Compte sandbox développeur : obtenu par un formulaire sur le site développeurs, « essentially like a regular Pipedrive company account », 5 sièges par défaut.
Zoho CRM	Sandbox : environnement isolé qui protège la production ; plusieurs environnements possibles sous un même compte ; les modifications validées peuvent être déployées vers la production (la page cite workflows, Blueprints et pages Canvas).
Salesforce	Non lu pendant cette session : la page d'aide de l'éditeur n'a pas pu être consultée. Vérifiez les types de sandbox et leurs limites sur la documentation officielle avant de chiffrer.

HubSpot : trois niveaux

Le compte de test développeur a des limites listées sur la page : les e-mails marketing ne partent qu'aux adresses des utilisateurs ajoutés au compte de test ; les workflows sont plafonnés à 100 000 enregistrements inscrits par jour ; les comptes de test ne peuvent pas synchroniser de données avec d'autres comptes. Il expire après 90 jours sans appel API ; on le renouvelle à la main ou par un appel API, au plus tôt 30 jours avant la date d'expiration. Le sandbox standard, lui, suppose un abonnement Enterprise chez le client. La page ne précise pas ce que ces comptes copient, ni les limites des sandbox : posez la question à l'éditeur si votre recette en dépend. Voir aussi le chatbot IA sur HubSpot.

Pipedrive : un compte développeur

Le compte sandbox sert de bac à sable avec accès au Developer Hub. Il se conserve en restant actif : la page le dit inactif s'il n'y a aucune application créée dans les 45 jours suivant l'inscription, ou aucune application publique publiée ni privée mise en ligne dans les six mois, et les comptes inactifs sont supprimés. La page ne détaille pas les différences avec la production. Le budget d'appels et les webhooks sont décrits dans l'intégration API Pipedrive.

Zoho : des sandbox sous le compte

La page lue vante un environnement isolé où l'on teste règles de workflow, Blueprints, pages Canvas et e-mails. Elle explique que l'Outbox (Setup > Data Administration > Email Outbox) permet de vérifier les champs de fusion et les conditions de déclenchement. Elle ne dit rien des éditions requises, des types de sandbox, des éléments copiés ni des limites : à vérifier ailleurs. Voir le chatbot IA sur Zoho CRM.

Des données fictives, jamais de vraies données clients

Un compte de test se remplit avec des données inventées. Les raisons sont pratiques autant que prudentes : on évite d'envoyer un message de test à un vrai contact, et de laisser des données personnelles dans un outil où trop de monde a accès. Quelques règles :

des noms, des adresses de messagerie et des numéros manifestement faux (adresses sur un domaine que vous maîtrisez ou réservé aux exemples) ;
un jeu assez varié pour les cas difficiles : fiche sans e-mail, deux contacts homonymes, affaire sans montant, champ très long, caractères accentués ;
un volume suffisant pour tester la pagination et les limites d'appels, créé par un script rejouable ;
une remise à zéro simple : recréer l'environnement doit prendre minutes, pas jours, d'autant que certains comptes de test expirent ;
aucune copie de données de production sans accord écrit du client et sans anonymisation. Dans le doute, ne copiez que la structure.

Checklist de recette

À dérouler dans l'environnement de test, puis à reprendre en production sur un périmètre réduit :

Autorisation : connexion OAuth réussie, scopes au minimum, rafraîchissement du jeton testé, refus et révocation traités.
Lecture : l'assistant trouve la bonne fiche, y compris avec les cas difficiles du jeu fictif.
Écriture : chaque action d'écriture est testée une fois, puis rejouée pour vérifier qu'elle ne crée pas de doublon (voir la gestion des erreurs d'un flux).
Droits : l'assistant ne voit que ce que l'utilisateur qui l'interroge a le droit de voir.
Pannes : coupez le serveur, renvoyez des erreurs, dépassez les limites d'appels ; vérifiez alertes et rattrapage.
Webhooks : réception, doublons, délai de réponse.
Volume : estimation des appels par jour comparée aux limites du CRM.
Messages sortants : aucun courriel ou message ne part vers un tiers réel depuis l'environnement de test.
Reprise : l'environnement se recrée par script.
Passage en production : liste des changements à reproduire, par qui, avec quel retour arrière.

La recette fait partie du cadrage : cadrer un projet d'assistant IA liste ce qu'il faut convenir avec le client avant de commencer.

À retenir

Un sandbox n'est pas une copie conforme de la production : lisez ce que votre éditeur copie vraiment, et ce qu'il ne copie pas. Partez de l'idée que la recette finale se fait en deux temps : l'intégralité sur le compte de test, puis un essai limité chez le client.