ATS multi-établissements : 1 abonnement vs N — l'économie du multi-plateforme cloisonné

Quand un réseau territorial empile cinq, dix, quinze ATS séparés

Dans la plupart des réseaux territoriaux français — Chambres de commerce et d'industrie (CCI), Chambres de métiers et de l'artisanat (CMA), Centres de formation d'apprentis (CFA), groupements d'IUT, GRETA, groupes d'écoles de commerce ou d'ingénieurs, cabinets RH déployés sur plusieurs portails de marque — le même scénario se rejoue. Chaque site, chaque territoire, chaque marque a déployé son propre logiciel de recrutement à l'époque où il en avait besoin. Le premier site a choisi un ATS A en 2018, le deuxième un ATS B en 2020 parce qu'il avait un meilleur module SMS, le troisième un C en 2022 parce que le précédent avait été racheté et que les prix avaient explosé.

Résultat en 2026 : un même réseau opère cinq, dix, parfois quinze instances ATS distinctes. Cinq, dix, quinze contrats. Cinq, dix, quinze montants de licence qui s'additionnent. Cinq, dix, quinze fournisseurs à auditer côté DPO. Cinq, dix, quinze intégrations à maintenir pour la DSI. Cinq, dix, quinze formations utilisateurs à organiser. Cinq, dix, quinze silos de données impossibles à consolider.

Et lorsqu'un candidat dépose un dossier sur le portail de la chambre consulaire de la région A, puis tente sa chance trois mois plus tard sur le portail de la région B du même réseau, personne ne le sait. Les deux équipes recommencent le tri à zéro. Le candidat lui-même refait son CV, son consentement RGPD, ses entretiens préliminaires. L'inefficacité est totale, et pourtant chacun pris isolément utilise un outil qui fait son travail.

Ce paradoxe — chaque ATS est correct localement mais le réseau dans son ensemble paye N fois et ne capitalise rien — est précisément ce que résout l'approche multi-plateforme cloisonnée. Dans cet article, on décortique le modèle économique, la différence (souvent confondue) entre multi-tenant et multi-plateforme, le ROI chiffré pour un réseau type, et la mécanique technique réelle livrée par MyCVthèque V2 en juin 2026.

Le piège des ATS mono-établissement : pourquoi empiler N licences est intenable

Un ATS classique a été pensé pour un client unique : une entreprise, un cabinet, un établissement. Son modèle de données suppose qu'il y a un seul propriétaire des candidats, un seul jeu d'utilisateurs internes, un seul branding. Quand un réseau territorial déploie le même ATS sur cinq territoires, il signe en réalité cinq abonnements indépendants. Le piège a quatre composantes.

1. Coût licence multiplié mécaniquement par N

La tarification standard d'un ATS du marché tourne autour de 600 à 900 € HT par mois pour une PME, soit 7 200 à 10 800 €/an. Multipliez par cinq sites : vous êtes entre 36 000 et 54 000 € annuels rien que sur la licence. Et ce, sans aucun effet d'échelle : signer cinq contrats au même éditeur ne donne quasiment jamais de remise réseau, parce que l'éditeur a calibré ses prix par instance, pas par groupe. Pire : si chaque site a choisi un éditeur différent, vous cumulez aussi cinq engagements de durée différents, cinq dates de renouvellement, cinq équipes commerciales à gérer.

2. Données en silos : impossible de voir un candidat sur un autre site

Un candidat qui postule sur la plateforme de votre territoire Nord, puis sur la plateforme de votre territoire Sud, n'existe juridiquement et techniquement pas comme la même personne dans vos systèmes. Vous payez deux fois pour traiter le même dossier. Vous le recontactez deux fois. Vous lui faites passer deux entretiens qualif. Et si jamais ses deux candidatures arrivent à des étapes différentes — accepté côté Sud, en cours côté Nord — personne n'arbitre. Côté expérience candidat, c'est désastreux : votre marque réseau apparaît comme désorganisée.

3. Reporting consolidé impossible

