Migration d'un cabinet RH multi-portails vers MyCVthèque V2 : 10 000+ candidats en 1 journée, zéro downtime

Le contexte : un cabinet RH multi-marques, deux silos historiques

Le client de cette étude — qui restera anonyme conformément à notre engagement de confidentialité — est un cabinet RH du sud de la France, PME d'environ 25 collaborateurs, qui exploite depuis plus d'une décennie deux marques commerciales distinctes. La première opère sur le recrutement permanent en CDI / CDD pour ses clients entreprises ; la seconde porte une activité dédiée aux missions de consulting et au placement de consultants indépendants sur des missions de quelques mois à plusieurs années. Les deux marques partagent les mêmes locaux, la même direction et une partie du back-office, mais elles servent des marchés différents avec des cycles de vente et des viviers candidats que rien n'oblige à mélanger.

Jusqu'au printemps 2026, ce cabinet pilotait son activité avec deux instances distinctes du même ATS legacy hébergé chez un éditeur français de taille moyenne. Chaque marque avait son propre URL, son propre logo, son propre branding et — surtout — sa propre base de données. Les équipes commerciales et les chargés de recrutement basculaient d'un environnement à l'autre dans la journée, avec deux comptes différents, deux mots de passe, deux interfaces qui se ressemblaient sans être identiques. Un consultant qui souhaitait vérifier si un candidat permanent récemment placé pouvait être repositionné côté missions devait littéralement quitter une session, ouvrir un autre navigateur, se reconnecter ailleurs, recopier le nom à la main. Personne ne mesurait précisément le temps perdu, mais tout le monde le ressentait.

Ce schéma générait quatre types de douleur. D'abord des doublons silencieux : un même candidat ayant postulé sur les deux portails existait en deux fiches indépendantes, avec deux historiques d'entretien parallèles, sans qu'aucune des deux équipes ne le sache. Ensuite une vue de pilotage éclatée : la direction du cabinet n'obtenait jamais une vision consolidée du chiffre d'affaires recrutement, du nombre total de placements ni du délai moyen de fermeture — chaque trimestre, deux exports Excel étaient agrégés à la main avec leur lot d'erreurs de format. Troisième source de friction : l'impossibilité d'arbitrer des viviers. Un excellent profil ingénieur réseau identifié côté permanent n'était jamais proposé côté missions, alors qu'il y avait des opportunités. Enfin le coût, qui pesait deux fois : deux abonnements ATS, deux contrats de maintenance, deux montées de version à valider, deux DPO check-ups annuels.

En mars 2026, après un audit interne, la direction du cabinet a lancé un appel d'offres pour unifier ses deux marques dans un seul outil, tout en préservant leur autonomie commerciale et leur identité visuelle externe. La V2 de MyCVthèque, qui livrait précisément à cette date sa feature multi-marques cloisonnée intra-tenant, a été retenue après comparaison avec trois autres éditeurs du marché français.

L'enjeu : un seul ATS pour deux marques distinctes — multi-tenant vs multi-marques cloisonné

Le brief du DRH du cabinet tenait en une phrase : « je veux un seul outil pour les deux marques, mais les candidats des deux marques ne doivent jamais se voir entre eux, sauf si je l'autorise explicitement ». Cette exigence — apparemment simple — est en réalité ce qui fait la différence entre un ATS bien conçu et un ATS bricolé. Trois éditeurs candidats proposaient des contournements (un seul environnement avec un champ « marque » sur chaque fiche, à charge pour les équipes de filtrer manuellement) ; MyCVthèque proposait un cloisonnement structurel et auditable, vérifié au niveau du middleware applicatif et de la couche d'accès aux données.

La confusion habituelle : multi-tenant ≠ multi-marques

Le marché SaaS communique massivement sur l'architecture multi-tenant. C'est un terme technique précis qui ne désigne pas ce que beaucoup de DRH croient. 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, isolés logiquement par un champ tenant_id présent dans chaque table. C'est la séparation entre le cabinet Dupont et le cabinet Martin : ils sont deux clients de l'éditeur, deux abonnements, deux factures, et aucune requête ne peut traverser la frontière du tenant_id.

