Le CV bien présenté

Beaucoup de gens écrivent un CV comme celui d’Alex, et la plupart ne sont pas malhonnêtes. Ils travaillent dans des milieux où le CV est un document de vente. Les conseils qu’ils lisent en ligne disent la même chose : des verbes forts, un chiffre par ligne, les mots-clés de l’offre. Chaque petit pas semble normal. Ensemble, ces pas décrivent une personne qui n’existe pas.

Alex travaille depuis trois ans chez Brightpath Digital, une société de conseil. Une société de conseil vend les services de son personnel aux clients à la journée. Elle rédige donc leurs profils pour décrocher des projets. Alex a appris à décrire son travail dans ce langage. Maintenant, il a moins de mandats clients et veut un poste dans une équipe produit. L’offre de Quillfield demande presque tous les outils dont il a entendu parler. Son CV les reprend donc.

Cette page montre ce qui arrive quand un CV promet plus qu’une personne peut expliquer. À la fin, nous racontons la même histoire honnêtement et voyons ce que valait son expérience réelle.

AM

La personne candidate

Alex Moreau

Ingénieur en IA, 3 ans dans une société de conseil

• 3 ans chez Brightpath Digital
• Python
• Montréal
• Candidature envoyée par le site d'offres d'emploi

• Ingénieur en IA, Brightpath Digital (3 ans). Livré des solutions d’IA générative pour des entreprises en finance, en commerce de détail et dans le secteur public.
• Conçu l’architecture de systèmes multiagents avec LangGraph, CrewAI et AutoGen.
• Effectué le réglage fin de Llama 70B avec LoRA pour l’adapter à un domaine.
• Construit un système RAG d’entreprise avec une exactitude de 98 %.
• Réduit les coûts des LLM de 70 %.
• Expert en ingénierie de requêtes, DSPy, garde-fous et LLMOps (exploitation des LLM).

Ce que Nadia voit avant l’appel

Nadia lit le CV avec l’offre d’emploi ouverte à côté. Ils correspondent presque mot pour mot. L’offre énumère trois frameworks (cadres logiciels) d’agents, et le CV aussi. L’offre demande LoRA, et le CV le mentionne.

Cela seul lui apprend peu de choses. Beaucoup de bons candidats copient les mots-clés, parce qu’Internet leur conseille de le faire. Elle cherche donc des lignes qu’elle peut vérifier avec une ou deux questions précises :

• « Exactitude de 98 % ». Sur quoi, sur combien de questions, avec une vérification faite par qui? Un pourcentage sans le nombre sous-jacent n’est pas encore une preuve.
• « LangGraph, CrewAI et AutoGen ». Une équipe utilise rarement trois frameworks d’agents pour un seul système. Lequel a-t-il choisi, et pourquoi?
• « Réglage fin de Llama 70B ». LoRA sur un modèle de 70 milliards de paramètres est possible, mais demande des GPU puissants et de bonnes données. Quelles données a-t-il utilisées, sur quel matériel, et le résultat a-t-il été mis en production?
• « Réduit les coûts des LLM de 70 % ». De quel montant à quel montant, et la qualité est-elle restée la même?

Elle ne posera pas de questions sur le mot « expert » dans cinq domaines. Les autres lignes lui donneront la réponse. Son plan est le même que pour chaque candidature. Alex choisit un projet, puis elle suit ses propos en approfondissant d’un niveau à chaque fois.

Termes utilisés sur cette page

• RAG (génération augmentée par récupération) : le système trouve d’abord des passages dans vos documents, puis le modèle de langage répond à partir de ces passages.
• Un segment est un petit morceau d’un document. Un plongement (embedding) est une liste de nombres qui représente le sens d’un segment. Le système peut ainsi trouver des segments au sens semblable.
• Un garde-fou est une vérification qui bloque ou corrige une réponse dangereuse ou incorrecte.
• Une hallucination est une affirmation que le modèle écrit, mais que la source ne confirme pas.
• La reconnaissance optique de caractères (OCR) transforme une page numérisée en texte.
• Les PII sont des renseignements personnels qui permettent d’identifier une personne, comme un nom ou une adresse.

L’entrevue

Minutes 0 à 5 : l'ouverture

Nadia(intervieweur) :

