Mesurer et évaluer correctement le temps de chargement d'un site web

À quelle vitesse est mon site Web ? La question semble simple, mais ne peut pas être entièrement résolue par un seul chiffre.

Un site Web ne se résume pas au seul moment où il est „ chargé “. Le navigateur commence par se connecter au serveur, reçoit le HTML, charge d'autres ressources et construit progressivement la page visible et interactive à partir de celles-ci.

C'est pourquoi différents outils de performance peuvent afficher des mesures différentes pour un même site Web – sans que l'un d'eux ne soit nécessairement faux.

Dans ce guide, nous vous expliquons comment mesurer judicieusement le temps de chargement d'un site web, quelles sont les métriques importantes et comment évaluer correctement les résultats de mesure.

En bref : Ne jugez pas la vitesse d'un site Web sur la base d'un seul temps de chargement ou d'un seul test. Il est plus pertinent de combiner plusieurs mesures, différents indicateurs de performance et – si disponibles – des données de visiteurs réels.

Pourquoi n'y a-t-il pas un seul temps de chargement ? #

Lors du chargement d'un site web, de nombreux processus se déroulent successivement et parfois simultanément.

Simplifié :

Accéder à l'URL
    ↓
Établir la connexion
    ↓
Le serveur traite la requête
    ↓
Le HTML est transféré
    ↓
Le navigateur traite le HTML
    ↓
Chargement du CSS, JavaScript, des images et des polices
    ↓
Les premiers contenus deviennent visibles
    ↓
Le contenu principal important apparaît
    ↓
Chargement de ressources supplémentaires
    ↓
La page réagit aux interactions de l'utilisateur

Selon la partie de ce processus observée par un outil, on obtient une valeur de mesure différente.

Qu'est-ce qui influence le temps de charge mesuré ? #

Une mesure ne dépend pas seulement du site web lui-même.

Les conditions du test influencent également le résultat. Celles-ci comprennent, par exemple :

• Emplacement du système de test,
• Vitesse et latence du réseau,
• appareil utilisé ou matériel simulé,
• Navigateur,
• État du cache,
• Charge du serveur,
• services et ressources externes.

C'est pourquoi le même site web peut donner des résultats différents lors de deux mesures.

Que signifie TTFB ? #

TTFB signifie Temps jusqu'au premier octet.

L'indicateur décrit de manière simplifiée le temps écoulé entre le début d'une requête et l'arrivée du premier octet de la réponse HTTP.

Demande commence
      ↓
Connexion / Demande / Traitement
      ↓
premier octet de la réponse
      ↑
     TTFB

Le TTFB peut fournir des indications sur la première partie de la requête, mais il ne constitue pas une mesure complète du temps de chargement du site web.

Par exemple, un bon TTFB ne signifie pas automatiquement que de grandes images, un JavaScript volumineux ou des ressources externes seront ensuite traités rapidement.

Le TTFB n'est pas seulement la „ vitesse du serveur “ #

Le TTFB est souvent simplifié à tort comme le simple temps de réponse du serveur web. C'est inexact.

La valeur mesurée peut comprendre plusieurs éléments, notamment les temps de réseau et de connexion ainsi que le traitement de la requête du côté du serveur.

L'emplacement du système de mesure par rapport au serveur peut donc également avoir une influence.

Important : Utilisez le TTFB comme valeur de diagnostic, mais pas comme seule évaluation de la vitesse d'un site Web ou d'un serveur d'hébergement.

Que signifie FCP ? #

FCP signifie Premier affichage du contenu.

La valeur décrit le moment où le navigateur rend pour la première fois du contenu du document, par exemple du texte, une image ou d'autres éléments visibles.

FCP examine ainsi un autre aspect que le TTFB.

Le serveur répond
      ↓
Le navigateur traite la page
      ↓
Le premier contenu pertinent est affiché
      ↑
     FCP

Que signifie LCP ? #

LCP signifie Plus grand élément affiché.

L'indicateur examine le moment où le plus grand élément de contenu pertinent a été rendu dans la zone visible.

Cela peut être, par exemple, une grande image, un titre ou un autre bloc de contenu selon la page.

Une grande image principale peut donc avoir un impact considérable sur le LCP.

Nous expliquons la signification exacte du LCP, ainsi que de l'INP et du CLS, sous Core Web Vitals expliqués : LCP, INP et CLS.

