Festival Les Ondes Claires : 2 jours-homme pour sauver LCP, CLS et lisibilité
Vous finissez votre stage dans une agence qui livre le site du festival Les Ondes Claires (4 jours, 12 000 festivaliers attendus). La billetterie représente 78 % des recettes. Le client se plaint de lenteur sur mobile. Mesures PageSpeed sur un Android milieu de gamme en 4G : LCP 4,8 s, INP 340 ms, CLS 0,28, 3,4 Mo transférés, 62 requêtes. La page d'accueil charge un carrousel de cinq visuels PNG de 380 ko en moyenne, qui défile automatiquement toutes les 4 secondes. Trois graisses de Google Fonts sont appelées. Les chapôs sont en #999999 sur fond blanc, validé par la direction artistique. Les boutons du menu mesurent 30 px de haut. Il reste deux jours-homme de développement avant la mise en ligne, et la régie publicitaire du festival a déjà vendu deux emplacements sur la page d'accueil.
1. Priorisez les interventions techniques sur les deux jours restants. Justifiez chaque choix par son effet sur les Core Web Vitals et sur les recettes, et assumez ce que vous abandonnez.
Read the worked answer
Identifier l'élément LCP avant de coder. Sur ce type de page, le LCP est presque toujours le visuel principal du carrousel. Tant qu'il reste un PNG de 380 ko chargé en JavaScript, aucun réglage de police ne fera passer sous 2,5 s.
Lot 1 - le carrousel (≈ 0,5 jour, impact maximal). Remplacer les cinq PNG par un visuel unique en AVIF/WebP, en srcset/sizes (mobile 480 px, desktop 1 200 px), avec attributs width/height, fetchpriority="high" et préchargement. Effet attendu : ~1,9 Mo économisés, LCP divisé par deux environ, CLS quasi résolu. Supprimer les deux emplacements publicitaires du carrousel ou les déplacer sous la ligne de flottaison : ils sont vendus, mais un encart placé plus bas reste visible et n'écrase pas le LCP.
Lot 2 - le défilement automatique (≈ 0,2 jour). Il fait tourner un minuteur JavaScript (mauvais pour INP), déplace le contenu sous le doigt et n'est quasiment jamais utilisé. On le désactive ; s'il faut garder les 5 visuels, passer en grille statique ou en défilement manuel.
Lot 3 - polices et JS (≈ 0,5 jour). Deux graisses au lieu de trois, font-display: swap, preconnect vers le domaine de polices, defer sur les scripts non critiques. Poser aspect-ratio sur les images et réserver la hauteur du bandeau cookies pour finir de tuer le CLS.
Lot 4 - images sous la ligne de flottaison (≈ 0,3 jour). loading="lazy" et decoding="async" sur les pages accueil, programme, billetterie - les trois pages qui convertissent.
Ce que j'abandonne, et pourquoi. Pas de refonte du bundle CSS/JS, pas de migration de framework, pas de conversion des 40 pages secondaires, pas de suppression totale de Google Fonts (décision de la direction, à documenter comme dette). Avec 78 % des recettes sur la billetterie, chaque seconde gagnée sur l'accueil et le tunnel vaut plus qu'un site « propre » livré en retard. Je fixe un objectif réaliste et annoncé : LCP < 3 s et CLS < 0,1 à la livraison, le reste en phase 2 après le festival.
2. La direction artistique refuse de changer le #999999 et les boutons de 30 px. Traitez le désaccord : quels arguments techniques et quelles obligations citez-vous ?
Read the worked answer
Chiffrer plutôt que discuter. #999999 sur #FFFFFF donne un rapport de contraste d'environ 2,85:1. Le seuil WCAG 2.1 AA (repris par le RGAA 4.1, critère 3.2) est de 4,5:1 pour du texte normal, 3:1 pour du grand texte. Le gris le plus clair acceptable sur blanc est à peu près #767676 (4,54:1) : c'est un point de négociation concret, pas une opinion esthétique. Je propose de garder #999999 pour les filets et les légendes décoratives, et de passer les chapôs en #595959, ce qui préserve la hiérarchie visuelle voulue par la DA.
Sur les boutons. 30 px de haut est techniquement conforme au minimum WCAG 2.2 (critère 2.5.8, cible de 24×24 px CSS) : je ne peux donc pas parler de non-conformité. Mais le recommandé est 44×44 px, et le contexte réel est un festival en extérieur, en plein soleil, avec une main qui tient une bière ou un sac. J'argumente en usage et en accessibilité motrice, pas en norme.
Le cadre juridique, sans surjouer. Le RGAA s'impose aux sites des services publics ; le festival est une association. Je vérifie donc deux choses : les clauses du cahier des charges avec la collectivité qui subventionne, qui impose souvent l'accessibilité contractuellement, et le périmètre de l'European Accessibility Act applicable depuis le 28 juin 2025, dont l'interprétation pour un service de billetterie en ligne doit être confirmée - je pose la question au juridique au lieu de trancher seul.
Sortie de crise. Je ne renvoie pas la DA à ses obligations un vendredi soir : je produis deux maquettes côte à côte, avec les ratios calculés, un test sur téléphone en extérieur, et une note d'une page arbitrée par le chef de projet. Si la DA maintient son choix, la décision est tracée par écrit avec le risque associé.
3. Comment vérifiez-vous, avant la mise en ligne, que les correctifs ont réellement amélioré les choses ?
Read the worked answer
Séparer laboratoire et terrain. Lighthouse ou PageSpeed en laboratoire donne un diagnostic reproductible mais optimiste : il faut aussi regarder les données de terrain (CrUX / Search Console) quand elles existent. Pour un site neuf, on simule : WebPageTest avec un profil Android milieu de gamme et un débit 4G bridé, plusieurs passages, en notant l'élément LCP identifié par l'outil - pas seulement le score global.
Protocole concret en une heure.
- Tester sur un vrai téléphone d'entrée/milieu de gamme, pas seulement sur le portable du développeur en Wi-Fi.
- Relever LCP, INP, CLS sur les trois pages clés (accueil, programme, billetterie), avant/après, en notant l'élément LCP et la cause du décalage.
- Vérifier que rien n'a cassé : images qui ne s'affichent plus, carrousel résiduel, bandeau cookies qui recouvre le bouton « acheter ».
- Contrôler le poids transféré et le nombre de requêtes (objectif : passer sous 1,5 Mo et 40 requêtes sur l'accueil).
Le piège à éviter. Annoncer « LCP 1,9 s » sur la base d'un test unique en Wi-Fi. Les Core Web Vitals se jugent au 75e percentile des chargements réels : un chiffre de laboratoire est une preuve de progrès, pas une garantie. Je prévois donc un relevé à J+3 après ouverture de la billetterie, quand le trafic réel arrive, et une capture d'écran comparative envoyée au client : c'est aussi ce qui protège l'agence en cas de contestation.