Bonjour Alex, merci de prendre le temps. Je suis Nadia, ingénieure principale dans l’équipe Claims Intelligence. Alors, voici le plan. D’abord, j’aimerais entendre parler de quelque chose que vous avez construit. Je vais poser beaucoup de questions pour approfondir. C’est normal. Ensuite, un problème chez nous, puis vos questions. Et comme indiqué dans l’invitation, cette étape se fait sans assistants d’IA. Les notes sur papier sont permises. Si vous voulez chercher quelque chose, dites-le-moi simplement.

Alex(personne candidate) :

Bien sûr, absolument. Merci de me recevoir. Les réclamations sont un domaine tellement intéressant pour l’IA générative.

Nadia(intervieweur) :

Bien. Alors commençons par vous. Choisissez un projet dont vous êtes fier et expliquez-moi comment vous l’avez réalisé.

Ce que l’intervieweur vérifie

Nadia explique la règle sur les outils d’IA à chaque personne candidate, au début, d’un ton neutre. Elle ne cherche à piéger personne. Elle veut que tout le monde connaisse les règles avant le début de cette étape.

Minutes 5 à 18 : le projet, puis les détails

Une pause avant sa réponse.

Alex(personne candidate) :

Bien sûr. Chez Brightpath, j’ai conçu l’architecture d’une plateforme de génération augmentée par récupération de niveau entreprise. Elle servait la base de connaissances interne d’un grand client. Le pipeline avait quatre couches. Une couche d’ingestion avec découpage sémantique et génération de plongements (embeddings). Une couche de récupération hybride, combinant recherche vectorielle dense et recherche par mots-clés, suivie d’un modèle de reclassement à encodeur croisé. Une couche d’orchestration multiagent sur LangGraph, avec un agent de routage, un agent de récupération et un agent de validation. Et une couche de garde-fous pour garantir des réponses fondées sur les sources, sûres et conformes. Nous l’avons évaluée avec un cadre robuste et avons atteint 98 % d’exactitude.

Ce que Nadia entend

Chaque phrase est correcte, mais rien n’est personnel. Il n’y a aucun document, aucun utilisateur, aucun chiffre qu’elle peut vérifier, et aucun « j’ai décidé ». Vous n’avez pas besoin de connaître ces mots. Ce qui compte, c’est qu’aucun ne parle d’un projet réel en particulier. Ses prochaines questions cherchent donc le projet précis derrière cette description.

Nadia(intervieweur) :

D’accord. Allons plus lentement. Quels étaient les documents, et qui posait les questions?

Alex(personne candidate) :

Le corpus était la base de connaissances interne du client. Des politiques, des procédures. Surtout des ressources humaines, en fait. Congés, avantages sociaux, déplacements.

Nadia(intervieweur) :

D’accord, des politiques de RH. Vous avez dit 98 % d’exactitude. 98 % de quoi?

Alex(personne candidate) :

Nous avons combiné l’évaluation automatisée et humaine. Du côté automatisé, les mesures RAGAS, donc la fidélité et la pertinence des réponses. Et en plus, une révision humaine pour valider les résultats. Les 98 %, c’était la part des réponses qui respectaient le seuil de qualité.

Nadia(intervieweur) :

Hum-hum. Ça représentait combien de réponses?

Alex(personne candidate) :

C’était… environ cinquante questions. Pour l’évaluation finale.

Nadia(intervieweur) :

Cinquante. Donc 48 bonnes… non, pardon, 49 bonnes, une mauvaise. Qui décidait qu’une réponse était bonne?

Alex(personne candidate) :

L’équipe de RH du client les a révisées avec nous.

Nadia(intervieweur) :

Et celle qui a échoué, vous vous en souvenez?

Alex(personne candidate) :

C’était un cas limite. Une requête ambiguë, où la récupération ramenait une politique liée au sujet, mais pas tout à fait pertinente. Nous avons atténué le problème en reformulant les requêtes.

Comment l’intervieweur va plus loin

Nadia ne dit jamais « je ne vous crois pas ». Elle demande le détail suivant : quoi, combien, qui, lequel. La personne qui a fait le travail se souvient de ces détails. Pour les autres, chaque question est plus difficile que la précédente.

Comment un chiffre mène aux détails

