Audit technique web : performance, architecture, sécurité et dette applicative

Un score Lighthouse de 92 peut coexister avec des utilisateurs qui attendent huit secondes. Le test a peut-être été réalisé sur la page d’accueil, depuis une machine rapide, sans authentification ni scripts de consentement. Les clients, eux, utilisent un mobile ancien sur la page de paiement.

L’inverse arrive aussi. Un score de laboratoire moyen peut cacher une expérience correcte pour la majorité du trafic réel.

L’audit doit donc répondre à quatre questions : que vivent les utilisateurs, quelle couche en est responsable, quel risque cela crée, et quelle correction offre le meilleur rendement sans fragiliser le reste ?

1. Les chiffres de référence en 2026

Google considère comme « bonnes » les valeurs suivantes pour les Core Web Vitals : Largest Contentful Paint inférieur ou égal à 2,5 secondes, Interaction to Next Paint inférieur ou égal à 200 millisecondes, et Cumulative Layout Shift inférieur ou égal à 0,1. L’évaluation porte sur le 75e percentile des chargements, séparé notamment entre mobile et desktop.

Ces seuils ne sont pas des SLA universels. Ils fournissent un langage commun centré sur chargement, réactivité et stabilité. Un parcours critique peut exiger davantage ; une application interne complexe doit aussi mesurer les tâches terminées.

Le Web Almanac 2025 de HTTP Archive observe une page d’accueil médiane de 2,86 Mo sur desktop et 2,56 Mo sur mobile. Sur mobile, la médiane comportait 632 Ko de JavaScript et 911 Ko d’images. 98,1 % des pages analysées demandaient au moins un fichier JavaScript.

Le poids a augmenté. Entre juillet 2015 et juillet 2025, la page d’accueil mobile médiane est passée d’environ 845 Ko à 2 559 Ko dans la série présentée, soit +202,8 %. Sur un an, la médiane mobile 2025 progressait encore de 8,4 %.

Le coût du JavaScript apparaît mieux dans les tests de laboratoire. HTTP Archive mesure un Total Blocking Time mobile médian de 1 916 ms en 2025, contre 1 209 ms en 2024, soit +58 %. Au 90e percentile, il dépassait 7,5 secondes. Dans le même temps, 77 % des pages mobiles de l’échantillon obtenaient un bon INP en données terrain. La divergence illustre pourquoi terrain et laboratoire ne sont pas interchangeables.

Le poids n’explique pas tout, mais la relation existe. Parmi les pages internes mobiles pesant moins de 1 Mo, 68 % passaient les trois Core Web Vitals ; au-delà de 5 Mo, 42 % les passaient. L’architecture, le CPU, le cache et l’ordre de chargement restent déterminants.

2. Le dossier d’entrée : cadrer l’audit

Avant de scanner, l’auditeur identifie :

• parcours qui génèrent revenu, opération ou obligation ;
• volumes, appareils, pays et réseaux ;
• objectifs de disponibilité, latence et déploiement ;
• incidents, coûts et demandes bloquées ;
• architecture, environnements et fournisseurs ;
• contraintes de conformité, sécurité et accessibilité ;
• changements prévus dans les douze mois.

Le périmètre peut couvrir frontend, backend, API, CMS, infrastructure, CI/CD, observabilité et dépendances. Si certaines couches sont exclues, le rapport le dit. Diagnostiquer un frontend sans accès API limite la confiance sur la cause.

Trois à cinq parcours servent de fils rouges : découverte, connexion, recherche, achat, espace client, publication ou action interne. Chaque recommandation précise lequel elle améliore.

3. Les quatre plans de preuve

3.1. Terrain

Les données RUM et Chrome UX Report montrent l’expérience réelle : LCP, INP, CLS, erreurs, latence API, appareil, connexion, page et version. Elles couvrent une population, mais pas toujours les utilisateurs authentifiés ou les événements métier.

On segmente au moins par mobile/desktop, pays, template, navigateur, nouveau/retour et percentile. Une moyenne masque les utilisateurs lents. Le p75 aligne les Core Web Vitals ; p95 et p99 révèlent les queues importantes.

Le terrain mesure aussi le résultat : conversion, tâche terminée, abandon, erreur et support. Une amélioration technique sans effet sur le parcours peut rester utile pour la résilience, mais son bénéfice est différent.

3.2. Laboratoire

Lighthouse, WebPageTest, DevTools et profils reproduisent des conditions. Ils fournissent waterfall, main thread, couverture de code, mémoire, cache et captures. L’auditeur fixe appareil, réseau, localisation, état du cache et consentement.

Plusieurs répétitions sont nécessaires. Un test unique peut tomber sur un cache chaud ou un pic. La médiane et la dispersion sont conservées.

Le laboratoire sert à isoler une cause et tester une correction. Il ne représente pas tout le trafic.

