Le modèle OAuth de LinkedIn pour l’API Marketing nécessite une ré-authentification humaine selon un calendrier fixe. Contrairement à Google Ads (compte de service, clé non expirante) et Meta (tokens de system user à longue durée avec refresh indéfini), les tokens d’accès LinkedIn expirent après 60 jours et les tokens de refresh expirent après 365 jours, sans alternative automatisée.
La hiérarchie des tokens
LinkedIn OAuth dispose de deux types de tokens :
Les tokens d’accès expirent après 60 jours. Chaque appel API que vous effectuez s’authentifie avec un token d’accès. Quand il expire, votre pipeline cesse de fonctionner.
Les tokens de refresh expirent après 365 jours. Un token de refresh vous permet de l’échanger contre un nouveau token d’accès sans que l’utilisateur ait à se reconnecter. Les tokens de refresh ne sont disponibles que pour les partenaires approuvés du LinkedIn Marketing Developer Platform (MDP) — l’accès API standard n’inclut pas le support des tokens de refresh.
La conséquence pratique : si vous avez un accès API standard (pas le statut de partenaire MDP), quelqu’un doit se connecter et se ré-authentifier tous les 60 jours. Aucune exception.
Si vous avez le statut de partenaire MDP et des tokens de refresh disponibles, vous atteignez quand même un mur dur à 365 jours. À ce moment-là, le token de refresh lui-même expire, et il n’y a aucun moyen d’en obtenir un nouveau sans authentification interactive. Quelqu’un doit ouvrir un navigateur, suivre le flux OAuth et autoriser à nouveau l’application. Vous ne pouvez pas automatiser cela — la conception de l’API de LinkedIn le prévient explicitement.
Comparaison avec les autres plateformes
Cette limitation vaut la peine d’être comprise dans son contexte, car elle influence la décision build vs. buy pour les pipelines LinkedIn.
Google Ads utilise un pattern de compte de service. Vous créez un compte de service dans GCP, accordez-lui l’accès à votre compte Google Ads et utilisez une clé de compte de service non expirante pour vous authentifier. Votre pipeline fonctionne indéfiniment sans intervention humaine. Le modèle de sécurité est centré sur le compte de service, pas sur l’utilisateur.
Les tokens de system user de Meta fonctionnent de façon similaire. Vous créez un system user dans Business Manager, générez un token longue durée, et ce token n’expire pas. Vous le faites tourner manuellement quand vous le souhaitez, pas quand Meta vous y oblige.
LinkedIn n’a pas d’équivalent de compte de service. L’authentification est toujours liée à un vrai utilisateur LinkedIn qui a autorisé l’application via le flux OAuth. Quand leur session expire, le pipeline s’arrête. C’est une décision de conception délibérée de la part de LinkedIn — leurs conditions d’utilisation restreignent l’accès programmatique à ce qu’un humain authentifié pourrait voir.
Stratégie opérationnelle pour les pipelines custom
Si vous êtes engagé dans un pipeline custom plutôt qu’un outil géré, voici à quoi ressemble une gestion réaliste des tokens :
Alertes calendrier, pas alertes code. Configurez un événement calendrier récurrent 45 jours après chaque émission de token (pas 60, pour laisser une marge). C’est le rappel pour se ré-authentifier. Si vous avez le statut de partenaire MDP et un token de refresh de 365 jours, configurez l’événement calendrier à 330 jours. Ne vous fiez pas aux alertes d’erreur de votre pipeline pour détecter cela — au moment où les alertes se déclenchent, vous êtes déjà en incident.
Monitoring du dashboard pour l’âge du token. Stockez l’horodatage d’émission du token dans une petite table de configuration dans votre warehouse. Écrivez une requête de monitoring simple qui alerte quand CURRENT_DATE - token_issued_date > 50 (pour les tokens d’accès de 60 jours) ou > 350 (pour les tokens de refresh de 365 jours). Attachez cela à votre exécution standard de monitoring de qualité des données afin que l’alerte remonte avant l’expiration.
Documentez qui effectue la ré-authentification. Le refresh du token nécessite quelqu’un avec un compte LinkedIn qui a accès au compte publicitaire. Documentez quelle personne est propriétaire de cette tâche et assurez-vous que cette personne ne quitte pas l’entreprise sans transférer l’accès. Cela semble évident jusqu’à ce que vous receviez une alerte à 2h du matin indiquant que votre pipeline LinkedIn est cassé parce que la personne qui l’a configuré a quitté il y a trois mois et personne n’a mis à jour les identifiants.
Testez le flux de ré-authentification avant d’en avoir besoin sous pression. Effectuez le flux OAuth une fois dans un environnement de staging pour savoir exactement quelles étapes sont requises. Le faire pour la première fois lors d’un incident de production en fin de trimestre financier est une mauvaise situation.
Quand les outils gérés ont plus de sens
Fivetran, Airbyte et des outils ELT similaires gèrent OAuth via leurs propres flux OAuth partenaires. Quand vous connectez un compte LinkedIn à Fivetran, Fivetran gère le cycle de vie du token en votre nom. L’expiration du token ne cause pas d’interruption du pipeline — Fivetran invite le propriétaire du compte à se ré-authentifier via leur interface, généralement avec une marge par rapport à la date d’expiration.
Pour les équipes où LinkedIn Ads est une source de données secondaire (pas le focus principal du système d’analytics), la surcharge opérationnelle de gérer manuellement les tokens OAuth est souvent l’argument décisif pour un connecteur géré. Le coût de Fivetran est souvent inférieur au coût d’un incident de production causé par un refresh de token oublié.
Si LinkedIn est une source de données centrale et que vous exécutez un pipeline custom pour des raisons de contrôle (pivots démographiques spécifiques, structures de données de formulaires lead, logique d’incrémentalité custom), construisez l’infrastructure de gestion des tokens dès le départ. Ne l’ajoutez pas plus tard.
Statut de partenaire MDP
Si votre équipe ou votre produit implique la gestion des données LinkedIn Ads pour plusieurs clients, vous pourriez être éligible au statut de partenaire MDP, qui débloque les tokens de refresh et des patterns d’accès à plus longue durée. La barre est plus haute — LinkedIn examine les candidatures MDP plus attentivement que l’accès API standard — mais les bénéfices opérationnels sont significatifs pour les pipelines de production à grande échelle.
Pour la plupart des équipes analytics d’une seule entreprise construisant des rapports internes, le statut MDP n’est pas la voie. Le cycle de token d’accès de 60 jours avec renouvellement basé sur le calendrier est le modèle opérationnel réaliste. Construisez-le explicitement plutôt que d’espérer passer aux tokens de refresh plus tard.