On a failli recruter un lead front dont le CV faisait saliver le CTO. Cinq ans de React, trois migrations majeures, un GitHub propre. Il a calé sur une question qu’on pensait basique : « Dans ce waterfall LightHouse, qu’est-ce qui bloque le FCP ? » Il n’avait jamais ouvert l’onglet Performance de Chrome. Il codait vite, très vite, mais il n’avait aucune idée de ce que son code produisait côté navigateur. Et c’est exactement là que les processus RH passent à côté du vrai talent technique.
Les ressources humaines et la technologie évoluent ensemble, mais pas au même rythme. Les équipes de recrutement appliquent des matrices de compétences pensées pour l’ère du CMS monolithique, alors que le métier exige désormais une intelligence du rendu, du crawl et du Core Web Vitals. Résultat : on recrute des profils qui savent répondre à des tests algorithmiques mais qui ne savent pas pourquoi une balise canonique renvoie vers une URL en 302. On mesure le nombre d’années sur un framework au lieu de mesurer la capacité à réduire un INP de 300ms en différant un script tiers. Cette obsession du CV empêche de voir ce qui fait vraiment la valeur d’un développeur ou d’un SEO technique en 2026.
Le diplôme ne lit pas un waterfall
Pendant des années, les départements RH ont utilisé le diplôme comme proxy de compétence. Une école d’ingénieur, un master informatique, et on cochait la case. Sauf que les algorithmes de classement de Google n’ont jamais demandé à voir un diplôme avant de crawler un site. Ce qui compte, c’est la propreté du code, la gestion des ressources, l’architecture de l’information. Et ces compétences s’acquièrent en lisant des logs serveur, en instrumentant des metriques RUM, en épluchant la Search Console à 23h. Pas forcément sur les bancs d’une école.
On a vu des autodidactes diagnostiquer une erreur d’hydration partielle en quinze minutes là où un bac+5 alignait les console.log sans comprendre pourquoi son composant clignotait. La différence ? Le premier avait passé des nuits à débuguer des sites en production, à confronter la doc de Next.js aux vrais logs Vercel. Le second avait validé des projets cadrés où tout fonctionnait sur localhost. Ce fossé entre la maîtrise théorique et la compréhension profonde de la chaîne de rendu, les grilles salariales ne le captent pas. Pire, elles le pénalisent en filtrant sur le niveau d’études.
L’optimisation des Core Web Vitals est un exemple typique de ce décalage. Combien de recruteurs savent évaluer la capacité d’un candidat à identifier un layout shift causé par une police système mal chargée ? Aucun ne pose la question. Pourtant, c’est ce genre de micro-décision qui sépare une page qui convertit d’une page qui frustre. La compétence est technique, elle est mesurable, et elle n’a strictement rien à voir avec un intitulé de poste.
Le marché recrute des frameworks, pas des cerveaux
Une annonce classique demande « 5 ans d’expérience React ». Si vous prenez le temps de regarder ce qui se cache derrière cette exigence, vous découvrez en général que l’entreprise a un problème de performance sur sa SPA, un LCP qui traîne au-dessus de 4 secondes, et qu’elle espère que le nouveau senior va résoudre ça par magie. Sauf que le problème ne vient probablement pas d’un manque de connaissance de useEffect, mais d’une stratégie de chargement qui envoie 2 Mo de JavaScript non splitté au premier rendu.
Recruter sur un framework, c’est comme choisir un pilote parce qu’il possède un volant. La question pertinente, c’est ce qu’il fait avec. Sait-il découper son bundle pour ne livrer que le code critique au premier affichage ? A-t-il déjà mis en place du streaming SSR sur une fiche produit e-commerce ? Peut-il expliquer la différence entre fetchPriority et preload, et quand utiliser l’un plutôt que l’autre ? Tant que les fiches de poste aligneront des logos de bibliothèques au lieu de poser ces questions, on continuera de recruter à côté de la plaque.
Un cas d’école : le choix d’un outil de state management. Une boîte qui migre vers React va naturellement chercher un développeur qui maîtrise Redux, parce que c’est ce qui traîne dans les descriptions de poste depuis 2017. Mais si son vrai besoin, c’est une interface rapide avec peu d’états partagés, Zustand est souvent un bien meilleur levier. Simple, peu de boilerplate, bundle minime. Un candidat qui propose Zustand plutôt que Redux en argumentant sur la taille du bundle et l’impact sur le LCP n’aura pas moins de valeur que l’expert Redux. Il en aura plus. Mais pour le voir, il faut que les RH et le CTO évaluent la pertinence du raisonnement, pas la correspondance exacte avec une stack prédéfinie.
L’IA ne remplace pas le talent, elle le révèle
Avec l’arrivée de GitHub Copilot, puis de Claude Code, le code « syntaxique » se génère de plus en plus vite. Ce qui était chronophage devient quasi instantané. On tape un commentaire, on obtient une fonction. Les recruteurs pourraient en déduire que le métier de développeur est en train de disparaître. C’est l’inverse. La partie facile du métier s’automatisant, ce qui reste, c’est la compréhension du système. Savoir pourquoi une suggestion de l’IA casse le SSR. Savoir lire le code généré comme on lit un pull request d’un junior, avec un regard critique sur la performance, la sécurité, l’indexabilité.
La compétence distinctive, c’est la capacité à dialoguer avec l’outil sur un plan d’architecture. Comparer Claude Code et Cursor IDE ne consiste pas à savoir lequel tape le code le plus vite, mais à comprendre leurs différences de modèles de contexte, leur capacité à raisonner sur une codebase entière, à proposer des refactorings qui réduisent le TTFB au lieu de l’augmenter. Un développeur qui maîtrise ce dialogue-là vaut cinq développeurs qui tapent plus vite que leur autocomplétion. Mais pour le reconnaître, il faut un processus de recrutement qui évalue la prise de décision technique, pas la vélocité de frappe.
Ce que les RH devraient mesurer (et ne mesurent pas)
Les entreprises tech les plus performantes ont basculé depuis longtemps vers des évaluations sur cas réels. Elles vous donnent un repo avec un LCP à 3.9s, une Search Console pleine de « Détectée, actuellement non indexée », et vous demandent ce que vous faites. Pas de QCM, pas de test de personnalité, pas de « où vous voyez-vous dans cinq ans ». Un problème concret, un accès aux DevTools, et une heure pour proposer une solution. Ce dispositif filtre immédiatement ceux qui ont une compréhension systémique de la chaîne de rendu.
Pourtant, la majorité des processus restent basés sur des entretiens où l’on demande la différence entre useMemo et useCallback sans jamais poser la question qui fâche : « Combien de kilooctets votre composant injecte-t-il dans le thread principal au montage ? » La différence entre les deux approches, c’est qu’on recrute un exécutant dans le premier cas, et un ingénieur dans le second. Une équipe capable de trancher un débat technique avec des métriques plutôt qu’avec des opinions, c’est une équipe qui avance deux fois plus vite.
Quand on cherche un SEO technique, le décalage est encore plus criant. On demande « connaissez-vous les Core Web Vitals ? » comme si on demandait « savez-vous lire ? ». La réponse est toujours oui. La vraie question serait : « Décrivez-moi la dernière fois où vous avez fait gagner plus de 500ms de LCP sur un site en production, et ce que vous avez changé dans la config du serveur ou le bundle JS. » Là, la moitié des candidats regardent leurs chaussures. L’autre moitié se met à parler concrètement de lazy-loading natif, de fetchpriority="high" sur le LCP image, de loading="eager" conditionnel. Et c’est elle qu’on veut.
Le talent, c’est de savoir désapprendre
L’ère numérique évolue si vite que le talent ne consiste plus seulement à accumuler des connaissances, mais à désapprendre activement les pratiques obsolètes. Un SEO formé en 2015 vous parlera encore de densité de mots-clés, vous déconseillera le JavaScript côté client par principe, et vous recommandera des silos de contenu en pensant que Google lit votre site comme un plan thématique. Ce profil était compétent il y a dix ans. Aujourd’hui, il peut faire plus de mal que de bien en appliquant des recettes qui ne tiennent pas compte du rendu dynamique et des signaux utilisateurs.
Désapprendre, c’est accepter que le noindex en meta robots ne suffit plus quand Google explore votre site comme un navigateur headless. Désapprendre, c’est arrêter de croire que le poids de la page n’a pas d’importance parce que « les connexions sont rapides aujourd’hui » (un INP médiocre sur mobile vous prouvera le contraire en une session). C’est cesser de recommander un framework parce qu’il est populaire et commencer à le choisir en fonction de son impact sur le LCP et le TTFB. Les RH qui comprennent cela cherchent des profils capables de remettre en cause ce qu’ils savent, pas des encyclopédies.
C’est un basculement difficile pour les recruteurs, car il n’y a pas de certification « désapprentissage continu ». Personne n’affiche sur LinkedIn une compétence en « capacité à abandonner une stack qui dégrade mes métriques ». Et pourtant, c’est probablement le plus solide prédicteur de performance à long terme dans les métiers techniques du web.
Questions fréquentes
Le télétravail a-t-il modifié la façon d’évaluer le talent technique ?
Oui, et pas toujours en bien. En remote, beaucoup d’entreprises ont renforcé les tests chronométrés et les exercices de code en ligne, qui mesurent surtout la performance sous stress. Les vrais talents s’expriment mieux quand on leur confie un diagnostic asynchrone sur une vraie codebase, avec le temps de réfléchir. C’est dans la durée et la profondeur de l’analyse qu’on repère celui qui va faire la différence sur un LCP récalcitrant.
Faut-il continuer à exiger un diplôme pour un poste de développeur front en 2026 ?
Le diplôme peut rester un indicateur de rigueur, mais il ne doit plus être un filtre bloquant. Nous avons vu des profils issus de bootcamps ou entièrement autodidactes avoir une compréhension bien plus fine du rendu navigateur que certains ingénieurs diplômés. La question n’est pas le titre, c’est le temps passé les mains dans les DevTools. Si le processus de recrutement ne sait pas évaluer ça, exiger un master, c’est juste un aveu de faiblesse méthodologique.
Les IA génératives vont-elles réduire l’importance des développeurs seniors ?
Elles réduisent la pénibilité des tâches répétitives, ce qui force les développeurs à monter en compétence sur la conception et le diagnostic. Un développeur qui ne fait que traduire des maquettes en JSX est effectivement menacé. Un développeur qui utilise l’IA pour prototyper plus vite, mais qui relit le code généré en vérifiant l’impact sur le LCP, l’INP et l’indexabilité, devient plus précieux que jamais. L’IA agit comme un accélérateur de valeur pour ceux qui savent déjà où ils vont.
