Parsing de CV : pourquoi ça échoue et comment le mesurer

Tous les éditeurs annoncent un parsing de CV performant. Le taux réel sur vos documents à vous est toujours inférieur au taux annoncé, parfois de beaucoup, et il se mesure en une heure. Voici le protocole et ce qui explique les écarts.

Ce qu'un moteur d'extraction tente de faire

Un parseur transforme un document non structuré en champs. L'ordre de difficulté croissante :

L'adresse mail et le téléphone s'extraient par expression régulière et ne prouvent rien. La vraie question porte sur les blocs d'expérience : leur découpage, l'association correcte d'un employeur, d'un intitulé et d'une période.

Pourquoi ça échoue

Les colonnes. Un CV sur deux colonnes est lu par la plupart des extracteurs de texte dans l'ordre du flux du document, pas dans l'ordre visuel. Le résultat entremêle les blocs. C'est la première cause d'échec, et elle touche une proportion importante des CV modernes, qui sont presque tous mis en page sur deux colonnes.

Les PDF scannés. Une image de texte exige une reconnaissance optique, souvent absente ou de qualité inégale. Un CV scanné de travers ou photographié au téléphone produit fréquemment un résultat inexploitable.

Les tableaux invisibles. Beaucoup de CV sont mis en page avec des tableaux sans bordure. L'extraction linéarise les cellules et les périodes se retrouvent séparées de leur expérience.

Les formats de dates. « 2019-2021 », « janv. 2019 – déc. 2021 », « depuis 2019 », « 3 ans ». La dernière forme n'est pas une date et ne se rattache à rien.

Les icônes. Une enveloppe en pictogramme devant une adresse, un drapeau devant une langue : le lecteur humain comprend, l'extracteur ne voit rien.

Les intitulés non standards. « Growth hacker », « Ingénieur H/F polyvalent », « Chargé de mission RSE ». Un moteur qui s'appuie sur un référentiel fermé classera mal tout ce qui n'y figure pas.

Le protocole de mesure en vingt CV

Une heure de travail, et le résultat est le critère le plus discriminant d'une sélection d'outil.

Constituer l'échantillon. Vingt CV réellement reçus, pas choisis pour leur qualité. Imposez-vous une composition représentative : quelques CV sur deux colonnes, au moins un PDF scanné ou photographié, au moins un document bureautique, quelques CV très denses et quelques CV d'une page, au moins un nom à particule ou composé, au moins un parcours avec des périodes d'interruption.

Définir la grille. Sept champs par CV : nom, prénom, mail, téléphone, dernier intitulé de poste, dernier employeur, période du dernier poste. Cent quarante points de mesure au total.

Compter. Chaque champ est correct, incorrect ou absent. Un champ incorrect est plus grave qu'un champ absent : l'absence se voit et se corrige, l'erreur se propage silencieusement dans la base.

Le seuil utile. En dessous de 85 % de champs corrects, vos recruteurs vérifieront systématiquement chaque fiche, ce qui annule le gain de temps et ajoute une étape. Entre 85 et 95 %, le parsing fait gagner du temps à condition qu'une relecture rapide reste prévue. Au-dessus, il devient réellement transparent.

Faites passer le même échantillon à tous les outils finalistes. Les écarts sont généralement nets et ils ne suivent pas le classement des prix.

Réduire le problème plutôt que le résoudre

Trois leviers valent souvent mieux qu'un meilleur moteur.

Demander les champs critiques au formulaire. Nom, mail, téléphone et disponibilité saisis par le candidat sont fiables à 100 %. Chaque champ demandé au formulaire est un champ que le parseur n'a pas besoin de deviner. Le coût est un formulaire plus long, donc un taux d'abandon plus élevé : l'arbitrage se fait champ par champ, pas en bloc.

Importer depuis un profil structuré. Quand la candidature vient d'une plateforme qui expose des données déjà structurées, le parsing devient inutile pour ces profils.

Traiter le parsing comme une proposition, pas comme une vérité. Une interface qui affiche les champs extraits en attente de validation, à côté du document d'origine, donne un meilleur résultat qu'un parsing silencieux légèrement plus performant. Le travail de correction devient visible et rapide au lieu d'être diffus.

Le cas des modèles de langage

Un modèle de langage extrait mieux qu'un moteur classique sur les CV mal structurés, parce qu'il travaille sur le sens et non sur la position. Trois contreparties.

Il invente. Un moteur classique laisse un champ vide quand il ne sait pas ; un modèle de langage produit une valeur plausible. Sur un champ de date, une valeur plausible et fausse est pire qu'un vide.

Le coût et la latence. Passer chaque CV dans un modèle coûte, en argent et en délai. Sur un volume élevé, ce n'est pas neutre.

Les données sortent. Un CV envoyé à un service tiers est un transfert de données personnelles, avec tout ce que cela implique en matière de sous-traitance et de localisation.

L'architecture qui fonctionne combine les deux : extraction classique d'abord, modèle de langage en second passage uniquement sur les champs restés vides, avec les valeurs produites marquées comme incertaines. Le sujet des garde-fous est traité dans la note sur le scoring par modèle de langage.

Questions fréquentes

Quel taux de parsing est acceptable ?

85 % de champs correctement extraits sur un échantillon de vos propres CV est le plancher utile. En dessous, la vérification manuelle systématique s'installe et l'outil n'apporte plus rien. Mesurez les champs qui comptent — identité, dernier poste, dates — pas la moyenne sur tous les champs, qui est tirée vers le haut par le mail et le téléphone.

Le parsing fonctionne-t-il sur les CV en plusieurs langues ?

Sur les langues courantes, oui, à condition que le moteur détecte la langue. Le point de rupture est le CV mixte — texte en français, intitulés en anglais — assez fréquent sur les profils techniques, et qui met en échec les moteurs à référentiel monolingue.

Faut-il conserver le CV d'origine après extraction ?

Oui, systématiquement. C'est le document de référence en cas de doute sur un champ, et c'est ce que le candidat a réellement envoyé. La fiche extraite est une interprétation ; le document est la source. Cela vaut aussi pour répondre correctement à une demande d'accès.

Peut-on améliorer le parsing d'un ATS du marché ?

Pas le moteur lui-même, qui est fermé. Ce qu'on peut faire : demander davantage de champs au formulaire de candidature, ou intercepter les candidatures avant l'entrée dans l'ATS pour les enrichir. La seconde option suppose une API en écriture, ce qui n'est pas toujours le cas — voir l'anatomie d'un ATS.