En bref : HubSpot ferme la création d'applications privées héritées le 28 septembre 2026 (nouveaux comptes) et le 26 octobre 2026 (comptes existants). Les Service Keys les remplacent pour les connexions système-à-système sans webhook. Les applications existantes continuent de fonctionner jusqu'à l'échéance de migration de septembre 2027.
Vous êtes DSI (directeur des systèmes d'information) ou responsable applicatif d'une ETI ou d'une PME B2B française, et vos connecteurs entre HubSpot et votre ERP (progiciel de gestion intégré : Divalto, Sage X3, Cegid, EBP, Dynamics NAV) s'authentifient avec un jeton d'application privée ? Une fenêtre se ferme dans cinq semaines, une autre s'ouvre à douze mois. Voici comment décider sans immobiliser vos flux.
Sommaire
- Qu'est-ce qu'une Service Key HubSpot ?
- Que se passe-t-il le 28 septembre et le 26 octobre 2026 ?
- Service Key ou application privée héritée : le comparatif
- Dans quels cas une Service Key ne suffit pas ?
- Comment basculer un connecteur ERP en 5 étapes ?
- Notre lecture : l'échéance qui compte est celle de 2027
- Questions fréquentes
Qu'est-ce qu'une Service Key HubSpot ?
Une Service Key est un identifiant d'accès aux API (interfaces de programmation) REST de HubSpot — celles qui lisent et écrivent les fiches du CRM (gestion de la relation client) — créé directement dans le portail, sans ligne de commande ni serveur OAuth (protocole d'autorisation délégué). Elle s'utilise comme jeton Bearer, exactement comme le jeton d'une application privée aujourd'hui.
HubSpot l'a ouverte en bêta publique le 10 février 2026 et la destine aux intégrations système-à-système : synchronisations ERP, outils décisionnels (Tableau, Power BI), entrepôts de données, automatisations internes et intégrations d'agents IA. Quatre propriétés la distinguent d'un jeton classique, telles que documentées par HubSpot :
- Étendues restreintes. Une clé ne porte que les scopes sélectionnés à sa création, et seulement ceux que son créateur détient déjà : aucune élévation de privilèges possible.
- Journal d'activité intégré. Un bouton « View logs » sur la fiche de la clé affiche les appels et l'horodatage de dernière utilisation.
- Rotation native. La clé suivante est générée, l'ancienne expire après sept jours — le temps de propager le secret dans le middleware. Expiration immédiate disponible. HubSpot recommande une rotation semestrielle.
- Visibilité réservée aux administrateurs. La valeur est masquée par défaut ; la création demande le droit « Accès aux outils pour développeurs » ou le statut de super administrateur.
Un paramètre à intégrer au calendrier : la fonctionnalité est en bêta publique, donc encore susceptible d'évoluer.
Que se passe-t-il le 28 septembre et le 26 octobre 2026 ?
HubSpot retire de l'interface la possibilité de créer de nouvelles applications privées héritées, en deux vagues calées sur l'âge du portail (changelog du 27 août 2026) : le 28 septembre 2026 pour les comptes créés à partir de cette date, le 26 octobre 2026 pour les comptes créés avant, ce qui couvre la quasi-totalité des portails en production.
Ce qui ne change pas : toutes les applications privées existantes continuent de fonctionner à l'identique. Aucun flux ne s'interrompt le 27 octobre. Ce qui change : tout nouveau besoin d'accès API passera par une Service Key ou par une application construite sur le cadre Developer Platform Projects.
La conséquence est d'abord organisationnelle. Un portail peut héberger jusqu'à 20 applications privées héritées. Consommer ses derniers emplacements avant la fermeture, c'est s'engager à gérer deux mécanismes d'authentification en parallèle pendant des années.
Service Key ou application privée héritée : le comparatif
Le tableau reprend les seuls écarts documentés publiquement par HubSpot au 22 septembre 2026.
| Critère | Application privée héritée | Service Key |
|---|---|---|
| Création de nouvelles instances | Fermée le 28/09/2026 (nouveaux comptes) et le 26/10/2026 (comptes existants) | Ouverte, en bêta publique depuis le 10/02/2026 |
| Horizon septembre 2027 | À migrer vers une application Projects | Voie recommandée par HubSpot pour les intégrations sans webhook |
| Webhooks | Pris en charge | Non pris en charge |
| Étendues (scopes) | Sélectionnées à la création | Sélectionnées à la création, plafonnées aux droits du créateur |
| Rotation du secret | Non documentée comme fonction native | Rotation intégrée, expiration différée de 7 jours |
| Journal des appels | Onglet « Logs » de l'application | Bouton « View logs » sur la fiche de la clé |
| Nombre maximum par portail | 20 | Non documenté |
| Limites d'appels | Identiques : régime des applications distribuées en privé | |
Ce dernier point détermine l'architecture de vos flux. Les Service Keys suivent le même régime de limites que les applications distribuées en privé :
| Édition HubSpot | Par 10 secondes (par clé ou application) | Par jour (partagé sur tout le portail) |
|---|---|---|
| Free et Starter | 100 | 250 000 |
| Professional | 190 | 625 000 |
| Enterprise | 190 | 1 000 000 |
| Option API Limit Increase | 250 | + 1 000 000 par option souscrite (2 maximum) |
La lecture utile tient en une phrase : la limite par salve se compte par clé, la limite quotidienne se partage entre toutes les clés du portail. Découper une synchronisation en cinq Service Keys multiplie le débit instantané, pas le volume journalier. C'est un arbitrage d'architecture à poser avant de découper.
Dans quels cas une Service Key ne suffit pas ?
HubSpot documente trois usages hors périmètre : l'authentification de webhooks, les appels depuis une extension d'interface CRM, et toute fonctionnalité de la plateforme développeur au-delà des requêtes REST. La réponse est alors une application construite avec le CLI (interface en ligne de commande) HubSpot sur le cadre Projects, ou le maintien de l'application privée existante.
Sur un connecteur ERP, la ligne de partage est nette. Le flux montant — commandes et factures poussées vers HubSpot par un lot nocturne ou un middleware — n'a besoin que de REST : une Service Key convient. Le flux descendant événementiel — HubSpot notifie l'ERP qu'une transaction passe en Gagnée — repose sur des webhooks et reste sur une application Projects. Quand les deux coexistent, séparez-les : chaque moitié porte alors ses propres droits et son propre journal.
Comment basculer un connecteur ERP en 5 étapes ?
La séquence que nous appliquons sur les portails que nous opérons : un atelier d'une demi-journée pour les deux premières étapes, puis un lot de développement borné.
- Inventorier les jetons en circulation. Pour chaque application privée : quel système l'utilise, quelles étendues elle porte, quand elle a servi pour la dernière fois. L'onglet « Logs » donne la réponse.
- Trier par dépendance aux webhooks. Un connecteur qui n'en consomme aucun est éligible à une Service Key. Les autres rejoignent le chantier Projects de 2027.
- Créer la clé avec le bon compte. Une clé ne porte que les étendues détenues par son créateur. Créée par un utilisateur aux droits partiels, elle sera muette sur une partie des objets, et l'écart se manifestera en production plutôt qu'à la configuration. Créez-la depuis un compte super administrateur. Chemin : Development → Keys → Service keys, ou Paramètres → Intégrations → Service Keys.
- Sélectionner les étendues au plus juste. Un connecteur qui pousse des commandes vers les transactions n'a pas besoin d'écrire sur les contacts. Les étendues se complètent après coup : commencez restreint, élargissez sur constat.
- Basculer avec recouvrement, puis révoquer. Déployez la nouvelle clé dans le middleware, laissez les deux jetons actifs le temps d'un cycle complet de synchronisation, vérifiez les journaux des deux côtés, supprimez l'ancien. Puis inscrivez la première rotation à six mois.
Notre lecture : l'échéance qui compte est celle de 2027
Le 26 octobre est une date de confort. Elle ne casse rien, elle ferme une porte. L'annonce qui structure le sujet est tombée le 15 septembre 2026, au Fall Spotlight : HubSpot a fixé à septembre 2027 la fin de support des API v1 à v3, des applications publiques héritées et des applications privées héritées. Le support des API v4 s'arrête pour sa part le 30 mars 2027.
La question n'est donc pas « faut-il créer une dernière application privée avant le 26 octobre ». Elle est : quel est le plan de sortie de vos intégrations héritées sur les douze mois qui viennent ? Deux chantiers se superposent — le mode d'authentification et la version d'API appelée — et ils ne se traitent pas au même endroit. Une intégration migrée vers Projects qui appelle encore des points de terminaison v3 reste concernée par l'échéance de 2027.
Pour une direction des systèmes d'information, c'est une bonne nouvelle de gouvernance : un secret d'accès daté, tracé, à périmètre explicite et rotatif, c'est le standard déjà appliqué aux autres briques du système d'information. HubSpot l'aligne sur cette norme et laisse douze mois pour y arriver.
Cet article prolonge notre lecture des trois échéances API de la rentrée 2026 et complète notre panorama des connecteurs ERP pour HubSpot.
Par où commencer ?
Trois actions tiennent dans la fenêtre qui reste : inventorier les jetons du portail, créer en Service Key toute nouvelle connexion dès maintenant, inscrire la migration des intégrations héritées au plan de charge 2027. L'inventaire conditionne les deux autres. Chez DigitaWeb, partenaire HubSpot Elite, l'architecture des intégrations API et ERP est le terrain quotidien de nos missions. Pour cadrer votre plan de bascule, réservons un atelier de cadrage (90 min, 290 €, déduit de la mission).
Réserver mon atelier de cadrage →
Questions fréquentes
Mes applications privées HubSpot vont-elles s'arrêter le 26 octobre 2026 ?
Non. HubSpot précise que toutes les applications privées héritées existantes continuent de fonctionner à l'identique. Seule la possibilité d'en créer de nouvelles disparaît de l'interface, le 28 septembre 2026 pour les comptes créés à partir de cette date et le 26 octobre 2026 pour les comptes existants. L'échéance de migration proprement dite est fixée à septembre 2027.
Qu'est-ce qu'une Service Key HubSpot et à quoi sert-elle ?
Une Service Key est un identifiant d'accès aux API REST de HubSpot, créé dans le portail et utilisé comme jeton Bearer. Elle est conçue pour les intégrations système-à-système : synchronisation ERP, outils décisionnels, entrepôts de données, automatisations internes et intégrations d'agents IA. Elle apporte des étendues restreintes, un journal d'appels, une rotation native avec préavis de sept jours et une visibilité réservée aux administrateurs.
Une Service Key gère-t-elle les webhooks HubSpot ?
Non. HubSpot indique que les Service Keys ne prennent pas en charge les webhooks, ni les appels depuis une extension d'interface CRM. Pour une intégration qui reçoit des notifications d'événements, la voie recommandée est une application construite sur le cadre Developer Platform Projects avec le CLI HubSpot, ou le maintien de l'application privée existante. Sur un connecteur ERP, on sépare souvent les deux moitiés du flux.
Combien d'appels API une Service Key autorise-t-elle ?
Les Service Keys suivent le régime des applications distribuées en privé : 100 appels par tranche de 10 secondes en Free et Starter, 190 en Professional et en Enterprise, 250 avec l'option API Limit Increase. Le plafond quotidien va de 250 000 à 1 000 000 d'appels selon l'édition. Point clé : la limite par salve se compte par clé, le plafond quotidien se partage entre toutes les clés du portail.
Qui peut créer une Service Key dans un portail HubSpot ?
Les super administrateurs et les utilisateurs disposant du droit « Accès aux outils pour développeurs ». Une contrainte structure le paramétrage : une clé ne peut porter que les étendues déjà détenues par son créateur, ce qui empêche toute élévation de privilèges. Créez donc la clé depuis un compte disposant des droits visés, sous peine de découvrir le manque en production plutôt qu'à la configuration.
DigitaWeb — partenaire HubSpot Elite (~1 % des partenaires dans le monde), 650 projets livrés pour plus de 350 entreprises. Membre du groupe Uptoo. Parlons de votre intégration ERP →
