Efficience IT
·Projet

Audit web chez Efficience IT : méthode, critères et contenu

Par Louis-Arnaud Catoire

Un audit technique ne se résume pas à lancer quelques outils et cocher des cases. C'est un processus structuré qui interroge chaque couche d'une application, du code source jusqu'aux décisions architecturales, pour produire un diagnostic exploitable. Chez Efficience IT, nous avons formalisé une méthodologie qui s'adapte à la maturité technique du projet audité.

Le cadrage : poser les bonnes questions avant de lire le code

Tout audit commence par une phase de cadrage avec le client. Nous cherchons à comprendre l'historique du projet, la composition des équipes qui y ont contribué, les contraintes métier et les objectifs à court et moyen terme. Un audit déconnecté de son contexte produit des recommandations théoriques ; un audit bien cadré produit une feuille de route actionnable.

Nous identifions également les indicateurs de succès du projet : volumétrie utilisateur, SLA attendus, fréquence de déploiement, couverture de tests existante. Ces éléments orientent la profondeur de l'analyse sur chaque axe.

Qualité du code et analyse statique

La qualité du code conditionne la capacité d'une équipe à faire évoluer un produit sans introduire de régressions. Nous évaluons d'abord la lisibilité : nommage des variables et des fonctions, respect des conventions, modularisation, séparation des responsabilités.

Outillage d'analyse statique

PHPStan constitue notre premier levier d'investigation. Configuré au niveau le plus élevé, il révèle les incohérences de typage, les appels de méthodes sur des types incompatibles, les variables potentiellement nulles non vérifiées. Le nombre d'erreurs détectées et le niveau maximal atteignable sans modification du code donnent une mesure objective de la rigueur technique du projet.

PHP_CodeSniffer vérifie la conformité aux PSR (PSR-1, PSR-4, PSR-12) et aux conventions du framework utilisé. Sur un projet Symfony, nous ajoutons les rulesets spécifiques au framework. L'écart entre le nombre de violations et le nombre de fichiers concernés indique si les problèmes sont systémiques ou localisés.

Nous évaluons aussi la présence et la pertinence des tests. Un projet sans tests unitaires ni fonctionnels est un projet dont chaque modification représente un risque. Nous mesurons la couverture de code, mais surtout la qualité des assertions : des tests qui n'assertent rien ne protègent de rien.

Relecture manuelle ciblée

Au-delà de l'outillage, une relecture manuelle identifie ce qu'aucun outil ne détecte : des classes aux responsabilités excessives, des dépendances circulaires entre modules, du code mort qui alourdit le projet, ou des abstractions mal placées qui complexifient la maintenance sans apporter de valeur.

Sécurité : du OWASP Top 10 à l'analyse des dépendances

La sécurité constitue un axe non négociable. Nous structurons notre analyse autour du référentiel OWASP Top 10, en adaptant la profondeur d'investigation au profil de risque de l'application.

Vecteurs d'attaque applicatifs

Nous vérifions systématiquement la validation des entrées utilisateur pour prévenir les injections SQL et les attaques XSS, le hachage des mots de passe avec des algorithmes robustes (bcrypt, Argon2), la protection CSRF sur les formulaires, et la configuration du composant Security de Symfony : voters, firewalls, principe du moindre privilège sur les rôles.

Les en-têtes HTTP de sécurité font aussi l'objet d'une vérification : Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options. Leur absence expose l'application à des vecteurs d'attaque facilement exploitables.

Audit des dépendances tierces

Un point souvent sous-estimé : les dépendances. Nous utilisons composer audit et le Symfony Security Checker pour identifier les bibliothèques présentant des CVE connues. Au-delà des vulnérabilités publiées, nous évaluons la santé des dépendances : date de dernière mise à jour, fréquence de maintenance, nombre de dépendances transitives. Une bibliothèque abandonnée par son mainteneur représente un risque latent même sans CVE déclarée.

Performances : métriques navigateur et profiling serveur

L'optimisation des performances impacte directement l'expérience utilisateur et le référencement. Notre analyse couvre les deux faces : ce que l'utilisateur perçoit dans son navigateur, et ce qui se passe côté serveur.

Interpréter les métriques Lighthouse

Lighthouse fournit des scores sur quatre axes : performance, accessibilité, bonnes pratiques et SEO. Mais un score global ne suffit pas. Nous analysons les métriques individuelles pour identifier les leviers d'optimisation les plus impactants.

Le Largest Contentful Paint (LCP) mesure le temps d'affichage du plus grand élément visible. Un LCP dégradé pointe souvent vers des images non optimisées, une police web bloquante, ou un temps serveur excessif. L'Interaction to Next Paint (INP) évalue la réactivité aux interactions utilisateur : un INP élevé révèle du JavaScript bloquant le thread principal. Le Cumulative Layout Shift (CLS) détecte les décalages visuels indésirables, souvent causés par des images sans dimensions explicites ou des éléments injectés dynamiquement.

