Audit de vitesse avant refonte : ne reconstruis pas sur des fondations cassées

Tu prépares une refonte, et la tentation est de partir d'une page blanche, tout repenser, tout reconstruire. Avant ça, fais une chose, audite la vitesse de ton site actuel. Pas après, avant. Parce que refondre sans connaître l'état de tes fondations, c'est risquer de reconstruire un bel étage sur des murs fissurés, et de te retrouver avec un site neuf aussi lent que l'ancien, sans comprendre pourquoi.

Un audit de vitesse avant refonte sert deux choses. Il identifie les problèmes de fond, ceux qui se cachent sous la surface et qu'une refonte esthétique emporterait sans les voir. Et il pose une mesure de référence, sans laquelle tu seras incapable de prouver que ta refonte a amélioré quoi que ce soit. Voici pourquoi ces deux raisons sont décisives, et la checklist à passer avant de toucher au premier pixel.

Une refonte change tout en même temps, donc masque les causes

Le piège d'une refonte, c'est qu'elle change tout d'un coup, le design, le code, la structure, parfois l'hébergement. Et quand tout change en même temps, tu perds la capacité d'attribuer quoi que ce soit. Si le nouveau site est plus rapide, tu ne sais pas grâce à quoi. S'il est plus lent, tu ne sais pas à cause de quoi. Tu as remplacé un état que tu ne connaissais pas par un autre que tu ne comprends pas mieux.

C'est pour ça que la mesure de référence, prise avant, est cruciale. Elle te donne un point de comparaison. Sans elle, "le site est plus rapide maintenant" est une impression, pas un fait, et tu n'as aucune preuve que les semaines de refonte ont servi la performance plutôt que de la dégrader.

L'autre raison est plus sournoise. Beaucoup de problèmes de vitesse ne sont pas dans le design, ils sont sous le design, dans le chemin de rendu, dans le serveur, dans la base de données. Une refonte qui se concentre sur l'apparence ne les voit pas, donc ne les corrige pas, donc les emporte intacts dans le nouveau site. Tu as payé une refonte, et le vrai frein est toujours là, parce qu'il n'a jamais été ni mesuré ni nommé.

Et le découvrir après le lancement est le pire scénario. Une fois la refonte en ligne, si le site est toujours lent, tu dois rouvrir un chantier que tu croyais fermé, sur une base de code neuve que ton équipe maîtrise encore mal, avec un budget déjà consommé et la fatigue d'un projet qu'on pensait terminé. Mesurer avant, c'est traiter le frein quand c'est le moins cher et le moins douloureux, sur l'ancien site que tu connais, plutôt que de le redécouvrir au plus mauvais moment, sur le nouveau. Un problème de fond ne disparaît pas parce qu'on a changé la façade, il attend juste, et il coûte plus cher chaque fois qu'on repousse sa découverte. C'est pourquoi je considère qu'une refonte lancée sans audit de vitesse préalable est une faute de méthode : avant de toucher au premier pixel, deux livrables doivent exister, une mesure de référence prise sur le terrain et une liste nommée des vrais freins. Sans eux, tu ne fais pas une refonte, tu fais un pari coûteux dont tu ne sauras jamais s'il a payé.

Les freins qu'une refonte n'aurait jamais vus

Deux cas de mes propres produits montrent à quel point le vrai problème se cache sous la surface.

• Zovalide, le frein invisible dans la base de données. À vide, tout paraissait correct. Sous charge réelle, le temps de réponse au 95e centile montait à 32 secondes, à cause de requêtes non indexées. Une refonte du design n'aurait jamais touché ça, le problème n'était pas à l'écran, il était dans la base. Poser les index a ramené ce p95 à 1,2 seconde. Une refonte aveugle aurait reconstruit l'interface par dessus le même goulot.
• Copyboost, le frein dans le chemin de rendu. Le ralentissement venait de neuf polices chargées sans préchargement, qui retardaient l'affichage. Une refonte esthétique aurait probablement reconduit le même schéma de polices, et emporté le problème dans le nouveau site. Le corriger a fait passer le score de 57 à plus de 75, sans rien refondre.

La leçon est nette. Dans les deux cas, le frein était invisible à l'oeil et absent des maquettes. Seul un audit de vitesse, qui regarde sous la surface, les révèle. Refondre sans cet audit, c'est rebâtir au dessus d'eux.

La checklist d'avant refonte, quatre livrables avant le premier pixel

Avant de lancer quoi que ce soit, produis ces quatre éléments.

1. La mesure de référence, sur le terrain. Relève tes indicateurs actuels au 75e centile, sur données réelles, mobile et desktop. C'est le point de comparaison sans lequel tu ne pourras rien prouver après.
2. La liste nommée des vrais freins. Identifie d'où vient la lenteur actuelle, chemin de rendu, serveur, base de données, ressources lourdes. Nomme chaque frein, pour que la refonte ait l'obligation de le traiter.
3. La décision garder ou supprimer. Pour chaque frein, décide s'il faut le corriger, le supprimer, ou le remplacer. C'est ça, partir sur des fondations saines, pas une page blanche posée sur les mêmes failles.
4. La cible mesurable à battre. Fixe le chiffre que la refonte devra dépasser, à partir de ta mesure de référence. Sans cible, tu ne sauras pas si tu as réussi.

Où tu commences : la mesure de référence, parce que tout le reste s'y rapporte. On ne juge une refonte qu'en la comparant à un avant qu'on a pris la peine de mesurer.

Ce qu'il faut retenir

Auditer la vitesse de ton site avant de le refondre, et pas après, t'évite deux échecs coûteux, reconstruire au dessus de freins invisibles, et être incapable de prouver que la refonte a servi. Beaucoup de problèmes de vitesse se cachent sous le design, dans le serveur ou la base, là où sur Zovalide un index oublié coûtait 32 secondes sous charge, invisible dans toute maquette. Avant de toucher au premier pixel, pose une mesure de référence et une liste nommée des vrais freins. Si tu veux cet audit avant de te lancer, savoir ce qui est cassé et ce qu'il faut absolument corriger, c'est exactement ce que pose le diagnostic performance.