1. 1

   « Expliquez-moi comment vous avez réalisé le projet. »

   Une architecture complète et générale. Les bons mots, rien à vérifier.

2. 2

   « 98 % de quoi? »

   D'abord, des noms de mesures. Puis : environ cinquante questions, donc 49 sur 50 dans un seul test.

3. 3

   « Qui décidait qu'une réponse était bonne? »

   L'équipe de RH du client. Le chiffre représentait donc 49 réponses sur 50 acceptées par les RH dans une démonstration. C'est une vérification réelle, mais limitée, pas l'« exactitude de niveau entreprise » que le CV laisse entendre.

4. 4

   « Laquelle a échoué? »

   Une réponse générale. Une personne qui a fait le test se souvient habituellement de la vraie question.

Nadia(intervieweur) :

Votre CV mentionne LangGraph, CrewAI et AutoGen. Lequel avez-vous utilisé pour l’assistant RH? Et pourquoi celui-là, plutôt que les deux autres?

Alex(personne candidate) :

Chaque cadre logiciel a ses forces. LangGraph offre un contrôle précis grâce à une machine à états basée sur un graphe, idéale pour les flux en production. CrewAI propose une abstraction de plus haut niveau, basée sur des rôles, pour le prototypage rapide. Et AutoGen excelle dans les échanges conversationnels entre agents. Donc ça dépend du cas d’utilisation.

Nadia(intervieweur) :

C’est une comparaison générale valable. Mais je parle de votre système.

Alex(personne candidate) :

LangGraph. Pour le contrôle. Quand l’agent de validation rejetait une réponse, le système revenait à la récupération avec une nouvelle requête. Jusqu’à un nombre maximal de tentatives.

Nadia(intervieweur) :

Quel était le maximum?

Alex(personne candidate) :

C’était configurable. Il faudrait que je vérifie, honnêtement.

Ce que l’intervieweur vérifie

« Lequel, et pourquoi pas les autres? » demande une décision, pas une définition. Alex répond avec une comparaison qui convient à n’importe quel projet. Quand les questions deviennent précises, ses réponses deviennent courtes. Nadia remarque ce changement plus que toute réponse individuelle.

Nadia(intervieweur) :

Pas de problème. Autre question. Quel était le pire bogue dans ce projet? Une journée où quelque chose a cessé de fonctionner et où vous avez dû trouver pourquoi.

Alex(personne candidate) :

Le plus grand défi était l’hallucination. Nous l’avons traité avec l’ancrage dans les sources, les citations et les garde-fous de sortie.

Nadia(intervieweur) :

Ça, c’est un type de problème. Je parle d’un bogue précis. N’importe lequel dont vous vous souvenez.

Alex(personne candidate) :

Euh. D’accord, il y en avait un. La politique de vacances avait un tableau. Les jours de congé selon les années de service. Et le robot donnait toujours le mauvais nombre. Quelqu’un avec six ans recevait le nombre pour deux ans.

Nadia(intervieweur) :

Comment avez-vous trouvé la cause?

Alex(personne candidate) :

J’ai vu trois réponses sur les congés qui étaient fausses de la même façon. Alors j’ai ouvert les segments récupérés. Les nombres étaient tous sur une seule ligne, sans en-têtes. L’analyseur PDF avait aplati le tableau. Felix, un collègue, a corrigé l’analyse. Mais c’est moi qui l’ai trouvé.

Nadia(intervieweur) :

Bien vu, et c’est un problème très courant avec les tableaux. Alors, quel était votre rôle dans l’équipe, au quotidien?

La seule réponse qui semble réelle

Cette réponse contient un document, un mauvais nombre, un collègue et les étapes suivies pour trouver la cause. Elle est aussi plus modeste : Alex a trouvé le problème, et quelqu’un d’autre l’a corrigé. C’est ce que Nadia cherchait.

Alex(personne candidate) :

J’étais responsable de la livraison de bout en bout. Je dirigeais les décisions d’architecture, la stratégie d’évaluation et la communication avec le client. Et je travaillais sur l’ensemble de la pile technologique.

Où cela tourne mal

Pendant un moment, Alex a parlé de son propre travail. Puis il est revenu au CV. Maintenant, les grandes affirmations rendent la petite histoire vraie plus difficile à croire.

