Un budget de performance sert à refuser des fonctionnalités, sinon il ne sert à rien

Presque toutes les organisations que je rencontre ont un budget de performance. Il figure dans un document de cadrage, il a été validé, il énonce des seuils raisonnables. Et dans la quasi-totalité des cas, il n’a jamais eu la moindre conséquence sur une décision. Aucune fonctionnalité n’a été retardée à cause de lui, aucune bibliothèque tierce n’a été refusée, aucune mise en production n’a été bloquée. Ce document n’est donc pas un budget. C’est une déclaration d’intention, et une déclaration d’intention en matière de performance a exactement la même valeur qu’un budget financier qu’on n’aurait jamais opposé à une dépense.

La distinction que je veux poser est simple et elle a des conséquences pratiques immédiates. Un objectif décrit un état souhaitable ; son non-respect ne produit rien. Un budget est une limite dont le dépassement bloque quelque chose. Le test permettant de savoir de quoi l’on parle tient en une question : au cours des 12 derniers mois, ce chiffre a-t-il fait annuler, reporter ou réduire une fonctionnalité que quelqu’un voulait ? Si la réponse est non, il n’existe pas.

Pourquoi un objectif cède toujours

Le mécanisme de dégradation est régulier au point d’être ennuyeux. Le site est rapide au lancement, parce que la performance a été un sujet du projet. Puis viennent les demandes légitimes, une par une : l’outil de chat, le widget d’avis, le pixel de la nouvelle régie, la bannière de personnalisation, le sélecteur de magasin. Aucune n’est déraisonnable. Chacune ajoute entre 20 et 80 Ko de script exécuté et une poignée de requêtes vers un domaine tiers.

Personne ne prend jamais la décision de dégrader le site. La dégradation est la somme de 18 décisions individuellement défendables, prises sur 12 mois par des personnes différentes, dont aucune ne voyait le cumul. 18 mois plus tard, le temps d’interaction a doublé, la conversion mobile a baissé de quelques points, et l’organisation commande un audit de performance pour comprendre.

C’est précisément ce cumul invisible qu’un budget rend visible — à condition qu’il soit opposable au moment de la 18e décision, et pas seulement constaté à la fin.

Deux familles de budgets, pour deux usages

	Budgets de ressources	Budgets de métriques utilisateur
Exemples	JS exécuté par gabarit, domaines tiers, poids transféré	LCP, INP, CLS
Mesuré où	Intégration continue, environnement stable	Terrain, visiteurs réels
Variance	Nulle — déterministe	Élevée — appareils et réseaux
Rôle	Bloquer la fusion au quotidien	Réviser les seuils de ressources
Fréquence	Chaque proposition de modification	Revue mensuelle

Je fixe systématiquement deux niveaux, parce qu’ils ne servent pas au même moment. Le détail de leur articulation figure plus bas ; le tableau ci-dessus en donne la répartition.

Les budgets de ressources portent sur ce que l’équipe contrôle directement : le poids du JavaScript exécuté par gabarit, le nombre de domaines tiers contactés, le poids total transféré sur les pages critiques. Leur vertu est d’être déterministes. Ils se mesurent en intégration continue, sur chaque proposition de modification, sans variance liée au réseau. Un développeur qui les dépasse le sait avant la revue de code, et il sait exactement ce qui a grossi. Ce sont les budgets du quotidien.

Les budgets de métriques utilisateur portent sur ce que le visiteur ressent : le temps d’affichage du plus grand élément, la latence d’interaction, la stabilité visuelle. Ils sont plus bruités et plus lents à mesurer, mais ils sont la seule vérification que les budgets de ressources ont été bien choisis. On peut respecter un plafond de kilo-octets et livrer une page lente ; l’inverse est plus rare.

La règle d’articulation est la suivante : les budgets de ressources bloquent au quotidien, les budgets de métriques déclenchent une révision des budgets de ressources. Confondre les deux conduit soit à une intégration continue instable — parce qu’on essaie de bloquer sur une mesure bruitée —, soit à une optimisation d’indicateurs qui ne correspondent à rien de vécu.

