Comment une agence a onboardé 80 comptes clients sans un seul identifiant partagé

Le point de rupture est arrivé, comme d'habitude, sous forme de tableur. Une agence de media buying qui était passée d'une poignée de clients à un portefeuille tentaculaire gardait un onglet appelé « Identifiants » — une ligne par client, des colonnes pour le nom d'utilisateur, le mot de passe, la sauvegarde 2FA, et la date du dernier changement. Le jour où cette feuille a franchi quatre-vingts lignes, le responsable des opérations a cessé de scroller et a admis l'évidence : ce n'était pas un système, c'était une responsabilité avec une barre de recherche. Voici l'histoire de la façon dont cette agence a appris à onboarder un compte pub client sans partager d'identifiant du tout — un token System-User saisi une fois, l'auto-découverte qui fait remonter chaque compte, et des rôles internes au lieu de mots de passe.

Ceci est un cas composite tiré de schémas d'agence courants, mais le mode d'échec et la correction sont réels. Les chiffres exacts sont illustratifs ; la prolifération d'identifiants, et la façon dont elle devient dangereuse à mesure qu'une agence scale, ne le sont pas.

Le point de rupture : un identifiant pour chaque client

Durant ses premières années, l'agence onboardait les clients de la seule façon qu'elle connaissait. Un nouveau client signait, et l'appel de lancement se terminait par la même demande gênante : « Pouvez-vous partager votre identifiant Meta pour qu'on puisse entrer dans le compte pub ? » Parfois le client remettait son mot de passe Facebook personnel. Parfois il créait un utilisateur jetable avec des droits admin. Dans les deux cas, l'agence repartait avec un identifiant de plus à stocker, et l'onglet « Identifiants » gagnait une ligne de plus.

À dix clients, c'était agaçant. À quatre-vingts, c'était un risque à plein temps. Chaque mot de passe qui changeait côté client cassait l'accès en silence jusqu'à ce qu'une campagne se périme. Chaque invite 2FA atterrissait sur un téléphone appartenant à une personne, qui devenait un point de défaillance unique pour tout le portefeuille d'activité. Et personne ne pouvait répondre à la question qui devrait avoir une réponse d'un mot : qui, exactement, a accès au compte de ce client en ce moment ?

Pourquoi les identifiants partagés étaient le vrai risque

L'agence avait supposé que son risque vivait dans la performance — une mauvaise semaine, un objectif raté. La vraie exposition était la feuille d'identifiants. Comme nous l'exposons dans pourquoi les identifiants partagés tuent votre agence pub, un identifiant partagé est le pire de tous les mondes à la fois : il ne peut pas être attribué, ne peut pas être révoqué en toute sécurité, et ne peut pas être audité.

Trois défaillances s'empilaient. Premièrement, les clés 2FA et les mots de passe vivaient dans un gestionnaire de mots de passe, donc l'accès à un coffre était l'accès à quatre-vingts clients — une surface de brèche qu'aucun client n'aurait approuvée. Deuxièmement, les juniors avaient un accès complet par défaut, parce qu'un identifiant partagé n'a aucune notion de rôles ; remettre à un nouveau buyer « le mot de passe » lui remettait tout. Troisièmement, l'offboarding était une traque manuelle : quand un buyer partait, quelqu'un devait se rappeler chaque Business Manager que ce buyer avait touché et retirer l'accès à la main, compte par compte, en espérant que rien ne manque.

Ce dernier point empêchait le responsable des opérations de dormir. Un buyer qui part avec un accès résiduel sur des dizaines de Business Managers clients est le résultat par défaut d'un modèle à identifiant partagé — exactement le genre de faille cataloguée dans notre récapitulatif des erreurs de permissions de comptes pub d'agence.

Le glissement : connecter avec un token, pas un mot de passe

Le changement était moins un nouvel outil qu'un nouveau modèle mental : cesser de traiter l'accès au compte comme un identifiant à collecter, et commencer à le traiter comme une connexion à établir une fois. L'agence a déplacé son portefeuille sur Wevion et a connecté les comptes clients via un token System-User plutôt qu'un identifiant personnel.

La mécanique était presque anticlimatique. Pour chaque client, l'agence établissait un token System-User contre le Business Manager du client — une connexion sanctionnée, de niveau machine, qui ne dépend du mot de passe personnel ou de la 2FA de personne. Le token était saisi une fois. Puis l'auto-découverte faisait la partie qui prenait jadis un après-midi : lisant le business_id, elle faisait remonter chaque compte pub et Business Manager que ce token pouvait atteindre et les tirait dans l'espace de travail automatiquement — pas de copie d'IDs de compte entre écrans, pas de comptes manquants découverts trois semaines plus tard.

Un identifiant partagé est un secret que vous devez protéger pour toujours. Un token System-User est une connexion que vous établissez une fois et gouvernez ensuite — la distinction explorée dans identifiants séparés contre une couche d'opération multi-marques. L'agence n'était plus dans le métier de stocker des mots de passe. Elle était dans le métier d'accorder de l'accès.

Mapper l'équipe à des rôles, pas à des identifiants

Avec les comptes connectés, l'agence a affronté la question que l'ère de l'identifiant partagé ne lui avait jamais permis de poser proprement : qui dans l'équipe devrait pouvoir faire quoi, sur quel client ?

Le contrôle d'accès interne basé sur les rôles en a fait une configuration, pas un identifiant. Chaque buyer s'est vu attribuer un rôle limité aux comptes qu'il travaillait réellement. Un senior sur le roster entreprise obtenait un large accès là et aucun sur le portefeuille des petites entreprises. Un junior obtenait exactement les comptes qui lui étaient assignés et rien d'autre. Crucialement, accorder cet accès n'impliquait jamais de remettre un identifiant Meta — le token sous-jacent restait chez l'agence, et le buyer opérait simplement dans l'espace de travail sous son rôle nommé.

