Checklist de migration ATS : le kit de contrôle

Une migration ATS fait partie de ces rares projets où une semaine calme est une victoire. Personne ne félicite un changement qui s’est bien passé. On ne remarque que celui qui a perdu la shortlist d’un client ou effacé deux ans de notes candidats.

Ce risque est réel, mais l’équipe peut maîtriser plusieurs causes courantes. Les données peuvent être mal mappées. La bascule peut ne pas avoir de responsable. Les volumes peuvent aussi ne pas être vérifiés dans le nouvel outil.

Ce guide corrige cela avec un kit de contrôle, pas un discours de motivation. Il vous donne les livrables réutilisables dont un cabinet a besoin pour migrer vers n’importe quel ATS cible : une cartographie des entités et des champs, des règles de tri, un échantillon pilote, une matrice de responsabilités, des tests de recette et des conditions de retour arrière claires. Déroulez-le dans l’ordre, et la semaine calme viendra d’elle-même.

Partez de votre date de renouvellement, pas de la mise en ligne

Il est tentant de caler le projet à rebours d’une date de lancement choisie parce qu’elle semble propre. C’est le mauvais point d’ancrage. Ancrez-vous plutôt sur votre contrat actuel.

Repérez votre date de renouvellement ou de préavis, puis comptez à rebours. Vous voulez un nouveau système en ligne et validé avec de la marge, pas une course dans la dernière semaine. Calculez cette marge selon le volume de fiches, le nombre d’intégrations, les risques et vos critères de recette, sans imposer une durée fixe.

Le calendrier protège aussi votre marge de négociation. Si vous exportez et basculez plusieurs semaines à l’avance, vous pouvez partir sereinement en cas de problème. Si vous attendez le dernier jour, vous négociez dos au mur. Posez tôt deux questions à votre éditeur actuel : facture-t-il un export de vos données, et dans quel format les livre-t-il ? Les réponses dessinent tout votre planning.

Évitez de lancer en pleine semaine chargée. Une bascule qui tombe sur des entretiens finaux ou une deadline d’offre transforme un projet gérable en crise. Choisissez une période plus calme, quitte à décaler la date.

Dressez l’inventaire des entités et des champs avant tout export

Avant qu’un seul fichier ne quitte l’ancien système, listez ce que vous détenez vraiment. Les migrations dérapent quand on exporte d’abord et qu’on réfléchit ensuite. L’inventaire est votre carte. Il évite les mauvaises surprises à mi-parcours.

Procédez par entité. Dans un cabinet de recrutement, les principales sont les candidats, les missions ou postes, les entreprises ou clients, les contacts, les deals ou placements, et les notes, tâches et pièces jointes rattachées à chacun. Pour chaque entité, notez le nombre de fiches et les champs utilisés. Ajoutez tout ce que votre équipe a créé sur mesure au fil des ans.

Un petit tableau d’inventaire garde tout cela honnête :

Entité	Fiches (env.)	Champs personnalisés	Pièces jointes	Migrer ?
Candidats	volume ancien ATS	source, disponibilité, salaire	CV, notes	besoin documenté
Missions / postes	volume	client, honoraires, étapes	fiches de poste	ouverts + besoin documenté
Entreprises / clients	volume	conditions, secteur	contrats	besoin documenté
Deals / placements	volume	honoraires, date de début	lettres d’offre	besoin de reporting documenté
Notes, tâches, historique	volume	liés aux fiches ci-dessus	fichiers	conserver pour les fiches gardées

Cet inventaire remplit deux fonctions. Il vous donne la vraie ampleur du chantier, et il devient la liste de contrôle que vous validerez plus tard. Sauvegardez-le. Vous le comparerez de l’autre côté.

Garder, archiver ou supprimer : documentez la règle de chaque fiche

Toutes les données ne méritent pas une place dans le nouveau système. Tout transporter coûte cher. Pour certaines fiches, c’est aussi un risque de conformité. Décidez les règles maintenant, par écrit. L’export sera alors une coupe nette, pas un arbitrage sous pression.

Un examen à trois voies peut vous aider. Gardez une fiche seulement si elle reste nécessaire à une finalité documentée et repose sur une base légale. Le consentement est une base possible, mais pas la seule. N’archivez la fiche que tant que cette finalité, cette base et une durée de conservation définie restent valables. Si le consentement est retiré ou expire et qu’aucune autre base ne s’applique, supprimez la fiche de façon sécurisée au lieu de l’archiver.