Que signifie „ entièrement chargé “ ? #

Même le terme „ complètement chargé “ n'est pas aussi univoque qu'il n'y paraît au premier abord.

Un site Web peut déjà sembler entièrement utilisable pour le visiteur, tandis que d'autres ressources ou requêtes sont encore traitées en arrière-plan.

Inversement, un événement de charge technique peut déjà avoir eu lieu, bien qu'une fonction externe importante ne soit pas encore prête.

C'est pourquoi une seule donnée telle que „ Temps de chargement : 2,1 secondes “ ne doit pas être considérée de manière isolée.

Que sont les données de laboratoire ? #

Les données de laboratoire sont générées dans des conditions de test contrôlées ou simulées.

Un outil de performance charge le site web dans des conditions définies et mesure différentes métriques.

Cela présente un grand avantage : les tests peuvent être répétés dans des conditions similaires et être comparés entre eux.

Les données de laboratoire se prêtent donc particulièrement bien au diagnostic technique et à la comparaison avant et après une modification.

Que sont les données de terrain ? #

Les données de terrain sont basées sur des mesures effectuées dans des conditions réelles d'utilisation.

Ils montrent l'expérience réelle vécue par les visiteurs sur le site Web, sur divers appareils et dans différentes conditions de réseau, à condition que les données disponibles pour le site ou l'URL concernés soient suffisantes.

Cela permet aux données de terrain d'offrir une perspective différente de celle d'un seul test en laboratoire.

En bref : Les données de laboratoire montrent comment un site Web fonctionne dans des conditions de test spécifiques. Les données de terrain montrent comment il a réellement été vécu dans des conditions d'utilisation réelles.

Pourquoi les données de laboratoire et de terrain peuvent-elles être différentes ? #

Un test en laboratoire utilise des conditions définies. En revanche, les visiteurs réels utilisent des appareils, des navigateurs, des connexions réseau et des emplacements différents.

Par exemple, un ordinateur de bureau puissant disposant d'une connexion rapide peut faire l'expérience d'un site Web différemment d'un smartphone plus ancien sur un réseau mobile.

Des résultats différents ne constituent donc pas automatiquement une contradiction.

Qu'sont les Core Web Vitals ? #

Les Core Web Vitals sont des métriques utilisées pour mesurer certains aspects de l'expérience utilisateur d'un site web.

Actuellement, cela inclut :

LCP → Largest Contentful Paint
      Performance d'affichage du plus grand élément

INP → Interaction to Next Paint
      Réactivité

CLS → Cumulative Layout Shift
      Stabilité visuelle

Ces trois valeurs examinent différents aspects d'un site Web et ne doivent donc pas être regroupées en un seul „ temps de chargement “ général.

Quelles sont les mesures importantes pour moi ? #

Cela dépend de ce que tu veux étudier.

Si vous voulez savoir si le serveur répond rapidement à une requête, le TTFB peut être intéressant.

Si vous voulez savoir quand des contenus visibles importants apparaissent, des métriques de rendu telles que le FCP et le LCP sont plus utiles.

Lorsque les utilisateurs signalent des réactions différées aux interactions, l'interactivité est à son tour pertinente.

Une bonne analyse de performance commence donc par la question :

Quel problème est-ce que je souhaite réellement mesurer ?

Mesurer un site web avec Google PageSpeed Insights #

Google PageSpeed Insights est un outil bien connu pour analyser les performances des sites web.

Il peut afficher des données de laboratoire provenant de Lighthouse et, pour autant que des données d'utilisation réelles soient disponibles pour la page ou l'origine concernée, des données d'utilisation réelles provenant du Chrome User Experience Report.

Cela rend PageSpeed Insights adapté à la fois à une première analyse technique et à l'examen des Core Web Vitals.

Nous expliquerons les différents domaines et recommandations dans le prochain article sous Comment utiliser correctement Google PageSpeed Insights.

Considérer le mobile et le bureau séparément #

Les résultats de performance pour les appareils mobiles et les systèmes de bureau peuvent différer considérablement.

Ce n'est pas surprenant : un smartphone possède des caractéristiques de performance différentes et peut accéder à un site Web via une connexion réseau différente de celle d'un ordinateur de bureau.

Ne jugez donc pas exclusivement le test de bureau sous prétexte qu'il y affiche une valeur de performance plus élevée.

