Nous avons passé nos 29 modèles au contrôle d'extraction : voici le texte exact que voit le robot

Pourquoi « le texte exact que voit le robot » est le bon test

Un ATS ne regarde pas votre CV ; il extrait la couche texte de votre fichier et analyse cela. Tout ce qu'un recruteur cherchera ou survolera plus tard dans l'ATS dérive de cette extraction, et le circuit est presque inévitable à grande échelle : l'étude de la Harvard Business School Hidden Workers: Untapped Talent rapporte que 99 % des entreprises du Fortune 500 utilisent un ATS. La question honnête à poser à un modèle n'est donc pas « a-t-il l'air propre ? » mais « quand cette mise en page devient un PDF, le texte extrait contient-il tout, dans l'ordre, avec des mots intacts ? »

Ce cadrage vous donne un test avec trois propriétés mesurables :

• La complétude. Chaque mot du CV source doit pouvoir être retrouvé dans la couche texte du PDF. Mesurée en couverture des tokens : la part des tokens attendus retrouvés dans l'extraction.
• L'ordre. Le nom, l'accroche et les titres de rubriques doivent apparaître dans l'extraction dans l'ordre de lecture déclaré du modèle. Une mise en page qui se lit bien à l'œil mais s'extrait brouillée a trahi son utilisateur en silence.
• L'intégrité. Les mots doivent ressortir en mots. Certains choix typographiques (notamment un interlettrage agressif) fragmentent l'extraction au point que « SUMMARY » devient six lettres séparées. Nous avons mesuré cet échec à partir de 0,11 em d'interlettrage, donc chaque modèle du catalogue est plafonné à 0,04 em.

Méthodologie : reproductible depuis notre base de code

Le test est un script de notre dépôt (scripts/check-template-parity.ts), pas un exercice marketing, et il tourne contre le vrai pipeline de rendu de production plutôt que contre une simulation. Pour chacun des 29 modèles du registre :

1. Le même CV d'exemple fixe est rendu à travers le modèle par notre route d'impression de production, servie par le même build Next.js que celui des utilisateurs, et converti en PDF par le même moteur basé sur Chromium qui produit chaque téléchargement client
2. La couche texte est extraite du PDF résultant avec unpdf, une bibliothèque d'extraction construite sur le moteur pdf.js, la même approche d'extraction dont dépendent les analyseurs ATS
3. L'extraction est comparée au texte canonique du CV source (la sérialisation resumeToText), token par token : le texte est normalisé Unicode (NFKC, qui refond aussi les ligatures PDF comme fi en lettres), passé en minuscules et découpé sur les caractères non alphanumériques
4. La couverture est calculée en multiensemble : chaque occurrence de chaque token attendu doit être retrouvée, donc un mot présent trois fois dans la source doit apparaître trois fois dans l'extraction pour compter pleinement
5. L'ordre de lecture est vérifié séparément : le nom, le titre de l'accroche et chaque titre de rubrique porteur de contenu doivent apparaître dans l'extraction dans la séquence de lecture déclarée du modèle
6. Le contrôle ne valide un modèle que si la couverture dépasse 95 pour cent ET que l'ordre est intact. Tout échec fait échouer le run entier, et les PDF rendus sont sauvegardés comme artefacts pour inspection manuelle

Résultats : chaque modèle, chaque chiffre

Dernier run mesuré : 22 août 2026, les 29 modèles, rendu deux pages du CV d'exemple dans tous les cas. L'ordre de lecture a été préservé dans 29 modèles sur 29. Couverture des tokens par modèle :

Ce que le contrôle a attrapé pendant la construction du catalogue