Le consentement et la durée de conservation méritent une vraie attention ici. Les articles 5, 6 et 17 du RGPD couvrent la limitation de la conservation, les bases légales du traitement et le droit à l’effacement. Une migration est un bon moment pour revoir ces exigences, puisque vous touchez de toute façon chaque fiche.

Les durées varient selon le pays et votre base légale. Vérifiez donc vos propres obligations plutôt que de copier un chiffre générique. Et rappelez-vous qu’une checklist ne vous rend pas conforme à elle seule. Elle rend simplement le chemin conforme plus facile à suivre.

Si votre base est en désordre, nettoyez avant de déplacer. Transporter des doublons et des fiches mortes dans un nouvel outil ne fait que déplacer le problème. Notre guide sur comment nettoyer votre CRM de recrutement déroule l’audit et la fusion à mener d’abord.

Mappez chaque champ de l’ancien ATS vers le nouveau

Le mapping des champs est au cœur du travail. Les champs standards sont souvent simples à déplacer. Le nom, l’e-mail, le téléphone et l’entreprise actuelle ont souvent une place évidente. L’effort porte sur les champs qui ne s’alignent pas.

Exportez la liste complète des champs de l’ancien ATS. Puis décidez où chacun atterrit dans le nouveau, champ par champ. Trois cas reviennent sans cesse. Un champ a une correspondance directe, donc vous le mappez. Un champ n’a pas d’équivalent, donc vous créez un champ personnalisé ou vous le basculez dans les notes. Un champ est un reliquat que vous avez convenu d’abandonner, donc vous le laissez derrière, volontairement.

Soignez particulièrement les étapes de pipeline, les tags et les champs personnalisés, car ils portent la logique propre de votre cabinet. Si votre ancien système comptait dix étapes et que le nouveau en propose cinq, décidez la correspondance avant de charger, pas après.

Un ATS moderne vous laisse généralement définir des champs personnalisés et des étapes de pipeline qui reflètent le fonctionnement réel de vos desks, ce qui facilite le mapping.

Consignez le mapping dans un tableau lisible par toute l’équipe :

Champ ancien ATS	Champ nouvel ATS	Type	Remarques
Statut candidat	Étape de pipeline	liste	reconvertir 10 étapes vers le nouveau jeu
Source	Champ perso : source	liste	conserver les valeurs telles quelles
Propriétaire	Propriétaire	membre équipe	rapprocher par e-mail
Salaire / taux	Champ perso : salaire	devise	confirmer la devise par fiche
Notes libres	Notes	texte	préserver les horodatages si possible

Écrivez-le avant de charger quoi que ce soit. Un mapping gardé dans une seule tête est le moyen le plus rapide de perdre des données en route.

Nettoyez doublons et pièces jointes avant qu’ils ne se multiplient

Les doublons sont mauvais dans un système, pires en travers de deux. Si votre ancienne base contient trois versions du même candidat, la migration en créera fidèlement trois dans la nouvelle. Votre départ tout neuf est déjà encombré.

Fusionnez avant d’exporter. Cherchez par e-mail, téléphone et nom pour faire remonter les paires probables, puis fusionnez au lieu de supprimer : vous gardez la fiche la plus riche et récupérez les notes des deux. Une plateforme qui déduplique les candidats à l’entrée gardera aussi propre la base nettoyée, au lieu de laisser le désordre revenir.

Les pièces jointes exigent leur propre contrôle. CV, lettres d’offre et conditions signées sont faciles à oublier, car ils vivent à côté de la fiche plutôt que dedans. Confirmez que votre export inclut les fichiers, pas seulement leurs noms, et que le nouveau système les accepte au volume que vous détenez. Testez sur une poignée avant de faire confiance au chargement complet.

Préservez vos projets, notes et historique LinkedIn Recruiter

Une partie importante du contexte de recrutement peut vivre hors de l’ancien ATS. LinkedIn Recruiter peut contenir des projets, des candidats enregistrés, des étapes de pipeline et des notes écrites contre chaque personne. Une migration qui ignore cela peut laisser un contexte utile derrière.