Nadia pose deux questions courtes sur les autres lignes. Pour le réglage fin, elle demande quelles données il a utilisées et comment il a mesuré le changement. Alex dit que c’était « une exploration » qui n’a pas été mise en production. Quand vous lisez « réglage fin pour l’adaptation au domaine », vous attendez des données d’entraînement et un résultat mesuré. Ni l’un ni l’autre n’existait.

LoRA

LoRA (adaptation de faible rang) est une façon peu coûteuse de faire le réglage fin d’un modèle. Les poids d’origine ne changent pas, et vous entraînez un petit nombre de poids supplémentaires. C’est une méthode réelle et courante.

Pour la réduction des coûts de 70 %, elle demande : « De combien à combien? » Alex donne d’abord une réponse générale. Puis il dit que c’était surtout une fonctionnalité, transférée à un modèle plus petit.

Minutes 18 à 25 : le tableau blanc

Nadia(intervieweur) :

Pourriez-vous dessiner l’assistant RH sur le tableau blanc partagé? Des boîtes et des flèches suffisent.

Alex(personne candidate) :

Bien sûr. Alors… utilisateur, agent de routage, agent de récupération, base de données vectorielle, le LLM. Puis l’agent de validation, les garde-fous, et retour à l’utilisateur.

Nadia(intervieweur) :

Merci. Quelle était la base de données vectorielle? Et quand une politique changeait, comment ajoutiez-vous la nouvelle version et retiriez-vous l’ancienne?

Alex(personne candidate) :

Pardon, retirer l’ancienne? Vous voulez dire supprimer les anciens documents?

Nadia(intervieweur) :

Oui. Disons que la politique de déplacements a une nouvelle version. Comment l’assistant cesse-t-il d’utiliser l’ancienne?

Alex(personne candidate) :

D’accord. Nous avons évalué plusieurs bases de données. Pinecone, Weaviate… Finalement, je crois que c’était Azure AI Search du client. Les mises à jour ne faisaient pas partie de la validation de principe. C’était une démonstration pour la direction du client.

Nadia(intervieweur) :

Ah, donc les employés ne l’ont pas utilisé en production?

Alex(personne candidate) :

Pas encore. Le client réfléchit encore à la prochaine phase.

Ce que l’intervieweur vérifie

Chaque boîte dans un dessin invite une question. Alex dessine le schéma général de sa première réponse. Les faits réels apparaissent un à un : politiques de RH, cinquante questions, une démonstration, pas en production.

Nadia(intervieweur) :

Merci, c’est utile. J’ai une bonne idée de ce projet, alors je vais passer à notre problème maintenant.

Comment Nadia gère la situation

Nadia reste calme et polie. Elle ne souligne pas les contradictions et ne demande pas « Est-ce que vous lisez ça? » Elle ne peut pas le savoir, et une accusation n’aiderait personne. Les pauses et les regards ne veulent rien dire à eux seuls. Les gens font des pauses pour plusieurs raisons : un deuxième écran, des notes, le stress ou une réflexion dans une deuxième langue. Elle pose des questions sur les faits, prend de courtes notes et indique clairement quand elle passe à autre chose.

Minutes 25 à 48 : le problème de Quillfield

Nadia(intervieweur) :

Voici un vrai problème chez nous. Un dossier de réclamation arrive : 20 à 60 pages, formulaires numérisés, notes de l’expert en sinistres, courriels, photos, estimation d’un entrepreneur. Les experts nous disent qu’ils passent environ 40 minutes à lire un dossier avant de pouvoir agir. Nous voulons leur fournir une ébauche de résumé d’une page : les faits clés, les questions ouvertes et ce qui manque. Comment aborderiez-vous ça?

Alex(personne candidate) :

Excellent problème. Je concevrais un pipeline multiagent. Un agent d’ingestion avec reconnaissance optique de caractères et analyse de la mise en page pour les documents numérisés. Un agent de résumé avec une requête (prompt) soigneusement conçue, possiblement optimisée avec DSPy. Un agent critique qui vérifie le résumé par rapport à la source pour détecter les hallucinations. Une couche LLMOps, pour l’exploitation des LLM, avec traçage, suivi des coûts et évaluation continue. Et des garde-fous pour masquer les renseignements personnels et rester conforme au RGPD.

Où cela tourne mal

