— Étude de cas
1,87 million de praticiens — et une facture qu’on regarde vraiment.
agenda.direct est le plus gros site que nous opérons. C’est aussi celui qui démontre le mieux une conviction : la performance et le coût d’exploitation sont un sujet de conception, pas une découverte de fin de mois.
Le cas particulier qui confirme la règle
Nous générons nos sites à l’avance, sans serveur. Ce site-là fait exception, et l’exception est argumentée : avec près de deux millions de praticiens référencés, une recherche qui doit répondre pendant la frappe et des pages qui changent, la question n’est plus « statique ou pas » — il faut un moteur qui travaille à la demande. Nous en avons donc mis un, uniquement là où il est nécessaire.
C’est un point de méthode : nous ne plaquons pas la même solution partout. Un site vitrine qui tournerait sur cette architecture paierait un serveur pour rien.
Mesurer la facture comme on mesure le trafic
Sur ce type de site, on paie à l’usage. La plupart des projets découvrent le montant quand il arrive. Nous avons fait l’inverse : relevé le coût réel dès la mise en ligne, puis cherché d’où venaient les appels au serveur.
La réponse était instructive : les deux tiers venaient d’un chargement anticipé automatique, un mécanisme qui devine ce que l’internaute va cliquer et le charge d’avance. Sur un annuaire où chaque visiteur ouvre une ou deux fiches, cela revenait à payer pour des pages que personne n’allait voir. Coupé, avec une seconde optimisation du même ordre.
Ce que ça dit de notre façon de travailler
Un site, ce n’est pas seulement ce que voit le visiteur. C’est aussi une facture mensuelle, un temps de réponse, et des décisions techniques que personne ne relit une fois le projet livré. Nous les relisons, et nous vous disons ce qu’elles coûtent.
Un projet qui sort de l’ordinaire ?
Beaucoup de fiches, un catalogue, une recherche, des données à jour : ce sont les projets où les mauvais choix se paient longtemps. Autant les prendre au départ.