Audit technique d'un site web : ce qu'on y regarde

Un site lent, un trafic qui s’érode, une refonte envisagée sans savoir par quel bout la prendre : trois situations qui appellent le même préalable. Un audit technique d’un site web consiste à mesurer l’état réel d’une installation avant de décider quoi que ce soit, plutôt qu’à empiler des correctifs choisis au ressenti. L’exercice n’a rien de mystérieux, et savoir ce qu’un auditeur regarde permet de commanditer un travail utile plutôt qu’un rapport décoratif.

Ce que couvre réellement un audit technique

Le mot recouvre des périmètres très différents selon les interlocuteurs, d’où l’importance de le cadrer par écrit. Cinq domaines composent un examen complet : la performance perçue par le visiteur, la capacité des moteurs de recherche à explorer et comprendre le site, l’accessibilité, la sécurité, et enfin la qualité du socle logiciel. Un rapport qui n’aborde qu’un seul de ces axes est utile, à condition d’être vendu comme tel.

Un audit n’est pas une refonte, ni un plan d’action commercial. Sa vocation est de produire un constat mesuré, hiérarchisé par gravité et par effort, sur lequel l’entreprise décide ensuite. Un rapport qui conclut systématiquement à la nécessité de tout reconstruire mérite un second avis : la reconstruction est parfois la bonne réponse, elle n’est jamais la seule envisageable.

La méthode combine trois sources. Les outils automatiques, qui parcourent le site et relèvent des milliers d’anomalies. Les données réelles d’usage, issues de la mesure d’audience et des journaux du serveur. L’examen manuel enfin, qui seul permet de distinguer un défaut cosmétique d’un problème structurel. Un audit reposant uniquement sur un outil produit une liste de mille lignes que personne ne saura trier.

Performance : ce que mesurent vraiment les indicateurs

La performance ne se résume pas à un score coloré. Trois mesures se sont imposées pour décrire l’expérience réelle du visiteur. La première évalue le délai avant l’affichage du plus grand élément visible de la page, autrement dit le moment où le visiteur estime que la page est là. La deuxième mesure la réactivité aux interactions : le temps entre un clic et la réponse visible de l’interface. La troisième quantifie la stabilité visuelle, c’est-à-dire les décalages de contenu qui font manquer un bouton.

Deux précautions accompagnent ces chiffres. Ils se mesurent sur mobile en priorité, car c’est là que les écarts se creusent, et ils se lisent sur des données de terrain plutôt que sur un test en laboratoire. Un test unique lancé depuis une connexion en fibre optique ne dit rien de ce que vit un visiteur en zone mal couverte.

Les causes de lenteur se répètent d’un site à l’autre : images trop lourdes ou mal dimensionnées, scripts de suivi accumulés au fil des années, polices de caractères chargées avant le texte, absence de mise en cache, hébergement sous-dimensionné. La bonne nouvelle est que les correctifs les plus rentables sont aussi les plus simples : compression des images et suppression des scripts inutiles règlent souvent la moitié du problème pour quelques jours de travail.

Indexation et structure : ce que voient les moteurs

L’exploration du site par un robot révèle des écarts saisissants entre ce que le propriétaire croit publier et ce qui est réellement accessible. Les points contrôlés sont peu nombreux mais décisifs. Le fichier qui autorise ou interdit l’exploration, d’abord, souvent hérité d’une phase de développement où tout était bloqué. Les balises d’indexation ensuite, qui peuvent exclure discrètement des pages entières.

Vient ensuite la question des doublons. Une même page accessible par plusieurs adresses, avec ou sans slash final, en majuscules ou en minuscules, avec des paramètres de suivi, dilue le signal envoyé aux moteurs. Un site marchand ou une plateforme multi vendeurs, dont le catalogue génère des combinaisons de filtres, comme dans le cas d’une place de marché en ligne, produit facilement des dizaines de milliers d’adresses redondantes.

Le rendu des pages constitue un autre point d’attention devenu central. Les sites dont le contenu est construit dans le navigateur, après le chargement initial, exposent aux robots une page parfois vide au moment de la lecture. Les moteurs savent traiter ce cas, mais l’exploration coûte plus cher, se fait plus tard et reste plus fragile. Un audit vérifie donc ce que renvoie le serveur avant toute exécution de script : si le texte principal n’y figure pas, le sujet mérite un arbitrage technique, pas un simple réglage.

