Ce qu'un logiciel ATS fait vraiment à votre fichier de CV

« Nous n'avons pas pu lire votre fichier » : ce que cette phrase signale vraiment

Vous passez une soirée sur votre CV. Il est net, il tient sur deux pages, les blancs sont bien répartis, et pour une fois vous en êtes un peu fier. Vous l'envoyez, et soit il ne se passe rien pendant trois semaines, soit une ligne revient pour dire que le fichier n'a pas pu être lu. Aucun diagnostic, aucune section signalée, aucune indication sur ce qui a lâché. Ce silence est tout le problème, parce que ce qui s'est passé est parfaitement connaissable et que personne ne vous le dit.

Un logiciel de recrutement ne lit pas votre CV comme vous le voyez. Il en extrait un flux de texte linéaire et tente de le répartir dans des champs de base de données, si bien que tout ce dont le sens tient à la mise en page plutôt qu'à l'ordre du texte peut être déplacé, fusionné avec le champ voisin, ou perdu.

Le message d'erreur est plus étroit qu'on ne le croit. Il couvre une courte liste de causes, toutes dans le fichier lui-même : un PDF scanné ou constitué d'images, dont la couche texte est vide, un document protégé par mot de passe ou verrouillé contre la copie, un fichier dont l'extension ne correspond pas au contenu réel, ou un format que le formulaire n'accepte tout simplement pas. C'est un échec de lecture au niveau des octets. Ce message ne porte aucun jugement sur votre expérience.

Une délimitation avant d'aller plus loin, car deux questions distinctes se confondent en permanence. Cette page traite de la façon dont le fichier lui-même se casse à l'entrée. Savoir si un système automatique vous écarte ensuite sur le fond est un autre débat, et je l'ai traité dans l'article sur le rejet automatique des CV par un ATS. Je ne le refais pas ici.

Et la concession, tout de suite plutôt qu'enterrée à la fin, parce que c'est l'objection la plus solide contre cette page entière. Vous ne devriez pas avoir à concevoir votre CV autour d'un logiciel incapable de lire deux colonnes. C'est une défaillance d'ingénierie côté éditeur, pas une faute du candidat. Celui qui a perdu un entretien à cause d'un bug d'ordre de lecture n'a rien fait de mal, et personne ne devrait avoir à apprendre les entrailles des formats de documents pour postuler. J'écris quand même cette page, pour une seule raison : savoir ne vous coûte rien, et le mail de refus ne vous le dira jamais.

Votre CV est une image. Le logiciel veut une ligne de base de données.

Un PDF stocke des glyphes à des coordonnées, pas une structure. Cette seule phrase explique l'essentiel de ce qui suit, alors voici ce qu'elle veut dire concrètement. Une page PDF est un jeu d'instructions de dessin : place ce caractère, dans cette police, à cette position x et y. Elle ne dit pas « ceci est un titre », « ceci est une cellule de tableau », « ce bloc est la colonne latérale ». Sauf si le fichier porte un arbre de balises d'accessibilité, ce que la plupart des CV exportés d'un outil de design ne font pas, cette information n'existe que dans vos yeux.

L'extracteur doit donc la reconstruire par inférence. Il regroupe les glyphes en mots en observant les espaces, les mots en lignes grâce à leur ligne de base commune, et les lignes en blocs par proximité. Chacune de ces étapes est une supposition, juste la plupart du temps. Chaque défaillance décrite plus bas est l'une de ces suppositions qui déraille sur une mise en page qui la rendait difficile.

Un DOCX est une autre bête. Sous le capot, c'est une archive de XML où un paragraphe est un élément paragraphe, un tableau un élément tableau, et un titre porte un style nommé. La structure est déclarée au lieu d'être devinée. Cela ne veut pas dire qu'il faut toujours envoyer du Word. Beaucoup de logiciels traitent très bien le PDF, un PDF s'affiche à l'identique sur toutes les machines, et pas mal d'employeurs n'acceptent qu'un seul des deux formats. Suivez d'abord la consigne de l'annonce, toujours. Ce qui est vrai est plus étroit : un DOCX offre au logiciel une structure qu'il devrait sinon deviner.

L'autre moitié du travail, c'est la mise en correspondance. Une fois le flux de texte obtenu, le système essaie de remplir des champs. Ce sont ceux-ci qui comptent, et chaque défaillance ci-dessous est l'échec de l'un d'eux.

• Nom
• Coordonnées : e-mail, téléphone, ville
• Employeur, pour chaque poste
• Intitulé du poste, pour chaque poste
• Date de début et date de fin, pour chaque poste
• Compétences
• Formation et diplômes