3.3. Code et architecture

La revue examine frontières de modules, rendu, état, cache, appels, base de données, files, traitements, erreurs, dépendances et sécurité. Elle cherche les mécanismes, pas seulement les symptômes.

Une API lente peut venir d’une requête N+1, d’un index absent, d’un appel séquentiel ou d’une dépendance tierce. Ajouter un cache peut masquer le défaut et créer une incohérence. L’audit compare les options.

3.4. Exploitation

Les pipelines, environnements, versions, rollback, sauvegardes, alertes, incidents, coûts et responsabilités déterminent la fiabilité. Un code propre sans restauration testée reste risqué.

L’auditeur suit une release et un incident récent. Il mesure lead time, taux d’échec, temps de détection et de rétablissement. Il observe les étapes manuelles et les accès privilégiés.

4. Performance frontend : le budget par parcours

Le budget ne fixe pas seulement un poids global. Il porte sur les ressources et le travail du navigateur.

Exemple pour une page de service mobile :

Ces valeurs sont illustratives. Le budget vient de l’appareil cible et de la valeur. Une application 3D aura un profil différent, mais elle doit toujours expliquer le coût.

4.1. Diagnostiquer le LCP

Le LCP se décompose en temps jusqu’au premier octet, délai de découverte, chargement de ressource et délai de rendu. Optimiser l’image ne suffit pas si elle est découverte après un script ou si le serveur répond en deux secondes.

L’audit vérifie préchargement, priorité, format, dimensions, responsive images, CDN, cache et rendu. Il identifie l’élément LCP par template, car une bannière cookie peut parfois modifier la mesure.

4.2. Diagnostiquer l’INP

L’INP observe la latence des interactions. L’audit profile l’entrée la plus lente : attente avant exécution, traitement et présentation. Les causes incluent tâches longues, hydratation, rendu massif, écouteurs tiers et calcul synchrone.

La correction peut découper le travail, reporter, virtualiser, utiliser un worker, simplifier l’état ou réduire le JavaScript. Ajouter un spinner ne réduit pas nécessairement la latence réelle.

4.3. Diagnostiquer le CLS

Le CLS vient de contenus sans dimensions, polices, publicités, composants injectés ou animations de mise en page. L’auditeur reproduit avec cache froid et états dynamiques. Il réserve l’espace et utilise des transformations adaptées.

Une page stable au chargement peut bouger après consentement ou personnalisation. Les scénarios couvrent ces états.

5. JavaScript : coût de téléchargement et coût d’exécution

HTTP Archive parle de « double taxe » : le code est téléchargé puis exécuté. Cent kilooctets d’une bibliothèque simple ne valent pas cent kilooctets d’un script qui analyse le DOM et bloque le thread principal.

L’audit construit une carte de bundles : route, module, propriétaire, taille compressée, couverture, temps CPU et moment d’exécution. Il recherche doublons de bibliothèques, polyfills inutiles, dépendances lourdes et code chargé avant besoin.

Les scripts tiers reçoivent une fiche : finalité, propriétaire, consentement, poids, CPU, données, disponibilité et plan de suppression. Un widget sans propriétaire est un passif.

Le rendu côté serveur ou statique peut améliorer découverte et premier affichage. Il ajoute cache, invalidation et hydratation. L’audit ne recommande pas une mode ; il compare les besoins par route.

6. Backend et API : mesurer chaque frontière

La latence totale est décomposée : DNS, connexion, edge, application, base, cache et tiers. Des traces distribuées relient la requête.

L’audit examine :

• temps p50/p95/p99 par endpoint ;
• taux d’erreur et timeouts ;
• requêtes base et plans d’exécution ;
• appels séquentiels ou redondants ;
• caches, clés, TTL et invalidation ;
• idempotence et retries ;
• pagination et limites ;
• files, jobs et poison messages ;
• rate limits et circuit breakers ;
• sérialisation et taille des payloads.

Les tests de charge augmentent progressivement. Ils identifient le point de saturation et le comportement dégradé. Ils ne sont exécutés en production qu’avec autorisation, protection et fenêtre.

Un endpoint qui répond vite à dix utilisateurs peut s’effondrer à 200 en raison d’un pool de connexions. La capacité doit être reliée au pic attendu et à une marge.

7. Architecture : frontières, dépendances et changement

Le diagramme C4 ou équivalent montre utilisateurs, systèmes, conteneurs, composants et flux. L’audit recherche les couplages qui rendent une petite modification dangereuse.

Un monolithe n’est pas une dette par nature. Il peut être simple à déployer et cohérent. Des microservices peuvent multiplier réseaux, données, opérations et incidents. La question est : les frontières correspondent-elles aux équipes et rythmes de changement ?

Les ADR — décisions d’architecture — expliquent les choix et alternatives. Leur absence ne rend pas le système mauvais, mais complique la transmission. L’audit documente les décisions les plus structurantes.