Alex conçoit une solution avant de poser une seule question sur le problème. Il mentionne aussi le RGPD, la loi européenne sur la protection des données personnelles. Mais les assureurs de Quillfield sont au Canada et aux États-Unis, où la LPRPDE et d’autres lois s’appliquent. C’est une petite erreur. Elle montre tout de même que la réponse est générale, pas propre à ce problème.

Nadia(intervieweur) :

D’accord. Prenons un cas. L’estimation de l’entrepreneur dit que le toit a été remplacé en 2019. La note de l’expert dit 2021. C’est important pour la réclamation. Que devrait faire le résumé? Et comment sauriez-vous, avant la mise en production, qu’il le fait?

Alex(personne candidate) :

L’agent critique détecterait l’incohérence et la signalerait. Pour valider, j’utiliserais une approche avec un LLM comme juge. Avec des scores de fidélité et d’exhaustivité, suivis dans un tableau de bord.

Nadia(intervieweur) :

Et qui vérifie le juge?

LLM comme juge

LLM comme juge signifie qu’un deuxième modèle de langage note la sortie du premier. C’est rapide et peu coûteux, mais le juge peut aussi se tromper. Une équipe compare donc d’abord les scores du juge aux étiquettes humaines. La courte question de Nadia vérifie si Alex le sait.

Alex commence à parler, s’arrête, puis recommence.

Alex(personne candidate) :

Honnêtement… dans notre projet, il n’y avait pas de juge finalement. Les gens des RH ont passé les cinquante réponses dans un tableur. Bonne, mauvaise ou partiellement bonne, et un commentaire. Nous avons corrigé des choses, puis ils les ont revues.

Nadia(intervieweur) :

C’est en fait beaucoup plus proche de ce que nous ferions. Nous avons deux anciens experts en sinistres qui étiquettent les données. Environ quatre heures par semaine à eux deux, au total. La majorité sert à l’échantillon hebdomadaire des dossiers reçus. Si vous aviez quelques-unes de ces heures, que leur demanderiez-vous de faire en premier?

Alex(personne candidate) :

Hum. Peut-être… leur donner vingt vrais dossiers, et leur faire noter les faits qui doivent figurer dans le résumé. Ensuite, on vérifie si le résumé les contient.

Nadia(intervieweur) :

D’accord. Et le cas du toit?

Alex(personne candidate) :

Des contradictions comme le toit, on voudrait inclure exprès quelques exemples de ça.

Une meilleure réponse, dès le départ

Alex avait une bonne réponse depuis le début, parce qu’il l’avait vécue. Donnée au début, elle pourrait ressembler à ceci :

« Je n’ai pas construit d’évaluation à cette échelle. Dans mon dernier projet, c’était cinquante questions. L’équipe de RH du client vérifiait chaque réponse dans un tableur. C’était petit, mais j’en ai appris quelque chose. Les gens qui connaissent les documents doivent décider ce que “bon” veut dire. Alors ici, je commencerais de la même façon. Je demanderais à vos experts en réclamations de lister les faits qui doivent figurer dans le résumé. Pour vingt ou trente vrais dossiers, avec quelques contradictions choisies exprès. Ensuite, je compterais trois choses : les faits manquants, les faits erronés et les affirmations sans source dans le dossier. Seulement après, j’ajouterais un LLM juge, et je le vérifierais d’abord avec leurs étiquettes. »

Nadia(intervieweur) :

C’est un début raisonnable. Encore une chose. Disons que nous résumons chaque dossier à son arrivée. Deux jours plus tard, un nouveau document arrive pour la même réclamation. Qu’est-ce qui se passe?

Alex(personne candidate) :

Alors… on le générerait de nouveau, je suppose. Pour être honnête, je n’ai pas vraiment travaillé avec des documents qui changent.

La limite

Ici, Alex atteint la limite de ses connaissances : les documents qui changent constamment. Il le dit, et c’est bien. Mais après les affirmations du CV, Nadia se demande aussi : qu’est-ce qui dépassait encore le travail réel?

Nadia pose aussi des questions sur les pages numérisées et les renseignements de santé dans les réclamations pour blessures. Alex propose le « masquage des renseignements personnels » pour les deux. Il ne demande pas qui peut voir ces renseignements.