Cette architecture est l'état de l'art SaaS depuis quinze ans. Mais elle ne résout pas le problème d'un cabinet RH qui opère plusieurs marques sous une même entité juridique. Si chaque marque est un tenant distinct, le cabinet paie deux abonnements et perd la consolidation. Si toutes les marques partagent un même tenant sans cloisonnement supplémentaire, les viviers se mélangent et l'autonomie commerciale disparaît.

La réponse : multi-marques cloisonné intra-tenant

La V2 de MyCVthèque livre une couche supplémentaire à l'intérieur d'un même tenant. Le cabinet reste un seul client, un seul abonnement, une seule administration centrale. Mais chaque entité métier — candidat, offre, action, utilisateur — porte un champ plateformes[] qui détermine à quelles marques elle est rattachée. Un consultant commercial scopé à la marque « permanent » ne verra jamais les candidats de la marque « consultants », même via une URL directe ou un export. Le filtre est appliqué au niveau du middleware applicatif (impossible à contourner depuis le frontend) et au niveau de la couche d'accès aux données (impossible à contourner même en cas de bug applicatif).

RGPD par marque, audit par marque

Cette architecture présente un bénéfice juridique direct : chaque marque peut désigner son propre périmètre de traitement RGPD, sa propre durée de conservation, ses propres mentions légales sur les formulaires publics, son propre DPO référent. Les registres de traitement sont séparables. En cas de demande d'effacement RGPD d'un candidat, l'opérateur sait exactement laquelle des deux marques est concernée, et n'efface jamais accidentellement une donnée appartenant à l'autre périmètre. C'est une réponse directe à l'article 32 du RGPD sur la sécurité des traitements et à l'article 25 sur la protection des données dès la conception.

ROI immédiat : un abonnement au lieu de deux

Le bénéfice financier de cette architecture est immédiat : le cabinet passe d'un budget ATS double à un budget ATS unique, sans perdre la séparation commerciale. Le calcul détaillé est repris plus bas, mais l'ordre de grandeur est clair : économie de 50 % sur le poste ATS annuel, soit la valeur d'un demi-ETP junior réaffectable au sourcing actif.

La migration en 24 heures : timeline détaillée

Une fois le contrat signé fin avril 2026, la migration a été planifiée pour une journée ouvrée unique fin mai 2026, après une semaine de préparation. La timeline détaillée ci-dessous est celle réellement exécutée, sans embellissement.

J-7 : audit et écriture du script d'extraction

L'équipe MyCVthèque a obtenu un accès en lecture à une copie de production du legacy. L'audit a consisté à cartographier le schéma de la base source (tables candidats, candidatures, documents, actions, utilisateurs, clients entreprises), identifier les champs custom propres à chaque marque, lister les binaires hébergés sur SFTP (CV, lettres de motivation, pièces jointes diverses) et mesurer les volumes réels. Le script extract_legacy_tenant.py a été écrit en deux jours, paramétrable par marque source, capable de produire un dump JSON normalisé prêt à être importé dans le schéma V2 avec les champs plateformes[] correctement positionnés.

J-1 : dry-run complet sur staging

