Un cahier des charges qui ne fixe aucun seuil de performance chiffré aboutit presque toujours au même résultat : un site rapide à la livraison, qui s’alourdit mois après mois à mesure que des visuels, des extensions et des scripts tiers s’accumulent, jusqu’à ce qu’un client s’étonne de la lenteur constatée deux ans plus tard. Le budget de performance existe pour éviter ce glissement progressif, en fixant des limites concrètes dès la conception du projet.
Pourquoi fixer un budget avant de développer
Un budget de performance défini après coup, une fois le site construit, ne sert qu’à constater un dépassement. Fixé en amont, il devient une contrainte de conception : le designer sait qu’il dispose d’un budget d’images limité, le développeur sait combien de requêtes le gabarit peut se permettre. Cette contrainte change les décisions prises pendant la construction, pas seulement après coup.
Choisir des seuils mesurables
Un budget de performance n’a de valeur que s’il peut être vérifié automatiquement, sans jugement subjectif. Voici les seuils que nous intégrons couramment dans un cahier des charges de site vitrine WordPress :
- Poids total de la page : 1,5 Mo au chargement initial, hors polices déjà en cache navigateur.
- Nombre de requêtes HTTP : 40 requêtes maximum sur une page de contenu standard.
- Largest Contentful Paint : sous 2,5 secondes sur un profil réseau 4G simulé.
- Cumulative Layout Shift : sous 0,1, sans exception pour les emplacements publicitaires ou embeds.
- JavaScript exécuté au chargement : 300 Ko non compressé maximum pour le bundle critique.
Intégrer le budget dans le cahier des charges
Ces seuils doivent figurer noir sur blanc dans le document contractuel, pas uniquement dans une note interne à l’agence. Un exemple de formulation utilisée sur un projet récent :
Le site livré respecte un budget de performance de 1,5 Mo par page de contenu standard, contrôlé sur les trois gabarits principaux (accueil, article, page de contenu) avant recette finale. Tout dépassement constaté fait l’objet d’une correction avant validation.
Contrôler le budget à chaque livraison, pas seulement au lancement
Un budget fixé au lancement et jamais recontrôlé perd toute utilité dès la première mise à jour de contenu ou d’extension. L’intégration d’un contrôle automatique dans le pipeline de déploiement évite ce glissement :
# extrait d'une configuration Lighthouse CI
ci:
assert:
assertions:
resource-summary:script:size:
- error
- maxNumericValue: 307200
total-byte-weight:
- error
- maxNumericValue: 1572864
largest-contentful-paint:
- error
- maxNumericValue: 2500Ce type de contrôle bloque un déploiement qui dépasserait le budget fixé, plutôt que de laisser le dépassement passer inaperçu jusqu’au prochain audit ponctuel.
Adapter le budget au type de site
Un budget uniforme pour tous les projets n’a pas de sens : une boutique WooCommerce avec des fiches produit riches en visuels ne peut pas viser le même poids de page qu’un blog textuel. L’important est de fixer un budget cohérent avec le type de contenu et le public visé, en particulier son profil de connexion (un public majoritairement mobile justifie un budget plus strict).
Checklist pour intégrer un budget de performance
- Fixer les seuils avant le début du développement, en concertation avec le design et le développement.
- Écrire les seuils dans le cahier des charges contractuel, pas seulement dans un document interne.
- Choisir des seuils mesurables automatiquement, jamais des formulations vagues comme « le site doit être rapide ».
- Contrôler le budget à chaque livraison, avec un outil automatisé plutôt qu’un contrôle manuel ponctuel.
- Revoir le budget une fois par an, les standards du web évoluent et un budget figé cinq ans devient vite obsolète.
En résumé
Un budget de performance transforme une intention vague, « le site doit être rapide », en engagement contrôlable. Sa valeur ne vient pas des chiffres choisis en eux-mêmes, mais de la discipline de les fixer avant le développement et de les vérifier à chaque livraison, sans exception accordée « juste cette fois ».