Minutes 48 à 57 : les questions d'Alex

Alex(personne candidate) :

Utilisez-vous LangGraph en production, ou un autre cadre logiciel?

Nadia(intervieweur) :

Ni l’un ni l’autre, pour le moment. L’extraction se fait avec de simples étapes Python dans un service FastAPI. Il nous faudrait une raison pour ajouter un cadre logiciel. La liste dans l’offre est plus longue que ce que nous utilisons. C’est notre erreur.

Où cela tourne mal

Les questions d’Alex sont polies, mais générales. Il ne pose pas de questions sur le travail réel : qui est de garde, comment les heures des experts sont utilisées, ou quand une fonctionnalité est prête. Voir Une entrevue est une conversation dans les deux sens.

Minutes 57 à 60 : la conclusion

Nadia(intervieweur) :

Merci, Alex. Je vais rédiger mes notes aujourd’hui, et l’équipe discute de toutes les candidatures ensemble. Hannah vous donnera une réponse d’ici la fin de la semaine prochaine, un oui ou un non.

Alex(personne candidate) :

Merci. Est-ce que je peux vous demander comment vous trouvez que ça s’est passé?

Nadia(intervieweur) :

Je préfère ne pas donner de résultat avant la discussion d’équipe. Mais je peux dire ceci : le tableau des vacances et le tableur ont été les parties les plus utiles pour moi.

Pourquoi cela fonctionne

Nadia ne prend pas la décision seule. Mais elle donne à Alex une phrase honnête, qui lui indique quoi faire la prochaine fois.

Après l’appel : les notes de Nadia

Nadia écrit ses notes dans l’heure qui suit. Elle évalue seulement ce qu’elle a entendu et pu vérifier.

Candidat : Alex Moreau. Étape : approfondissement technique. Intervieweuse : Nadia Rahman.

Preuves solides : aucune à cette étape.

Quelques preuves :

• RAG : une des quatre personnes ayant réalisé une preuve de concept (politiques RH, environ 50 questions de test, démonstration seulement). Le bogue d’analyse des tableaux était précis et vécu directement.
• Évaluation : a vérifié les réponses à la main avec l’équipe RH du client. À petite échelle, mais le bon réflexe.

Aucune preuve :

• Systèmes de LLM en production. Le projet n’a pas été mis en service.
• Cadriciels d’agents. Ne pouvait pas expliquer pourquoi LangGraph, ni donner la limite de tentatives.
• Réglage fin. « Une exploration »; ne pouvait pas décrire les données ni un résultat.
• Documents qui changent, passage à l’échelle, gestion des défaillances.

Préoccupation : plusieurs affirmations du CV n’ont pas résisté aux questions de suivi. « 98 % d’exactitude » représentait 49 réponses sur 50 dans une seule démonstration. « Coûts des LLM réduits de 70 % » représentait une fonctionnalité transférée à un modèle plus petit. Les réponses étaient longues et générales, puis courtes et différentes quand les questions devenaient précises. Ma décision repose sur les affirmations que je n’ai pas pu vérifier.

Recommandation : ne pas embaucher. Problème de confiance : je ne sais pas quelles parties du CV sont vraies, donc je ne peux me fier à aucune. Les parties honnêtes étaient prometteuses, mais pour un poste plus junior.

La suite

Lors du bilan, Marcus pose une question sur le poste junior prévu au prochain trimestre. Nadia dit que les parties vraies constituent un point de départ raisonnable. Mais l’équipe doit pouvoir croire ce qu’une personne dit de son propre travail. Après cette entrevue, ce n’est pas possible. Ils conviennent de ne pas poursuivre.

Hannah envoie un refus poli à Alex huit jours plus tard. Il demande des commentaires, et Quillfield lui envoie deux phrases : « L’intervieweuse a eu du mal à relier les affirmations de votre CV à votre travail concret. Votre description de l’évaluation avec l’équipe RH et du bogue des tableaux a été la partie la plus utile. »

La même personne, présentée honnêtement

Nous racontons maintenant l’histoire à nouveau. Même personne, mêmes trois années, même projet. Seul changement : le CV dit ce qu’il a vraiment fait.

AM

La personne candidate

Alex Moreau

Consultant en données et en IA, 3 ans d'expérience, en transition vers l'ingénierie de l'IA