Un contrôle n'est intéressant que s'il a des dents, alors voici ce qui a échoué sur le chemin de ces chiffres. La trouvaille la plus instructive est typographique : les modèles serif classiques utilisent traditionnellement un interlettrage large sur les noms en capitales et les titres de rubriques, et nous avons constaté que l'extraction de texte PDF commence à couper ce texte en fragments d'une lettre à partir de 0,11 em d'interlettrage. L'échec est binaire et net : sous le seuil, les mots s'extraient entiers ; au-dessus, « SUMMARY » s'extrait en lettres séparées qui ne correspondent à aucune recherche. Chaque modèle du catalogue plafonne désormais l'interlettrage à 0,04 em au maximum, et notre famille Heritage tire son allure traditionnelle de la casse, des filets et du choix de caractères plutôt que de l'interlettrage.

Cette trouvaille se généralise au-delà de nos modèles, et c'est un point que presque aucune checklist « compatible ATS » ne mentionne : si votre CV actuel utilise un espacement stylisé sur les titres, son extraction peut être brisée exactement de cette façon, quelle que soit la sobriété apparente de la mise en page. C'est aussi invisible à l'œil, et c'est précisément pourquoi nous montrons l'extraction : le vérificateur calcule quelle part des mots de votre fichier se relit en mots entiers, et met le texte brut sous vos yeux.

Le contrôle impose aussi l'ordre de lecture par modèle, ce qui contraint le design de façon utile. Les en-têtes bandeaux (Nova, Onyx), les ordres formation d'abord pour les étudiants (Beacon, Primer) et le style monospace (Mono) ont tous dû prouver leur séquence d'extraction avant d'être livrés. La règle est simple : une idée de mise en page qui ne peut pas garder le nom, l'accroche et les titres de rubriques dans l'ordre déclaré du flux extrait n'est pas livrée avec le badge, aussi belle soit-elle.

Les quatre modèles que nous refusons de badger, honnêtement

Nos quatre modèles de la famille Statement (Studio, Panorama, Duet, Atlas) sont des mises en page à deux colonnes, et dans cette étude même, ils ont mesuré 98,94 pour cent de couverture des tokens avec un ordre de lecture propre. Alors pourquoi portent-ils l'étiquette « Best for human review » au lieu d'ATS-Verified ?

Parce que le test que nous pouvons leur appliquer est structurellement plus faible, et l'intégrité du badge compte plus que le nombre de badges. Pour un modèle à une colonne, le contrôle vérifie une propriété avec une vraie force : le CV entier est un flux de texte unique, donc il n'existe qu'un seul ordre de lecture qu'un analyseur puisse trouver. Pour un modèle à deux colonnes, aucune séquence unique de ce genre n'existe. Notre contrôle vérifie l'ordre interne de chaque colonne indépendamment (en-tête et colonne principale ; colonne latérale), et sur les rendus multi-pages, la pagination entrelace légitimement les deux colonnes page par page. Des analyseurs ATS différents parcourent les pages multi-colonnes différemment, et aucun ne publie comment. Nous pouvons prouver que notre extraction deux colonnes est cohérente en interne ; nous ne pouvons pas promettre que chaque analyseur réassemblera les deux voies comme un œil humain le fait. Alors l'étiquette dit ce que nous savons : au plus fort quand une personne lit d'abord.

Quand les utiliser malgré tout ? Cooptation, salons, copies imprimées, recrutements portés par le portfolio : les contextes où un humain est le premier lecteur et où la voie visuelle pour les compétences et diplômes gagne sa place. La page de la famille Statement couvre l'arbitrage, et chaque export retombe sur une seule colonne propre en DOCX et TXT, pour que vous ne soyez jamais enfermé dans le pari des deux colonnes pour une candidature via portail.

Limites : ce que cette étude ne peut pas vous dire

Une étude ne vaut que par ses limites déclarées, alors voici les nôtres, spontanément.