Si une part importante de vos visiteurs utilise des appareils mobiles, l'utilisation mobile est au moins tout aussi pertinente.

Pourquoi le lieu du test est-il important ? #

Les données doivent être transférées entre le système de test et les serveurs concernés.

Plus la distance réseau et la route sont grandes ou défavorisées, plus la latence peut être élevée.

Une page Web dont la cible principale se trouve en Suisse ou en Europe centrale ne devrait donc pas être évaluée exclusivement sur la base d'un test unique provenant d'un emplacement éloigné.

Pour des mesures comparables, tu devrais utiliser des sites de test aussi similaires que possible.

Que signifie latence ? #

En termes simples, la latence décrit le délai de transmission des données entre deux points.

Elle n'est pas la même chose que la bande passante.

Une connexion peut avoir un débit maximal élevé et présenter néanmoins une latence relativement élevée.

Sur les sites Web, de nombreuses opérations réseau peuvent avoir lieu, c'est pourquoi la latence peut être pertinente pour la vitesse perçue.

Le cache influence les résultats de mesure #

Lors du premier chargement d'un site Web, il peut être nécessaire de charger des ressources qui seront déjà présentes dans le cache du navigateur lors d'une visite ultérieure.

Les systèmes de cache côté serveur peuvent également permettre de fournir une réponse déjà préparée ou mise en cache plus rapidement qu'une requête qui doit être entièrement générée à nouveau.

C'est pourquoi vous devez savoir si vous mesurez dans un état dit froid ou déjà réchauffé.

Que signifient un cache froid et un cache chaud ? #

Simplifié :

Cache froid
→ les données requises ne sont pas encore présentes dans le cache concerné

Cache chaud
→ les données requises peuvent déjà être fournies à partir d'un cache

Les caches impliqués dépendent du site web et de l'infrastructure.

Lors de comparaisons de performances, tu devrais mesurer dans des conditions aussi comparables que possible.

Un seul test ne suffit pas #

Les réseaux et les serveurs ne fonctionnent pas dans des conditions totalement constantes.

Une mesure peut, par exemple, être influencée par un délai réseau de courte durée ou par un service externe.

Effectue par conséquent plusieurs mesures et fais attention aux schémas récurrents.

Exemple :

Test 1 → 1,8 s
Test 2 → 2,0 s
Test 3 → 1,9 s

autre test :

Test 1 → 1,7 s
Test 2 → 8,4 s
Test 3 → 1,8 s

Pour le deuxième exemple, il conviendrait d'examiner d'abord pourquoi une mesure se détache nettement du lot avant d'en tirer une conclusion générale sur le site Web.

Toujours comparer la même URL #

La page d'accueil n'est pas automatiquement représentative de l'ensemble du site Web.

Une simple page de contact peut, par exemple, nécessiter nettement moins de ressources qu'une page de produits détaillée ou qu'une boutique en ligne.

Par conséquent, lorsque vous comparez des optimisations, utilisez la même URL avant et après la modification.

Avant :
/produit/exemple/

Après :
/produit/exemple/

C'est la seule façon de comparer le même type de page.

Tester plusieurs types de pages importants #

Pour une évaluation plus complète, tu ne devrais pas te limiter à mesurer uniquement la page d'accueil.

Selon le site Web, les types de pages suivants peuvent par exemple s'avérer judicieux :

Page d'accueil
Page de service importante
Article de blog
Page de destination
Page produit
Page de catégorie de boutique
Paiement

Une seule page rapide ne prouve pas que toutes les autres zones possèdent la même performance.

Documenter les tests avant et après les modifications #

Si vous souhaitez évaluer une mesure de performance, vous devez documenter l'état initial et l'état final.

Exemple :

URL :
https://example.com/beispiel/

Test :
mobile

Emplacement du test :
identique

Date :
même fenêtre de test

AVANT modification :
Noter les mesures

Modification :
Image principale optimisée

APRÈS modification :
Recueillir à nouveau les mesures

Cela te permet de mieux évaluer si la modification concrète a réellement apporté une amélioration mesurable.

Ne pas changer dix choses en même temps #

Si vous compressez des images, modifiez le cache, désactivez des plugins, supprimez du JavaScript et changez de version PHP en même temps, le site web peut ensuite être plus rapide, mais vous saurez à peine quelle mesure a eu quel effet.