La direction réseau veut une réponse simple à des questions simples : combien de candidats traités ce trimestre tous sites confondus, quel coût moyen par embauche, quel délai moyen de recrutement, quelle source recrute le mieux ? Avec N ATS séparés, vous n'avez aucune de ces réponses sans projet BI. Il faut exporter cinq CSV, les harmoniser à la main parce que les statuts ne sont pas les mêmes d'un éditeur à l'autre, les charger dans un Power BI, maintenir le tout. Chaque réorganisation interne casse le pipeline. La donnée vous coûte en énergie ce que vous croyez économiser en outil.

4. DSI : N intégrations à maintenir

Côté DSI, le multi-ATS est un cauchemar de surface d'attaque. Cinq instances SaaS = cinq comptes admin à sécuriser, cinq SSO à configurer si vous voulez fédérer l'identité, cinq webhooks vers votre SIRH, cinq calendriers d'audit de pénétration, cinq politiques de mots de passe à harmoniser. Et chaque éditeur a sa propre API : harmoniser un connecteur LinkedIn Recruiter, un export vers Sage Paie ou une synchro Teams revient à faire le travail cinq fois. Sans compter qu'au moindre changement d'éditeur côté un seul site, tout l'écosystème d'intégrations doit être ré-aligné.

Multi-tenant vs multi-plateforme cloisonné : ne pas confondre les deux modèles

La plupart des éditeurs SaaS communiquent sur leur architecture « multi-tenant ». C'est un terme technique précis qui ne veut pas dire ce que beaucoup de DRH croient. Il faut bien distinguer deux concepts complémentaires : multi-tenant (architecture éditeur) et multi-plateforme intra-tenant (organisation client).

Multi-tenant : 1 instance partagée, isolation BDD par tenant_id

Un SaaS multi-tenant est une plateforme où plusieurs clients juridiquement distincts partagent la même base de code, le même hébergement et la même base de données, mais sont isolés logiquement par un champ tenant_id présent dans chaque table. Concrètement : le cabinet Dupont et le cabinet Martin sont tous deux clients du même éditeur, leurs données vivent dans la même base PostgreSQL, mais aucune requête ne peut traverser la frontière du tenant_id. C'est la séparation juridique : chaque client est un tenant, point.

Ce modèle est l'état de l'art SaaS depuis quinze ans. Il permet à l'éditeur de maintenir un seul code, de patcher tout le monde en même temps, d'auditer une seule architecture. Mais du point de vue d'un réseau territorial, il ne résout rien : votre réseau apparaît à l'éditeur comme cinq tenants distincts, donc cinq abonnements distincts, et chaque tenant ne peut pas voir les autres — par construction.

Multi-plateforme intra-tenant : 1 tenant, N sous-marques, cloisonnement par plateformes[]

Le multi-plateforme cloisonné est une couche supplémentaire au sein d'un tenant. Vous êtes un seul client, donc un seul tenant, donc un seul abonnement. Mais à l'intérieur de votre tenant, vous opérez N sous-marques (vos N territoires, vos N centres, vos N portails de candidature). Chaque candidat, chaque utilisateur, chaque pipeline porte un champ plateformes[] qui peut contenir une ou plusieurs valeurs.

Sur MyCVthèque V2, ce cloisonnement est concrétisé par deux concepts complémentaires : formateur.plateformes[] côté objets métier (candidats, formateurs, offres) et user.plateforme_scope côté utilisateurs internes. Un admin local a un plateforme_scope = ['nord'], il ne verra jamais que les candidats dont plateformes[] contient 'nord'. Un admin réseau a un plateforme_scope = ['*'], il bascule via le sélecteur en haut à droite entre vues locales et vue consolidée.

Quand choisir lequel ?