Planifiez-le délibérément. Décidez quels projets Recruiter comptent, et vérifiez comment la nouvelle plateforme les transfère. Un détail compte plus que tout. L’import doit tourner sous votre propre compte Recruiter autorisé, et il doit respecter les règles et limites de LinkedIn. Aucun outil ne devrait promettre de contourner les autorisations ou les quotas d’un fournisseur. Méfiez-vous de ceux qui le prétendent.

Leonar gère cela avec un réimport planifié que vous déclenchez vous-même. Il importe votre historique de projets LinkedIn Recruiter dans des projets équivalents, structure et notes côté Recruiter comprises. La planification est quotidienne et respecte les limites du fournisseur LinkedIn.

L’import suit une planification quotidienne conçue pour respecter les limites du fournisseur LinkedIn. Un historique volumineux peut donc arriver sur plusieurs jours plutôt qu’en une salve. Résultat : le contexte bâti par vos consultants reste avec eux après le changement.

Lancez d’abord une migration pilote sur un échantillon

Ne faites jamais du chargement complet votre première tentative. Lancez un pilote sur un échantillon représentatif, vérifiez-le face à vos critères de recette, puis seulement passez à l’échelle. Vous pourrez ainsi repérer des problèmes de mapping ou de pièces jointes avant le chargement complet.

Choisissez un échantillon qui met le mapping à l’épreuve. Dimensionnez-le selon le volume de fiches, le nombre d’intégrations, les risques et vos critères de recette. Incluez des champs personnalisés, des pièces jointes, différentes étapes de pipeline et au moins un cas limite connu. Chargez ces fiches dans le nouveau système, idéalement dans un espace de préproduction si l’éditeur en propose un.

Inspectez ensuite l’échantillon face à votre mapping. Chaque champ a-t-il atterri où vous le vouliez ? Les étapes se sont-elles reconverties correctement ? Les CV sont-ils passés et s’ouvrent-ils ? Les propriétaires et les dates ont-ils survécu ? Consignez chaque anomalie, corrigez le mapping et relancez l’échantillon. Répétez jusqu’à ce qu’un run pilote propre ne produise aucune surprise. Alors seulement, chargez la base complète.

Décidez si vous faites tourner les deux systèmes en parallèle

Un double run garde l’ancien ATS disponible, en lecture seule le plus souvent, pendant que l’équipe travaille dans le nouveau. C’est un filet de sécurité : si quelque chose cloche, vous gardez une source de vérité à vérifier. Ce n’est pas gratuit pour autant, car cela peut signifier de la double saisie pendant un temps.

La décision tient au risque et au volume. Des enjeux élevés plaident pour le double run : grosses bases, nombreuses intégrations, ou un desk chargé qui ne peut pas se permettre une mauvaise surprise. Des enjeux faibles plaident pour une bascule nette : une base petite, bien mappée et pilotée avec confiance peut souvent basculer d’un seul coup.

Si vous roulez en parallèle, gardez la fenêtre courte et datée. Fixez sa durée selon le volume de fiches, le nombre d’intégrations, les risques de migration et vos critères de recette. Convenez de la date de fin à l’avance pour que le double run ne devienne pas discrètement permanent, ce qui viderait la bascule de son sens.

Attribuez une matrice de responsabilités pour que rien ne passe entre les mailles

Les migrations échouent dans les interstices entre les personnes. L’ancien éditeur suppose que le nouveau s’en charge. Le consultant suppose que l’admin a vérifié. Personne ne possède le décompte final. Une matrice de responsabilités ferme ces trous en nommant une seule personne par tâche.

Gardez-la simple et visible. Une tâche, un responsable, un suppléant :

Tâche	Responsable	Suppléant
Export de données de l’ancien ATS	Admin CRM	Resp. opérations
Validation du mapping	Resp. opérations	Dirigeant du cabinet
Décisions garder / supprimer	Team leads	Resp. opérations
Validation du pilote	Admin CRM	Lead consultant
Import de l’historique LinkedIn	Admin CRM	Resp. opérations
Feu vert de bascule	Dirigeant du cabinet	Resp. opérations
Tests de recette après migration	Resp. opérations	Admin CRM

Le but n’est pas la bureaucratie. C’est que, lorsqu’une question surgit en pleine bascule, chacun sache exactement à qui revient la décision. Des responsabilités claires réduisent la confusion évitable le jour J.

Jour de bascule : l’ordre qui garde les desks au travail

La bascule est le moment où vous faites passer le travail quotidien de l’équipe sur le nouveau système. Dans le bon ordre, c’est calme. L’ordre compte plus que la vitesse.