Pour un diagnostic précis, des modifications contrôlées sont préférables.

Conseil pratique : Mesurer → effectuer un changement traçable → mesurer à nouveau. C'est ainsi que vous comprendrez beaucoup mieux quelle optimisation fonctionne réellement.

Le score de performance et le temps de chargement ne sont pas la même chose #

De nombreux outils d'analyse calculent un score à partir de plusieurs valeurs mesurées.

Un tel score est pratique pour classer rapidement des résultats, mais il n'est pas identique à un temps de chargement directement mesuré.

Une valeur telle que :

Performance : 92

ne signifie pas :

Le site web est rapide à 92 %.

Le score est calculé à partir de différentes mesures selon une méthodologie spécifique.

Ne pas optimiser exclusivement pour 100 points #

Un score parfait peut être un objectif motivant, mais il ne doit pas devenir une fin en soi.

Une mesure peut théoriquement améliorer une valeur mesurée tout en dégradant le site Web réel, par exemple si une image importante est visiblement trop compressée ou si une fonction nécessaire est supprimée.

L'optimisation des performances doit donc toujours prendre en compte conjointement les métriques techniques et l'expérience utilisateur réelle.

Pourquoi deux outils de performance peuvent-ils donner des résultats différents ? #

Différents outils peuvent utiliser des emplacements de test, des profils d'appareils, des conditions réseau, des navigateurs ou des méthodes de calcul différents.

C'est pourquoi tu ne dois pas comparer sans esprit critique les chiffres absolus des différents services.

Pour les comparaisons avant-après, il est judicieux d'utiliser autant que possible le même outil avec des paramètres comparables.

Que signifie analyse en cascade ? #

Une vue en cascade, ou « waterfall », montre quelles ressources une page charge et quand les requêtes respectives commencent ou se terminent.

Simplifié :

HTML       ███████
CSS           ████
Police           █████
Image 1          █████████
Image 2             ███████
JavaScript       ███████████
API                      █████

Cela vous permet par exemple de voir si un fichier image volumineux, un service externe ou une autre ressource prend particulièrement de temps.

Le nombre de requêtes à lui seul n'est pas une mesure de la qualité #

Une page avec plus de requêtes HTTP n'est pas automatiquement plus lente qu'une page avec moins de requêtes.

La taille, la priorité, la mise en cache, le protocole, les dépendances et le traitement des ressources jouent également un rôle.

Une simple prescription d'objectif telle que „ moins de 50 requêtes “ n'est donc pas une règle de performance universelle.

Évaluer correctement la taille totale d'une page #

La quantité de données transférées est un indicateur utile, en particulier pour les sites web riches en images.

Mais elle doit également être replacée dans son contexte.

Une galerie de photos nécessite par nature plus de données d'image qu'une simple page de texte.

L'objectif n'est pas de forcer chaque site web à avoir la même taille globale, mais d'éviter les transferts de données inutiles.

Nous expliquons comment préparer efficacement les images sous Optimiser les images pour le Web : taille de fichier, format et référencement.

Les ressources externes peuvent influencer les performances #

Les sites Web chargent souvent du contenu provenant d'autres services.

Cela peut par exemple inclure :

Polices web
Services d'analyse
Vidéos
Cartes
Contenus de réseaux sociaux
Services publicitaires ou de suivi
Bibliothèques JavaScript externes

Vous ne contrôlez pas entièrement vous-même le temps de réponse de ces ressources.

Si un service externe répond lentement, cela peut par conséquent affecter certains aspects de votre site web.

Un site web lent ne signifie pas automatiquement un hébergement lent #

Lorsqu'un site web semble lent, on a souvent tendance à blâmer immédiatement le serveur d'hébergement.

Cela peut être une cause possible, mais ce n'est de loin pas la seule.

Une feuille de style, des images volumineuses, des requêtes de base de données complexes, des extensions, des thèmes, du JavaScript ou des services externes peuvent par exemple ralentir un site web.

À l'inverse, une application inefficace peut également rester lente sur une infrastructure performante.

Nous abordons la manière de circonscrire systématiquement de telles causes sous Site web lent : identifier les causes de manière systématique.

Faire la distinction entre l'heure du serveur et l'heure du frontend #

Pour le diagnostic, il est utile de distinguer grossièrement entre la génération ou la mise à disposition d'une réponse et le traitement ultérieur dans le navigateur.

