04 — Barème et niveaux de difficulté

Répartition des points

Malus : −2 points par fonctionnalité ou élément visuel supprimé au lieu d'être optimisé. La contrainte d'iso-rendu n'est pas négociable : un site vide a d'excellentes métriques.

Les trois niveaux

Les problèmes du site sont répartis en trois niveaux de difficulté. Vous n'êtes pas obligés de tous les trouver pour avoir une bonne note, mais les niveaux supérieurs départagent.

Niveau 1 — Visible à l'œil nu (≈ 60 % des problèmes)

Se repèrent en triant l'onglet Réseau par taille et en lisant les opportunités Lighthouse. Le code fautif est lisible et commenté.

Compétences évaluées : lire une cascade réseau, comprendre le rapport entre taille source et taille d'affichage, connaître les attributs HTML de performance.

→ Les trouver tous vaut 4 points sur 6. C'est aussi là que se trouve l'essentiel du gain mesurable : ne négligez pas ce niveau au prétexte qu'il est facile.

Niveau 2 — Demande un profil d'exécution (≈ 30 %)

Ne se voient pas en lisant le code : il faut enregistrer une session dans le panneau Performance, trier l'onglet Bottom-Up et remonter la pile d'appels. Le code fautif peut être minifié, d'apparence tierce, et son effet peut résulter de l'interaction entre deux morceaux de code anodins séparément.

Compétences évaluées : lire un flamegraph, identifier un reflow forcé, reconnaître une complexité quadratique, savoir déplier et juger une dépendance.

→ +1,5 point.

Niveau 3 — Conditionnel (≈ 10 %)

Un problème au moins ne se manifeste que sous certaines conditions et après un certain délai. Il est invisible dans un audit standard. Le trouver suppose d'avoir remarqué une incohérence entre deux mesures et d'avoir cherché pourquoi.

Compétences évaluées : rigueur méthodologique, enregistrement long, variation systématique des conditions de test, lecture de code volontairement obscurci.

→ +0,5 point, et la mention « a compris ce qu'est un audit ».

Ce qui rapporte des points

• Une mesure avant, une mesure après, dans les mêmes conditions.
• Une capture d'écran qui prouve ce que vous affirmez.
• Le bon vocabulaire : chaîne critique, reflow forcé, long task, LCP.
• Reconnaître qu'une optimisation n'a rien changé. C'est un résultat.
• Repérer une optimisation impossible ici (en-têtes HTTP, build) et expliquer ce que vous feriez ailleurs.
• Une correction qui traite la cause plutôt que le symptôme.

Ce qui en coûte

• « J'ai optimisé les images » sans chiffre.
• Une capture Lighthouse sans indication du profil (mobile ? desktop ?).
• Supprimer du contenu ou une fonctionnalité pour gagner des points.
• Recopier le guide de résolution sans l'appliquer au cas présent.
• Une archive qui traîne des node_modules ou des fichiers de travail.
• Un historique de fork réduit à un commit « optimisations ».
• Mesurer en file://, ou avec le cache actif.

Rendu

Une archive nom-prenom.zip déposée sur Moodle, contenant :

• le site corrigé, complet et fonctionnel ;
• votre rapport avant/après, en Markdown ou en PDF, à la racine ;
• les captures d'écran dans un dossier audit/.

Le rapport doit indiquer l'adresse de votre site déployé et celle de votre fork : PageSpeed Insights n'analysant que des URL publiques, la première permet de vérifier vos relevés « après », et la seconde de lire l'historique de vos commits.