Audit technique site web avant refonte : la méthode

On m'a demandé l'an dernier de faire évoluer un site que je n'avais pas construit. Le client voulait ajouter une fonctionnalité, budget serré, délai court. J'ai lancé mon audit habituel avant de dire oui, et en une demi-journée j'ai su que le devis d'évolution qu'il avait en tête était impossible : le code n'avait aucun test, le rendu bloquait pendant quatre secondes sur mobile, et la moindre modification risquait de casser trois pages ailleurs. L'audit n'a pas réparé le site, mais il a transformé une négociation floue en décision claire.

Un audit technique avant refonte n'est pas une formalité qu'on facture pour meubler. C'est l'instrument qui vous dit si vous partez d'un socle réparable ou d'un champ de ruines, et combien de risque vous prenez en signant. Voici la méthode que j'applique, les commandes réelles, et le moment où l'audit lui-même devient du gaspillage.

La performance se mesure, elle ne se devine pas

Le premier réflexe est de sortir des chiffres, pas des impressions. J'installe Lighthouse en ligne de commande et je lance un rapport complet sur l'URL cible, ce qui donne quelque chose comme npx lighthouse https://exemple.fr --output=json --output=html --output-path=./audit --preset=desktop, puis une seconde passe en profil mobile avec throttling activé, parce que c'est là que les sites s'effondrent. Le mobile simule un réseau lent et un CPU bridé, et un site qui passe en desktop peut être catastrophique dès qu'on coupe le fibre.

Dans le rapport JSON, je ne lis pas d'abord le score global, qui agrège tout et masque les causes. Je vais chercher les métriques une par une. Le Largest Contentful Paint me dit en combien de temps le plus gros élément visible se peint, le Total Blocking Time m'indique combien de temps le fil principal est bloqué par du JavaScript, et le Cumulative Layout Shift chiffre les sauts de mise en page. Un LCP à 4,2 secondes avec un TBT à 900 millisecondes raconte une histoire précise : trop de JavaScript qui bloque le rendu, un problème que je détaille dans mon article sur WordPress lent et PageSpeed parce que c'est le symptôme numéro un des sites à thème surchargé.

Le laboratoire ment, le terrain dit vrai

Lighthouse en local produit des données de laboratoire : une mesure unique, dans des conditions simulées, sur ma machine. C'est utile pour diagnostiquer une cause, mais dangereux pour juger l'expérience réelle. Un site peut afficher un beau 92 en local et infliger deux secondes de LCP aux vrais utilisateurs sur des téléphones milieu de gamme.

Je croise donc systématiquement avec les données de terrain. Le rapport CrUX, alimenté par les vrais Chrome des vrais visiteurs, remonte les Core Web Vitals mesurés au 75e centile, c'est à dire l'expérience des trois quarts les moins bien lotis. Si la Search Console du client est accessible, l'onglet Signaux web essentiels donne la même information triée par URL groupées. Quand le laboratoire est vert et le terrain rouge, le coupable est presque toujours le parc d'appareils réels, plus lents que ma machine, et c'est cette réalité là qui compte pour le référencement et la conversion. L'INP en particulier, qui mesure la latence de réponse aux interactions et a remplacé le FID, ne se voit bien que sur le terrain parce qu'il dépend de ce que fait l'utilisateur.

La dette technique se lit dans le code, pas dans la vitrine

Un site peut être rapide et pourtant impossible à faire évoluer. La performance mesure l'expérience visiteur ; la dette technique mesure votre coût futur à vous. Pour la chiffrer, je descends dans le dépôt. La première question est la couverture de test : sur un projet Symfony je lance php bin/phpunit --coverage-text --coverage-html=var/coverage, sur du JavaScript npx vitest run --coverage, et je regarde le pourcentage de lignes exercées par les tests.

La couverture ne dit pas si le code est bon, c'est une erreur classique de le croire. Ce qu'elle révèle, c'est votre marge de manœuvre. Un module de logique métier complexe couvert à 4 pour cent est un module qu'on ne peut pas modifier sans prier, parce que rien ne vous préviendra si vous cassez un comportement existant. À l'inverse, une couverture solide sur les parties sensibles signifie qu'on peut refactorer en confiance. J'accompagne toujours cette lecture d'une analyse statique, phpstan analyse --level=6 ou l'équivalent, qui remonte les erreurs de typage, le code mort et les incohérences que l'œil ne voit pas. Le nombre d'avertissements par millier de lignes est un indicateur brutal mais fiable de l'état des fondations, et il pèse lourd quand vient la question du choix entre Symfony et WordPress pour la reconstruction.

L'accessibilité n'est pas une case, c'est un chantier chiffrable

Lighthouse remonte une note d'accessibilité, mais elle est partielle : elle attrape les contrastes insuffisants, les images sans alternative textuelle, les libellés de formulaire manquants, soit environ un tiers des critères. Le vrai référentiel en France est le RGAA, et ses 106 critères ne se testent pas tous automatiquement. Pour la partie automatisable, j'ajoute axe-core au navigateur ou je lance npx @axe-core/cli https://exemple.fr, qui produit une liste d'infractions avec le sélecteur exact du nœud fautif.

Le reste demande un passage manuel : navigation entière au clavier pour vérifier que rien n'est piégé et que l'ordre de focus est logique, écoute au lecteur d'écran des zones clés, contrôle que les composants dynamiques annoncent bien leurs changements d'état. Ce que je livre au client n'est pas un score, c'est un décompte des critères RGAA non conformes classés par effort de correction, parce que pour une agence qui répond à un marché public ou vend à une collectivité, ce décompte est un chiffrage direct de travail à provisionner.

Quand l'audit est du gaspillage et qu'il faut reconstruire

Voici la limite que je pose honnêtement : dans certains cas, auditer finement est une perte de temps et d'argent. Si le premier coup de sonde montre un socle mort, une version de framework en fin de vie sans mise à jour de sécurité, un thème acheté et bricolé au fil des ans, aucun test, aucun contrôle de version propre, alors continuer à cartographier la dette ligne par ligne ne sert à rien. Vous documentez en détail une maison qui doit être démolie.

La règle que je m'impose : si le coût estimé de remise à niveau du socle dépasse la moitié du coût d'une reconstruction propre, l'audit approfondi s'arrête et bascule en cadrage de refonte complète. Continuer l'analyse détaillée reviendrait à facturer un diagnostic dont la conclusion est déjà écrite. Un audit léger, une demi-journée, suffit alors à établir le constat de non-viabilité et à passer à la phase utile, qui est d'écrire un brief technique pour la nouvelle version.

Le même raisonnement s'applique quand on reprend le travail d'un prestataire disparu : parfois il n'y a tout simplement pas assez de matière pour auditer, et le sujet devient de reprendre un site après le départ du prestataire en repartant de l'existant fonctionnel visible plutôt que du code. L'audit technique est un outil de décision, pas un rituel. Sa seule fonction est de vous dire, chiffres à l'appui, s'il faut réparer ou reconstruire, et de vous éviter de payer une refonte posée sur des fondations qu'il fallait raser.