L’audit examine aussi la profondeur de navigation, c’est-à-dire le nombre de clics nécessaires depuis l’accueil pour atteindre une page donnée. Au-delà de quatre niveaux, l’exploration se raréfie et l’indexation devient partielle. Les redirections en chaîne, les erreurs renvoyées silencieusement et les pages orphelines, accessibles par aucun lien interne, complètent le tableau. Ces défauts ne se voient pas à l’œil nu : ils apparaissent uniquement dans les journaux du serveur et dans un parcours automatisé complet.

Accessibilité, sécurité et dette logicielle

L’accessibilité mesure la capacité d’un site à être utilisé par des personnes en situation de handicap : navigation au clavier, contrastes suffisants, alternatives textuelles aux images, structure de titres cohérente, formulaires correctement étiquetés. Les organismes publics y sont soumis depuis longtemps, et un cadre européen étend progressivement des exigences comparables à certains services numériques du secteur privé. Au-delà de l’obligation, ces corrections profitent à tous : une structure de titres propre sert autant un lecteur d’écran qu’un moteur de recherche.

La sécurité fait l’objet de contrôles distincts. Le chiffrement du transport et la validité des certificats, les en-têtes de protection du navigateur, la présence de fichiers de configuration exposés par erreur, l’existence d’interfaces d’administration accessibles publiquement. Le point le plus fréquemment défaillant reste la mise à jour des composants tiers : une bibliothèque abandonnée depuis trois ans concentre à elle seule plus de risques que l’ensemble du code écrit sur mesure.

La dette logicielle clôt l’examen. Elle se mesure à la version du langage utilisé, à l’âge des dépendances, à la présence de tests automatisés et à la qualité de la documentation. Un site fonctionnel bâti sur un socle dont le support a pris fin n’est pas en panne, mais il est en sursis : la prochaine faille impose une migration en urgence, dans les pires conditions. Ce diagnostic conditionne directement l’arbitrage entre réparation et refonte, et donc les scénarios de migration à envisager.

Livrables attendus et budgets de marché

Un audit exploitable produit trois documents. Un tableau des anomalies, chacune classée par gravité, par effort estimé et par domaine. Une note de synthèse lisible par une direction non technique, qui explique les trois ou quatre enjeux réels. Un plan d’action séquencé, distinguant ce qui se corrige en une journée de ce qui suppose un chantier.

La qualité d’un rapport se juge à un détail : la présence, pour chaque anomalie, d’une conséquence chiffrée ou au moins qualifiée. « Images non compressées » ne dit rien à une direction ; « 2,4 secondes de chargement supplémentaires sur les pages produit, corrigeables en deux jours » déclenche une décision. Un auditeur qui se contente de recopier la sortie d’un outil n’a fait que la moitié du travail, et la moitié la moins utile.

Trois exigences à poser au commanditaire. La restitution orale, d’abord : un rapport livré sans échange n’est presque jamais mis en œuvre. La disponibilité des données ensuite, car un audit sans accès aux statistiques réelles et aux journaux du serveur travaille à l’aveugle. L’indépendance enfin : un audit réalisé par l’équipe qui a construit le site, ou par celle qui espère le reconstruire, mérite d’être relu avec ce biais en tête.

Après le rapport : transformer le constat en décisions

Un audit ne vaut que par ce qu’il déclenche. La séquence efficace commence par les correctifs à fort effet et faible coût, souvent regroupables en une à deux semaines de travail : compression des médias, nettoyage des scripts, correction des redirections, mise à jour des composants critiques. Ces actions produisent un gain mesurable qui légitime la suite du programme auprès de la direction.

Les chantiers structurels viennent ensuite, arbitrés selon leur impact commercial et non selon leur intérêt technique. Refondre un tunnel de commande lent se justifie par le chiffre d’affaires ; réécrire une partie du code que personne ne consulte se justifie rarement. Chaque décision gagne à s’appuyer sur une mesure avant et après, suivie dans un tableau de bord tenu à jour plutôt que dans des captures d’écran archivées au fil de l’eau.

Reste la question du rythme. Un site actif se dégrade naturellement : chaque nouvelle fonctionnalité ajoute du poids, chaque campagne ajoute un script, chaque mois éloigne les dépendances de leur version courante. Un contrôle léger deux fois par an coûte infiniment moins cher qu’un audit complet tous les cinq ans, suivi d’une reconstruction. La performance technique se maintient, elle ne se rattrape pas.