Nous croisons ces métriques avec les données du Chrome User Experience Report lorsqu'elles sont disponibles, pour distinguer les problèmes de laboratoire des problèmes terrain.

Profiling côté serveur

Le Symfony Profiler est un allié précieux pour diagnostiquer les goulets d'étranglement serveur. Nous traquons les requêtes N+1 en Doctrine, les services trop coûteux à instancier, et les temps de réponse anormaux. Nous vérifions la configuration du cache HTTP, la mise en place de stratégies de cache applicatif (Redis, Memcached), et l'utilisation de CDN pour les assets statiques.

Sur les applications à forte volumétrie, nous analysons aussi les logs de requêtes lentes en base de données et les index manquants, qui représentent souvent les gains de performance les plus significatifs.

Compatibilité navigateurs et accessibilité

Nous vérifions le rendu sur les navigateurs les plus utilisés par l'audience du site, versions mobiles incluses. Un formulaire qui fonctionne sur Chrome peut se comporter différemment sur Safari, notamment pour la gestion des dates et des sélecteurs. Le test responsive sur différentes tailles d'écran garantit une expérience cohérente.

Conformité accessibilité

L'accessibilité est évaluée selon les standards WCAG et le RGAA en France. Nous vérifions les attributs alt sur les images, la hiérarchie des titres, le contraste texte/arrière-plan, la navigabilité au clavier, et l'association correcte des labels aux champs de formulaire. Les messages d'erreur doivent être interprétables par les technologies d'assistance.

L'audit comme évaluation architecturale

Pour les projets matures, l'audit dépasse l'analyse fichier par fichier et devient une évaluation architecturale. Nous examinons la cohérence globale des choix techniques : le découpage en couches est-il respecté ? Les bounded contexts sont-ils clairement définis ? Les flux de données entre composants sont-ils prévisibles et traçables ?

Quantifier la dette technique

La dette technique n'est utile comme concept que si elle est quantifiable. Nous catégorisons chaque problème identifié selon trois dimensions : l'impact sur la vélocité de l'équipe (frein quotidien ou frein ponctuel), le risque de défaillance (probabilité et gravité), et le coût de remédiation (effort en jours/homme). Cette matrice permet de passer d'un inventaire de problèmes à un modèle économique de la dette.

Un projet peut vivre avec une dette technique maîtrisée. L'enjeu n'est pas de tout corriger, mais de savoir précisément ce que l'on accepte de porter et ce qui nécessite une intervention.

Priorisation par le risque

Nous utilisons une approche de priorisation basée sur le risque, inspirée des méthodes de gestion de projet : chaque recommandation est classée selon sa criticité (impact en cas de non-traitement), sa complexité de mise en oeuvre, et son effet de levier (une correction qui en débloque d'autres). Les failles de sécurité critiques et les problèmes de stabilité passent systématiquement en priorité haute, indépendamment de leur complexité.

Du diagnostic à la feuille de route stratégique

Le livrable final n'est pas un simple catalogue de défauts. Pour chaque point identifié, le rapport contient une description du problème, sa localisation, son niveau de criticité, et une recommandation de correction. Un tableau de synthèse permet de visualiser l'état général du projet.

Mais l'essentiel réside dans la transformation du diagnostic en plan d'action. Selon l'ampleur des constats, plusieurs trajectoires se dessinent.

Si les problèmes sont ciblés, un plan de correction à court terme suffit : mise à jour des dépendances vulnérables, correction des failles critiques, optimisation des requêtes les plus lentes. Ces interventions apportent des bénéfices immédiats et mesurables.

Si l'audit révèle une dette technique structurelle, nous proposons un accompagnement sur le moyen terme via une Tierce Maintenance Applicative (TMA). Cette approche permet de traiter progressivement les problèmes par lots priorisés, sans interrompre le fonctionnement du site.

Dans les cas les plus avancés, l'audit peut recommander une refonte partielle de certains composants. Nous préconisons alors une approche progressive, module par module, avec des critères de succès mesurables à chaque étape. La feuille de route qui en résulte articule les corrections immédiates, les chantiers à moyen terme et la vision architecturale cible, en donnant à chaque partie prenante, développeurs comme décideurs, les éléments nécessaires pour arbitrer.

Un audit technique régulier, comme un contrôle technique pour un véhicule, détecte les problèmes avant qu'ils ne deviennent critiques et prolonge la durée de vie de votre application.

Pour aller plus loin

← Retour au blog