La veille de la bascule, un dry-run a été exécuté de bout en bout sur un environnement de staging dédié, isolé du domaine de production. Volume migré lors du test : la totalité des candidats, candidatures, documents et actions des deux marques. Durée totale du dry-run : 3 heures 40 minutes, dont 1 heure 20 de pure copie SFTP des binaires. Trois écarts mineurs ont été détectés (un champ de date au format hétérogène sur d'anciens enregistrements, un encodage UTF-8 incohérent sur quelques fiches anciennes, un tag obsolète sans correspondant V2) et corrigés dans le script avant la bascule réelle.

J0 — 8h00 : pg_dump legacy

Démarrage en conditions réelles. L'ancien outil est maintenu accessible en lecture seule côté utilisateurs métier — ils peuvent continuer à consulter les fiches, mais les écritures sont gelées pour la journée. Un pg_dump compressé de la base legacy est lancé : durée 22 minutes pour les deux marques cumulées. Le dump est rapatrié sur le serveur de migration et restauré dans un schéma temporaire.

J0 — 10h00 : 12 000 candidats migrés

Le script extract_legacy_tenant.py est exécuté deux fois (une fois par marque source) et produit deux fichiers JSON normalisés. L'import dans la V2 est lancé : transactions PostgreSQL atomiques, validation des contraintes d'intégrité, attribution automatique des champs plateformes[] en fonction de la marque source. Volume total importé : un peu plus de 10 000 candidats agrégés sur les deux marques, plus de 3 000 candidatures actives ou archivées, environ 25 utilisateurs internes répartis entre les deux marques. Durée d'import : 1 heure 50.

J0 — 12h00 : près de 10 000 documents copiés via SFTP

Pendant que les données structurées finissent leur import, la copie SFTP des binaires démarre en parallèle. Près de 10 000 documents (CV au format PDF, lettres de motivation, attestations diverses) sont rapatriés depuis le serveur legacy vers le stockage objet de la V2, avec recalcul des chemins et mise à jour des références dans la base cible. Une vérification d'intégrité (hash MD5) est exécutée à la volée : tous les binaires sont récupérés sans corruption.

J0 — 14h00 : recette par l'équipe métier

Deux heures sont consacrées à la recette par l'équipe consultants du cabinet. Le DRH et trois opérationnels accèdent à la V2 en pré-production. Ils vérifient une vingtaine de fiches candidats stratégiques choisies à l'avance, contrôlent que les documents s'ouvrent correctement, testent la recherche, valident le branding par marque, vérifient que les filtres par plateforme fonctionnent à la fois en vue locale et en vue consolidée. Trois micro-ajustements de mapping sont demandés et appliqués en moins de 30 minutes (libellé d'un statut, ordre d'affichage de deux champs custom, mise à jour d'un template d'email signature).

J0 — 16h00 : bascule DNS effective

Sur OK explicite du DRH, la bascule DNS est lancée. Les enregistrements DNS des deux URLs publiques sont mis à jour pour pointer vers la V2 MyCVthèque, avec un TTL réduit à 300 secondes pour une propagation rapide. L'ancien outil reste accessible sur des sous-domaines techniques en lecture seule pendant 30 jours, pour permettre un audit comparatif si besoin. À 16h47, la bascule est confirmée propagée sur l'ensemble du territoire français.

J+1 : aucun ticket support

Le lendemain de la bascule, l'équipe MyCVthèque ouvre un canal Slack dédié au support post-migration. Vingt-quatre heures plus tard, aucun ticket n'a été remonté. Aucune fiche manquante, aucun document inaccessible, aucun utilisateur bloqué. Trois questions de prise en main ont été posées sur le sélecteur de marque en haut à droite (« comment je passe de l'une à l'autre ? »), résolues en moins de cinq minutes chacune.

La feature multi-marques cloisonnée — comment ça marche techniquement

Pour comprendre ce qui rend cette migration possible et durable, voici l'architecture sous le capot. Quatre éléments visibles côté utilisateur, plus un modèle de données serveur.

1. Le champ Formateur.plateformes[] côté objets métier

Chaque entité métier — un candidat dans le vocabulaire ATS, un formateur dans le vocabulaire historique de la CVthèque — porte un champ plateformes[]. C'est un tableau JSONB indexé en PostgreSQL avec un index GIN qui rend les filtres ultra-rapides même sur des bases de 100 000+ fiches. Le tableau contient les identifiants des marques auxquelles cette fiche est rattachée. Dans 95 % des cas, une fiche n'appartient qu'à une marque (['permanent'] ou ['consultants']) ; dans 5 % des cas, sur décision explicite, elle peut être visible des deux (['permanent', 'consultants']).

2. Le champ User.plateforme_scope[] côté utilisateurs internes

Chaque utilisateur du cabinet porte un champ plateforme_scope[] qui détermine son périmètre d'accès. Trois cas typiques :

• plateforme_scope: ['permanent'] — chargé de recrutement permanent : ne voit que les candidats de la marque permanent, ne peut exporter que ces candidats, ne peut envoyer de SMS qu'à ces candidats.
• plateforme_scope: ['consultants'] — consultant placement missions : périmètre cloisonné symétrique.
• plateforme_scope: ['*'] — DRH du cabinet ou administrateur réseau : voit les deux marques, peut basculer entre vue locale et vue consolidée via le sélecteur en haut à droite.

3. Le badge marque sur chaque fiche

Côté interface, chaque candidat, chaque offre, chaque action affiche un badge coloré indiquant à quelle marque il appartient. Quand le DRH parcourt sa vue consolidée, il identifie d'un coup d'œil l'origine de chaque dossier sans cliquer. Le badge utilise la couleur primaire de la marque, paramétrable dans les réglages.

4. Le sélecteur de marque en haut à droite

Un sélecteur affiche en permanence la marque active. Un utilisateur cloisonné voit le sélecteur grisé (contexte fixe). Un utilisateur multi-marques a un menu déroulant avec les marques de son périmètre + une option « Vue réseau (toutes) ». Changer de marque reconfigure instantanément l'UI : liste des candidats, statistiques, branding, mentions légales des formulaires publics.

Schéma ASCII : flux de filtrage RGPD

┌──────────────────────────────────────────────────────────┐
│   Utilisateur connecté : Consultant scope=['consultants']│
└──────────────────────────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────┐
│   Middleware applicatif (FastAPI dependency)             │
│   → injecte plateforme_scope dans chaque requête         │
└──────────────────────────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────┐
│   Couche d'accès aux données (SQLAlchemy 2.0 async)      │
│   → WHERE candidats.plateformes && ARRAY['consultants']  │
└──────────────────────────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────┐
│   PostgreSQL — Index GIN sur plateformes[]               │
│   → filtre en < 5 ms même sur 100 000+ fiches            │
└──────────────────────────────────────────────────────────┘
                          │
                          ▼
                  ✅ Résultat : 0 fuite
                  ✅ Audit : journalisé
                  ✅ RGPD article 32 : respecté

Pourquoi le cloisonnement est inviolable

Le filtre par plateformes[] n'est jamais activé manuellement par l'utilisateur. Il est injecté au niveau du middleware applicatif (impossible à bypasser depuis le frontend) et appliqué dans la couche d'accès aux données (impossible à bypasser même en cas de bug applicatif). C'est ce qu'on appelle un cloisonnement en défense en profondeur : deux couches indépendantes qui doivent toutes les deux échouer pour qu'une fuite soit possible. La conformité avec l'article 32 du RGPD sur la sécurité du traitement est donc native, et non pas issue d'une discipline d'utilisation.

Module CRM premium activé en parallèle

L'un des arbitrages stratégiques du cabinet a été d'activer simultanément le module CRM premium de MyCVthèque V2. Pourquoi en même temps ? Parce qu'un cabinet RH n'a pas seulement besoin de gérer ses candidats : il a besoin de piloter son pipeline commercial, ses bons de commande clients et ses activités de relance.

Pipeline commercial intégré aux fiches candidats

Le module CRM ajoute un objet « affaire commerciale » qui peut être lié à un ou plusieurs candidats, à une ou plusieurs offres, et à un client entreprise. Chaque affaire suit un pipeline configurable (prise de brief, qualification, proposition, négociation, signature, livraison, facturation). Le DRH voit en temps réel l'avancement de l'ensemble du portefeuille, le chiffre d'affaires prévisionnel pondéré par étape, le délai moyen de fermeture par consultant.

Bons de commande générés depuis l'ATS

Quand une affaire passe à l'étape « signature », le module CRM génère automatiquement un bon de commande client au format PDF, signé électroniquement via DocuSign ou son équivalent open source. Le BC est attaché à l'affaire, archivé côté entreprise cliente, et déclenche un workflow de facturation côté back-office. Plus de double saisie entre l'ATS et l'outil de facturation : la donnée commerciale circule.

Activités IA-proactives

Le module CRM intègre une couche d'IA dite proactive : le système analyse l'historique des affaires, des relances et des interactions, et propose au consultant en début de journée une liste priorisée d'actions à mener — relancer tel client dont la proposition a 7 jours, repositionner tel candidat sur telle offre où le scoring est bon, planifier un point avec tel autre client en risque de churn. L'IA ne fait jamais d'action automatique : elle propose, le consultant valide.

+30 % de productivité commerciale ressentie

Un mois après l'activation du module CRM, le DRH a remonté une amélioration ressentie de l'ordre de 30 % sur la productivité commerciale de ses consultants. Le chiffre est qualitatif (perception managériale), pas encore quantitatif, mais il est cohérent avec ce qui est observé sur d'autres cabinets ayant déployé un module CRM proactif similaire. Une mesure objective sera publiée dans une mise à jour de cette étude de cas après 12 mois d'usage.

Le ROI sur 12 mois

Voici la vue financière consolidée du projet à 12 mois, sur la base des chiffres pré-migration du cabinet et des premiers mois d'usage post-bascule.

Le poste ATS lui-même est divisé par deux. En intégrant le module CRM (auparavant souscrit chez un éditeur tiers) et le reporting consolidé (auparavant tenu à la main par une responsable RH), l'économie globale dépasse 60 % sur la première année.

Gain temps RH : 4 heures par semaine récupérées

Au-delà du coût direct, le cabinet mesure un gain de temps de l'ordre de 4 heures par semaine sur la fonction RH support, principalement issu de la disparition des doubles saisies entre les deux anciens ATS, des exports manuels pour reporting trimestriel, et de la résolution des doublons silencieux qui revenaient régulièrement dans les revues mensuelles. Sur 47 semaines ouvrées, cela représente environ 188 heures, soit 25 jours-RH récupérables, réaffectés à du sourcing actif et à de la qualification candidat.

Conversion candidats améliorée par la vue Kanban et le statut MYCV

Côté pipeline candidats, deux outils V2 ont eu un impact mesurable sur la conversion. La vue Kanban permet à chaque consultant de visualiser ses candidatures par étape (qualifié, en entretien, présenté client, accepté, refusé) et de glisser-déposer entre colonnes : le temps moyen de mise à jour d'un statut est passé de quelques minutes à quelques secondes. Le statut MYCV (un statut visuel agrégé qui synthétise l'état réel d'un candidat dans son parcours) permet d'identifier en un coup d'œil les candidats qui méritent une action immédiate. Les premiers indicateurs internes du cabinet remontent une amélioration du taux de conversion qualifié → présenté de l'ordre de plusieurs points de pourcentage. Une mesure consolidée sera publiée dans la mise à jour 12 mois de cette étude.

Synthèse financière sur 3 ans

Cumulée sur trois ans, l'économie nette dépasse 70 000 € pour ce cabinet. C'est l'équivalent du coût annuel chargé d'un consultant junior — un ETP supplémentaire potentiellement réaffecté à la croissance commerciale, sans aucune dégradation de l'outillage métier.

FAQ — 10 questions que nous posent les cabinets RH multi-portails

Comment se passe concrètement une migration vers MyCVthèque V2 ?

La migration suit un protocole en cinq étapes : audit du legacy (J-7), écriture d'un script extract_legacy_tenant.py adapté au schéma source, dry-run sur un environnement de staging (J-1), bascule réelle avec pg_dump + import + copie des binaires SFTP (J0), recette par l'équipe métier, puis bascule DNS sur OK explicite. L'ancien outil reste en lecture seule en parallèle pendant 30 jours, ce qui garantit zéro perte de données et un rollback instantané possible.

Combien de temps prend la migration de 10 000 candidats ?

Pour un volume de 10 000 à 12 000 candidats, 3 000 à 4 000 candidatures et près de 10 000 documents (CV et pièces jointes), la migration technique tient en une seule journée ouvrée : 2 heures pour le dump et la transformation des données, 2 heures pour la copie SFTP des binaires, 2 heures de recette équipe, puis bascule DNS. L'avant-projet (audit + script + dry-run) demande environ une semaine en parallèle de l'activité courante.

Quel est le risque RGPD lors d'une migration de base candidats ?

Le risque est maîtrisé si trois conditions sont respectées : base légale identifiée (continuité du contrat de traitement entre ancien et nouvel éditeur), durées de conservation reportées à l'identique, et journalisation de la migration dans le registre des traitements. MyCVthèque génère automatiquement un rapport de migration horodaté listant les volumes, les durées, les transformations et les enregistrements écartés. Ce rapport est fourni au DPO pour archivage.

MyCVthèque V2 est-elle compatible avec Ypareo, Apogée ou un SIRH existant ?

Oui. Les connecteurs Ypareo et Apogée sont natifs côté secteur formation. Côté cabinet RH, les exports CSV structurés et l'API REST permettent l'intégration avec n'importe quel SIRH (Sage Paie, Cegid, ADP, PayFit) et tout outil bureautique (Excel, Google Sheets, Power BI). Une intégration personnalisée via webhooks est livrée en standard pour les volumes supérieurs à 1 000 candidats annuels.

Quelle différence entre un ATS multi-tenant et un ATS multi-marques cloisonné ?

Multi-tenant signifie que plusieurs clients juridiquement distincts partagent la même base de code et la même base de données, isolés par un champ tenant_id. C'est une architecture éditeur. Multi-marques cloisonné est une couche supplémentaire à l'intérieur d'un même tenant : un seul client opère plusieurs sous-marques (portails de candidature distincts) avec des branding, des URLs et des pipelines indépendants, mais un seul abonnement et une administration centrale optionnelle.

Comment est gérée la confusion entre apprentissage et autres marques ?

Chaque marque dispose de ses propres pipelines, statuts et vocabulaire (le terme « candidat » peut devenir « consultant », « alternant » ou « stagiaire » selon la marque). L'utilisateur d'une marque ne voit jamais les libellés des autres. Côté reporting consolidé, un mapping commun ramène tout sur des KPI agrégeables. L'équipe technique MyCVthèque accompagne cette configuration lors du kick-off. La question de l'affichage homogène des identifiants (un sujet de représentation hexadécimale dans certaines vues très spécifiques) est suivie comme un point d'amélioration produit identifié et trackée publiquement dans la roadmap.

Peut-on consolider un reporting sur plusieurs marques au sein du même cabinet ?

Oui. Les utilisateurs au scope étendu (plateforme_scope = ['*']) accèdent à une vue réseau qui agrège les KPI des deux marques en temps réel : volumes, taux de placement, sources de candidatures, délai moyen de recrutement, NPS interne. Chaque KPI reste filtrable par marque, et les exports peuvent être consolidés ou ventilés au format Excel ou PDF.

Les connecteurs LinkedIn Recruiter et Indeed sont-ils inclus ?

Oui. La diffusion d'offres vers LinkedIn, Indeed, France Travail et HelloWork est incluse dans le forfait standard. La récupération de candidatures via LinkedIn Easy Apply et Indeed Apply est également couverte. La connexion à un compte LinkedIn Recruiter dédié pour le sourcing est disponible en option dans l'offre Cabinet Premium.

En combien de temps une équipe est-elle opérationnelle après la bascule ?

L'onboarding standard tient en 2 demi-journées : une session de prise en main pour les utilisateurs métier (consultants, chargés de recrutement) et une session admin pour les responsables d'équipe (configuration des pipelines, des utilisateurs et du branding par marque). Les équipes habituées à un ATS du marché sont autonomes en 48h. Un support chat est disponible pendant le premier mois.

Quel est le tarif pour un cabinet RH opérant deux marques distinctes ?

Le tarif ne dépend pas du nombre de marques mais du volume total de candidats et d'utilisateurs. Pour un cabinet RH multi-marques de 20 à 30 collaborateurs avec un stock total de 10 000 à 15 000 candidats actifs, comptez entre 14 880 et 18 480 €/an tout compris (licence + module multi-marques + onboarding + support). Cela représente une économie de l'ordre de 50 % par rapport à deux abonnements ATS classiques séparés.