Le 30 septembre 2026, une partie de vos intégrations Salesforce Marketing Cloud peut cesser de fonctionner du jour au lendemain. Depuis mars 2026, Salesforce applique une durée de vie de 180 jours aux client secrets des Installed Packages : tout secret qui n'a jamais été renouvelé depuis le 25 mars 2026 expirera à cette date. Concrètement, vos appels REST et SOAP renverront une erreur d'authentification, vos automatisations s'arrêteront, et vos flux vers le CRM, la plateforme e-commerce ou l'entrepôt de données se figeront. Voici la marche à suivre pour auditer votre tenant, renouveler vos secrets sans coupure de service et industrialiser la rotation pour les 180 jours suivants.

Ce que Salesforce a changé

Jusqu'au printemps 2026, un client secret créé dans un Installed Package vivait indéfiniment. Beaucoup d'équipes se retrouvent donc avec des secrets vieux de cinq ou six ans, partagés entre plusieurs prestataires et stockés dans des fichiers de configuration jamais audités. Salesforce a mis fin à cette pratique en introduisant une expiration systématique.

180 jours, sans exception

Tout client secret généré depuis le 25 mars 2026 expire 180 jours après sa création. La règle s'applique à l'ensemble des Installed Packages, qu'ils soient de type Server-to-Server ou Web App, et quelle que soit l'édition de votre tenant.

La bascule du 30 septembre 2026

Les secrets antérieurs à cette réforme bénéficient d'une période de grâce : ils expirent tous le 30 septembre 2026. En revanche, si vous avez déjà effectué une rotation après le 25 mars 2026, votre échéance n'est plus le 30 septembre mais 180 jours après la génération du nouveau secret. Vérifiez donc la date réelle affichée par la plateforme plutôt que de vous fier au calendrier collectif.

Ce que l'expiration casse réellement

Un secret expiré ne provoque pas une dégradation progressive : l'appel au endpoint de token échoue immédiatement. Voici les zones à cartographier en priorité.

Étape 1 — Auditer vos Installed Packages

Rendez-vous dans Setup > Apps > Installed Packages. Le tableau récapitulatif affiche désormais une date d'expiration pour chaque secret. Exportez cette liste, puis complétez-la avec trois informations que Salesforce ne vous donnera pas : qui consomme ce package, où le secret est stocké, et qui est responsable de sa mise à jour.

Cet inventaire est souvent la partie la plus longue de l'exercice. Dans un tenant d'entreprise, il n'est pas rare de trouver quinze à vingt packages dont un tiers n'est plus utilisé. Profitez-en pour supprimer les packages orphelins : chaque secret que vous n'avez pas à renouveler est un incident que vous n'aurez pas.

Pour vérifier qu'un package est encore vivant, testez son couple client_id et client_secret contre le endpoint de token :

POST https://VOTRE_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
Content-Type: application/json

{
  "grant_type": "client_credentials",
  "client_id": "xxxxxxxxxxxxxxxxxxxxxxxx",
  "client_secret": "yyyyyyyyyyyyyyyyyyyyyyyy",
  "account_id": "7XXXXXXX"
}

Une réponse 200 accompagnée d'un access_token confirme que le package sert encore. Une réponse 401 signale soit un secret déjà invalide, soit un package dormant que vous pouvez archiver.

Étape 2 — Générer et mettre en place le nouveau secret

Dans le package concerné, déclenchez l'action de rotation du secret. Salesforce génère une nouvelle valeur tout en conservant l'ancienne active pendant une fenêtre de transition. C'est ce chevauchement qui rend une bascule sans coupure possible : exploitez-le, plutôt que de laisser le secret expirer par défaut.

Copiez immédiatement le nouveau secret dans votre coffre-fort (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, ou à défaut le gestionnaire de secrets de votre chaîne CI). Ne le collez jamais dans un ticket, un canal de messagerie ou un fichier partagé : c'est le moment précis où la plupart des fuites de credentials se produisent.

Étape 3 — Basculer sans interruption de service

La bonne pratique consiste à ne jamais coder un secret en dur. Si vos intégrations lisent leur secret depuis un coffre-fort, la bascule se résume à une mise à jour de valeur. Sinon, traitez chaque consommateur individuellement, dans cet ordre : environnements de recette d'abord, puis production, en commençant par les flux les moins critiques.

Côté code, prévoyez une gestion explicite de l'échec d'authentification plutôt qu'une relance aveugle :