Commencez par un dernier export de l’ancien système, pris au plus près de la bascule pour capter les changements récents. Chargez-le, lancez une réconciliation rapide face à votre inventaire, et confirmez que les volumes principaux concordent. Puis dirigez votre équipe vers le nouvel outil, l’ancien restant en lecture seule si vous avez choisi un double run.

Briefez l’équipe avant, pas pendant. Les consultants doivent savoir où vivent leurs projets, comment les nouvelles étapes correspondent aux anciennes, et à qui s’adresser en cas de doute. Prévoyez une courte présentation adaptée aux changements de workflow, puis vérifiez que l’équipe sait accomplir les tâches clés. Gardez un journal partagé ouvert pour les premières anomalies, afin que rien ne soit corrigé deux fois ni oublié une fois.

Validez la migration avec des tests de recette

Une migration n’est pas finie quand les données sont chargées. Elle est finie quand vous avez prouvé que les données sont justes. Les tests de recette transforment le « ça a l’air bon » en « on a vérifié, ça concorde ».

Menez deux couches de contrôles. D’abord, réconciliez les volumes. Candidats, missions, entreprises et deals du nouveau système doivent concorder avec l’ancien, une fois retiré ce que vous avez sciemment abandonné. Un écart ici signifie des fiches perdues ou mal filtrées. Vous voulez le savoir avant la signature de recette, pas après.

Ensuite, contrôlez un échantillon dans la nouvelle interface. Dimensionnez-le selon le volume de fiches, le nombre d’intégrations, les risques et vos critères de recette. Pour chaque fiche choisie, confirmez que les champs sont corrects et l’étape juste. Vérifiez que les notes sont présentes, le propriétaire renseigné et les pièces jointes ouvrables.

Rédigez vos tests en contrôles binaires, réussite ou échec :

• Le nombre de candidats concorde avec l’inventaire, suppressions volontaires comprises.
• Les volumes de missions et d’entreprises concordent de la même façon.
• Un échantillon de fiches montre champs, étapes, propriétaires et dates corrects.
• Les CV et pièces jointes s’ouvrent et appartiennent à la bonne personne.
• Les projets et notes LinkedIn Recruiter apparaissent là où on les attend.
• Aucune fiche gardée n’a de propriétaire vide ni d’étape cassée.

Si chaque contrôle passe, vous avez mérité votre signature de recette. Si l’un échoue, vous tenez un problème précis et corrigeable plutôt qu’une inquiétude vague.

Fixez les conditions de retour arrière et signez avant de vous engager

Avant d’annuler l’ancien contrat, convenez de ce qui vous ferait revenir en arrière. Les conditions de retour arrière sont la ligne que vous tracez à l’avance, au calme, pour ne pas décider dans le feu d’une mauvaise journée.

Restez concret. Un retour arrière se justifie dans quelques cas clairs. Les volumes ne concordent pas et l’écart porte sur de vraies données. Une entité critique, comme les candidats actifs ou les postes ouverts, n’a pas migré correctement. Ou les pièces jointes manquent à grande échelle.

Les défauts cosmétiques ne sont pas des motifs de retour arrière ; ce sont des corrections de première semaine. La distinction compte, car revenir en arrière pour un détail coûte plus qu’elle ne sauve.

La signature de recette est le miroir du retour arrière. C’est un oui court et explicite d’un responsable nommé, consigné une fois les tests passés. Ce n’est qu’après cette signature que vous démantelez l’ancien système et résiliez l’ancien contrat. Conservez l’export final seulement pendant la durée prévue par votre calendrier de conservation, limitez son accès aux responsables nommés, puis supprimez-le de façon sécurisée à l’échéance.

Comment Leonar s’inscrit dans une migration ATS de cabinet

Leonar est un ATS et CRM réunis dans une plateforme pensée pour les cabinets de recrutement. Les briques utiles à une migration sont celles qui gardent vos données sous votre propre contrôle. Il n’y a ici ni service de migration géré ni promesse de délai fixe, seulement des workflows que vous menez vous-même.

Côté données, vous importez contacts et entreprises par CSV. Vous définissez les champs personnalisés et les étapes de pipeline qui reflètent votre ancienne configuration. Et vous vous appuyez sur une déduplication intégrée, pour qu’un import propre reste propre.

