Dylan Arnaud, Data Analyst | J’aide les entreprises à piloter leur activité et leur rentabilité en concevant des tableaux de bord sur mesure | Power BI & Fabric | ⭐ 5/5 Malt, a récemment partagé une réalité qui pique: "Beaucoup de CV data passent à la poubelle avant même qu'un humain ne les lise." Il ajoute que le problème vient souvent des ATS (les robots de recrutement) qui filtrent d’office, puis des CV qui finissent par "ressembler à tous les autres" une fois sur le bureau d’un recruteur.

Cette idée m’a donné envie de développer le sujet en format blog, parce qu’elle touche à un point crucial: en data, vous êtes jugé sur votre capacité à produire de la valeur mesurable. Or beaucoup de CV décrivent des tâches, pas des résultats. Et beaucoup de mises en page "jolies" se font littéralement détruire par les ATS.

"Design surchargé, jauges de compétences subjectives, descriptions vides type 'nettoyage de données, création de graphiques'… rien qui ne capte l'attention."

Dans cet article, je reprends les "red flags vs green flags" cités par Dylan Arnaud, et je les transforme en plan d’action concret pour construire un CV data qui passe les filtres ET donne envie de vous rencontrer en 30 secondes.

Comprendre le double objectif: ATS + recruteur pressé

Un CV data efficace doit réussir deux examens.

L’examen machine (ATS)

L’ATS lit du texte. Il extrait des sections (expérience, compétences, formation) et cherche des correspondances de mots-clés.
Il déteste les tableaux, colonnes multiples, pictogrammes, barres de progression, éléments graphiques non textuels.

L’examen humain (le scan en 30 secondes)

Un recruteur (ou un manager data) scanne d’abord: titre, dernières expériences, technologies, signaux de crédibilité (projets, liens, impact chiffré).
Si votre CV ressemble à un modèle Canva générique sans preuves, vous perdez.

L’ambition, comme le résume Dylan Arnaud: un CV qui passe les ATS ET qui donne envie au recruteur de vous rencontrer rapidement.

Structure: sobre, lisible, et "ATS-friendly"

Dylan Arnaud recommande une base simple: PDF, une colonne, et des liens cliquables (GitHub, LinkedIn) dès l’en-tête. J’ajoute quelques précisions pratiques.

Ce qui marche bien

Format: PDF (sauf consigne contraire). Évitez les exports qui convertissent le texte en image.
Mise en page: une seule colonne, sections clairement titrées (Expérience, Projets, Compétences, Formation, Certifications).
En-tête utile: rôle visé (ex: Data Analyst), ville ou "Remote", email, téléphone, et surtout GitHub + LinkedIn cliquables.

Ce qui vous pénalise

Templates trop design avec icônes partout, jauges, logos, doubles colonnes.
Informations clés reléguées en bas ou dans une sidebar.

Astuce rapide: si vous copiez-collez votre PDF dans un bloc-notes, le texte doit rester lisible et dans le bon ordre. Si c’est un chaos, l’ATS verra un chaos.

Compétences: stop aux jauges, place aux preuves

Dylan Arnaud vise juste: les jauges subjectives ("90% en Python") n’aident ni l’ATS ni l’humain. Elles déclenchent même de la méfiance.

Green flag: une liste factuelle, précise

Au lieu de "Python", détaillez l’écosystème:

Python: pandas, numpy, scikit-learn, requests, beautifulsoup, pydantic
Data viz: Power BI (DAX, Power Query), Tableau
Data: SQL (PostgreSQL, BigQuery), dbt, Spark
Cloud: AWS, Azure

Faites correspondre l’offre, sans tricher

Un bon CV est un matching document.

Reprenez les technologies exactes de l’annonce (ex: "PostgreSQL" et pas uniquement "SQL").
Si vous avez une alternative proche, mentionnez-la clairement (ex: "BigQuery (équivalent Redshift sur certains usages)").

Expérience: décrivez l’impact, pas la fiche de poste

Le point le plus différenciant du post de Dylan Arnaud est là: chiffrer l’impact.

Exemple cité: "automatisation du reporting réduisant le temps de 4h à 15min/semaine via Python & Power BI"

Un bon bullet d’expérience en data

Structure simple en 1 ligne:

Action + livrable + techno + résultat mesuré

Exemples (à adapter):