• 3 ans chez Brightpath Digital
• Python et SQL
• Montréal

• Consultant en données et en IA, Brightpath Digital (3 ans). Deux ans de pipelines de données Python et de tableaux de bord pour quatre clients; dernière année consacrée à l’IA générative.
• Un des quatre ingénieurs d’une preuve de concept RAG répondant aux questions sur les politiques RH (environ 400 documents). A rédigé les 50 questions de test avec l’équipe RH du client et dirigé la vérification des réponses. 49 réponses sur 50 jugées acceptables lors de la démonstration finale. Non déployé.
• A trouvé pourquoi les réponses sur les congés étaient fausses : l’analyseur PDF aplatissait les tableaux, mélangeant les lignes dans les segments. A aidé un collègue à corriger le problème (chaque ligne du tableau conservée avec ses en-têtes).
• A transféré une fonctionnalité (tri des documents par type) à un modèle plus petit après comparaison des sorties sur 100 exemples. Coût de cette fonctionnalité réduit d’environ 70 %.
• Apprentissage : a suivi un tutoriel de réglage fin LoRA sur un petit modèle ouvert. Aucun réglage fin en production.

Ce CV est plus modeste. En entrevue, il est beaucoup plus solide, parce qu’Alex peut expliquer chaque ligne. Voici une réponse honnête à la même question sur le projet.

Minutes 5 à 15, version honnête

Alex(personne candidate) :

Donc, d’abord : c’est une preuve de concept, pas un système en production. Nous étions quatre à créer un assistant qui répondait aux questions sur les politiques RH d’un client. Environ 400 documents. Moi, je m’occupais surtout de l’évaluation. J’ai écrit cinquante questions de test avec deux personnes de leur équipe RH. Ensuite, on a vérifié chaque réponse dans un tableur. Bonne, fausse ou partiellement bonne, avec un commentaire. À la démonstration finale, les RH ont dit que 49 des 50 réponses étaient acceptables.

Nadia(intervieweur) :

D’accord. Vous avez découvert quelque chose en cours de route?

Alex(personne candidate) :

Oui, un bogue avec un tableau de jours de congé. L’analyseur l’aplatissait, donc les réponses utilisaient la mauvaise ligne. Je pense que c’est la chose la plus utile que j’ai trouvée.

Nadia(intervieweur) :

Bien. Comment vous et les RH avez-vous défini ce qui était « acceptable »?

Alex(personne candidate) :

On avait trois règles. La bonne politique, le bon nombre s’il y en avait un, et un lien vers la bonne section. Les deux personnes des RH n’étaient pas d’accord sur… peut-être cinq réponses au début? Quelque chose comme ça.

Nadia(intervieweur) :

Quel genre de réponses?

Alex(personne candidate) :

Surtout des réponses correctes, mais qui omettaient une exception. On a décidé qu’une exception manquante rendait la réponse fausse.

Nadia(intervieweur) :

Pourquoi cette décision?

Alex(personne candidate) :

Parce qu’un employé agit en fonction de la réponse. Si elle dit quinze jours, mais oublie que le personnel à temps partiel en a moins, ça pose un vrai problème.

Nadia(intervieweur) :

C’est exactement notre problème avec les résumés de réclamations. Les omissions comptent autant que les erreurs. Que changeriez-vous à cette évaluation aujourd’hui?

Alex(personne candidate) :

Cinquante, c’est trop peu. Et les personnes qui les ont toutes écrites connaissent bien les documents. Les vrais employés posent leurs questions de façon moins organisée. Donc, je recueillerais de vraies questions auprès d’un groupe pilote. Et je garderais les cinquante anciennes comme test de régression, pour qu’un changement ne brise pas ce qui fonctionnait déjà.

Nadia(intervieweur) :

Bien. Vous n’avez rien exploité en production. Comment voyez-vous cette lacune?

Alex(personne candidate) :

C’est ma plus grande lacune. C’est aussi pourquoi je veux un poste dans une équipe produit. J’ai écrit des pipelines de données qui s’exécutaient chaque nuit pour des clients. Donc, je connais certaines bases, comme la journalisation et les relances. Mais je n’ai jamais assuré la garde pour une fonctionnalité d’IA en service. Je voudrais apprendre ça aux côtés de quelqu’un qui l’a déjà fait.

