Le 3 novembre 2026, HubSpot a annoncé la fin des fonctions serverless créées dans le design manager. Le 1er février 2027, celles qui tournent encore cesseront de répondre. Le simulateur de devis ou le formulaire relié à votre ERP pourrait s'arrêter avec elles.
Sur le papier, il vous reste trois mois pour migrer vos fonctions serverless HubSpot. En réalité, la date qui compte est le 17 novembre : à partir de là, vous ne pourrez plus modifier ces fonctions ni corriger le moindre bug. Et la bonne question n'est pas seulement « comment migrer ? ». C'est « cette fonction mérite-t-elle de survivre ? ».
Voici le calendrier, les trois options pour chacune de vos fonctions serverless HubSpot et la méthode qu'on applique chez if/else agency pour trancher 👇🏼
D'après l'annonce publiée sur le changelog développeurs de HubSpot, deux choses disparaissent en même temps : les fonctions serverless du design manager, servies depuis les adresses en /_hcms/api/, et les versions Node.js 20 et antérieures des actions de code personnalisé dans les workflows. La raison : ces environnements ne reçoivent plus de correctifs de sécurité, et HubSpot dit ne pas pouvoir les mettre à niveau.
/_hcms/api/ échouentQui est concerné ? La documentation de HubSpot rappelle que les fonctions serverless exigent Content Hub Enterprise. Sans cette licence, la première partie de l'annonce ne vous concerne pas. Les actions de code personnalisé des workflows, elles, se retrouvent dans bien plus de portails.
HubSpot ne migrera rien automatiquement. Chaque fonction doit être reconstruite dans un projet développeur, sous une nouvelle adresse en /hs/serverless/, puis chaque page, module ou template qui l'appelle doit être mis à jour.
Après le 17 novembre, vos fonctions continueront de tourner jusqu'en février. Mais elles seront figées. Qu'une API tierce change de format ou qu'un jeton expire, vous ne pourrez plus toucher au code. Reste alors le choix entre une fonction cassée et une migration dans l'urgence.
Même logique pour les workflows. Une action en Node.js 20 continue de s'exécuter, mais vous ne pourrez plus enregistrer la moindre modification. Et le passage à Node.js 24 ne se règle pas dans un menu déroulant : selon le guide de mise à niveau de HubSpot, les fonctions à callback ne sont plus acceptées, la bibliothèque request disparaît et le client API HubSpot saute de la version 11 à la version 13.
En clair : l'inventaire ne peut pas attendre janvier.
Le piège classique : croire qu'on connaît ses fonctions. Le guide de migration de HubSpot liste les endroits où se cachent les appels :
Il conseille aussi de vérifier les appels sur le site en ligne, dans l'onglet réseau du navigateur, et de relire les logs de chaque fonction. Celles qui échouent déjà, par exemple parce qu'elles reposent sur une ancienne clé d'API retirée, sont à réparer ou à retirer. Surtout pas à recopier telles quelles.
Exemple concret : prenons un site B2B industriel avec trois fonctions. Un simulateur de devis branché sur une grille tarifaire, un envoi de formulaire vers l'ERP, et un connecteur vers un outil de webinar abandonné depuis deux ans. Les deux premières doivent être migrées. La troisième, on la supprime : la migrer coûterait du temps pour rien.
C'est la voie prévue par HubSpot, et la bonne pour les tâches légères : masquer une clé d'API ou valider un formulaire. Les fonctions de projet tournent sur Node.js 24 avec les versions de plateforme 2026.03 et 2026.09, et reçoivent les correctifs de sécurité automatiquement.
Attention, le copier-coller ne suffit pas. D'après le guide de HubSpot, la signature des fonctions change, les variables d'environnement deviennent des secrets, chaque dépendance doit être déclarée et les informations de quota ne sont plus fournies : à vous de gérer les erreurs 429. Le délai d'exécution passe de 10 à 15 secondes. Point de vigilance : un endpoint devient public dès le déploiement du projet.
Notre critère de tri : une fonction qui s'approche des 15 secondes maximum autorisées en projet, traite de gros volumes ou enchaîne plusieurs routes mérite de sortir de HubSpot. Un petit service hébergé chez vous ou chez un fournisseur cloud vous laisse la main sur l'environnement d'exécution et sur les mises à jour. C'est ce qu'on recommandait déjà dans notre article sur les appels API et les limites des fonctions serverless.
Le revers : quelqu'un doit maintenir ce serveur, sinon le problème reviendra dans deux ans.
Certaines fonctions ont été écrites à une époque où HubSpot ne savait pas faire. Avant de migrer, vérifiez si un formulaire natif, un workflow ou une intégration du marketplace couvre désormais le besoin. Et une fonction inutile, on la retire.
Pour les repérer, HubSpot conseille de filtrer vos workflows par type d'action « Code personnalisé », puis d'ouvrir chaque action pour lire la version de Node.js indiquée. Copiez le code actuel hors de HubSpot avant de toucher à quoi que ce soit.
Breeze peut proposer la mise à niveau vers Node.js 24 directement dans l'éditeur. HubSpot précise lui-même que l'assistant peut se tromper : comparez son résultat avec votre copie et vérifiez que chaque sortie est toujours renvoyée.
Le problème, c'est que le test d'une action applique réellement ses modifications à l'enregistrement choisi, d'après la documentation. Testez sur un contact ou une transaction de test, jamais sur un vrai client.
On garde le même chemin après le préfixe, pour que la modification côté site se résume à remplacer /_hcms/api/ par /hs/serverless/. Et on documente chaque projet (endpoints et procédure de retour arrière) pour que la personne suivante ne reparte pas de zéro.
HubSpot fournit même un prompt pour un agent de code IA, qui demande une validation avant chaque modification en ligne. Utile pour aller plus vite, à condition qu'un développeur relise chaque étape. Si vous ne savez pas ce qui tourne sur votre site, commencez par un audit technique de votre site HubSpot. Et pour les fonctions à reconstruire ou à sortir de HubSpot, c'est le cœur de notre accompagnement en intégration API et back-end.
La fin des fonctions serverless du design manager est une échéance technique avec un calendrier clair. C'est aussi une bonne occasion de faire le ménage dans le code qui tourne en coulisses de votre site.
Le vrai risque, c'est de découvrir en février qu'un formulaire n'envoie plus rien à votre ERP depuis une semaine, sans message d'erreur.
Conseil if/else : faites l'inventaire avant le 17 novembre, même si vous migrez en janvier.
Besoin d'aide pour trier et migrer vos fonctions serverless ? Parlons-en.