Le 16 juin 2026, HubSpot a rebaptisé Commerce Hub en Revenue Hub. Changer un nom est rarement anodin chez un éditeur, mais ici le mot dit l'intention. « Commerce » évoquait la transaction ponctuelle : un lien de paiement, une facture isolée. « Revenue » désigne un flux continu, celui d'entreprises B2B qui renouvellent, étendent, renégocient des contrats en permanence. La majorité de nos clients vivent dans ce second monde, pas dans le premier.
Le moteur de cette bascule n'est pas un nouveau bouton. C'est un objet de données. Depuis avril 2026, HubSpot dispose d'un objet Contrats natif qui sert d'ancre structurelle entre le devis, la facturation et le renouvellement. C'est lui qui transforme une suite d'événements isolés en un cycle qui reste à jour. Le reste (CPQ enrichi, facturation connectée, paiements intégrés) s'organise autour de cette colonne vertébrale.
Cet article s'adresse aux directions commerciales, financières et RevOps qui veulent comprendre ce que Revenue Hub recouvre réellement, distinguer ce qui est livré de ce qui relève encore de la feuille de route, et savoir ce que cette évolution implique pour un portail HubSpot déjà en production.
Un chiffre résume le problème que cette bascule cherche à régler. Selon l'étude State of B2B Revenue 2026 de HubSpot, 76 % des dirigeants revenue déclarent manquer des renouvellements parce que leur donnée de revenu vit ailleurs que dans la fiche client, et seulement 32 % des équipes finance et commerciales clôturent le mois à partir des mêmes chiffres (source : State of B2B Revenue 2026, HubSpot). Ce n'est pas un problème d'équipes. C'est un problème de contexte : la donnée existe, mais pas au bon endroit.
Présenter Revenue Hub comme un lancement isolé serait inexact. C'est l'aboutissement d'une trajectoire que HubSpot a déroulée en trois jalons.
En septembre 2025, l'éditeur a livré un CPQ avancé, capable de gérer des configurations de prix plus complexes que les anciens devis. En avril 2026, l'objet Contrats natif est arrivé : c'est le point de bascule réel, celui qui permet à une donnée de devis de devenir une donnée de revenu vivante. En juin 2026, le rebranding officialise l'ensemble et y connecte la facturation et des échéances de paiement rattachées directement au contrat.
Pourquoi cette chronologie compte pour vous ? Parce qu'elle indique où porter votre attention. Le sujet n'est pas « un nouveau Hub à acheter ». Le sujet est : votre quote-to-cash peut désormais vivre nativement dans HubSpot, à condition que votre modèle de données soit prêt à accueillir cet objet Contrats et les associations qu'il suppose.
Revenue Hub rassemble trois briques que beaucoup d'organisations gèrent aujourd'hui dans des outils séparés : la configuration et l'édition de devis (CPQ), la facturation adossée aux contrats, et l'encaissement des paiements. L'intérêt n'est pas la juxtaposition, c'est la continuité : un devis signé devient un contrat, le contrat porte les échéances de facturation, les factures sont payées, et les renouvellements ou extensions repartent du contrat existant.
Le nouvel éditeur de devis abandonne l'ancien format multi-onglets pour une interface en glisser-déposer sur une seule page. Les commerciaux génèrent des devis personnalisés et de marque directement depuis une fiche transaction.
Breeze, l'assistant IA de HubSpot, peut produire une lettre de motivation commerciale ou un résumé exécutif en s'appuyant sur les données client déjà présentes. L'assistant se glisse directement dans l'éditeur, au niveau du module à rédiger.
Sur le fond, le CPQ apporte des capacités qui manquaient aux anciens devis : la tarification par paliers (par volume, progressive ou par tranche), les approbations standard et avancées, le suivi d'activité d'un devis (qui l'a ouvert, quand), les pièces jointes, et des règles de devis qui bloquent ou alertent quand une combinaison de produits ou une remise sort des clous. La logique conditionnelle de base, comme les dépendances entre produits ou les règles de remise, est désormais disponible.
C'est ici que l'objet Contrats prend tout son sens. À l'acceptation d'un devis, un contrat se crée automatiquement et porte la visibilité sur l'ACV, l'ARR et le MRR. Les changements (montées en gamme, réductions de périmètre, renouvellements) se gèrent depuis ce contrat, avec une traçabilité entre le contrat de renouvellement et le contrat d'origine. Les factures se génèrent depuis HubSpot, avec des échéanciers, des avoirs et des relances automatiques.
Le dernier maillon ferme la boucle. Les paiements se collectent dans HubSpot via HubSpot Payments (disponible uniquement aux États-Unis, au Royaume-Uni et au Canada) ou via Stripe partout où Stripe opère. En France, HubSpot Payments n'est pas disponible : l'encaissement natif passe donc par Stripe. Liens de paiement, paiements sur facture, méthodes de paiement enregistrées, gestion des litiges et des remboursements, relances automatiques des paiements échoués : chaque transaction reste rattachée à la fiche CRM.
Voici notre position, et elle n'est pas neutre. Revenue Hub rapproche HubSpot du monde de la finance et de la facturation, mais il ne fait pas de HubSpot un ERP. C'est un distinguo que nous tenons sur tous nos projets, et que la communication produit a peu d'intérêt à formuler.
HubSpot reste une suite CRM agile, conçue pour le quotidien des interactions prospect et client sur tous les canaux. Un ERP gère une autre complexité : la comptabilité analytique, la gestion de stock, la facturation à l'usage fine, les chaînes logistiques, les contraintes fiscales avancées. Les meilleures architectures que nous déployons cherchent le meilleur des deux mondes, un ERP optimisé pour la complexité métier adossé à HubSpot pour la relation client.
Ce que Revenue Hub apporte de réellement nouveau, ce n'est donc pas un remplacement de votre ERP. C'est le rapatriement du contexte revenu à l'endroit où vit déjà le contexte client. Avant, vos équipes avaient le « qui » (le contact, l'historique, le pipeline) sans le « combien » (ce qui a été acheté, payé, ce qui arrive à échéance). Revenue Hub réunit les deux. C'est précieux. Ce n'est pas la même chose que remplacer un système financier.
Une conséquence pratique : si votre besoin réel est de la facturation à l'usage, de la gestion de stock dans le devis ou du guided selling complet, HubSpot CPQ ne couvre pas encore ces cas. L'éditeur le reconnaît lui-même. Ces besoins relèvent soit d'un ERP, soit d'un connecteur CPQ tiers, et ce sera l'objet d'un article dédié.
Une limite mérite d'être posée clairement pour le marché français, et les supports de lancement HubSpot ne la mentionnent pas. La facturation native de Revenue Hub n'est pas une solution de facturation électronique conforme à la réforme française.
À partir du 1ᵉʳ septembre 2026, toutes les entreprises devront recevoir leurs factures B2B au format électronique structuré (Factur-X, UBL ou CII), et les grandes entreprises et ETI devront aussi les émettre via une Plateforme de Dématérialisation Partenaire (PDP). Les PME et TPE suivront au 1ᵉʳ septembre 2027. Les factures PDF classiques ne seront plus recevables pour les transactions B2B domestiques.
Or HubSpot génère des factures, pas des factures électroniques structurées transmises via une PDP agréée. La conséquence est concrète : Revenue Hub reste pertinent pour piloter le devis, le contrat et l'encaissement dans le CRM, mais l'émission de la facture légale conforme passera par une PDP ou un ERP connecté. C'est un sujet d'architecture à cadrer en amont, pas à découvrir en septembre 2026. La même logique vaut pour l'encaissement : HubSpot Payments n'étant pas disponible en France, c'est Stripe qui prend le relais.
Un article utile doit faire un tri que les supports de lancement font rarement : séparer ce que vous pouvez activer aujourd'hui de ce qui est annoncé. Le déploiement de Revenue Hub est progressif, par portail et par édition. Et une partie des fonctionnalités les plus citées sont en beta ou planifiées.
| Statut | Capacités |
|---|---|
| Disponible et exploitable | Nouvel éditeur CPQ, modèles de devis en glisser-déposer, tarification par paliers, approbations standard et avancées, suivi d'activité des devis, e-signature, règles de devis, objet Contrats, facturation, paiements (HubSpot Payments ou Stripe) |
| En beta / private beta | Price Books (private beta, GA visée fin juin 2026), Breeze Closing Agent, Revenue Agent (private beta, public beta à venir), Customer Agent sur les questions de facturation, personnalisation par modules React |
| Annoncé / feuille de route | Taxe automatisée, écriture via MCP pour les agents IA, modèle tarifaire dédié à la facturation |
Tableau indicatif au 17 juin 2026, à recroiser avec la documentation HubSpot du jour avant mise en ligne : le déploiement est progressif par portail et par édition.
Notre recommandation tient en une phrase : évaluez Revenue Hub sur ce qui est livré, pas sur la feuille de route. HubSpot le dit d'ailleurs en toutes lettres dans ses propres mentions, une décision d'achat ne doit pas reposer sur des fonctionnalités annoncées qui peuvent évoluer à tout moment.
Beaucoup d'organisations utilisent encore les « anciens devis » (legacy quotes) du Sales Hub. Le passage au CPQ de Revenue Hub mérite d'être planifié, parce qu'il n'est ni automatique ni sans contrepartie.
Trois points à anticiper. D'abord, les modèles ne se transfèrent pas : un modèle d'ancien devis ne peut pas être repris tel quel dans le nouvel outil, il faut le reconstruire. Ensuite, certaines capacités restent aujourd'hui propres aux anciens devis : les échéances de paiement posées directement sur le devis, et les modèles entièrement codés en HubL. Le nouveau CPQ adopte une autre logique de personnalisation avancée, par modules React (en beta), plus modulaire mais différente. Enfin, l'accès au nouveau CPQ suppose une édition Revenue Hub Professional ou Enterprise et l'attribution de sièges aux utilisateurs qui créent ou envoient des devis.
La bonne nouvelle : la coexistence est possible. Un compte peut conserver l'accès aux anciens devis tout en activant les nouveaux. Les comptes Sales Hub Starter, Professional et Enterprise conservent l'accès aux anciens devis. Mais coexistence ne veut pas dire absence de décision : laisser deux expériences de devis ouvertes sans règle claire, c'est créer de l'incohérence dans la donnée commerciale, exactement ce que le CPQ est censé éviter.
La promesse la plus ambitieuse de Revenue Hub n'est pas le devis rapide. C'est l'idée que votre contexte revenu, une fois centralisé dans HubSpot, devient interrogeable par n'importe quelle IA via API, MCP et CLI. Demander à un agent « quels comptes renouvellent ce trimestre et combien paient-ils ? » et obtenir une réponse exploitable.
Cette promesse repose sur une hypothèse silencieuse : que la donnée revenu soit propre, structurée et gouvernée. C'est l'hypothèse la plus souvent fausse. Le mécanisme est le même que pour les agents Breeze : l'IA ne vérifie pas la donnée, elle la consomme. Un objet Contrats mal associé, des produits dupliqués, des étapes de cycle de vie ambiguës, et l'agent qui interroge votre revenu produit des réponses fausses avec une parfaite assurance.
Notre conviction, valable pour le revenu comme pour le reste du portail : l'IA amplifie ce qui existe. Sur une base propre, elle démultiplie la capacité des équipes. Sur une donnée désordonnée, elle industrialise les erreurs. C'est pour cette raison que nous abordons Revenue Hub comme un projet RevOps avant d'être un projet outil : cadrage du modèle de données revenu, structuration de l'objet Contrats et de ses associations, gouvernance des permissions sur les champs sensibles d'un devis, puis activation. C'est le chantier que nous menons dans nos missions de consulting SalesOps et Data.
Revenue Hub vise d'abord les entreprises B2B SaaS et de services, avec du revenu récurrent ou contractuel, qui gèrent aujourd'hui leur quote-to-cash dans des outils dispersés. Pour ce profil, la valeur est réelle dès lors que trois conditions sont réunies : un catalogue produits maîtrisé, des process de devis et d'approbation que l'on peut formaliser, et une volonté de tenir la donnée revenu dans la durée.
À l'inverse, deux situations appellent la prudence. Les organisations dont le besoin central relève de l'ERP (stock, usage billing fin, configurateur produit complexe) trouveront les limites actuelles du CPQ rapidement. Et les portails dont la donnée n'est pas gouvernée gagneront à traiter ce chantier avant d'empiler une couche transactionnelle, sous peine de transformer un problème de devis en problème de revenu.