Vous avez déjà vu le résultat de cette mise en correspondance sans qu'on vous dise que c'était cela. Quand un formulaire de candidature vous fait téléverser le fichier puis retaper les trois mêmes postes dans des cases, les cases arrivées préremplies sont cette mise en correspondance qui montre son travail, et celles arrivées fausses sont son échec sous vos yeux. Savoir si cette étape signifie qu'un humain vérifie quelque chose est une autre question, et j'y ai répondu dans l'article sur le CV téléversé puis le formulaire à remplir quand même.

« La colonne latérale se retrouve lue au milieu de votre parcours »

Cette phrase vient d'une personne qui publie sur r/resumes, qui déclare analyser des CV à titre professionnel et qui a décrit ce qui cassait sur un échantillon de 3 835 fichiers qu'elle dit avoir traités. Je reviendrai sur le poids que ce chiffre peut porter. La phrase elle-même n'a besoin d'aucun échantillon pour tenir, car elle découle directement de la façon dont l'ordre de lecture est reconstruit, et c'est la défaillance la plus coûteuse de toute cette page.

Imaginez la mise en page que livre presque tous les modèles récents : une colonne étroite à gauche avec compétences et langues, une colonne large à droite avec votre parcours. À l'écran, les deux colonnes sont manifestement séparées. Dans le fichier, ce ne sont que des glyphes à des coordonnées, et les glyphes de gauche partagent les mêmes lignes de base horizontales que ceux de droite. Un extracteur qui regroupe ligne par ligne, au lieu de détecter d'abord la frontière entre colonnes, les fait sortir ensemble.

Lisez le second bloc comme le ferait une machine. La ligne censée porter votre intitulé de poste dit maintenant « Python Contrôleur de gestion ». Un système qui cherche un intitulé sur cette ligne récupère un intitulé avec un langage de programmation soudé devant. Vos compétences ne forment plus une liste, elles sont le premier mot de quatre lignes sans rapport. Et si l'extracteur regroupe plutôt par blocs et insère la colonne latérale là où la proximité le suggère, la colonne compétences peut atterrir entre deux postes, de sorte que les dates qui suivent s'accrochent au mauvais poste. Voilà le mécanisme d'un CV qui affiche les bonnes dix années à l'écran et les mauvaises dans la base.

La réserve honnête : beaucoup de logiciels détectent parfaitement les colonnes, et je ne peux pas vous dire à l'avance lequel se trouve au bout d'un envoi donné. Le conseil n'est donc pas « deux colonnes vous détruiront ». Il est plus étroit et plus défendable. Une mise en page sur une seule colonne supprime l'ambiguïté au lieu de parier qu'elle sera bien tranchée. Vous ne perdez rien de ce qu'un recruteur valorise : personne n'a jamais été embauché pour une colonne latérale.

Tableaux aplatis, blocs de compétences et dégâts au niveau des caractères

La deuxième défaillance rapportée dans ce même fil était une rubrique compétences aplatie en un seul bloc, et les tableaux en sont généralement la cause. Un tableau donne du sens au lecteur par la grille : cette cellule va avec celle-là. Dans un flux extrait, les frontières de cellules ont disparu, et il ne reste qu'une suite de mots dans l'ordre où les cellules ont été parcourues.

Chaque appariement devient une supposition, et cela empire ensuite. La reconnaissance de compétences fonctionne en général en cherchant des termes connus dans le texte. Un terme fondu dans une chaîne plus longue, ou coupé là où l'extracteur croit voir un retour à la ligne, peut tout simplement ne pas être trouvé. Vous aviez la compétence sur la page. La recherche ne l'a pas vue, et cela n'est signalé nulle part.

Reste le niveau des caractères, la partie dont presque personne ne parle. Les puces personnalisées issues d'une police d'icônes ressortent souvent comme un caractère non mappé, ou comme rien du tout. Les ligatures sont l'exemple le plus net, et je le sais de première main parce que cela m'a coûté une semaine sur l'extracteur PDF de careerify. Une ligature est un glyphe unique qui dessine deux caractères à la fois, comme beaucoup de polices dessinent fi d'un seul trait. Dans une police Windows très répandue, notre extracteur nous rendait ce glyphe sous forme de caractère nul, et le mot arrivait donc troué en son milieu. À l'écran, le CV était impeccable. Dans le flux extrait, un mot était cassé, et rien dans le fichier ne le signalait.

Presque tout ce qui figure sur cette page est invisible de votre côté. Le fichier vous paraît correct parce que vous regardez le dessin. Le logiciel, lui, regarde les instructions.