• Multi-tenant pur (= N abonnements) : si vos N entités sont juridiquement indépendantes (filiales avec SIREN distincts, holdings non solidaires), il peut être pertinent d'avoir des tenants séparés pour des raisons de gouvernance des données. Pour clarifier : ce sont N contrats avec l'éditeur.
• Multi-plateforme cloisonné intra-tenant (= 1 abonnement) : si votre réseau est un même groupe (même SIREN, ou consortium opérant des marques sœurs sous la responsabilité d'une entité centrale), le multi-plateforme intra-tenant est la bonne réponse. C'est le cas d'un cabinet RH multi-portails, d'un réseau CCI multi-territoire, d'un groupe d'écoles, d'un GRETA inter-académique, d'un opérateur d'apprentissage exploitant plusieurs marques.
• Hybride : certains réseaux combinent les deux. Plusieurs tenants juridiques au niveau régional, chacun opérant lui-même N plateformes intra-tenant. MyCVthèque supporte les deux niveaux nativement.

La confusion habituelle fait croire qu'un SaaS multi-tenant suffit à servir un réseau. C'est faux : multi-tenant règle un problème éditeur (mutualisation), multi-plateforme règle un problème client (consolidation). Les deux sont nécessaires, mais c'est le second qui produit l'économie réelle pour vous.

Le modèle économique 1 abonnement vs N : ROI chiffré sur 5 sites

Mettons les chiffres sur la table. Prenons un réseau type de cinq sites : cinq territoires d'un réseau consulaire, cinq centres d'un CFA multi-site, cinq portails d'un cabinet RH multi-marques. On compare deux scénarios à fonctionnalité équivalente.

Sur un horizon de trois ans, l'économie cumulée dépasse 110 000 €. Sur cinq ans, on franchit la barre des 175 000 €. Et ce calcul ne prend pas en compte les gains indirects : reporting plus rapide, équipes RH locales moins saturées, candidats traités sans double saisie, marque réseau plus cohérente.

Pourquoi ce différentiel n'est pas une promo : il est structurel

L'écart n'est pas une remise commerciale. Il vient de l'architecture. Sur un ATS classique, chaque site consomme une instance avec ses propres ressources serveur, son propre support, sa propre base, sa propre supervision. Sur MyCVthèque multi-plateforme, les cinq sites partagent l'infrastructure mais sont cloisonnés par les champs plateformes[] et plateforme_scope. Le coût marginal d'un site supplémentaire est quasi nul côté éditeur, donc transmis au client sous forme d'abonnement unique.

Mêmes données disponibles selon le rôle, sans rien casser

Le cœur du modèle : les économies ne se font pas au détriment de la séparation des rôles. Un admin local de la plateforme « Nord » continue de voir exactement et uniquement ce qu'il voyait dans son ancien ATS dédié. Un admin réseau, lui, bascule entre vue Nord, Sud, Est, Ouest et vue consolidée en un clic. La séparation est applicative et auditée : le système refuse toute requête en cross-plateforme qui ne provient pas d'un compte explicitement scopé en multi-plateforme.

Le piège commercial à éviter

Méfiez-vous des éditeurs qui vous proposent un « pack 5 instances » à prix réduit. Ce n'est pas du multi-plateforme : c'est un regroupement de facturation. Vous payez moins par instance mais vous gardez les silos, le reporting impossible et la maintenance DSI multipliée. La vraie économie vient de l'unification structurelle, pas du grouping commercial.

Démo : comment ça marche techniquement dans MyCVthèque V2

La feature multi-plateforme livrée par MyCVthèque le 1^er juin 2026 s'appuie sur quatre éléments visibles dans l'interface, plus un modèle de données sous le capot.

1. Le sélecteur de plateforme dans la navigation

En haut à droite de l'application, juste à côté de l'avatar utilisateur, un sélecteur affiche la plateforme active. Un admin scopé à une seule plateforme voit le sélecteur grisé (il a un contexte fixe). Un admin réseau a un menu déroulant avec toutes les plateformes de son périmètre, plus une option « Vue réseau (toutes) ». Changer de plateforme reconfigure instantanément toute l'UI : liste des candidats, statistiques, offres, utilisateurs, branding.

2. Le badge plateforme sur la fiche candidat

Chaque candidat, chaque offre, chaque action affiche un badge coloré indiquant à quelle plateforme il appartient. Quand un admin réseau parcourt sa vue consolidée, il identifie d'un coup d'œil l'origine de chaque dossier sans avoir à cliquer. Le badge utilise la couleur primaire de la plateforme (paramétrable dans les réglages de marque).

3. Le scope utilisateur : Admin local vs Admin réseau

Le champ user.plateforme_scope est un tableau qui détermine ce que l'utilisateur peut voir :

• plateforme_scope: ['nord'] → admin local exclusivement scopé à la plateforme Nord. Aucune fuite possible : ses requêtes API et SQL sont automatiquement filtrées par middleware.
• plateforme_scope: ['nord', 'sud'] → cas intermédiaire, par exemple un coordinateur régional sur deux territoires.
• plateforme_scope: ['*'] → admin réseau, accès à toutes les plateformes du tenant.

4. Le filtre automatique tout au long de l'UI

Le filtre par plateforme n'est jamais à activer manuellement : il est appliqué par défaut en fonction du scope de l'utilisateur connecté. Recherche candidat, export CSV, déclenchement d'une campagne SMS, génération d'un rapport : tout est automatiquement borné. C'est important pour la conformité RGPD : un utilisateur cloisonné ne peut jamais accidentellement exporter ou consulter une donnée d'une autre plateforme, même via les URL directes.

Modèle de données sous le capot

Sur le candidat (table formateurs dans le legacy CVthèque, ou candidats en V2), le champ plateformes[] est un tableau JSONB indexé qui contient les identifiants des plateformes auxquelles ce candidat est rattaché. La plupart du temps un candidat n'appartient qu'à une plateforme. Mais le modèle permet d'attacher un même candidat à plusieurs plateformes (ex : un candidat qui a explicitement consenti à être visible des deux territoires d'un réseau). Côté requêtes, un index GIN PostgreSQL rend les filtres ultra-rapides même sur des bases de 100 000+ candidats. Le cloisonnement n'a aucun coût de performance perceptible.

