Quand développer une application privée
Les trois conditions à réunir avant de coder, les fragilités d'une application privée, et les bornes du code exécuté dans un workflow.
À partir de quand faut-il développer sur mesure plutôt que d'utiliser ce qui existe, et qu'est-ce que cela engage ?
Trois conditions doivent être réunies. Si une seule manque, cherchez encore du côté de l'existant.
- Aucune application du marketplace ne couvre le besoin, après avoir lu sa section des données partagées.
- La logique ne tient pas dans un workflow ni dans un automatiseur.
- Quelqu'un maintiendra le code dans deux ans, et cette personne est identifiée.
Sur le comment, deux voies existent. Une application privée pour un usage interne à votre portail, gratuite mais réservée aux super administrateurs et plafonnée à vingt par portail. Ou la plateforme développeur si l'intégration doit être distribuée, les applications publiques héritées ne pouvant plus être créées depuis juin 2026.
Le piège à connaître. Si vous retirez l'utilisateur qui a créé une application privée, certains appels échouent avec une erreur d'autorisation. Créez-la donc avec un compte de service, jamais avec un compte nominatif.
Pourquoi une application privée dépend de son créateur
Une application privée porte une fragilité organisationnelle rarement anticipée. Si vous retirez l'utilisateur qui l'a créée, certains appels échouent avec une erreur d'autorisation. Le montage technique dépend donc d'une personne, ce qui est exactement ce qu'on cherche à éviter.
Deuxième fragilité, la perte silencieuse de portées. Une application privée perd l'accès à des portées quand le compte est rétrogradé. L'intégration cesse de fonctionner sans qu'un changement de code l'explique.
Troisième contrainte, la rotation des jetons. Supprimer une application révoque définitivement son jeton d'accès. Une rotation avec expiration différée laisse sept jours, et HubSpot recommande une rotation tous les six mois. Il faut donc un processus, pas seulement un jeton dans un fichier.
Une limite fonctionnelle qui oriente le choix. Une application privée ne prend pas en charge les événements de chronologie personnalisés. Si votre besoin en comporte, HubSpot recommande explicitement une application publique.
Sur le code exécuté dans un workflow, les bornes sont précises. L'action de code personnalisé demande Data Hub Professionnel ou Entreprise, doit terminer en vingt secondes et ne dispose que de cent vingt-huit mégaoctets de mémoire. Au-delà, il faut un intermédiaire externe.
Trois pièges de code personnalisé, documentés et contre-intuitifs. Les variables déclarées hors de la fonction principale peuvent être réutilisées d'une exécution à l'autre. Le générateur aléatoire peut produire les mêmes nombres sur des exécutions différentes. Et un test exécute réellement le code, donc modifie réellement la fiche choisie.
Un filet de sécurité généreux, en revanche. HubSpot réessaie une action en échec pendant trois jours, avec un intervalle pouvant atteindre huit heures.
En pratique, décider s'il faut développer sur mesure
Le test de décision avant de coder
- Cherchez sur le marketplace, et lisez la section des données partagées, pas seulement le descriptif.
- Essayez un workflow. Une bonne partie des besoins tient dans un déclencheur, une condition et une action.
- Essayez un automatiseur, si le besoin est un événement transmis.
- Écrivez qui maintient, avec un nom. Si vous n'avez pas de nom, vous n'avez pas de projet.
Si vous partez sur une application privée, la checklist
- Créez-la avec un compte de service, pas avec le compte d'une personne qui peut quitter l'entreprise.
- Documentez les portées demandées, puisqu'une rétrogradation d'abonnement peut les retirer.
- Posez un rappel de rotation du jeton tous les six mois.
- Prévoyez un compteur d'appels, le quota journalier étant partagé avec les autres intégrations.
Ce qu'il ne faut pas faire
Mettre de la logique métier durable dans une action de code personnalisé, au motif que c'est plus rapide. Vingt secondes d'exécution, cent vingt-huit mégaoctets et un état partagé entre exécutions ne font pas un environnement d'exécution fiable pour du critique.
À surveiller sur le développement d'une application privée HubSpot
- Vingt applications privées maximum par portail, et il faut être super administrateur.
- Retirer l'utilisateur créateur casse certains appels. Utilisez un compte de service.
- Une rétrogradation d'abonnement retire des portées sans message d'erreur explicite.
- Supprimer l'application révoque définitivement son jeton.
- Pas d'événement de chronologie personnalisé sur une application privée.
- Le code personnalisé exige Data Hub Professionnel ou Entreprise, vingt secondes et cent vingt-huit mégaoctets.
- Un test de code modifie réellement la fiche choisie.
- Les applications publiques héritées ne se créent plus depuis juin 2026.
Articles liés au développement d'une application privée HubSpot
- Les limites d'usage de l'API HubSpot
- Intégration native, data sync, automatisation ou développement
- Reconstruire les automatisations dans un nouveau portail
Quand nous contacter sur le développement d'une application privée HubSpot
Contactez Yuzu Corp avant d'engager du développement. La question utile n'est pas de savoir si c'est faisable, mais qui maintiendra le montage quand l'équipe aura changé.
Pour aller plus loin, découvrez notre offre RevOps.
Auteur, sources et date de vérification
Rédigé par Antoine Coatanoan
Sales Ops chez Yuzu Corp · 2 ans sur HubSpot · Nantes & Paris
Yuzu Corp est partenaire HubSpot Diamond et membre du Claude Partner Network
Publié le 3 septembre 2026 · Vérifié sur HubSpot le 1 septembre 2026