« Les applications privées HubSpot permettent de définir des portées d’accès précises pour chaque intégration », précise la documentation officielle des développeurs HubSpot. Cette précision a pris tout son sens pour une agence gérant un réseau de 300 fronts headless indépendants, chacun consommant WordPress comme source de contenu et transmettant ses formulaires de contact au même compte HubSpot mutualisé, via une seule et même clé d’API partagée entre l’ensemble des projets.
Cette checklist décrit comment cloisonner cette intégration partagée, projet par projet, sans traiter la performance de l’intégration elle-même, qui reste hors périmètre de cet article.
1. Identifier le risque d’une clé unique partagée
Avec une seule clé API HubSpot utilisée par les 300 fronts, la compromission d’un seul projet, par exemple via une variable d’environnement mal protégée sur un front peu surveillé, expose immédiatement l’intégralité du compte HubSpot mutualisé, avec ses contacts, ses transactions et son historique commercial complet, bien au-delà du périmètre du front réellement compromis.
2. Créer une application privée HubSpot distincte par front
La correction technique consiste à remplacer la clé unique par une application privée HubSpot dédiée à chaque front, avec des portées d’accès (scopes) strictement limitées au strict nécessaire pour ce projet précis : généralement, uniquement la création de contacts et de tickets, sans jamais de droit de lecture ou de suppression sur l’ensemble de la base de contacts existante.
fetch('https://api.hubapi.com/crm/v3/objects/contacts', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.HUBSPOT_TOKEN_FRONT_COMMUNE_312}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
properties: { email, firstname, lastname, source: 'commune-312' },
}),
});3. Nommer et documenter chaque jeton individuellement
Sur un réseau de 300 fronts, la gestion manuelle de 300 jetons distincts devient rapidement ingérable sans convention claire. Chaque jeton est nommé selon une convention systématique incluant l’identifiant du front concerné, et documenté dans un registre centralisé indiquant sa date de création, ses portées exactes, et la personne responsable de sa rotation en cas d’incident.
- Un jeton par front, jamais de mutualisation même entre deux projets jugés proches.
- Portées d’accès limitées à la création de contacts, sans lecture ni suppression étendue.
- Registre centralisé listant chaque jeton, son propriétaire et sa date de dernière rotation.
4. Permettre une rotation individuelle sans interruption du réseau
L’avantage majeur du cloisonnement par jeton individuel apparaît en cas d’incident : si un front spécifique est compromis, seul son jeton doit être révoqué et régénéré, sans que les 299 autres fronts n’en subissent la moindre interruption de service. Avec la clé unique partagée d’origine, la même situation aurait imposé une rotation générale, avec mise à jour simultanée des 300 projets, un chantier de plusieurs jours pendant lequel l’ensemble du réseau aurait fonctionné en mode dégradé.
5. Surveiller les volumes anormaux par jeton
Le cloisonnement par jeton permet également une supervision plus fine : un volume anormal de créations de contacts sur un jeton précis, très supérieur à la moyenne historique de ce front, devient un signal d’alerte exploitable individuellement, alors qu’il aurait été noyé dans le volume global d’une clé unique partagée par 300 projets.
Mutualiser un compte CRM entre de nombreux projets indépendants est souvent un choix économique justifié ; mutualiser la clé d’accès qui protège ce compte ne l’est presque jamais, dès que le nombre de projets dépasse la poignée que l’on peut encore surveiller individuellement à l’œil.
En résumé
Le passage d’une clé API HubSpot unique à 300 applications privées distinctes, une par front, a demandé un effort de migration réel mais a transformé un risque systémique en une série de risques isolés, chacun cantonné à son propre périmètre. Cette approche, transposable à toute intégration tierce mutualisée sur un grand nombre de fronts indépendants, reste la seule façon fiable d’éviter qu’un incident isolé ne se propage à l’ensemble d’un réseau.
