Comment une agence a absorbé 40 comptes acquis sans migration

Le deal s'est conclu un vendredi. Le mardi suivant, cette agence possédait tout le portefeuille d'un concurrent — et avec lui, quarante comptes ads clients qu'elle n'avait jamais touchés, éparpillés sur des logins et des Business Managers séparés. Le plan que tout le monde supposait suivre était un projet de migration : collecter chaque identifiant, se connecter à chaque compte, tout resaisir à la main sur quelques semaines pénibles. Ce qui s'est réellement passé fait l'objet de cette étude de cas sur la façon de mener un transfert d'acquisition d'agence et de consolidation de comptes ads — parce que l'agence a déposé un seul token System-User acquis, laissé l'auto-découverte faire remonter chaque compte, et exploitait les deux portefeuilles depuis un seul espace de travail avant même que la migration ne soit programmée.

Ceci est une histoire composite tirée de la façon dont les vraies agences gèrent la consolidation post-acquisition. Les noms et les chiffres exacts sont illustratifs ; le problème de transfert, et la forme de la correction, ne le sont pas.

Le deal se conclut : vous possédez désormais le portefeuille clients d'un concurrent

Acquérir une agence plus petite est une façon normale de faire croître un portefeuille : vous achetez les relations clients, les forfaits, et les gens qui les servent. Sur le papier, l'agence venait d'ajouter quarante comptes du jour au lendemain. En pratique, elle avait hérité d'un enchevêtrement — la boutique acquise avait géré ses comptes comme la plupart des agences avant de le dépasser, avec un éparpillement de logins, deux ou trois Business Managers, et la connaissance des accès vivant dans la tête de quelques personnes.

La propre maison de l'agence était en ordre. Elle exploitait déjà ses clients existants via une seule couche avec des sièges nommés et des rôles cantonnés, l'opposé du chaos de login partagé décrit dans pourquoi les logins partagés tuent votre agence ads. Le problème était d'absorber quarante comptes gérés selon les conventions de quelqu'un d'autre, assez vite pour que les clients hérités ne ressentent jamais la couture. Une acquisition transfère les contrats instantanément et la réalité opérationnelle lentement, et l'écart entre « on le possède » et « on peut l'exploiter » est là où les transferts post-acquisition calent.

Le coût caché des fusions-acquisitions : des dizaines de comptes derrière des logins séparés

Parcourez le portefeuille hérité et le coût de l'ancienne structure devient concret. Quarante comptes ne signifiaient pas quarante entrées bien rangées. Cela signifiait deux Business Managers montés à des moments différents, un éparpillement de comptes attachés à chacun, plusieurs que les anciens propriétaires atteignaient via des logins accordés par le client, et une poignée où le seul chemin d'entrée était un mot de passe partagé que trois anciens employés connaissaient.

Rien de tout cela n'est inhabituel ; c'est à quoi ressemble la couche d'accès d'une agence quand elle grandit un client à la fois. Mais cela transforme chaque acquisition en un projet d'archéologie : avant de pouvoir exploiter un compte, vous devez le trouver, confirmer qui peut l'atteindre, et établir votre propre voie d'entrée — quarante fois, sur plusieurs plateformes.

Le plan habituel : une migration identifiant par identifiant mesurée en semaines

La responsable des opérations de l'agence a d'abord cadré l'approche évidente. Lister chaque compte ; pour chacun, identifier le chemin d'accès, collecter l'identifiant, se connecter, confirmer une voie d'entrée durable qui ne dépendait pas d'un ancien employé, et la rétablir sous la propre structure de l'agence. Puis le compte suivant, et le suivant, sur deux Business Managers et plusieurs plateformes.

Estimé honnêtement, c'est des semaines de travail fragile. Chaque mot de passe partagé est un point de défaillance unique — si un employé partant le change ou cesse de répondre, un compte s'éteint. Chaque login accordé par le client doit être re-confirmé pour que la relation survive au changement de propriété. Et pendant toute la durée de la migration, les clients hérités sont dans les limbes : techniquement sous la responsabilité de l'agence, en pratique encore à moitié gérés via les logins de l'ancienne boutique. L'équipe avait déjà mené des versions plus petites de cela — la précipitation de la première semaine couverte dans leur propre playbook pour onboarder un nouveau compte client en première semaine — et à quarante comptes, cette précipitation ne scale pas.

Le raccourci : déposer le token System-User acquis

Il y avait un raccourci, et il a changé la forme de tout le projet. L'agence acquise, comme la plupart des agences opérant à grande échelle, avait émis un token System-User au niveau du Business Manager pour ses intégrations de plateforme. Un token System-User n'est pas un login personnel lié à un employé ; c'est un identifiant durable, au niveau du business, qui porte déjà l'accès à chaque compte ads que son Business Manager gère. L'agence n'avait pas besoin de quarante identifiants — elle avait besoin du token, acquis avec le business.

Alors au lieu de lancer une migration, la responsable des opérations a fait une seule chose : déposer le token System-User de l'agence acquise dans la couche opérationnelle, le même mécanisme de connexion-unique que l'agence utilisait déjà pour onboarder un compte client sans jamais partager de login Meta. Un token, un collage, pour tout un Business Manager de comptes. Le plan de migration aurait touché chaque compte individuellement ; le token a touché la couche qui les tenait déjà tous.

