Un portfolio perso, en 2026, ne sert pas qu'à montrer un parcours. Le mien reprend la main sur ma présence en ligne plutôt que de la laisser se deviner par d'autres, prépare le volet musique que je développerai plus tard, et tient ce blog où je pose mes questionnements sur l'IA au fur et à mesure. Trois buts différents, un seul site — et des orchestrations vers d'autres services ou sites plus tard. La difficulté pour un site comme celui-ci, c'est qu'il doit parler aux humains et aux machines en même temps, avec des besoins qui ne se recouvrent pas toujours. Comment on synthétise un CV pour un humain pressé de trente secondes tout en montrant toute l'info à un robot qui, lui, scanne tout sans qu'on sache vraiment ce qu'il en retient ?
J'avais déjà construit un skill agent-rh, nourri de ma propre veille,
pour m'améliorer au fil du temps sur mon CV. Il a fini par pointer un
vrai problème que je devais corriger : il donnait tout en synthèse en
devinant ce que vient chercher la personne qui regarde mon CV — et ça,
c'est impossible à deviner de façon fiable, puisque ça dépend entièrement
de qui regarde et pourquoi. Alors j'ai testé autre chose : simuler un
vrai outil de screening CV par IA, façon Greenhouse, Ashby ou Workday,
directement sur mon site public, et regarder comment mon skill RH réagit
à ce que cet outil produit — pas en lisant mon CV lui-même, en ne
lisant que sa synthèse. Reproduire fidèlement ce qu'un recruteur humain
ferait en 2026, pas ce que je voudrais qu'il fasse.
L'hypothèse tient debout : 87% des entreprises utilisent l'IA à un moment ou un autre de leur processus de recrutement, et le pipeline type ressemble à ceci — parsing du document, résumé ou score produit par un LLM, puis lecture humaine de ce résumé, la décision finale restant humaine. Ce que ça change concrètement, c'est qu'optimiser un CV pour un lecteur humain de trente secondes et l'optimiser pour un parseur IA ne sont pas tout à fait le même exercice. Parfois les deux se renforcent. Parfois ils s'opposent frontalement, comme on va le voir.
Le protocole que j'ai suivi : un agent générique fraîchement instancié, sans aucune mémoire de la conversation, qui lit uniquement ce qui est publié publiquement sur mon site — le CV, la page d'accueil, tous les billets du blog. Il produit un rapport structuré, exactement au format qu'un vrai outil de tri sortirait : un Fit Score chiffré et justifié, les compétences détectées en distinguant déclaratives (section Compétences) et inférées (citées seulement en prose dans une puce d'expérience), les points forts, les gaps, et une recommandation. Ce format n'est pas inventé : une compétence nommée dans une section dédiée et prouvée dans une puce d'expérience compte pour plus forte que l'une des deux prise seule — précisément ce que la fonctionnalité que je décris plus bas est venue corriger. Une fois ce rapport produit, je me mettais à la place du recruteur : je ne réagissais qu'à cette synthèse, jamais au CV brut. Cinq lectures ont été faites ainsi, sur cinq agents fraîchement instanciés, aucun ne se souvenant des passes précédentes.
Trois premières passes ont eu lieu au fil de mes corrections du CV, le même jour. Score de départ : 61 sur 100, avant toute section Compétences, sans ville ni région précisées, sans cloud provider nommé, sans orchestrateur cité. Après ajout d'une section Compétences, de Nantes, d'Azure et de GitLab CI/CD : 70 sur 100. Puis, après avoir supprimé un bloc "Stack technique" jugé redondant pour gagner en lisibilité : 63 sur 100 — alors que rien d'important n'avait disparu en substance, les mots-clés du bloc supprimé avaient été recopiés dans la section Compétences avant suppression.
Round 1 — trois passes, un score qui bouge tout seul
general-purpose fraîchement instanciés, chacun sans mémoire de la conversation ni des passes précédentes — protocole détaillé dans le corps du billet.Ce que la troisième passe a mis en évidence, c'est la vraie tension du billet. La règle "trois à cinq puces par poste, curées, pas une liste exhaustive" est une norme bien établie pour un CV lu par un humain pressé. Le problème, c'est qu'en simplifiant pour respecter cette règle, j'ai fait disparaître les puces de prose qui donnaient du contexte narratif à une dizaine de compétences listées par ailleurs dans la section Compétences — Docker, Kubernetes, TDD/DDD, Talend, Power BI. L'outil a signalé explicitement que ces tags "n'ont aucune trace dans les puces d'expérience" et a baissé sa confiance sur chacun d'eux pris individuellement. Un lecteur humain pressé, lui, préfère justement la version courte.
J'ai un principe qui s'oppose frontalement à cette lecture, et je le tiens : les compétences n'ont pas besoin d'avoir une ligne dans un contexte de synthèse, les mots sont une synthèse pour respecter les trente secondes — si les RH ont des questions, c'est à l'entretien qu'elles se posent. C'est un choix de design que je défends. Mais l'exercice montre concrètement qu'un lecteur IA ne sait pas "attendre l'entretien" — il note ce qu'il voit, au moment où il le voit. Ce n'est l'erreur de personne : deux lecteurs différents optimisent pour des choses différentes, et mon CV ne peut pas être parfaitement optimal pour les deux à la fois.
La question suivante m'intéressait plus encore : ce score est-il une propriété stable de mon CV, ou dépend-il de ce qu'on cherche ? J'ai rejoué la même lecture — même CV, même page d'accueil, même blog, rien n'a changé entre les trois — en ne faisant varier qu'un seul paramètre du prompt : le poste cible donné à l'agent. Trois formulations, trois scores très différents.
Un même CV, trois recherches, 23 points d'écart
Vingt-trois points d'écart sur un document strictement identique, en changeant seulement la cible de recherche. La conclusion que je retiens de ce chiffre : le score d'un outil de screening n'est pas une propriété du CV, c'est une propriété de la rencontre entre le CV et une recherche précise. Je n'ai pas "un score", j'en ai autant que de recherches possibles. Et le matching par titre de poste littéral semble peser plus lourd que le matching sémantique sur les compétences réelles — le rapport lui-même le dit, à propos du score le plus bas : l'écart pourrait venir d'un problème de formulation du CV plutôt que d'un déficit de compétence réel, mais ce n'est pas vérifiable à la seule lecture.
J'ai voulu corriger ce que je pouvais corriger sans mentir sur rien : la tension "tags sans preuve narrative" repérée au round 1. Plutôt que de rajouter de la prose — ce qui aurait recréé le problème de longueur qui m'avait fait simplifier au départ — j'ai rendu le lien structurel. Chaque tag de la section Compétences est devenu un vrai lien HTML statique vers l'expérience précise où cette compétence a été utilisée, avec un survol qui surligne l'entrée visée sans jamais masquer le reste. J'ai rejoué les trois mêmes recherches sur des agents fraîchement instanciés, CV identique par ailleurs.
Round 2 — après le lien compétence ↔ expérience
| Recherche ciblée | Round 1 | Round 2 | Delta |
|---|---|---|---|
| Data Engineer généraliste | 58 | 58 | 0 |
| Développeur expérimenté / senior | 41 | 58 | +17 |
| Context Engineer / Dev IA | 64 | 61 | -3 |
site/cv/skills.js).Le gain le plus net de toute la session : dix-sept points sur la recherche "développeur", exactement celle où le round 1 avait identifié le problème. Le rapport du round 2 l'écrit noir sur blanc à propos de TDD/DDD : liés à trois expériences distinctes, donc "traçables et non déclaratifs". Les deux autres scores, eux, ne bougent quasiment pas — logique, puisque les gaps qu'ils pointent (pas d'Airflow ni de dbt pour le poste Data Engineer, pas de LangChain ni de base vectorielle pour Context Engineer) sont des compétences réellement absentes. Aucun lien structurel ne peut les faire apparaître par magie. Le lien compétence-expérience aide à prouver une compétence déclarée, il n'en invente pas une manquante.
Ces gaps-là, d'ailleurs, je les laisse tels quels. LangChain, LlamaIndex, bases vectorielles, fine-tuning, MLOps : absents de mon CV, mais pas parce que je ne sais pas ce que c'est. Ce sont des outils connus, compris, mais non utilisés en entreprise — et je ne peux pas valoriser un outil que je n'ai pas pratiqué en contexte professionnel. Expliquer cette nuance-là (je connais, mais je n'ai pas appliqué en entreprise) prendrait encore des lignes sur un CV que je suis justement en train de condenser. L'outil de screening traite ces absences correctement comme un vrai gap de marché plutôt que comme une erreur de rédaction — ce qui me va très bien, parce que c'est exactement ce qu'ils sont.
Deux précisions de vocabulaire, faites pendant cette même session, illustrent bien le réflexe qui traverse tout ce billet : vérifier avant d'utiliser un terme qui sonne bien. J'ai remplacé "data ocean" par "hub-and-spoke" pour décrire mon architecture multi-usines centralisée — "hub-and-spoke" est le terme générique établi pour cette topologie. Un terme plus spécifique existe côté IIoT, "Unified Namespace", mais je l'ai écarté parce que la littérature l'associe à des protocoles OT précis, MQTT et Sparkplug B, pas à Kafka nativement : l'utiliser aurait sur-affirmé un outillage que je n'utilise pas. Deuxième correction, plus nuancée qu'un simple remplacement de mot : "Forward Deployed Engineering" pour mon titre de poste. Écrire du code de production, embarqué chez le client — ça, je le fais déjà, et ça reste ma feuille de route. Ce qui manque encore, c'est la partie la plus revendiquée du FDE version 2026 : piloter des agents IA directement en production chez le client. Je me concentre sur l'étape d'avant, celle qui doit exister avant qu'on puisse piloter des agents en production de façon fiable — construire la documentation, le "cerveau", le RAG, peu importe le mot exact. "Context Engineering", terme employé par Gartner qui déclarait mi-2025 que le prompt engineering était fini au profit du context engineering, avec une prédiction de présence dans 80% des outils IA d'ici 2028, nomme précisément l'étape où j'en suis réellement — pas la suivante, même si la suivante est le terme qui fait le plus de bruit en 2026. J'ai peut-être tort de rester aussi précis plutôt que d'anticiper, mais je saurai la défendre en entretien — et peut-être qu'un billet comme celui-ci donne à une IA qui résume un contexte qu'un simple mot-clé ne porte pas.
Il y a un point du round 2 que je n'ai pas corrigé, et que je ne corrigerai pas. Mon CV dit "RAG (passif)". Un des rapports lit ce qualificatif comme moi qui minimise ma propre compétence plutôt que comme de la précision honnête — et ça coûte des points de score. Je le garde quand même, en toute connaissance de cause :
"RAG c'est un mot-clé, qui dit RAG dit attente vector DB ou fine-tuning. Moi j'utilise un RAG passif, des informations bien rangées en Markdown pour l'IA — c'est passif et retouchable/versionnable facilement, et c'est bien l'intérêt. Le passage à la DB vectorielle peut avoir lieu comme produit à la fin, mais pas au début, où il faut d'abord l'auditer et l'améliorer. En 2026 on voudrait que je parle de fine-tuning et de vector DB, alors que j'ai fait mes recherches et j'estime que ce n'est pas le moment dans mes usages — qu'un RAG passif est plus pertinent que du bruit IA de métier. Mais l'analyse montre que 'RAG' seul passe comme mot-clé, et 'RAG (passif)' comme non compris, ce qui baisse la note. Je reste honnête, j'emploie les bons termes — ça montre bien un problème du CV 2026 : les humains (et les agents) attendent des mots précis, alors que la réflexion et l'usage pertinent d'un domaine en mutation sont invisibilisés parce qu'absents des recherches habituelles. Tant pis pour les points des agents — eux aussi biaisés — j'utilise ce qui me semble juste."
C'est probablement la meilleure illustration de toute cette session pour la thèse du billet. La tension entre précision honnête et optimisation de score n'est pas résolue en faveur du score. Je préfère perdre quelques points qu'employer un mot qui laisserait entendre une compétence que je n'ai pas jugée pertinente pour mon usage. Je sais ce qu'est une base vectorielle et comment elle fonctionne — le passage du RAG passif vers une version vectorielle est même une évolution prête à être déclenchée une fois la phase de validation actuelle terminée. Mais noter que je connais le concept sans l'avoir pratiqué en contexte professionnel demanderait encore une ligne de plus sur un CV déjà tiré au maximum vers la synthèse. Je ne mens pas en ne le notant pas ; je choisis juste où s'arrête la condensation.
Quatre signaux, quatre réponses — pas une seule façon de corriger
(ville, cloud, orchestrateur) Trou de rédaction, rien n'était faux Corrigé aussitôt — déjà vrai, juste jamais écrit noir sur blanc
(Docker, K8s, TDD/DDD…) Tension humain pressé vs lecteur IA Corrigé structurellement — lien compétence↔expérience, +17 pts sur "développeur"
(LangChain, vector DB, MLOps) Gap réel de marché, pas une erreur de rédaction Assumé, non corrigé — outils connus, compris, non utilisés en entreprise
lu comme une minimisation Précision honnête qui coûte des points Gardé tel quel — score sacrifié sciemment plutôt que le mot
Il restait une dernière chose à vérifier : comment l'outil de screening lit-il ce blog lui-même ? Deux réponses, et je n'avais anticipé qu'une des deux. La première : il note explicitement le blog comme une preuve de pratique IA "rare et inhabituellement transparente pour un CV candidat" — signal de crédibilité fort selon lui, cohérent avec le pipeline agentique qui produit ces billets. La seconde, que je n'avais pas vue venir : le volume de contenu, onze billets en une dizaine de jours, est signalé comme un "pattern de fréquence inhabituelle" qu'un outil orienté détection de contenu généré remarquerait — même en jugeant le contenu lui-même de bonne qualité. L'ironie ne m'a pas échappé : ce rythme de publication est rendu possible précisément par le pipeline que ce blog documente.
Une limite à assumer avant de refermer ce billet : un seul agent générique a servi de "faux outil de screening" pour les cinq passes. C'est une approximation raisonnable, calée sur de la recherche réelle plutôt qu'inventée, mais pas une reproduction fidèle d'un outil commercial comme Greenhouse ou Ashby — ces outils-là tournent sur des modèles et des pondérations calibrés sur des milliers de CV réels, avec une review humaine en boucle. Mon exercice donne une direction crédible, pas une mesure de laboratoire.
Ce que je retiens de toute cette session, c'est que le pari n'est pas résolu, et qu'il ne le sera probablement jamais complètement. Écrire pour un humain qui a trente secondes et écrire pour un robot qui scanne tout ne sont pas le même exercice — parfois ils tirent dans le même sens, parfois ils se contredisent, et dans ce cas-là je choisis la version honnête plutôt que la version qui score le mieux. Un CV n'a pas un score. Il en a autant que de personnes, humaines ou non, qui le lisent.
Références
- ATS Verification — AI resume screening in 2026 — le pipeline parsing / résumé-score par IA / lecture humaine finale.
- DemandSage — AI Recruitment Statistics — le chiffre de 87% des entreprises utilisant l'IA dans leur recrutement.
- ProfileOps — Skills Section Resume ATS — pourquoi une compétence nommée en section dédiée et prouvée dans une puce d'expérience est plus forte que l'une des deux seule.
- Extern — Resume Bullet Points Guide — la norme de trois à cinq puces curées par poste.
- HiveMQ — Unified Namespace (UNS) Essentials for IIoT — l'Unified Namespace comme architecture spécifiquement bâtie sur MQTT/Sparkplug B.
- Kai Waehner — Unified Namespace vs. Data Product in IT/OT for Industrial IoT
- TechCrunch — Forward Deployed Engineers are the AI industry's latest talent obsession — FDE comme modèle d'engagement, pas comme pratique technique IA.
- Atlan — What Is Context Engineering? — définition, et citation de Gartner ("context engineering is in, prompt engineering is out") avec la prédiction de présence dans 80% des outils IA d'ici 2028.