Un seul moteur d'extraction. Nous extrayons avec unpdf, une implémentation open source de l'extraction de texte PDF. Les analyseurs ATS commerciaux utilisent leurs propres moteurs, et les moteurs peuvent diverger sur des fichiers piégeux. Notre défense est que les modèles sont conçus pour ne pas avoir de parties piégeuses : flux de texte uniques, vraies polices, interlettrage plafonné. Plus l'entrée est simple, moins les moteurs ont de place pour diverger, et rendre l'entrée simple est exactement ce que le contrôle impose. Malgré tout, « s'extrait parfaitement dans un moteur » est un indice, pas une preuve, pour tous les moteurs.

Un seul gabarit. Chaque chiffre de cette étude vient d'un seul CV d'exemple de deux pages délibérément complet. Un CV différent (URL très longues, Unicode inhabituel, dix pages de postes) pourrait faire apparaître d'autres résidus. Le gabarit est conçu pour exercer chaque type de rubrique que notre éditeur prend en charge, mais il ne peut pas exercer chaque CV qui existe. C'est pourquoi le vérificateur compte : il lance la même extraction sur votre fichier réel, le seul test qui couvre votre contenu réel.

L'analyse, pas le classement. Le contrôle mesure si le texte survit au voyage dans un ATS. Il ne dit rien de la façon dont le classement, les filtres ou les recherches d'un recruteur traiteront ce texte, ce qui dépend de votre contenu et de leur configuration. Un modèle vérifié fait entrer vos mots intacts dans la base ; il ne peut pas rendre les mots bons.

Une photographie à un instant donné. Ces chiffres décrivent le catalogue tel que mesuré le 22 août 2026. Les modèles évoluent, les moteurs de rendu se mettent à jour, et le contrôle se relance à chaque changement précisément parce que les résultats passés ne certifient pas les builds futurs. Quand les chiffres changent, cette page change.

Comparé à la façon dont les modèles sont habituellement vendus

Nous avons étudié le paysage concurrentiel en profondeur en construisant ce catalogue, et le schéma standard du marché des éditeurs de CV est : décrire chaque modèle comme compatible ATS, n'attacher aucun test, ne publier aucun chiffre. Parfois l'affirmation décore des mises en page à colonnes latérales sombres, barres de notation de compétences et structures à deux colonnes, précisément les éléments qui rendent l'extraction imprévisible, sans aucune distinction pour l'acheteur.

Nous n'allons pas affirmer que les modèles des concurrents échouent à l'analyse ; nous ne les avons pas mesurés, et cette étude n'affirme que ce que nous avons mesuré. Ce que nous dirons est structurel : une affirmation sans méthode n'est pas une information, c'est une décoration. Les questions utiles à poser à tout vendeur de modèles, nous compris, sont celles auxquelles cette étude répond à découvert :

• Qu'est-ce qui a été testé exactement, sur quel pipeline de rendu : le vrai, celui par lequel les utilisateurs exportent, ou une maquette ?
• Qu'est-ce qui a été mesuré : la couverture des tokens contre le contenu source, l'ordre de lecture, les deux, ni l'un ni l'autre ?
• Quel seuil un modèle doit-il franchir, et que se passe-t-il quand l'un n'y arrive pas ?
• Quels modèles portent l'affirmation et lesquels non, et le vendeur accepte-t-il d'étiqueter une partie de son propre catalogue comme NON vérifiée ?
• Le test peut-il être relancé, et les artefacts sont-ils inspectables ?

Ce que cela signifie pour votre CV, quel que soit votre outil

Vous n'utiliserez peut-être jamais nos modèles, et l'étude vous donne quand même une checklist opérante, parce que les modes d'échec contre lesquels nous avons verrouillé sont universels :

