Deux lectures possibles d'un même parcours
Les intitulés AI Engineer et ML Engineer se recouvrent largement, mais les attentes derrière ne sont pas les mêmes. La distinction utile n'est pas le titre : c'est de savoir si l'entreprise cherche quelqu'un qui construit un produit autour de modèles existants, ou quelqu'un qui fabrique et fiabilise les modèles eux-mêmes.
Lecture orientée produit
Intégration de modèles existants, conception du système autour, évaluation de la qualité perçue, mise en production, coût et latence. Le livrable est une application qui tient.
Lecture orientée modèle
Préparation et qualité de la donnée, expérimentation, entraînement ou adaptation, mesure de performance, industrialisation du cycle de vie. Le livrable est un modèle fiable et reproductible.
Beaucoup de postes mélangent les deux. Le CV doit rendre visible la dominante, pas nier l'autre.
Un même projet peut donc alimenter les deux lectures. Un assistant interne construit sur un modèle existant contient une histoire d'intégration et de production, mais aussi une histoire de qualité de données et de mesure. Ce que vous mettez en avant change ; les faits, non.
Identifier la lecture attendue à partir de l'offre
L'intitulé est peu fiable. Quatre indices dans le texte de l'offre sont bien plus parlants. Pour décrypter une annonce dans son ensemble, notre guide sur la lecture d'une offre IA va plus loin ; on s'en tient ici à ce qui change dans le CV.
- La donnée : si l'offre parle de collecte, de labellisation, de qualité ou de volumétrie, la lecture est orientée modèle.
- La production : si elle parle d'utilisateurs, de latence, de coût, de disponibilité ou de support, la lecture est orientée produit.
- Les livrables : « un service », « une application », « une API » d'un côté ; « un modèle », « un pipeline d'entraînement », « une amélioration de performance » de l'autre.
- Les interlocuteurs cités : produit et métier signalent une dominante applicative ; recherche et data engineering signalent une dominante modèle.
Quand l'offre est trop vague pour trancher, c'est une information en soi : le poste n'est probablement pas encore stabilisé. Préparez plutôt la question pour l'entretien que la version parfaite du CV.
Réordonner avant de réécrire
La modification la plus efficace est aussi la plus rapide : changer l'ordre. Un recruteur consacre peu de temps au premier passage, et ce temps se joue en haut de page.
- En-tête : une ligne de positionnement qui nomme les systèmes que vous construisez, pas un titre générique.
- À l'intérieur d'une expérience : les responsabilités correspondant à la lecture attendue en premières puces.
- Compétences : regroupées par usage (construction, évaluation, exploitation), pas en liste d'outils alphabétique.
Cette réorganisation ne modifie aucun fait. Elle rend simplement lisible ce qui est pertinent pour ce poste précis, ce qui est exactement l'objectif d'un CV.
Écrire une ligne d'expérience utile
La plupart des lignes de CV décrivent une tâche. Une ligne utile décrit une décision. La trame la plus robuste tient en trois éléments : le problème, la décision, le résultat observable.
Avant
« Développement d'un chatbot interne avec Python, LangChain et une base vectorielle. »
Après
« Assistant de recherche documentaire pour le support : indexation par version des procédures, citation obligatoire des sources, jeu d'évaluation relu par deux référents métier. Réduction des réponses fondées sur des documents périmés. »
Aucun chiffre inventé : un résultat observable peut être qualitatif s'il est vérifiable en entretien.
Une ligne gagne aussi en crédibilité quand elle dit ce que vous avez porté personnellement. « Nous avons mis en place » ne se vérifie pas en entretien ; « j'ai conçu l'indexation et le jeu d'évaluation, l'équipe a pris en charge la mise en production » se vérifie très bien. Distinguer votre part de celle de l'équipe n'affaiblit pas le parcours : c'est ce qui le rend interrogeable.
Avant (orienté modèle)
« Entraînement de modèles de classification sur des données clients, amélioration des performances. »
Après (orienté modèle)
« Modèle de classification de tickets : reprise du jeu d'entraînement avec les équipes support pour corriger un étiquetage incohérent, validation par période plutôt qu'aléatoire pour éviter la fuite temporelle, réentraînement mensuel automatisé. Écart réduit entre la validation et le comportement observé en production. »
Même parcours, autre lecture : ce qui est démontré ici porte sur la donnée, le protocole et la reproductibilité.
Ne mentionnez un chiffre que si vous pouvez expliquer comment il a été mesuré. Une amélioration annoncée sans méthode de mesure est perçue comme un argument commercial, et se retourne contre le candidat au moment de l'entretien technique.
La section compétences : arrêter la liste d'outils
Une longue liste d'outils ne différencie plus personne et brouille le niveau réel. Trois regroupements suffisent, et ils suivent la même logique que les entretiens : construire, mesurer, exploiter.
- Construction : langages, frameworks d'orchestration, bases utilisées, types de systèmes réellement livrés.
- Évaluation : méthodes de mesure de la qualité, constitution de jeux d'exemples, relecture humaine.
- Exploitation : déploiement, supervision, gestion des coûts, cycle de vie des modèles.
Distinguez ce que vous pratiquez de ce que vous avez croisé. Une mention « pratique quotidienne » et « notions » sur deux blocs distincts est bien mieux reçue qu'une liste indifférenciée où tout semble au même niveau.
Projets personnels, formations et certifications
Ils comptent surtout quand l'expérience professionnelle ne couvre pas encore la lecture attendue : un profil Data Scientist qui vise un poste applicatif, ou un profil applicatif qui vise un poste orienté modèle.
- Gardez deux projets au maximum, réellement accessibles et documentés.
- Décrivez le problème et la limite connue, pas la stack ; un dépôt sans explication dessert plus qu'il n'aide. Notre guide sur un portfolio GitHub crédible détaille ce qu'un relecteur y cherche réellement.
- Les certifications comptent comme un signal d'entrée dans un domaine, pas comme une preuve d'expérience : ne les placez jamais avant les expériences.
- Retirez les projets de cours identiques à ceux de milliers de candidats, sauf si vous les avez prolongés significativement.
Deux versions, pas une par offre
Maintenir un CV par annonce est intenable et produit des documents incohérents. Deux versions stables — une orientée produit, une orientée modèle — couvrent la quasi-totalité des candidatures. Chaque envoi ne demande alors qu'un ajustement de l'en-tête et de l'ordre des puces.
Sur les conventions de forme, adaptez-vous au marché visé plutôt qu'à une règle universelle : les usages diffèrent en France, en Espagne et sur les marchés internationaux, notamment sur la photo, la longueur et la langue du document. En cas de doute pour une entreprise internationale, une version en anglais, sans photo et tenant sur deux pages reste l'option la plus sûre.
Sur les filtres automatiques, restez mesuré : reprendre la terminologie de l'offre quand elle correspond réellement à votre expérience aide à être trouvé, empiler des mots-clés ne trompe personne et se voit dès la première question. Écrivez pour un lecteur humain, avec les mots que ce lecteur emploie.
Relecture avant envoi
Six points à vérifier une fois le CV terminé. Chacun se corrige en moins de dix minutes.
- La première expérience visible correspond à la lecture attendue par l'offre.
- Chaque ligne d'expérience contient un problème, une décision et un résultat observable.
- Aucune affirmation chiffrée que je ne pourrais pas expliquer en entretien.
- La section compétences distingue ce que je pratique de ce que j'ai croisé.
- Les projets personnels visibles sont accessibles et documentés.
- Un lecteur non technique comprend en trente secondes ce que je sais résoudre.
À retenir
- Deux familles de rôles, deux lectures : produit/intégration ou modèle/expérimentation.
- L'offre indique la lecture attendue : regardez la donnée, la production et les livrables cités.
- Réordonner et reformuler suffit presque toujours ; réécrire son parcours n'est ni utile ni crédible.
- Une ligne utile contient un problème, une décision et un résultat observable.
- Deux versions de CV par famille de rôles, pas une version par offre.
- Opportunités
- AI Engineering
- MLOps
- Évaluation