La réversibilité couvre données, contenus, identités, fichiers, DNS, CDN et services. Une dépendance propriétaire est évaluée selon coût de sortie, pas selon principe abstrait.

8. Dette technique : construire un registre économique

La dette est un choix ou héritage qui augmente le coût, le risque ou le délai futur. Elle ne se mesure pas au nombre de TODO.

Chaque dette reçoit :

• symptôme et cause ;
• parcours affecté ;
• probabilité et impact ;
• coût récurrent ;
• option de correction ;
• dépendances ;
• preuve de fermeture.

Logiks distingue dette de code, architecture, données, infrastructure, sécurité, tests, observabilité et connaissance. Une documentation absente peut être plus risquée qu’une duplication de vingt lignes.

La priorité combine intérêt payé et risque. Une dette qui ajoute deux jours à chaque release mensuelle coûte 24 jours par an. Une bibliothèque vulnérable exposée peut exiger une correction immédiate même sans coût récurrent visible.

Le registre contient aussi les dettes acceptées. Réécrire un composant stable en fin de vie produit peu de valeur. L’audit doit pouvoir recommander de ne pas intervenir.

9. Sécurité : le dépistage intégré

Un audit technique web inclut un examen de surface, sans se substituer à un pentest lorsque celui-ci est nécessaire.

Il vérifie authentification, sessions, autorisations, secrets, dépendances, en-têtes, upload, injection, SSRF, XSS, CSRF, journalisation et exposition d’environnements. Les contrôles s’alignent sur le contexte et l’OWASP Application Security Verification Standard ou référentiels adaptés.

Les vulnérabilités sont confirmées avec prudence. Un scanner peut produire des faux positifs. Aucun test destructif n’est lancé hors autorisation.

Les dépendances sont triées par exploitabilité, exposition et usage réel. Mettre à jour tout aveuglément peut casser le produit ; ignorer un CVE critique exposé est pire.

La chaîne de déploiement est incluse : protection de branche, secrets CI, artefacts, provenance, comptes cloud et accès d’agence.

10. Accessibilité et performance se croisent

Une interface rendue uniquement après JavaScript peut gêner technologies d’assistance et moteurs. Des animations lourdes affectent réactivité et préférences de mouvement. Un focus perdu après un rendu dynamique est une dette fonctionnelle.

Le dépistage teste clavier, focus, noms accessibles, structure, zoom, erreurs de formulaire et contrastes. Un audit RGAA complet demande une méthodologie spécifique et des tests manuels plus larges.

Le WebAIM Million 2026 a détecté 56 114 377 erreurs sur un million de pages d’accueil, soit 56,1 par page en moyenne, +10,1 % sur un an. L’étude précise que les outils automatiques ne détectent pas tous les échecs et que l’absence d’erreur ne prouve pas la conformité. Cette réserve doit accompagner tout score automatique.

11. Observabilité et résilience

Les SLO couvrent disponibilité, latence, taux d’erreur et parcours terminé. Un budget d’erreur définit la marge de défaillance tolérée. Lorsque le budget est consommé, la fiabilité devient prioritaire.

Les alertes sont basées sur l’impact : hausse d’échecs de paiement, file bloquée, p95 dépassé, certificat proche de l’expiration. Une alerte CPU isolée peut être diagnostic, pas urgence.

L’audit simule ou examine : panne d’API tierce, base indisponible, cache vide, pic de trafic, rollback et restauration. Le mode dégradé doit préserver les fonctions importantes.

Les sauvegardes sont utiles si une restauration est testée. La mesure clé est le temps réel et la perte de données, comparés aux RTO et RPO attendus.

12. Cas pratique : checkout rapide en labo, lent pour les clients

Un e-commerce obtient 89 sur Lighthouse pour son checkout. Les conversions mobiles baissent pourtant après une refonte.

Les données terrain montrent un INP p75 de 420 ms sur Android milieu de gamme. Le laboratoire standard n’avait pas déclenché le widget de paiement, la CMP et le chat. Ensemble, ils ajoutent 480 Ko de JavaScript et deux longues tâches après le premier clic.

La trace révèle aussi que chaque frappe dans l’adresse recalcule tout le panier. L’équipe sépare l’état, charge le chat après demande, repousse un tag marketing et remplace le widget par une intégration plus légère sur les appareils concernés.

Le budget impose 250 Ko de JavaScript initial sur le checkout et aucune tâche tierce supérieure à 100 ms avant paiement. Un test synthétique et un RUM par version contrôlent la régression.

Après quatre semaines, l’INP p75 passe sous 200 ms sur le segment, les erreurs restent stables et la conversion est comparée à une cohorte témoin. L’audit n’attribue pas automatiquement tout le gain à la vitesse ; il mesure.

