Migration ATS : 5 erreurs à éviter
Vous avez comparé les solutions, enchaîné les démos, négocié les tarifs et enfin choisi votre nouvel ATS. Légitimement, vous pensez que le plus gros du travail est derrière vous.
En réalité, l'aventure ne fait que commencer : il vous faut maintenant déménager toutes vos données !
Et soyons honnête : si votre outil actuel cumule des années de candidatures, d'historiques clients et de documents, la transition risque d’être bien plus complexe qu'un simple transfert de fichiers.
Doublons, perte d'informations, données impossibles à retrouver une fois importées... Les erreurs sont fréquentes et coûtent cher en temps et en sérénité.
Pour identifier les principaux pièges, on a donc passé en revue les coulisses d’une migration avec Sarah, qui accompagne les clients de T4S lors de leur onboarding et voit passer ces problématiques au quotidien.
Voici donc les 5 erreurs qui reviennent le plus souvent, et surtout, comment les éviter.
Erreur #1 : trop attendre avant de sauter le pas
Un ATS trop lent, une ergonomie datée, des fonctionnalités manquantes… vous le savez : votre outil actuel vous freine. Mais entre le constater et agir, il y a souvent un monde.
Vous repoussez le projet à "après le pic d’activité", puis à "l'année prochaine", puis vous n'en parlez plus jusqu'à la prochaine crise de frustration collective.
C’est un grand classique : d’après une étude SHRM citée dans un guide 2026, 41 % des équipes RH et recrutement mettent 12 mois ou plus à migrer d'ATS après avoir pourtant acté que le changement était nécessaire.
Un an, minimum, pendant lequel l'équipe continue de travailler avec un outil qu'elle sait déjà obsolète. Un an de productivité perdue, de recruteurs qui bricolent des contournements, de données qui continuent de s'accumuler dans le mauvais système, et qu'il faudra migrer un jour ou l'autre de toute façon.
L’erreur, ici, c’est donc de considérer l’attentisme comme l’option la moins coûteuse. En réalité, son coût est bien réel, même s'il ne figure sur aucune facture.
Erreur #2 : sous-estimer le temps et les ressources nécessaires
“La migration, c'est le problème de l'éditeur, non ?”
C'est souvent comme ça qu'on l'aborde : un projet IT qu'on confie au nouveau prestataire, en espérant qu'il gère l'essentiel pendant que l'équipe continue de tourner normalement à côté.
Sauf que dans les faits, ce qu’on observe sur le terrain, c’est que ça ne fonctionne jamais vraiment comme ça.
« Un éditeur peut migrer des données, paramétrer des champs, importer des historiques. Ce qu'il ne peut pas faire à votre place, c'est arbitrer sur les doublons ambigus, décider quelles anciennes missions conserver ou déterminer si une fiche client correspond encore à la réalité du terrain. » — Sarah, Implementation Project Manager, T4S
Une migration se budgète donc à deux niveaux : le coût de l'outil et le temps humain qu'elle va absorber en interne. Et le second peut être beaucoup plus élevé que prévu.
Erreur #3 : vouloir tout migrer sans faire le tri
Changer d’ATS, c’est aussi l’occasion de découvrir tout ce qui s’est accumulé dans votre base au fil des années : candidats en triple, fiches clients abandonnées, anciennes missions, champs remplis au petit bonheur la chance, CV datant de 2017…
Face à quelques dizaines de milliers de fiches, la tentation est grande : tout migrer maintenant et se dire qu’on fera le ménage plus tard.
C’est précisément le piège. Une migration ne va pas miraculeusement améliorer la qualité de votre base. Si vous importez des données obsolètes, incomplètes ou dupliquées, vous démarrez simplement votre nouvel ATS avec le bazar de l’ancien.
Et non, l’idée n’est évidemment pas de demander à vos recruteurs de vérifier 40 000 fiches une par une. Une partie du nettoyage peut être automatisée ou prise en charge avec votre nouvel éditeur : détection des doublons, normalisation des champs, règles pour exclure certaines données de l’import…
À vous, en revanche, de fixer les règles : qu’est-ce qu’on conserve, qu’est-ce qu’on archive, qu’est-ce qu’on ne migre pas ?
Le nettoyage fait en tout cas partie de la migration, et non de l’après-migration.
Erreur #4 : croire que “données migrées” veut dire “données récupérées”
C’est probablement l’un des pièges les plus trompeurs d’une migration.
Votre nouvel éditeur vous annonce que vos CV, notes, historiques candidats, clients et missions seront repris. Parfait. Mais sous quelle forme ? Et où allez-vous les retrouver ?
Une note peut avoir été transférée, mais atterrir dans un champ où personne ne pensera à la chercher. Un historique peut être présent, mais dans un format qui ne permet plus de l’exploiter comme avant.
Techniquement, la donnée n’est pas perdue. Pour le recruteur qui ne peut plus la retrouver ou l’utiliser, la différence est assez théorique.
Pour éviter ce genre de mauvaise surprise, il faut travailler le mapping des champs en amont et prévoir une migration test sur un échantillon représentatif de la base.
L’objectif : vérifier non seulement que les données sont là, mais qu’elles sont au bon endroit, dans le bon format et réellement exploitables.
« On voit parfois des migrations annoncées comme “complètes” parce que 100 % des données ont bien été transférées. Mais si vos commentaires deviennent une pièce jointe ou que vos historiques arrivent dans un bloc de texte impossible à filtrer, vous avez techniquement récupéré l’information… mais vous ne pourrez jamais l’exploiter. C’est pour ça qu’on a développé chez T4S un module d’import qui ne regarde pas seulement si la donnée est passée, mais aussi où et comment elle est restituée. » — Sarah, Implementation Project Manager, T4S
Erreur #5 : négliger la formation des équipes
Vous pouvez avoir parfaitement migré vos données et paramétré vos workflows : si personne ne sait vraiment utiliser le nouvel ATS, la migration reste à moitié ratée.
Et une démo d’une heure le jour du lancement ne suffira pas.
C’est même le sujet sur lequel il vaut mieux en faire trop : former, former et encore former.
Vos recruteurs ont parfois passé des années sur l’ancien outil. Ils ont leurs habitudes, leurs raccourcis, leurs façons de renseigner les fiches… et vont naturellement chercher à reproduire exactement la même chose dans le nouveau.
« La formation doit commencer avant la bascule, idéalement avec quelques utilisateurs pilotes chargés de tester les vrais cas d’usage de l’équipe. » — Sarah, Implementation Project Manager, T4S
Le risque, si la formation n’est pas à la hauteur ? Des fonctionnalités sous-utilisées, des données renseignées n’importe comment et, dans le pire des cas, le retour des fameux fichiers Excel “juste pour mon suivi perso”.
Avant de signer : ne vous laissez pas aveugler par la démo
Évidemment, une migration réussie dépend aussi d’une chose : avoir choisi le bon outil au départ.
Et sur ce point, attention à l’effet “waouh” de la démo.
Une nouvelle fonctionnalité IA peut être très séduisante. Mais si vous gagnez une feature spectaculaire tout en perdant trois petites fonctionnalités que vos recruteurs utilisent 20 fois par jour, le calcul risque d’être moins intéressant que prévu.
Avant les démos, séparez donc vos must have de vos nice to have, sans oublier les fonctionnalités les moins sexy, mais essentielles au quotidien.
Ne vous contentez pas de regarder un commercial dérouler le scénario parfait. Son rôle est de vous montrer l’outil sous son meilleur jour. Et c’est normal.
Mais la personne qui vous accompagnera une fois le contrat signé n’a pas tout à fait le même rôle.
Demandez donc à rencontrer votre futur CSM ou la personne qui gérera votre onboarding. Là où le commercial vous présente ce que l’ATS peut faire, elle pourra vous expliquer beaucoup plus concrètement comment il répondra à vos besoins, comment se passera la migration et où se situent les éventuels points de friction.
Et surtout, demandez un compte de test. Reproduisez quelques actions du quotidien : retrouver un ancien candidat, créer une mission, ajouter une note, envoyer un profil à un client, faire une recherche…
Le meilleur moyen de dépasser l’effet “poudre aux yeux” de la démo, c’est finalement de confronter trois choses : ce que le commercial vous promet, ce que le CSM vous explique et ce que vous arrivez réellement à faire dans l’outil.
Enfin, posez les questions qui fâchent avant qu’elles ne deviennent des problèmes :
→ Quelles données seront réellement reprises, et sous quelle forme ?
→ Comment les champs de l’ancien ATS seront-ils mappés vers le nouveau ?
→ Une migration test est-elle prévue ?
→ Quels connecteurs devront être recréés ?
→ Comment allez-vous vérifier que les informations restent exploitables après l’import ?
→ Quelle formation est prévue avant et après le lancement ?
→ Qui intervient si quelque chose se passe mal, et sous quel délai ?
Retenez en tout cas qu’un bon éditeur ne doit pas seulement être capable de vous montrer à quoi ressemblera votre nouvel ATS.
Il doit pouvoir vous montrer comment vos équipes vont réellement travailler avec. Et surtout, vous expliquer précisément comment vous allez passer de l’ancien au nouveau.
Sur ce, bonne migration !