C'est la moitié du système que les identifiants partagés rendent impossible. Vous ne pouvez pas limiter un mot de passe — vous pouvez seulement le donner ou le retenir. Les rôles permettent à l'agence d'accorder l'accès précis dont une personne a besoin et rien de plus, ce qui est la prémisse derrière le flux d'onboarding discipliné que nous décrivons dans le playbook d'onboarding client de la première semaine de l'agence. L'accès est devenu quelque chose que vous assignez, relisez et ajustez — pas un secret dont vous espérez qu'il reste contenu.

Onboarder le client suivant dès la première semaine

La preuve s'est montrée la fois suivante où l'agence a signé un client. Dans l'ancien modèle, onboarder un nouveau compte était une affaire de plusieurs jours, tendue : courir après le client pour les identifiants, les stocker, tester l'accès, découvrir un sous-compte que personne n'avait mentionné, courir à nouveau, et enfin faire travailler un buyer à la fin de la deuxième semaine.

Le nouveau flux a réduit tout cela. L'agence établissait le token System-User, l'auto-découverte faisait remonter les comptes et Business Managers du client en une passe, et le responsable des opérations assignait leurs rôles aux buyers. Le buyer travaillait dans l'espace de travail dès la première semaine — pas en attente d'une réinitialisation de mot de passe, pas bloqué par une invite 2FA routée vers quelqu'un en congé. Le client, de son côté, était soulagé de ne pas remettre son mot de passe Facebook personnel à une agence extérieure, transformant une demande de lancement inconfortable en un point de confiance.

Ce qui a changé pour la sécurité et l'audit

L'histoire de la sécurité était la partie que le responsable des opérations n'avait pas pleinement anticipée. Deux choses se sont nettement améliorées d'un coup.

L'offboarding est passé d'une traque à un clic. Quand un buyer partait, il n'y avait pas de liste de Business Managers à passer au peigne fin et pas de mot de passe partagé à réinitialiser sur quatre-vingts clients. Le rôle du buyer était révoqué dans l'espace de travail, et son accès se terminait partout d'un coup — en une action en pratique. L'angoisse du « avons-nous tout eu ? » a disparu, parce que l'accès n'avait jamais été dispersé entre des identifiants au départ.

Et l'agence pouvait enfin répondre à la question de l'accès. Parce que chaque buyer travaillait sous un rôle nommé plutôt qu'une identité partagée, l'agence avait une image claire de qui pouvait toucher quoi, et une trace de qui l'avait fait — les permissions décident qui peut changer un compte, et la trace enregistre ce qu'il a changé. Une agence qui fait tourner son portefeuille ainsi peut dire à tout client précisément qui a accès et ce qu'il a fait, ce qui est une conversation différente de « on pense que c'était l'un de nos buyers ».

La vue portefeuille : un espace de travail, six plateformes

Le modèle token-et-rôles n'était pas une commodité Meta-only. Le même principe — connecter un compte une fois, accorder des rôles internes, ne jamais faire circuler d'identifiant — s'étend sur les six plateformes que l'espace de travail supporte : Meta, Google, TikTok, Taboola, Snapchat et Outbrain. Un client faisant tourner Meta et TikTok et un peu de Taboola n'était plus trois problèmes d'identifiant. C'était un client connecté dans un espace de travail, avec les buyers de l'agence travaillant chaque canal sous le même rôle qu'ils avaient déjà.

Cette consolidation a enfin retiré l'onglet « Identifiants » pour de bon. L'agence ne gérait pas quatre-vingts mots de passe sur six plateformes — un nombre qui aurait grimpé à des centaines d'identifiants. Elle gérait un portefeuille, gouverné par des rôles, connecté par des tokens, visible en un seul endroit. Le reste du playbook d'opération vit dans le hub agency-tools.

Côté tarif, le modèle scale avec le portefeuille plutôt qu'avec l'équipe : les sièges sont illimités sur chaque plan, donc ajouter des buyers ne coûte jamais plus, et les comptes parallèles scalent de trois sur le tier Free permanent (0 €) en passant par Starter à 99 €/mois et Pro à 499 €/mois jusqu'à illimité sur Plus à 1 499 €/mois (1 199 € en annuel, facturé à l'année à -20 %), avec Enterprise en plan sur mesure. Chaque tier payant inclut un essai de 14 jours qui coexiste avec le plan gratuit.

La leçon : séparer la couche d'opération de l'identifiant

Quand on lui demande ce qu'il dirait à une version plus jeune de l'agence, le responsable des opérations est direct : l'erreur était de traiter l'accès au compte et l'outil d'opération comme la même chose. Ils ne le sont pas. L'identifiant — le mot de passe, la clé 2FA — appartient au client. La couche d'opération, où vos buyers lancent, éditent et reportent, vous appartient. L'ère de l'identifiant partagé les a fusionnés, et cette fusion était la source de chaque problème : la prolifération, les traques d'offboarding, la question d'accès sans réponse.

Les séparer est toute la correction. Connectez le compte une fois via un token System-User, laissez l'auto-découverte faire remonter tout ce que ce token peut atteindre, et donnez à votre équipe des rôles internes au lieu de mots de passe. Faites cela, et onboarder le quatre-vingt-unième client ressemble à onboarder le premier — une connexion établie et quelques rôles assignés — au lieu d'une ligne de plus sur un tableur qui aurait dû cesser de grandir il y a longtemps. L'agence qui peut onboarder un compte client sans partager d'identifiant est celle qui peut continuer d'ajouter des clients sans que son risque se compose à leurs côtés.