Serveur / Backend
→ Traiter la requête
→ Fournir le HTML

Navigateur / Frontend
→ Analyser le HTML
→ Traiter le CSS
→ Exécuter le JavaScript
→ Charger les images
→ Afficher la page

Si le serveur répond rapidement, mais que le navigateur doit ensuite traiter des ressources très volumineuses, la page peut tout de même sembler lente.

À l'inverse, un front-end léger peut être ralenti par un traitement côté serveur très lent.

Pourquoi une connexion Internet rapide peut tromper le développeur #

Quiconque teste un site Web avec une connexion fibre optique rapide et un ordinateur puissant ne ressentira pratiquement aucun décalage.

Cependant, les visiteurs peuvent avoir d'autres conditions.

C'est pourquoi les conditions de test mobiles simulées et les données d'utilisation réelles sont utiles. Elles révèlent des aspects qui passent presque inaperçus lors d'un accès depuis un poste de travail rapide.

Tester les performances directement sur un smartphone #

Au-delà des outils automatisés, un véritable test pratique en vaut la peine.

Ouvrez des pages importantes sur un smartphone et observez le comportement réel du site web.

Observe par exemple :

Quand le contenu principal apparaît-il ?

La mise en page change-t-elle pendant le chargement ?

Puis-je interagir rapidement avec la page ?

Les images apparaissent-elles à temps ?

Une bannière de cookies bloque-t-elle l'utilisation ?

La navigation réagit-elle immédiatement ?

De telles observations ne remplacent pas une mesure technique, mais constituent un complément utile.

Ne pas tester le site web uniquement à l'état connecté #

Les systèmes de gestion de contenu peuvent se comporter différemment pour les administrateurs connectés que pour les visiteurs normaux.

Il est possible de contourner les caches pour les utilisateurs connectés, par exemple.

Testez par conséquent la site web public en plus dans une fenêtre de navigation privée, dans laquelle vous n'êtes pas connecté au CMS.

Éviter les mesures pendant les travaux de maintenance #

Si des sauvegardes, des importations, des mises à jour ou d'autres travaux intensifs sont en cours, les mesures peuvent ne pas être représentatives.

Il en va de même pour une structure de cache qui vient d'être vidée, si vous souhaitez réellement évaluer l'état normal d'un visiteur.

Par conséquent, documentez les conditions de test lors de comparaisons importantes.

Qu'est-ce qu'un bon temps de chargement ? #

La question d'un „ bon temps de chargement “ unique est trop générale.

Google définit des seuils précis pour les Core Web Vitals. Pour le LCP, par exemple, une évaluation allant jusqu'à 2,5 secondes au 75e centile est considérée comme „ bonne “.

Cela ne signifie toutefois pas que toute autre métrique de temps de chargement envisageable doive également être systématiquement inférieure à 2,5 secondes.

Différents indicateurs mesurent des choses différentes.

Important : Ne transférez pas simplement une limite d'indicateur de performance spécifique à toutes les autres valeurs de temps de chargement.

Que signifie le 75e centile ? #

Lors de l'utilisation de données d'utilisation réelles, on ne se contente pas d'examiner de simples valeurs maximales ou moyennes individuelles.

Le 75e percentile signifie simplement que 75 pour cent des expériences examinées atteignent une valeur égale ou supérieure à cette limite.

Cela ne permet pas seulement de considérer des appels individuels particulièrement rapides.

Performance et SEO #

La performance d'un site Web peut également être pertinente dans le cadre de la recherche Google. Les Core Web Vitals font partie des signaux d'expérience utilisateur pris en compte par Google.

Cela ne signifie pas pour autant qu'un meilleur score de performance entraîne automatiquement une amélioration du classement.

La performance technique doit être optimisée avant tout parce qu'un site Web rapide et stable est plus facile à utiliser pour les visiteurs.

La mesure des performances est un diagnostic, pas une compétition #

Il est peu judicieux de comparer exclusivement un score avec un site web complètement différent.

Un blog simple, une boutique en ligne complexe et une application Web ont des exigences différentes.

La question la plus pertinente est :

Où se trouvent les goulots d'étranglement concrets de mon site web et lesquels puis-je améliorer utilement ?

Vérifier régulièrement les performances #

Un site web change.

