Développement web

La performance n'est pas une finition, c'est une contrainte de conception

On ne rend pas rapide une application lente : on la reconstruit. La vitesse se décide au moment de l'architecture — ce qui est rendu sur le serveur, ce qui part dans le navigateur, ce qui n'a jamais besoin d'exister.

C'est aussi une contrainte mesurable, et publique. Google évalue chaque site sur trois indicateurs, au 75ᵉ percentile des visites réelles sur 28 jours glissants — autrement dit sur l'expérience des trois quarts de vos visiteurs, pas sur un test de laboratoire :

• LCP — affichage du contenu principal : sous 2,5 s
• INP — réactivité aux interactions : sous 200 ms
• CLS — stabilité visuelle : sous 0,1

Ces seuils sont notre engagement de départ, pas un objectif à négocier en fin de projet.

Choisir la bonne quantité de JavaScript

La plupart des sites lents le sont pour une raison unique : ils envoient au navigateur un programme entier là où une page suffisait. Nous décidons page par page.

• Page statique — contenu éditorial, pages de présentation, articles. Rendu à la construction, servi tel quel. Rien à exécuter côté client.
• Rendu serveur — contenu personnalisé ou qui change à chaque visite. Le navigateur reçoit du HTML complet, il n'attend rien.
• Îlots interactifs — seuls les composants qui en ont besoin embarquent du JavaScript : un formulaire, un filtre, une carte. Le reste de la page n'en charge aucun.

Ce site en est l'illustration : il est construit avec Astro, et l'essentiel de ses pages ne charge aucun script applicatif.

Une application se juge sur cinq ans, pas sur sa mise en ligne

Le coût d'une application se concentre après la livraison. Trois choix pèsent plus que tous les autres :

1. Des types de bout en bout. TypeScript du modèle de données à l'interface. Un changement de schéma qui casse quelque chose le fait savoir à la compilation, pas en production six semaines plus tard.
2. Des tests qui décrivent des règles, pas des états. Un test qui affirme « la page d'accueil contient douze articles » se casse à chaque publication. Un test qui affirme « chaque article publié apparaît dans son index » tient.
3. Des dépendances qu'on peut retirer. Chaque bibliothèque est une dette future. Nous en prenons peu, choisies pour leur stabilité et leur sortie possible.

Mesurer la livraison, pas l'agitation

Nous suivons les quatre indicateurs de référence du programme DORA, qui distinguent les équipes qui livrent de celles qui s'activent : fréquence de mise en production, délai entre un commit et sa mise en ligne, part des livraisons qui provoquent un incident, temps de rétablissement.

Ils ont un intérêt inhabituel : ils ne récompensent pas la prudence. Une équipe qui livre rarement pour « limiter les risques » y apparaît comme ce qu'elle est — une équipe dont chaque livraison est un événement risqué.

Reprendre l'existant plutôt que tout refaire

Une refonte totale est presque toujours le mauvais choix : elle gèle l'évolution pendant des mois et rejoue les mêmes erreurs sur une technologie plus récente. Nous préférons isoler ce qui pose problème, le remplacer derrière une interface stable, et laisser le reste en place tant qu'il rend service. Un système qui fonctionne mérite mieux qu'une réécriture par principe.