Cas d'usage type : un réseau de 4 territoires

Pour ancrer le modèle, prenons un cas réel anonymisé. Un cabinet RH du Sud opère quatre portails de candidature distincts, chacun positionné sur un bassin d'emploi : Région A (métropole), Région B (périurbain), Région C (rural tertiaire), Région D (industriel). Chaque portail a sa propre marque, son propre site web, ses propres clients entreprises.

La situation avant migration

Le cabinet utilisait jusqu'en 2025 quatre instances séparées d'un ATS du marché. Chaque consultant régional pilotait son propre périmètre. La direction générale n'avait pas de vision consolidée — uniquement quatre Excel agrégés à la main en fin de trimestre. Coût total annuel : ~48 000 € de licences + ~12 jours-DSI/an de maintenance. Aucun candidat ne pouvait être proposé d'un territoire à l'autre, même quand le profil correspondait à un besoin urgent ailleurs.

La cible avec MyCVthèque multi-plateforme

Quatre plateformes cloisonnées (Région A, B, C, D) au sein d'un même tenant. Chaque plateforme conserve son branding, son URL publique, ses formulaires, son SSO. Quatre admins locaux (un par région) avec plateforme_scope = ['region-X'] : ils retrouvent exactement leur interface habituelle, leurs candidats, leurs offres. Aucun changement perceptible pour eux côté quotidien.

Un admin central (la direction) avec plateforme_scope = ['*'] : il bascule en un clic vers la « Vue réseau » qui agrège les KPI des quatre territoires. Il voit en temps réel : 1 247 candidats actifs au total (412 A, 318 B, 287 C, 230 D), un délai moyen de recrutement de 17 jours (vs 22 sur Région D, à creuser), une source dominante différente par région.

Le bénéfice opérationnel : la mobilité inter-régions

Premier mois post-migration, la direction identifie un candidat hautement qualifié sur Région A qui correspond à un besoin urgent et non pourvu sur Région D. Avec accord du candidat (consentement RGPD explicite, journalisé), son dossier est partagé sur la plateforme D. Recrutement bouclé en 8 jours. Sur quatre ans d'ATS séparés, ce scénario n'aurait jamais existé : ni la direction ni le consultant D n'auraient eu connaissance de ce candidat.

Le bénéfice financier mesuré sur 12 mois