De nouveaux plugins, images, scripts de suivi, polices, vidéos ou fonctionnalités peuvent affecter les performances.

C'est pourquoi une mesure n'est pas valable pour toujours.

Une nouvelle vérification vaut particulièrement la peine après des modifications importantes.

À quel moment dois-je mesurer à nouveau ? #

Une nouvelle mesure des performances est particulièrement utile après :

Refonte de site web
Changement de thème
Modifications majeures de plugins
Nouveaux scripts de suivi ou marketing
Intégration d'images ou de vidéos volumineuses
Modifications de la mise en cache
Modifications du serveur ou de PHP
Extensions majeures de la boutique

L'accessibilité d'un site web est différente de la performance #

Un site Web peut être accessible tout en réagissant lentement.

Inversement, un test de performance ne mesure pas automatiquement et de manière fiable si un site Web est disponible 24 heures sur 24.

Des systèmes de surveillance sont utilisés pour le contrôle continu de l'accessibilité.

Nous traitons ce sujet sous Surveillance de sites web : surveiller l'accessibilité et les pannes.

Déroulement pratique d'une mesure de performance #

sélectionner une URL représentative
        ↓
définir les conditions de test
        ↓
tester sur mobile et ordinateur
        ↓
effectuer plusieurs mesures
        ↓
documenter les valeurs mesurées
        ↓
identifier les ressources problématiques
        ↓
analyser une cause précise
        ↓
effectuer une modification ciblée
        ↓
mesurer à nouveau dans des conditions comparables
        ↓
évaluer le résultat

Quelles valeurs dois-je documenter ? #

Quelles données sont pertinentes dépend de l'outil utilisé. Pour une comparaison reproductible, les informations suivantes peuvent par exemple être utiles :

URL testée
date et heure
outil de test
mobile ou bureau
emplacement du test, si sélectionnable
TTFB
FCP
LCP
autres Core Web Vitals
quantité de données transférées
ressources notables
modification effectuée

Cela vous permettra de mieux replacer les mesures ultérieures dans leur contexte.

Erreurs fréquentes lors de la mesure de la vitesse d'un site web #

n'exécuter qu'un seul test
ne tester que la page d'accueil
ne regarder que le bureau
comparer directement différents outils
ignorer différents emplacements de test
ne pas tenir compte de l'état du cache
confondre le score de performance avec des secondes
optimiser uniquement pour 100 points
effectuer plusieurs modifications en même temps
attribuer immédiatement chaque site lent à l'hébergement
évaluer les métriques sans l'expérience utilisateur réelle

Liste de contrôle pour une mesure pertinente #

Quelle URL est-ce que je souhaite analyser ?
        ↓
Quel problème est-ce que je souhaite mesurer ?
        ↓
Les conditions de test sont-elles comparables ?
        ↓
Mobile ET Desktop pris en compte ?
        ↓
Plusieurs tests effectués ?
        ↓
Données de laboratoire et de terrain différenciées ?
        ↓
TTFB et rendu examinés séparément ?
        ↓
Ressources suspectes vérifiées ?
        ↓
Une seule modification ciblée effectuée ?
        ↓
Nouvelle mesure effectuée dans les mêmes conditions ?
        ↓
Site Web réel également testé par soi-même ?

Résumé #

Il est impossible de décrire la vitesse d'un site Web de manière pertinente par un seul chiffre. Lors du chargement d'une page, la réponse du serveur, le réseau, le navigateur, les images, le CSS, le JavaScript, les services externes et de nombreux autres facteurs interagissent.

Les métriques telles que le TTFB, le FCP et le LCP examinent différentes étapes de ce processus. Les données de laboratoire sont générées dans des conditions de test contrôlées, tandis que les données de terrain reflètent les expériences d'utilisation réelles.

Pour des comparaisons pertinentes, tu devrais tester plusieurs fois la même URL dans des conditions aussi comparables que possible et prendre en compte les scénarios mobiles et de bureau.

Un score de performance constitue à cet égard un repère utile, mais ne représente pas une fin en soi. L'essentiel est d'identifier des goulots d'étranglement concrets et de vérifier ensuite si une optimisation ciblée apporte effectivement une amélioration.

Une bonne analyse des performances ne consiste pas à collecter le plus de chiffres possible. Elle consiste à mesurer dans des conditions comparables, à comprendre les bons indicateurs et à en déduire la bonne mesure technique.