Mis en place un pipeline de nettoyage (Python, pandas) pour fiabiliser 12 sources et réduire les erreurs de reporting de 18%.
Construit un dashboard Power BI (modèle en étoile, DAX) utilisé par 6 équipes, diminuant le temps de préparation mensuelle de 2 jours.
Optimisé des requêtes SQL (PostgreSQL) divisant par 3 le temps de génération des exports.

Quels chiffres si vous n’en avez pas?

Vous pouvez quantifier autrement:

Temps économisé (heures par semaine)
Volume (lignes, sources, utilisateurs, dashboards)
Qualité (taux d’erreur, complétude, SLA)
Business (CA, marge, churn, conversion) si vous avez le droit et l’ordre de grandeur

Même une estimation raisonnable vaut mieux qu’une liste de tâches génériques.

Projets: oubliez Titanic, montrez du "real world"

Dylan Arnaud conseille d’éviter les projets vus et revus (Titanic, Iris). Je suis d’accord, non pas parce qu’ils sont "interdits", mais parce qu’ils ne prouvent pas grand-chose sur votre capacité à travailler comme en entreprise.

Ce qu’un recruteur data veut voir

End-to-end: collecte ou ingestion -> traitement -> analyse -> restitution
Des contraintes réalistes: données sales, problèmes de jointure, mises à jour, documentation

Idées de projets plus crédibles:

Scraping + analyse: collecte de prix (dans le respect des CGU), normalisation, stockage, dashboard.
Projet "analytics" complet: définition de KPI, modèle de données, dashboard, et recommandations.
Reproduction d’un cas métier: cohortes, funnel, RFM, prévision simple, A/B test simulé.

Le README "béton" (le vrai différenciateur)

Un bon GitHub ne se résume pas à du code. Votre README devrait inclure:

Le contexte et l’objectif
Les données (source, dictionnaire, limites)
Les choix techniques (modèle, hypothèses)
Comment exécuter le projet (setup)
Résultats, captures, et prochaines étapes

Soft skills: prouvez-les par des situations

Dylan Arnaud souligne un piège classique: lister "rigoureux, autonome, esprit d’équipe" ne convainc personne.

Green flag: prouver par l’exemple.

"Participation à un hackathon en équipe de 4" (coordination, délais, communication)
"Animation d’un atelier KPI avec l’équipe Sales" (stakeholders)
"Rédaction de documentation et formation de 10 utilisateurs" (pédagogie)

Le recruteur veut des signaux observables, pas des adjectifs.

Certifications: mieux vaut 2 solides que 15 gadgets

Dylan Arnaud recommande la sélectivité: éviter l’accumulation de micro-certificats et privilégier des références reconnues (ex: Microsoft PL-300, AWS, Azure DP-900).

Mon ajout: une certification n’est utile que si elle est cohérente avec le poste.

Cible Power BI? PL-300 a du poids, surtout si vous pouvez aussi montrer un portfolio de dashboards.
Cible cloud data junior? DP-900 ou un badge AWS peut rassurer.

Et si vous n’avez pas de certif: compensez par un projet orienté "prod" (tests, CI simple, structure claire).

Checklist finale: le CV qui donne envie en 30 secondes

Avant d’envoyer, vérifiez ces points:

En-tête: rôle visé + liens cliquables GitHub/LinkedIn
Structure: une colonne, sections nettes, pas de graphiques inutiles
Compétences: listes précises (outils + librairies), alignées avec l’offre
Expérience: 2-4 bullets par poste, chacun avec un impact chiffré
Projets: 1-3 projets pertinents, README solide, démonstration end-to-end
Soft skills: 1-2 preuves concrètes, pas de liste de buzzwords
Certifications: peu mais reconnues, ou compensées par des preuves

Conclusion

Ce que Dylan Arnaud pointe est simple, mais souvent oublié: votre CV data est un produit. Il doit être lisible par une machine, puis désirable pour un humain. Et dans un marché où beaucoup de candidatures se ressemblent, la différence se fait sur la clarté, la preuve, et l’impact.

Si vous deviez ne changer qu’une chose aujourd’hui, faites comme dans son exemple: transformez chaque ligne "j’ai fait X" en "j’ai fait X, avec Y, et ça a produit Z".

This blog post expands on a viral LinkedIn post by Dylan Arnaud, Data Analyst | J’aide les entreprises à piloter leur activité et leur rentabilité en concevant des tableaux de bord sur mesure | Power BI & Fabric | ⭐ 5/5 Malt. View the original LinkedIn post →