Côté LinkedIn, le réimport Recruiter planifié amène votre historique de projets, sa structure et les notes côté Recruiter, sous votre propre compte autorisé, dans le respect des limites du fournisseur. Cette combinaison couvre les deux classes de données que les cabinets craignent le plus de perdre : leurs fiches CRM et leur contexte LinkedIn.

Si vous cadrez un changement, le bon prochain pas est de vérifier si l’adéquation est réelle pour vos desks. Confrontez les workflows à votre propre mapping, consultez le tarif transparent par utilisateur, et si cela vous convient, lancez un essai gratuit pour y faire passer votre échantillon pilote. C’est un bien meilleur test que n’importe quelle promesse de migration.

Votre checklist de migration ATS, en une ligne

Une migration ATS propre ne tient pas à la chance. Elle tient à un inventaire, un mapping des champs, des règles de conservation documentées, un pilote, une matrice de responsabilités, des tests de recette et des conditions de retour arrière convenues d’avance. Déroulez ces livrables dans l’ordre, et le changement devient la semaine calme qu’il devrait être.

Partez de votre date de renouvellement, protégez votre historique LinkedIn et validez avant de signer. Soumettez l’ancien export au même calendrier documenté et aux mêmes contrôles d’accès que les données personnelles qu’il contient, puis supprimez-le de façon sécurisée à l’échéance.

Questions fréquentes

Peut-on continuer à utiliser son ancien ATS pendant la migration ?

Oui, en général. Garder l'ancien système en lecture seule pendant que l'équipe travaille sur le nouveau s'appelle un double run. Fixez sa durée selon le volume de fiches, le nombre d'intégrations, les risques et vos critères de recette. Le revers, c'est la double saisie : prévoyez une date de fin claire et fermez l'ancien système seulement après la réussite des contrôles convenus.

Faut-il tout migrer, ou seulement les fiches actives ?

Rarement tout. Migrez seulement les fiches encore nécessaires à une finalité documentée, fondées sur une base légale et inscrites dans votre calendrier de conservation. Le consentement est une base légale possible, mais pas la seule. N'archivez une fiche que tant que cette finalité, cette base et une durée définie restent valables. Sinon, supprimez-la de façon sécurisée. Documentez ces règles avant l'export.

Comment mapper les champs de l'ancien ATS vers le nouveau ?

Exportez la liste complète des champs de l'ancien système, puis trouvez à chacun une place dans le nouveau. Les champs standards comme le nom, l'e-mail ou l'étape se mappent facilement. Le travail se concentre sur les champs personnalisés, les tags et les étapes de pipeline, qui coïncident rarement un pour un. Là où le nouvel ATS n'a pas de champ équivalent, créez un champ personnalisé ou basculez la donnée dans les notes. Écrivez le mapping avant de charger quoi que ce soit.

Combien de temps faut-il faire tourner les deux systèmes en parallèle ?

Assez longtemps pour réussir vos critères de recette, assez court pour limiter la double saisie. Fixez la fenêtre selon le volume de fiches, le nombre d'intégrations et les risques de migration. Profitez-en pour lancer vos tests, confirmer les volumes et laisser les consultants travailler de vrais desks dans le nouvel outil. Fixez la date de fin à l'avance pour que le double run ne s'éternise pas et ne vide pas la bascule de son sens.

Que faut-il contrôler après une migration ATS ?

Commencez par les volumes : candidats, missions, entreprises et deals du nouveau système doivent concorder avec l'ancien, une fois retirées les fiches supprimées volontairement. Vérifiez ensuite un échantillon de fiches pour les champs, les étapes, les notes et les pièces jointes. Confirmez que les CV s'ouvrent, que les liens LinkedIn répondent et qu'aucun propriétaire ni aucune étape n'est vide. Ne signez la recette qu'une fois les volumes concordants et l'échantillon validé.

Peut-on conserver l'historique des projets LinkedIn Recruiter en changeant d'ATS ?

Oui, si la nouvelle plateforme l'importe sous votre propre compte autorisé. Leonar réimporte votre historique de projets LinkedIn Recruiter dans des projets équivalents, structure et notes côté Recruiter comprises, selon une planification quotidienne conçue pour respecter les limites du fournisseur LinkedIn. Le contexte bâti par vos consultants reste ainsi avec eux, au lieu d'être abandonné au moment du changement d'ATS.