Ce que l'auto-découverte a fait remonter : chaque compte et BM, sans inventaire manuel

Ce qui s'est passé ensuite est la raison pour laquelle le projet de migration n'a jamais eu lieu. La couche opérationnelle a lu le token, résolu le business_id derrière lui, et énuméré les comptes automatiquement — chaque compte ads sous ce Business Manager, fait remonter sans que personne ne tape une liste. Le second Business Manager est entré de la même façon avec son propre token, et entre les deux, le gros des quarante comptes était visible en un après-midi.

Il n'y avait pas d'inventaire manuel parce que le token connaissait déjà l'inventaire. L'auto-découverte via business_id signifiait que la source de vérité pour « quels comptes existent » était le Business Manager lui-même, pas un tableur reconstruit à partir des souvenirs d'anciens employés. La poignée de comptes détenus via un accès accordé par le client plutôt que via le BM acquis nécessitait encore une re-confirmation individuelle, mais c'était une courte traîne, pas tout le projet.

Mapper l'équipe héritée dans des rôles RBAC internes

Faire remonter les comptes était la moitié du travail ; l'autre moitié était de décider qui pouvait les toucher. L'agence acquise avait conservé certains buyers dans le cadre du deal et en avait laissé partir d'autres, et l'agence n'allait pas répliquer l'éparpillement d'accès de l'ancienne boutique. Les comptes étant désormais à l'intérieur de la couche opérationnelle, gouverner qui les travaillait était une décision interne, pas une propriété des logins de plateforme.

La responsable des opérations a assigné des rôles cantonnés. Les buyers conservés ont obtenu des sièges nommés correspondant aux comptes qu'ils continueraient de servir, pour que les relations clients restent chaudes via des gens que les clients connaissaient déjà ; les propres responsables de l'agence ont obtenu une supervision sur les deux portefeuilles ; le personnel partant n'a rien obtenu. Rien n'a eu besoin d'être révoqué sur les plateformes natives, parce qu'aucun des buyers hérités n'opérait jamais via les logins sous-jacents. Ils travaillaient via des rôles internes par-dessus un seul token connecté, le modèle que l'agence utilise pour empêcher les logins séparés de devenir la couche opérationnelle. La gouvernance des accès s'est faite une fois, au lieu de quarante fois sur les écrans de permissions natifs.

Exploiter les deux portefeuilles depuis un seul espace de travail dès la première semaine

À la fin de la première semaine, l'agence exploitait ses clients d'origine et les quarante comptes hérités depuis le même espace de travail. La réunion de scaling, la file de lancement, le reporting — tout couvrait les deux portefeuilles à la fois, dans une seule vue au lieu de basculer entre la propre structure de l'agence et les deux Business Managers de la boutique acquise. Les clients hérités ont obtenu la cadence de reporting standard de l'agence immédiatement plutôt qu'après un trimestre de transition.

Les clients n'ont rien ressenti. Pas de réinitialisations de mots de passe, pas d'emails « on migre votre compte », pas de rupture dans la gestion — l'agence qui avait racheté leur ancienne boutique a simplement continué de gérer leurs publicités. Les semaines de limbes à moitié gérés qu'une migration aurait créées n'ont jamais existé.

Leçon : quand le token fait la découverte, une acquisition est une connexion

Interrogée après coup sur ce qu'elle dirait à une autre agence face à une acquisition, la réponse de la responsable des opérations a été précise : avant de cadrer une migration, vérifiez si l'accès que vous achetez inclut un token System-User de Business Manager. S'il l'inclut, vous ne migrez pas quarante comptes — vous connectez deux Business Managers et re-confirmez une courte traîne de comptes accordés par le client, et votre vrai travail est la couche de gouvernance par-dessus.

Cette reformulation est toute la leçon. Une migration suppose que le travail scale avec le nombre de comptes ; une connexion suppose qu'il scale avec le nombre de chemins d'accès — et un token System-User réduit tout un Business Manager à un seul chemin. L'agence a consolidé quarante comptes en un après-midi parce que l'auto-découverte via business_id avait déjà fait le travail compte par compte. Le même schéma tient sur les six plateformes ads que la couche opérationnelle prend en charge, alors un portefeuille acquis couvrant Meta, Google, TikTok, Taboola, Snapchat et Outbrain entre canal par canal plutôt que compte par compte.

Les offres de Wevion démarrent par un palier gratuit permanent (0 €), puis Starter à 99 €/mois, Pro à 499 €/mois, et Plus à 1 499 €/mois (1 199 € en annuel, facturé à l'année à -20 %), avec Enterprise en offre sur mesure, et chaque palier payant inclut un essai de 14 jours qui coexiste avec le plan gratuit. Connecter un token System-User et regarder les comptes s'auto-découvrir s'inscrit dans ce cadre. Le reste du playbook se trouve dans le cluster outils d'agence.

L'enseignement se généralise à toute agence qui grandit par acquisition : la taille du transfert n'est pas le nombre de comptes que vous avez achetés, c'est le nombre de façons distinctes que vous avez de les atteindre. Héritez le token qui porte tout le Business Manager, laissez la découverte faire l'inventaire, gouvernez l'équipe héritée via des rôles internes — et la migration que vous redoutiez s'avère avoir été une étape de connexion.