La plupart des équipes abordent l’optimisation des Core Web Vitals comme un sprint sans fin. On ouvre Lighthouse, on repère un LCP rouge, on crée un ticket Jira « améliorer le LCP », on y ajoute dix sous-tâches vagues, et trois semaines plus tard le score n’a pas bougé. Le problème n’est pas la compétence technique. C’est l’absence de flux.
Un board Kanban avec des colonnes explicites et une limite de travail en cours inverse la logique. On arrête de pousser du code en espérant un miracle. On tire une seule carte à la fois, on la termine jusqu’à ce que le critère de succès soit atteint, et on mesure avant de passer à la suivante. Voici comment on a appliqué cette méthode sur des projets Next.js, Remix et WordPress headless, et pourquoi elle nous a fait gagner plus de temps que n’importe quel outil de monitoring.
Le piège de la checklist de performance
Les audits Lighthouse génèrent des dizaines d’opportunités : « Éliminez les ressources bloquantes », « Réduisez le JavaScript inutilisé », « Préconnectez les origines ». La tentation est grande de tout mettre dans un backlog et de répartir les tâches entre trois développeurs. Résultat : trois branches mergées plus tard, le LCP a pris 300 ms.
Pourquoi ? Parce qu’une checklist aplatie ignore les dépendances. Réduire le JavaScript inutilisé sur un bundle Next.js peut accélérer le TBT, mais si le HTML initial met 1,2 seconde à arriver parce que le TTFB est à 800 ms, l’effort est invisible dans le champ LCP. Le Kanban oblige à séquencer les tâches en fonction de leur impact cumulé. On ne passe pas à « réduire le CSS inutilisé » tant que la carte « TTFB sous 400 ms » n’a pas bougé le 75e percentile dans le Chrome User Experience Report.
💡 Conseil : Quand vous estimez une carte d’optimisation Web Vitals, demandez-vous toujours « cette tâche peut-elle produire un gain mesurable si la précédente n’est pas résolue ? ». Si la réponse est non, placez-la derrière.
Les colonnes qui remplacent la liste de courses
On utilise quatre colonnes.
La première, « Investiguer », accueille les anomalies remontées par la Search Console et les alertes CrUX. Pas de ticket tout prêt. Une carte correspond à un constat brut : « INP à 480 ms sur mobile pour les pages produit avec filtre à facettes ». Tant qu’on n’a pas reproduit la lenteur, identifié la cause racine, et formulé une hypothèse d’amélioration, la carte ne bouge pas.
La deuxième colonne, « Prêt », contient les cartes qui ont une hypothèse vérifiable et une condition d’acceptation chiffrée. Exemple : « Régression INP causée par le recalcul des facettes après chaque clic. Solution : blocage du 2e clic tant que le DOM n’est pas stabilisé. Objectif : INP à 75e percentile < 180 ms. »
La troisième colonne, « En cours », a une limite de WIP fixée à 1. Une seule optimisation à la fois, déployée sur un environnement de staging instrumenté avec web-vitals.js. On compare les distributions avant/après sur 72 heures de données réelles.
La dernière colonne, « Terminé », ne contient que les cartes dont l’objectif a été validé sur les données de terrain à 28 jours glissants, pas sur un rapport Lighthouse ponctuel.
Lire aussi dans la catégorie optimisation core web vitals pour d’autres méthodes de mesure continue.
Un WIP à 1 ou rien
Deux commits en parallèle sur le JavaScript inutilisé et le lazy-loading, c’est zéro traçabilité quand le LCP bouge. WIP à 1, et la priorisation se fait à l’entrée : quelle métrique touche le plus de pages à trafic organique significatif sur 30 jours ? Le reste attend.
Traiter le LCP comme une tâche finie, pas un chantier permanent
LCP passé de 3,4 s à 2,7 s après déploiement. Trois jours plus tard, le 75e percentile remonte à 3,1 s parce qu’une campagne pub a changé la provenance géographique du trafic.
La colonne Terminé ne devrait contenir que des gains résilients. Pour ça, on introduit un critère de stabilité : la métrique cible doit rester dans la fourchette définie pendant au moins 14 jours avant qu’on archive la carte. Si une fluctuation du trafic casse le résultat, la carte retourne en « Prêt ».
Concrètement, pour une page dont le LCP dépend d’une image chargée via un CDN, le simple fait d’ajouter un fetchpriority="high" ne suffit pas. La carte n’est terminée que quand on a aussi vérifié que le TTFB depuis la zone géographique majoritaire ne dépasse pas 400 ms. Ce couplage TTFB + fetch priority, c’est le genre de dépendance que la checklist masque et que le Kanban expose.
Même logique de critères chiffrés quand on compare Claude Code et Cursor : on n’évalue pas tout en même temps.
Ce que le Kanban change dans la chasse au INP
L’INP, contrairement au LCP, est corrélé aux interactions utilisateur : clics, touchers, entrées clavier. Un board Kanban force à associer chaque carte d’INP à un événement précis, pas à une page entière.
On isole l’événement. Sur un site avec un panier dynamique en React, on a ouvert une carte « INP panier : le clic sur le bouton quantité déclenche un calcul de prix qui prend 220 ms ». On a reproduit l’interaction avec le profileur Chrome, constaté un re-render de l’arbre entier, migré l’état local vers un store léger. L’INP est passé à 90 ms.
L’étape suivante n’a pas été de continuer à traquer chaque bouton. On a tiré la carte suivante, qui concernait le lazy-loading des sections Below the fold, une tâche qui, elle, impactait le LCP. On ne passe pas trois semaines sur l’INP en oubliant que le TTFB a dérivé.
Le piège des données lab sans données terrain
Une carte Kanban basée uniquement sur un score Lighthouse est une fausse promesse. Lighthouse simule un Moto G4 sur une connexion throttled ; il ne voit pas le vrai trafic mobile d’une zone rurale en 4G instable. On a vu trop de cartes marquées Terminé parce que le lab passait au vert, alors que les données terrain CrUX restaient rouges.
Notre colonne Investiguer inclut systématiquement un lien vers le rapport CrUX de la page ou du groupe de pages. Si l’écart entre le lab et le terrain dépasse 20 %, la carte n’est pas acceptée en colonne Prêt. Elle est renvoyée avec une note : « l’écart lab/terrain est inexpliqué ». Ça peut cacher un problème de rendu hybride, de state management lourd, ou d’hydration partielle non détectée en local.
On a aussi découvert que certaines optimisations passaient en lab mais ne se reflétaient jamais sur le terrain, à cause de la façon dont le bundle hydratait des composants React. Remplacer un contexte global par un store comme Zustand a réduit la taille du JavaScript évalué et l’écart entre lab throttlé et mobile réel.
Questions fréquentes
Comment estimer la durée d’une carte d’optimisation quand on ne connaît pas la cause racine ?
On ne l’estime pas. La colonne « Investiguer » a une durée plafond : trois jours ouvrés. Si la cause racine n’est pas identifiée à l’issue, la carte est fragmentée en hypothèses plus petites ou jointe à une carte existante similaire. L’erreur consiste à transformer l’investigation en ticket de développement indistinct.
Peut-on utiliser un Kanban pour les Core Web Vitals si l’équipe fait déjà du Scrum ?
Oui, le Kanban peut cohabiter avec un Sprint Scrum. Il suffit de dédier un board physique ou digital (comme un tableau Notion ou un projet GitHub) uniquement pour les métriques Web Vitals, distinct du backlog produit. Le flux tiré ne remplace pas la planification d’itération, il la protège en évitant que les bugs de performance soient noyés dans les user stories.