async function getToken(secretProvider) {
  const secret = await secretProvider.get('sfmc/client_secret');

  const res = await fetch(TOKEN_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      grant_type: 'client_credentials',
      client_id: process.env.SFMC_CLIENT_ID,
      client_secret: secret,
      account_id: process.env.SFMC_MID
    })
  });

  if (res.status === 401) {
    // Secret expire ou revoque : on alerte, on ne boucle pas.
    await notifyOps('SFMC : token refuse, verifier la rotation du client secret');
    throw new Error('SFMC_AUTH_FAILED');
  }

  const data = await res.json();
  return { token: data.access_token, expiresIn: data.expires_in };
}

Une relance automatique sur un 401 ne fera que multiplier les appels échoués et brouiller vos logs. Une alerte immédiate, elle, vous fait gagner les heures qui comptent.

Étape 4 — Surveiller depuis Marketing Cloud

Vous pouvez aussi instrumenter la surveillance directement dans Automation Studio, avec une activité Script exécutée chaque semaine. L'idée est simple : tenter une authentification et journaliser le résultat dans une Data Extension de supervision.

<script runat='server'>
Platform.Load('Core', '1.1.1');
var de = DataExtension.Init('Ops_Auth_Monitor');

try {
  var req = new Script.Util.HttpRequest(tokenUrl);
  req.emptyContentHandling = 0;
  req.retries = 0;
  req.contentType = 'application/json';
  req.method = 'POST';
  req.postData = Stringify({
    grant_type: 'client_credentials',
    client_id: clientId,
    client_secret: clientSecret,
    account_id: mid
  });

  var resp = req.send();

  de.Rows.Add({
    CheckedOn: Now(),
    PackageName: 'Middleware_ETL',
    StatusCode: String(resp.StatusCode)
  });
} catch (e) {
  de.Rows.Add({
    CheckedOn: Now(),
    PackageName: 'Middleware_ETL',
    StatusCode: 'EXCEPTION'
  });
}
</script>

Branchez ensuite une alerte sur cette Data Extension : dès qu'un code différent de 200 apparaît, vous savez quel package traiter avant que la production ne le découvre à votre place.

Les pièges les plus fréquents

Le premier est le secret partagé. Quand un même package sert à quatre intégrations différentes, la rotation devient une opération coordonnée entre quatre équipes, avec autant de fenêtres de maintenance à aligner. Le remède est structurel : un package par consommateur, avec les scopes strictement nécessaires.

Le deuxième est l'oubli des sandbox. Les tenants de recette ont leurs propres packages et leurs propres échéances. Ils cassent en général avant la production, ce qui est une chance si vous les surveillez.

Le troisième est la confusion entre secret et token. Un access token expire au bout de vingt minutes et se renouvelle automatiquement ; un client secret, lui, exige une action humaine. Vos runbooks doivent distinguer clairement les deux, sous peine de voir une équipe attendre un renouvellement qui n'arrivera jamais.

La rotation des client secrets n'est pas un incident ponctuel à traiter avant le 30 septembre : c'est un rituel semestriel à inscrire dans votre calendrier d'exploitation, au même titre que le renouvellement de vos certificats TLS.

Passer de l'urgence au processus

Les équipes qui traverseront cette échéance sans incident sont celles qui auront transformé la contrainte en routine : inventaire à jour, secrets centralisés dans un coffre-fort, rotation planifiée trente jours avant chaque expiration, et supervision automatisée. C'est aussi l'occasion de réduire la surface d'attaque de votre tenant en supprimant les accès dont plus personne ne se souvient.

Si vous souhaitez un audit de vos Installed Packages et un plan de rotation adapté à votre architecture, parlons-en.

À retenir

Une échéance ferme. Tout client secret non renouvelé depuis le 25 mars 2026 expire le 30 septembre 2026, et l'authentification échoue immédiatement.

180 jours désormais. Chaque nouveau secret vit 180 jours : la rotation devient un rituel semestriel, pas une opération exceptionnelle.

L'inventaire d'abord. Cartographiez packages, consommateurs et lieux de stockage avant de toucher au moindre secret.

Un coffre-fort, jamais du code en dur. Centraliser les secrets transforme la bascule en simple mise à jour de valeur.

Surveillez au lieu d'attendre. Un contrôle d'authentification hebdomadaire vous prévient avant vos utilisateurs.