Rentrée API HubSpot : 3 échéances pour vos intégrations ERP

En bref : depuis le 8 septembre 2026, la version 2026-09 de l'API HubSpot applique aux écritures des intégrations les règles de validation définies par vos administrateurs. Deux autres échéances suivent : la fin des applications privées héritées (28 septembre et 26 octobre) et l'arrêt de l'API Pipelines V1 le 4 décembre 2026. Trois notes techniques qui, prises ensemble, font du connecteur ERP un sujet de gouvernance des données.

Vous êtes DSI (directeur des systèmes d'information) ou directeur commercial d'une ETI ou d'une PME B2B française, et votre ERP (progiciel de gestion intégré : Divalto, Sage X3, Cegid, EBP, Dynamics NAV) alimente HubSpot en clients, commandes et factures ? Cette rentrée transforme trois notes techniques en une décision de gouvernance des données. Voici ce qui change, pour qui, et dans quel ordre agir.

Quelles sont les trois échéances API de la rentrée 2026 ?

HubSpot a publié trois annonces sur son changelog développeurs entre le 11 et le 27 août 2026. Prises ensemble, elles dessinent une trajectoire claire : la plateforme applique désormais aux machines les règles qu'elle appliquait aux humains.

Que change la validation des écritures API pour un connecteur ERP ?

Jusqu'ici, une règle du type « la date de clôture est obligatoire quand le deal passe en Gagné » ne s'appliquait qu'aux utilisateurs dans l'interface. Une intégration pouvait écrire le même deal sans date de clôture, sans être bloquée. À partir de la version 2026-09, l'API (interface de programmation) renvoie une erreur 400 VALIDATION_ERROR dans trois cas précis :

• Propriété conditionnellement obligatoire absente : code MISSING_CONDITIONAL_REQUIRED_PROPERTY. Exemple documenté par HubSpot : une propriété exigée en fonction de la valeur du pays.
• Champ requis à la création non fourni : code MISSING_REQUIRED_PROPERTY, sur les propriétés et associations marquées obligatoires dans Paramètres → Objets → Créer une fiche.
• Permission « Modifier les associations » manquante : uniquement pour les applications en OAuth utilisateur (protocole d'autorisation délégué), lorsque l'utilisateur ayant installé l'application n'a pas ce droit. Les jetons au niveau du portail ne sont pas concernés.

Trois nuances rendent le sujet gérable. Premièrement, l'application est liée à la version d'API : une intégration qui reste sur une version antérieure ne change pas de comportement tant qu'elle ne migre pas. Deuxièmement, rien ne change dans un portail où aucune règle de ce type n'a été configurée. Troisièmement, HubSpot a assoupli en parallèle la validation des dates : les formats ISO-8601, les horodatages en secondes ou les dates hors minuit sont désormais normalisés, avec un tableau warnings dans la réponse plutôt qu'un rejet.

Le cas typique d'un flux ERP vers HubSpot

Prenez un connecteur qui pousse chaque nuit les commandes de l'ERP vers les deals HubSpot. Côté ventes, un administrateur a rendu le montant et la date de clôture obligatoires au passage en Gagné, parce que le forecast en dépend. Côté ERP, une commande validée arrive avec un montant mais sans date de signature, parce que ce champ n'existe pas dans le progiciel. Sous l'ancienne version, le deal était créé incomplet et le forecast comptait un deal gagné sans date. Sous la version 2026-09, l'écriture est refusée et l'écart devient visible dans les journaux du connecteur.

C'est le point central : l'API ne crée pas un nouveau problème, elle rend visible un écart de règles entre deux systèmes. Pour une direction commerciale, c'est la garantie que les règles de pipeline décidées en comité s'appliquent aussi aux données qui arrivent de la comptabilité.

Pourquoi la fin des applications privées héritées concerne-t-elle votre DSI ?

Les applications privées « héritées » sont un mode d'authentification courant pour les connecteurs ERP : un jeton créé dans les paramètres du portail, puis copié dans un middleware ou une plateforme d'intégration (iPaaS, comme Make). HubSpot ne les désactive pas : les applications existantes continuent de fonctionner. Il ferme la création de nouvelles, en deux vagues (28 septembre pour les nouveaux comptes, 26 octobre pour les comptes existants).

Le remplacement, les Service Keys, apporte quatre propriétés qu'une DSI attend d'un secret de production, d'après la documentation HubSpot : périmètre de permissions restreint au besoin, journal d'activité intégré, rotation avec période de recouvrement de 7 jours, et visibilité de la clé réservée aux administrateurs. Pour les intégrations qui reposent sur des webhooks, HubSpot renvoie vers le cadre « Developer Platform Projects » (version 2026.09 ou ultérieure).

L'enjeu n'est pas la date butoir. C'est l'occasion de faire l'inventaire des jetons en circulation : qui les détient, quels droits ils portent, quand ils ont été créés.

Que faire de l'arrêt de l'API Pipelines V1 ?

L'API Pipelines V1 cesse de répondre le 4 décembre 2026. Elle sert à lire et modifier la structure des pipelines et de leurs étapes. Un connecteur ERP l'utilise pour une chose précise : traduire un statut de commande (« devis émis », « commande validée », « facturée ») en étape de pipeline. Si ce mapping a été codé il y a plusieurs années, il mérite une vérification.

La migration vers la version 2026-09, disponible en accès général le 9 septembre, se prépare en auditant le code du connecteur et de la plateforme d'intégration à la recherche des appels aux anciens points de terminaison. C'est un chantier borné, à traiter avant le pic d'activité de fin d'année.

Notre lecture : le CRM devient un référentiel gouverné

Le fil conducteur est le même : HubSpot aligne les machines sur les règles des humains. Les règles de saisie s'appliquent aux intégrations, les secrets d'accès deviennent tracés et rotatifs, les versions d'API sont datées et retirées à échéance connue. Ce mouvement a commencé avec le versionnement par date (format /AAAA-MM/) introduit en 2026 ; la validation des écritures en est la première conséquence visible pour les intégrateurs.

Pour un dirigeant, cela change la nature de la question. « Notre connecteur ERP fonctionne-t-il ? » devient « nos règles de données sont-elles les mêmes dans l'ERP, dans le CRM et dans le connecteur qui les relie ? ». La première relève de l'exploitation. La seconde relève de l'architecture de revenu (Revenue Architecture) : elle conditionne la fiabilité du forecast, la facturation et la qualité des identifiants clients (SIREN) que la facture électronique exige désormais dans le CRM.

Notre position : ces échéances avantagent les organisations qui ont déjà défini leurs règles de pipeline et de fiche, parce que la plateforme les fait respecter partout, sans contrôle supplémentaire. Pour les autres, c'est le bon moment pour les écrire, en commençant par les champs dont dépendent le forecast et la facturation.

Comment préparer votre intégration ERP en 4 étapes ?

La méthode que nous appliquons sur les portails que nous opérons tient en quatre étapes, ordonnées par risque décroissant.

1. Inventorier les règles du portail (1 atelier). Lister, objet par objet, les propriétés conditionnellement obligatoires (Paramètres → Propriétés), les champs requis à la création (Paramètres → Objets → Créer une fiche) et les permissions d'association des utilisateurs qui ont installé des applications OAuth. Le livrable est une matrice « règle × objet × source de données ».
2. Confronter cette matrice au mapping du connecteur. Pour chaque règle, vérifier que le flux ERP fournit la valeur attendue. Là où l'ERP n'a pas l'information (notre exemple de la date de signature), trancher : valeur par défaut documentée, enrichissement côté middleware, ou assouplissement de la règle côté HubSpot. C'est une décision métier, pas un correctif de code.
3. Adapter le connecteur avant de changer de version d'API. Récupérer les définitions de propriétés via GET /crm/{version}/properties/{objectType} avant chaque écriture, inclure les propriétés conditionnelles, analyser les erreurs VALIDATION_ERROR pour remonter un message actionnable à l'exploitant, et ne jamais rejouer une requête refusée à l'identique. Puis seulement, basculer sur /2026-09/.
4. Traiter les deux autres échéances dans le même lot. Remplacer les jetons hérités par des Service Keys à périmètre restreint pour toute nouvelle connexion, et auditer les appels Pipelines V1 avant le 4 décembre.

Ce plan s'appuie sur les principes détaillés dans notre article sur le choix d'un connecteur ERP pour HubSpot et sur notre offre d'intégrations API HubSpot.

Faut-il traiter ces échéances maintenant ?

Oui, mais dans l'ordre du risque. La validation des écritures ne s'applique qu'au moment où votre connecteur change de version d'API : c'est vous qui choisissez la date, à condition d'avoir fait l'inventaire des règles avant. Les Service Keys et la migration Pipelines V1 se traitent dans le même lot, avant le pic d'activité de fin d'année. Les organisations qui abordent ces trois échéances comme une question de gouvernance des données en sortent avec un forecast plus fiable et des accès mieux tenus.

Chez DigitaWeb, partenaire HubSpot depuis plus de 10 ans, c'est exactement le terrain de nos missions d'intégration API et ERP. Pour cadrer votre plan d'action sur votre portail et votre ERP, réservons un atelier de cadrage (90 min, 290 €, déduit de la mission).