Un budget de performance qui n’a jamais rien fait annuler n’est pas un budget respecté. C’est un budget qui n’existe pas, et dont personne ne s’est encore aperçu.

Où le budget doit vivre pour avoir un effet

Un chiffre dans un document ne bloque rien. Pour qu’un budget ait un effet, il doit être appliqué par un automate, à un moment où le retour arrière est encore bon marché.

Ce moment est la proposition de modification, pas la mise en production. Une régression détectée avant la fusion coûte une conversation ; la même régression détectée en production coûte un correctif urgent, une régression potentielle, et une réputation de fragilité. J’ai décrit ailleurs le détail de cette mécanique en intégration continue¹ ; le point de gouvernance qui m’intéresse ici est ailleurs.

Il tient à ceci : le budget doit être plus difficile à modifier qu’à respecter. Si n’importe quel développeur peut relever le seuil dans un fichier de configuration pour faire passer sa branche, le budget se dissout en 3 semaines. Le seuil doit vivre dans un fichier dont la modification exige une approbation explicite, et cette modification doit être visible comme telle dans l’historique. Ce n’est pas de la bureaucratie : c’est la seule chose qui distingue une contrainte d’une suggestion.

Le cas qui compte vraiment : la demande légitime qui dépasse

Tout ce qui précède est facile. La question difficile arrive le jour où la direction marketing demande une fonctionnalité qui, mesurée honnêtement, fait sortir du budget. Et cette fonctionnalité a une justification commerciale solide.

La mauvaise réponse est de refuser au nom de la performance. Elle place l’équipe technique en gardienne d’un chiffre abstrait contre une équipe qui défend du chiffre d’affaires, et cet arbitrage-là se perd à tous les coups — à juste titre, d’ailleurs.

La bonne réponse est de refuser la gratuité, pas la fonctionnalité. Elle prend la forme d’un échange, formulé sans jugement :

Ce widget pèse 42 Ko de script exécuté et ajoute 2 domaines tiers. Le budget de la page produit est atteint. Voici trois éléments actuellement chargés dont la suppression libérerait la place : l’ancien outil de chat, que 3 visiteurs par jour ouvrent ; le carrousel de la page d’accueil, dont le taux de clic est inférieur à 1 % ; le sélecteur de devise, redondant avec la détection automatique. Lequel retire-t-on ?

Cette formulation change la nature de la décision. Elle ne demande pas d’arbitrer entre la vitesse et le chiffre d’affaires — arbitrage impossible à trancher rationnellement en réunion. Elle demande d’arbitrer entre deux fonctionnalités, ce que la direction marketing sait faire et est légitime à faire. Et elle a un effet secondaire précieux : elle oblige l’organisation à connaître le rendement de ce qu’elle a déjà installé.

Ce que ce dispositif produit, et ce qu’il coûte vraiment

Un budget appliqué de cette manière produit un résultat qui n’est pas seulement technique. Il crée une pression permanente pour mesurer l’utilité de l’existant, parce qu’on ne peut libérer de la place qu’en sachant ce qui ne sert à rien. Après un an, l’organisation dispose d’une chose rare : une liste, tenue à jour, de ce que chaque élément du site coûte et rapporte.

Le coût est réel et il faut l’énoncer. Ce dispositif ralentit certaines livraisons, il crée des conversations désagréables, et il exige qu’une personne ait autorité pour trancher. Une entreprise qui n’est pas prête à ces trois choses n’a pas besoin d’un meilleur outil de mesure ; elle a besoin de renoncer honnêtement à l’idée d’avoir un budget, plutôt que d’en maintenir un qui ne fait rien.

C’est d’ailleurs la seule recommandation que je fais sans nuance sur ce sujet : entre un budget fictif et pas de budget du tout, l’absence est préférable. Elle a au moins le mérite de ne tromper personne sur l’état réel de la maîtrise.

---

Footnotes

1. Sur l’implémentation concrète — exécution en intégration continue, gestion de la variance, seuils bloquants sur les propositions de modification — voir Lighthouse CI sur Astro et Hydrogen : la performance comme contrainte de merge. ↩