Pourquoi cela fonctionne

Chaque réponse donne à Nadia une piste à explorer, et chaque question de suivi reçoit une vraie réponse. Alex atteint sa limite (la production) et la nomme lui-même. Nadia peut maintenant juger son vrai niveau, et elle peut travailler avec quelqu’un de ce niveau. Voir Acquérir de vraies compétences et apprendre à les expliquer.

Dans cette version, les notes de Nadia ne soulèvent aucune préoccupation concernant la confiance. La production reçoit « aucune preuve », et Alex l’a dit lui-même. Elle recommande l’étape de conception de systèmes. Elle ajoute qu’il pourrait convenir au bas de la fourchette, ou au poste junior du prochain trimestre. Rien n’est certain : l’entrevue avec Owen vérifiera précisément la lacune en production qu’Alex a nommée. Mais Alex poursuit le processus.

Alex honnête n’a pas plus de compétences. C’est la même personne. La différence, c’est que Nadia peut croire ce qu’il dit. Son expérience réelle compte donc.

Ce qu’il faut en retenir

• Une petite affirmation que vous pouvez expliquer vaut mieux qu’une grande que vous ne pouvez pas expliquer. « 49 réponses sur 50, vérifiées par les RH, dans une démonstration » est modeste et ouvre une bonne discussion. « 98 % d’exactitude » met fin à la discussion quand cette affirmation ne tient plus.
• Quand une affirmation perd sa crédibilité, les autres aussi. Nadia n’a pas rejeté Alex par manque d’expérience. Elle l’a rejeté parce qu’elle ne pouvait plus distinguer les parties vraies. Les parties vraies ont donc été perdues avec le reste.
• L’aide extérieure vous donne des mots, pas votre expérience. Un outil peut écrire une réponse générale parfaite. Il ne peut pas donner la limite de tentatives de votre système ni la question qui a échoué dans votre test. Voir Ne pas utiliser l’IA ou d’autres aides pour tricher.
• « Je n’ai pas fait ça » est une bonne réponse. Les meilleurs moments d’Alex étaient les moments honnêtes. Ils montraient à Nadia son vrai niveau.

Si votre profil ressemble à celui d’Alex

Si votre CV dépasse votre expérience, vous pouvez le corriger avant votre prochaine entrevue. Il suffit de quelques soirées.

1. Testez chaque ligne à voix haute. Pour chaque ligne, répondez à quatre questions. Qu’ai-je fait exactement? Combien, et comment l’ai-je mesuré? Qu’est-ce qui a mal fonctionné? Que changerais-je? Si vous ne pouvez pas répondre, réécrivez la ligne jusqu’à pouvoir le faire. Des preuves plutôt qu’une autoévaluation vous aide à distinguer votre travail de ce qui s’est passé autour de vous.
2. Dites ce que vous avez fait et donnez le décompte derrière chaque nombre. Écrivez « Un des quatre ingénieurs; j’ai écrit les données de test » et « 49 questions de test sur 50, vérifiées par les RH », pas « 98 % d’exactitude ».
3. Retirez les outils que vous connaissez seulement par vos lectures. Si vous avez suivi un tutoriel, écrivez « tutoriel ».
4. Exercez-vous à présenter un projet en détail. Utilisez la structure d’Expliquer vos décisions : le problème, les options, votre choix, le résultat chiffré, les limites. Enregistrez-vous une fois. Puis repérez les phrases qui pourraient décrire n’importe quel projet.
5. Comblez une vraie lacune avec un projet. La lacune d’Alex est la production. Déployez un petit projet RAG que d’autres personnes utilisent. Ajoutez des données de test et la journalisation, puis changez les documents et voyez ce qui ne fonctionne plus. Les éléments d’un portfolio montre quoi inclure. Les cours L’essentiel de Docker et du nuage pour les développeurs en IA et CI/CD, tests et mises en production sûres vous aident avec le déploiement. Ensuite, utilisez Se préparer aux candidatures pour choisir le niveau des postes auxquels vous postulerez.

Si vous travaillez dans une société de conseil, son langage commercial n’est pas votre faute. Mais en entrevue, vous parlez seulement en votre nom. Décrivez votre travail comme vous le feriez à un collègue qui était là.