Le diagnostic à examiner doit être explicite
Supposons que vous recrutiez un développeur chargé de la performance web. Vous lui présentez une situation hypothétique : un test de laboratoire indique un chargement satisfaisant, tandis que des données utilisateurs signalent une interaction lente. Nous proposons d’examiner comment le candidat explique ce qu’il peut comparer, puis choisit une vérification. Un raisonnement étayé mérite un approfondissement technique, une conclusion sans vérification appelle une demande de justification, et des données insuffisantes doivent laisser le diagnostic ouvert.
Cette distinction change ce que vous attendez de l’entretien. Une solution annoncée immédiatement ne vous permet pas encore de comprendre pourquoi le candidat la juge pertinente. Demandez-lui plutôt de relier les éléments observés à son hypothèse, puis d’expliquer quel résultat pourrait l’amener à changer d’avis. Vous pourrez ainsi examiner sa démarche sans confondre assurance dans la réponse et justification technique.
Chaque mesure doit être replacée dans son contexte
Dans Web Vitals, Google distingue chargement, interactivité et stabilité visuelle. L’Interaction to Next Paint (INP) mesure l’interactivité. Dans notre situation hypothétique, un résultat favorable sur le chargement ne renseigne donc pas directement sur la lenteur signalée après une interaction. Le candidat doit d’abord préciser le phénomène qu’il cherche à expliquer.
Google explique également que les mesures de laboratoire sont réalisées dans des conditions contrôlées pour permettre la reproduction du test. Les données de terrain forment, quant à elles, une distribution de mesures recueillies auprès des utilisateurs. Cette distinction ne rend pas une famille de mesures supérieure à l’autre : dans Web Vitals, Google précise que les mesures de laboratoire ne remplacent pas les mesures de terrain.
MDN apporte un éclairage complémentaire : sa documentation présente le suivi de la performance auprès des utilisateurs comme particulièrement adapté à l’observation des tendances dans le temps, et les tests synthétiques comme adaptés à la détection des régressions pendant le développement. Leur utilité dépend donc de la question posée.
Pour préparer l’évaluation, joignez aux résultats ce que vous connaissez des conditions de mesure : page examinée, appareil, parcours testé, période et population observée. Si une information manque, laissez cette absence visible dans le dossier remis au candidat. Vous pourrez examiner s’il la repère et s’il explique en quoi elle limite sa conclusion, plutôt que lui demander de deviner les conditions du test.
Le candidat doit expliquer comment il confronte les résultats
Précisons notre exercice hypothétique. Le test de laboratoire porte sur le chargement d’une page sur ordinateur, sans interaction après son ouverture. Les données de terrain concernent des interactions sur cette page depuis un mobile. Elles signalent un INP lent, mais le dossier ne précise ni l’élément utilisé ni le moment de l’interaction. Ces résultats décrivent des conditions et des phénomènes différents.
Demandez au candidat de préparer une courte note qui sépare ce qu’il constate, ce qu’il suppose et la prochaine vérification qu’il propose. Une réponse exploitable doit expliquer pourquoi les résultats fournis ne suffisent pas à établir une contradiction. Le candidat devrait également préciser les informations nécessaires pour rechercher l’interaction concernée, au lieu de choisir arbitrairement une action sur la page.
Dans sa documentation sur le diagnostic de terrain, Google recommande justement de relever l’élément concerné, le type d’interaction et son moment pour diagnostiquer un INP lent. Nous proposons d’utiliser cette démarche documentée comme support de discussion : quelles informations le candidat demanderait-il, et que ferait-il une fois ces informations obtenues ?
La suite doit rester conditionnelle. Dans sa documentation sur l’optimisation de l’INP, Google relie une interaction lente identifiée à sa reproduction en laboratoire, avant son optimisation. Le candidat peut donc proposer de reproduire l’action concernée dans des conditions explicites. Demandez-lui ce qu’il chercherait à observer pendant cette reproduction et comment il vérifierait que le problème examiné correspond bien au signal de terrain.
Si les résultats divergent encore après ce rapprochement, sa réponse doit nommer les différences qu’il souhaite examiner et expliquer quelles vérifications il effectuerait pour en évaluer l’effet sur les résultats. S’ils concordent, demandez-lui comment il poursuivrait l’analyse : constater une interaction lente dans les deux contextes ne suffit pas à en déterminer la cause. La concordance permet d’organiser la suite de l’investigation, sans transformer une hypothèse en explication acquise.
Les vérifications proposées rendent le raisonnement examinable
Pour interpréter la note, partez du lien entre chaque observation et l’action proposée. Une demande de données supplémentaires devient utile lorsque le candidat explique quelle incertitude elle permettrait de réduire. Une vérification devient examinable lorsqu’il décrit ce qu’il observerait et les conséquences possibles pour son hypothèse.
Google documente l’enregistrement d’une trace pour distinguer l’attente avant traitement, l’exécution des gestionnaires d’événements et le travail de rendu. Si le candidat propose cette analyse, faites examiner par un évaluateur technique la manière dont il relie la trace à l’interaction reproduite. Nommer une tâche coûteuse ne démontre pas automatiquement qu’elle explique toute la lenteur observée.
Vous pouvez ensuite lui demander ce qu’il ferait si la trace ne confirmait pas son explication initiale. L’intérêt de cette relance tient à la réponse obtenue : précise-t-il une autre vérification, reconnaît-il que les éléments restent insuffisants, ou conserve-t-il sa conclusion sans expliquer pourquoi ? Une hypothèse non confirmée laisse le diagnostic ouvert. Examinez la manière dont le candidat traite cette incertitude avant de porter un jugement sur sa conclusion.
L’absence de données de terrain ne doit pas non plus rendre l’exercice artificiellement impossible. Google précise qu’elle n’empêche pas de chercher des interactions lentes en laboratoire. Dans ce cas, demandez au candidat de justifier les parcours qu’il choisirait d’examiner et de distinguer la reproductibilité des problèmes en laboratoire de leur fréquence chez les utilisateurs, qui reste à établir.
Nous proposons ces questions pour rendre le raisonnement accessible à l’examen technique. Elles ne constituent ni un barème universel ni un test dont la valeur prédictive serait établie. Votre appréciation doit porter sur les explications et les vérifications effectivement présentées, au regard du dossier disponible.
La décision dépend des compétences effectivement démontrées
À l’issue de cet échange, déterminez ce qu’il faut approfondir. Si le candidat relie ses observations à une hypothèse et propose une vérification dont il explique comment interpréter les résultats, faites examiner cette démarche avec votre évaluateur technique. Si sa réponse reste ambiguë, demandez-lui de préciser le lien manquant avant de conclure.
Lorsque les données disponibles ne permettent pas de départager les explications, obtenez les éléments nécessaires ou adaptez l’exercice. Suspendez alors le jugement sur le diagnostic, plutôt que d’exiger une certitude que le dossier ne permet pas. Cet examen porte sur une compétence technique délimitée : il ne suffit pas, à lui seul, à valider l’ensemble du recrutement.
Sources
Google, web.dev : Why lab and field data can be different (and what to do about it)
MDN : Performance Monitoring: RUM vs. synthetic monitoring
Google, web.dev : Debug performance in the field
Google, web.dev : Optimize Interaction to Next Paint
Google, web.dev : Manually diagnose slow interactions in the lab