• Vérifiez l'extraction, ne la supposez pas. L'habitude la plus précieuse de toute cette étude : regardez le texte extrait de votre CV avant une salve de candidatures. Notre vérificateur le montre en quelques secondes, en illimité, sans compte.
• Traitez l'interlettrage comme un risque dur. Un espacement stylisé sur les noms et les titres peut briser l'extraction de façon invisible. Si votre modèle espace ses titres en capitales, vérifiez à quoi ressemblent les mots dans l'extraction.
• Préférez une colonne pour les candidatures via portail. Non parce que deux colonnes échouent toujours, mais parce qu'une colonne est la seule mise en page dont l'ordre de lecture est prouvable en général.
• Attendez-vous à ce que les URL longues s'effilochent. Les schémas et les fragments de chemin coupés à la ligne sont les premières victimes de l'extraction. Si un lien doit être copiable depuis la fiche analysée, gardez-le court et sur une ligne.
• Jugez les badges par leur méthode. Toute étiquette « approuvé ATS » sans test publié est un choix de police, pas un fait. Posez les cinq questions ci-dessus.

Questions fréquentes

Avez-vous testé contre de vrais ATS comme Workday ou Greenhouse ?

Non, et nous le disons franchement : les éditeurs d'ATS commerciaux n'exposent pas leurs analyseurs au benchmark, et tout outil qui prétend avoir noté votre CV « dans Workday » devrait expliquer comment. Ce que nous testons, c'est la couche dont chacun de ces systèmes dépend : le texte extractible du PDF. Si l'extraction est complète, ordonnée et intacte, vous avez sécurisé l'entrée que tous les analyseurs partagent.

Que signifie concrètement 98,94 pour cent de couverture ?

Le CV d'exemple se sérialise en 284 tokens attendus, comptés avec leur multiplicité. Dans un run à 98,94 pour cent, 281 des 284 occurrences de tokens ont été retrouvées dans le texte extrait du PDF ; les 3 manques étaient le schéma d'URL « https » (attendu trois fois, affiché autrement par les modèles). Tous les intitulés de poste, employeurs, dates, compétences et contenus de puces se sont extraits complètement.

Pourquoi trois modèles compacts mesurent-ils 98,24 pour cent au lieu de 98,94 ?

Dans Vector, Primer et Mono, la longue URL de projet GitHub de l'exemple passe à la ligne d'une façon qui coupe deux de ses tokens de chemin lors de l'extraction, en plus des trois tokens de schéma manquants partout. Cela fait 5 tokens sur 284, tous issus d'une seule URL. La prose du CV n'a pas été touchée, et les trois modèles franchissent le seuil de 95 pour cent avec l'ordre de lecture intact.

Puis-je reproduire cette étude ?

Le contrôle est un script de notre base de code (scripts/check-template-parity.ts) qui rend chaque modèle du registre à travers le build de production, extrait le texte de chaque PDF avec unpdf, et échoue si un modèle descend sous 95 pour cent de couverture ou casse l'ordre de lecture. Il sauvegarde les 29 PDF comme artefacts inspectables. Même gabarit d'entrée, même tokeniseur, même seuil à chaque run.

Si les modèles à deux colonnes mesurent 98,94 pour cent, pourquoi ne pas les badger ?

Parce que notre test prouve moins pour eux. Une colonne unique a un seul ordre de lecture prouvable ; deux colonnes ont deux voies ordonnées en interne que des analyseurs différents peuvent réassembler différemment, et les rendus multi-pages entrelacent les voies page par page. Nous vérifions ce qui est vérifiable et étiquetons le reste honnêtement : Best for human review, avec des replis DOCX et TXT à une colonne intégrés.

Comment vérifier ce qu'un analyseur lit dans mon CV actuel ?

Déposez-le dans le vérificateur ATS. Il extrait la couche texte de votre fichier avec la même approche que cette étude et vous montre le résultat brut, plus des contrôles déterministes sur la qualité d'extraction, les coordonnées, les titres de rubriques et les dates. Les analyses sont illimitées, et les fichiers sont traités en mémoire, jamais stockés.

Sources

Faits, prix et politiques vérifiés le 22 août 2026. Ils peuvent changer ; les pages de paiement des éditeurs font foi.

• Harvard Business School and Accenture, Hidden Workers: Untapped Talent (Fuller and Raman, 2021)