13. Le score et la priorisation

L’audit attribue des scores séparés : expérience terrain, frontend, backend, architecture, sécurité, exploitabilité, dette et accessibilité. Chaque score possède preuves et niveau de confiance.

Les recommandations sont classées :

• P0, risque critique ou indisponibilité imminente ;
• P1, parcours essentiel, sécurité élevée ou coût important ;
• P2, gain mesurable dans le trimestre ;
• P3, amélioration structurante ou opportunité.

Une matrice effort–impact ne suffit pas. Le séquencement considère dépendances et risque de changement. Une mise à jour de framework peut être nécessaire avant d’optimiser, ou l’inverse.

Chaque ticket contient métrique avant, cible, méthode de test et rollback. « Optimiser les images » devient « réduire l’image LCP mobile de 620 à moins de 180 Ko, conserver la qualité validée et mesurer le LCP p75 par template ».

14. Livrables attendus

• synthèse exécutive avec risques et décisions ;
• carte des parcours et métriques terrain ;
• dossier de traces laboratoire ;
• diagramme d’architecture et dépendances ;
• analyse frontend, backend, données et CI/CD ;
• registre de dette chiffré ;
• dépistage sécurité et accessibilité ;
• budgets de performance et SLO ;
• backlog priorisé avec critères d’acceptation ;
• plan 48 heures, 30 jours, 90 jours, 12 mois.

Les fichiers de test, requêtes et configurations sont remis lorsque possible. L’audit doit être reproductible.

15. Questions fréquentes

15.1. Lighthouse suffit-il ?

Non. C’est un outil de laboratoire utile. Il doit être complété par données terrain, parcours authentifiés, traces backend, architecture et exploitation.

15.2. Faut-il réécrire un produit ancien ?

Rarement sur la seule base de l’âge. Comparez modernisation incrémentale, extraction de modules, remplacement et maintien. La réécriture perd des règles métier et crée une période de double risque.

15.3. Combien de temps dure l’audit ?

Deux à six semaines pour une application moyenne. Les tests de charge, la sécurité profonde ou une architecture distribuée peuvent étendre le périmètre.

15.4. Peut-on corriger pendant l’audit ?

Les P0 peuvent être traités immédiatement avec accord. Pour préserver l’indépendance du diagnostic, les changements sont tracés et les mesures avant/après conservées.

15.5. À quelle fréquence auditer ?

Après refonte ou changement majeur, puis annuellement pour un produit critique. RUM, tests CI, dépendances et SLO surveillent entre les audits.

16. Ce que le laboratoire mobile peut établir sur le cache et les Core Web Vitals

Le laboratoire reproduit un scénario ; le terrain mesure une population réelle. Le diagnostic rapproche les deux. Une régression visible dans le RUM est reproduite avec appareil, réseau, cache, géographie et état de connexion comparables.

Le protocole fixe URL, parcours, nombre d’exécutions, médiane et dispersion. Il distingue première visite, retour, utilisateur authentifié et cache chaud. Les traces conservent waterfall, main thread, images, polices, scripts tiers et changements de mise en page.

Avant de conclure qu’un bundle est responsable, l’équipe désactive la ressource dans un environnement contrôlé, mesure l’effet plusieurs fois, vérifie les fonctionnalités perdues et recherche une interaction avec serveur, CDN ou tag tiers ; cette démarche évite de transformer une corrélation de profilage en certitude, puis de financer une réécriture qui ne change pas l’expérience au 75e percentile.

La recette associe un budget par template et un garde-fou CI sur les ressources maîtrisées. Après mise en ligne, une cohorte vérifie LCP, INP, CLS, erreurs et conversion. Le correctif n’est clôturé qu’après observation de terrain suffisante.

Les traces de diagnostic, versions et conditions de test restent attachées au ticket. Une future régression pourra ainsi être comparée sur une base identique, sans confondre évolution du site, du réseau, du navigateur ou du protocole.

17. Ce que Logiks recommande

Mesurez d’abord les parcours réels et les percentiles, puis utilisez le laboratoire pour isoler les causes. Reliez chaque dette à un coût ou un risque, imposez des budgets par route et testez restauration comme rollback. Le meilleur audit ne maximise pas le nombre de défauts trouvés : il réduit l’incertitude sur les prochaines décisions techniques.

18. Sources principales

• Google web.dev, Web Vitals et seuils Core Web Vitals : https://web.dev/articles/vitals
• HTTP Archive, Web Almanac 2025 — Page Weight : https://almanac.httparchive.org/en/2025/page-weight
• HTTP Archive, Web Almanac 2025 — Performance : https://almanac.httparchive.org/en/2025/performance
• WebAIM, The WebAIM Million 2026 : https://webaim.org/projects/million/
• OWASP, Application Security Verification Standard : https://owasp.org/www-project-application-security-verification-standard/