• Licences : 48 000 € → 14 880 € → économie 33 120 €
• Maintenance DSI : 12 j → 3 j → économie 5 400 €
• Reporting trimestriel (auparavant 2 jours-RH par trimestre, désormais natif) → économie 4 800 €
• Total économie année 1 : ~43 000 €

À cela s'ajoutent les gains qualitatifs : direction qui pilote enfin avec des chiffres consolidés en temps réel, candidats traités sans double saisie, marques régionales préservées, expérience utilisateur consultants inchangée.

FAQ : les 10 questions que les réseaux nous posent toujours

Mes 4 sites peuvent-ils avoir des branding différents au sein du même ATS ?

Oui. Chaque plateforme dispose de son logo, ses couleurs, ses URLs publiques et ses formulaires de candidature. Le candidat ne voit qu'une marque, jamais le tronc commun. Le branding par plateforme est entièrement paramétrable : logo, palette, mentions légales, signatures email et templates SMS.

Un candidat peut-il être visible sur plusieurs plateformes simultanément ?

Oui mais sur décision explicite. Par défaut un candidat reste cloisonné à sa plateforme d'origine. Un administrateur réseau peut activer la visibilité cross-plateforme pour un candidat consentant. Cela respecte le RGPD : aucune fuite involontaire entre marques.

Peut-on configurer un SSO différent par plateforme ?

Oui. Chaque plateforme peut être branchée à son propre fournisseur d'identité (Azure AD, Google Workspace, Okta). Les utilisateurs scopés à une plateforme se connectent via leur SSO local. Les administrateurs réseau ont un SSO central distinct.

Les statistiques sont-elles consolidées ou par plateforme ?

Les deux. Un admin local voit uniquement les KPI de sa plateforme. Un admin réseau bascule entre vue consolidée (tous sites) et vue détaillée par plateforme. Tableau de bord : volumes candidats, taux de placement, sources, délais de recrutement, NPS — agrégés ou filtrés.

Quel est le tarif pour 10 plateformes au sein du même abonnement ?

Le tarif ne dépend pas du nombre de plateformes mais du volume total de candidats et d'utilisateurs. Pour 10 plateformes cloisonnées avec mutualisation des abonnements, comptez en moyenne 24 000 à 32 000 €/an, contre 60 000 à 80 000 €/an avec 10 ATS séparés. Économie 50 à 60 %.

Comment migrer depuis 5 ATS séparés vers une plateforme unifiée ?

Migration accompagnée en 4 phases : audit (15 jours), export structuré depuis chaque ATS source, import cloisonné par plateforme cible (mapping conservé), recette parallèle 30 jours. Reprise complète des candidats, candidatures, documents et historique d'actions. Pas de perte d'antériorité RGPD.

Le cloisonnement entre plateformes est-il conforme RGPD inter-établissements ?

Oui. Chaque plateforme correspond à un périmètre de traitement distinct avec sa propre base légale, sa durée de conservation et son responsable. Le cloisonnement applicatif (champ plateformes[]) est doublé d'un cloisonnement strict : un user scopé plateforme A n'accède jamais à un candidat de plateforme B, ni en lecture ni en export.

Plusieurs DPO peuvent-ils intervenir sur des plateformes distinctes ?

Oui. Chaque plateforme peut désigner son propre DPO référent avec ses propres registres de traitement, exports RGPD et procédures de purge. Les DPO de plateformes différentes n'ont aucune visibilité l'un sur l'autre. Un DPO réseau optionnel peut superviser la cohérence globale.

Peut-on personnaliser les champs candidat différemment par plateforme ?

Oui. Chaque plateforme dispose de ses propres champs personnalisés, ses pipelines de candidature, ses statuts, ses tags et ses formulaires publics. Un réseau peut avoir une plateforme avec champs spécifiques apprentissage, une autre avec champs emploi, sans se contaminer.

Quelle différence entre le mode vue réseau et le mode vue locale ?

Vue locale : un admin de plateforme voit uniquement les candidats, offres et utilisateurs de sa marque. Vue réseau : un admin central bascule via le sélecteur en haut à droite pour consulter toute plateforme ou une vue agrégée. Les actions de masse, exports et campagnes peuvent se faire en vue réseau.