Les parties de votre CV que le logiciel ne verra peut-être jamais

L'ordre de lecture et les tableaux brouillent ce qui est là. Cette section porte sur du contenu qui n'atteint jamais le flux de texte, ce qui est pire : un champ brouillé peut encore être retrouvé par un humain qui parcourt le document, un champ absent non.

Les dates méritent une ligne de plus, car ce sont les plus discrètes des six. Votre parcours est une suite d'intervalles, et le logiciel doit déterminer où chacun commence, où il finit et à quel employeur il appartient. Donnez-lui un mois et une année à quatre chiffres, gardez le même format pour chaque poste et le même séparateur partout. Cela paraît pointilleux. C'est la correction la moins coûteuse de toute cette page.

L'image inverse de tout cela, c'est du texte présent dans le fichier mais invisible sur la page, exactement ce sur quoi repose l'astuce du texte blanc. C'est une mauvaise idée pour des raisons qui n'ont rien à voir avec l'extraction, et je les expose dans l'article sur l'instruction invisible cachée dans un CV. Tout ce que je recommande ici change le contenant, jamais les affirmations.

Des systèmes différents, des extracteurs différents, et ce que les chiffres peuvent porter

Workday, Greenhouse, Taleo et Lever sont des produits distincts, dotés d'extracteurs distincts, et il faut ici que je déçoive quiconque venait chercher un tableau de comportements par éditeur. Je ne peux pas vous dire ce que chacun fait en interne. Je ne les ai pas testés, leur comportement change d'une version à l'autre et d'une configuration client à l'autre, et chaque affirmation publique assurée sur l'extracteur d'un éditeur précis que j'ai cherché à vérifier s'est révélée sans méthode derrière. Celui qui vous vend un règlement par éditeur devine. Ce que l'on peut dire sans risque, c'est ce qui en fait la même catégorie de produit : chacun doit transformer un fichier de CV en une fiche enregistrée, donc en extraire du texte et le répartir dans des champs. Leur capacité respective à traiter les cas difficiles décrits plus haut, je ne peux pas vous la dire.

C'est aussi la réponse honnête à « quel format est le plus sûr ». Aucun format, aucun modèle et aucune mise en page ne garantit une extraction propre où que ce soit. Il n'existe que des choix qui laissent moins de choses à deviner. Je préfère vous donner cela qu'une règle que je ne peux pas défendre.

Venons-en au chiffre de 3 835, traité avec le soin qu'il exige. C'est une personne sur Reddit décrivant son propre échantillon déclaré, dans un fil où plusieurs commentateurs doutaient que le chiffre soit réel. Je ne vais pas le blanchir en « des études montrent », et je préfère que vous l'écartiez complètement plutôt que de lui accorder plus de poids qu'il n'en supporte. Notez que rien dans les sections mécaniques ci-dessus n'en dépend. L'ordre de lecture, les tableaux aplatis, les couches texte vides et les titres non reconnus découlent de la construction du PDF et du DOCX, et resteraient tout aussi vrais si ce fil n'avait jamais existé. L'échantillon vous dit que ces défaillances sont fréquentes. Les formats vous disent pourquoi elles se produisent.

Une dernière chose qu'il vaut mieux dire que cacher, car elle explique pourquoi la situation dure. Côté employeur, un tri qui perd quelques bons candidats est souvent considéré comme un coût acceptable pour absorber le volume. Je ne vais pas m'en indigner ici ; je vous le dis parce que cela règle correctement vos attentes. Le correctif ne viendra pas de l'éditeur à temps pour votre prochaine candidature, et c'est pour cela qu'il doit se faire sur votre fichier en attendant.

Le paragraphe produit, une fois, pour que vous puissiez le peser face à tout ce qui précède. careerify propose une vérification gratuite via le lien ci-dessous : sans compte, sans carte, trois vérifications par adresse IP sur 24 heures. Elle analyse réellement le PDF ou le DOCX que vous envoyez, comme n'importe quel autre système devrait le faire, puis compare ce qu'elle en a tiré à l'annonce que vous collez, et vous montre quels termes de l'annonce sont bien ressortis de votre fichier et lesquels non. C'est une inspection, pas une réparation. Si un terme que vous savez présent en première page revient comme manquant, vous venez de trouver l'une des défaillances de cette page. Le reste de ce que fait careerify, adapter un CV maître enregistré à une annonce précise, est borné par les faits que vous avez saisis vous-même et ne peut inventer ni un poste, ni un employeur, ni un chiffre que vous ne lui avez pas donné.