Une infrastructure web évolutive doit supporter les usages prévus sans ajouter de complexité inutile. Le bon dimensionnement ne se déduit pas d’un nombre mensuel de visiteurs : une page mise en cache, une recherche dans un catalogue et un paiement ne sollicitent pas le système de la même manière. Ce guide propose une méthode pour observer les limites, choisir une correction et vérifier son effet.
Décrire les parcours et la charge attendue
Listez les opérations importantes : lire une page, rechercher un produit, se connecter, envoyer une demande, enregistrer une commande ou produire un rapport. Identifiez les dépendances externes et les périodes où plusieurs opérations peuvent arriver ensemble. Une moyenne mensuelle masque les pics et ne prouve pas la capacité d’un serveur.
Pour chaque parcours, définissez ce qui serait un échec : réponse trop lente, erreur, donnée manquante, commande en double ou accès indisponible. Les objectifs de délai et de disponibilité sont à fixer selon votre activité et vos mesures, pas à reprendre d’un benchmark commercial sans contexte.
Mesurer le composant qui limite réellement le site
Comparez les temps de réponse de l’application, la base de données, l’utilisation des ressources et les erreurs. Un processeur peu occupé n’écarte pas une requête SQL lente ou un appel externe bloquant. Séparez les mesures côté serveur du chargement et des interactions dans le navigateur.
Avant de changer d’hébergement, vérifiez requêtes répétées, images, traitements synchrones et services tiers. Pour WordPress, le diagnostic de vitesse détaille cette approche. Une correction d’application peut être plus pertinente qu’un serveur supplémentaire ; seule une comparaison dans des conditions équivalentes permet de le vérifier.
Choisir une évolution adaptée aux preuves
Augmenter les ressources d’un serveur et répartir le travail entre plusieurs serveurs sont deux stratégies différentes. La première conserve une exploitation plus simple ; la seconde impose de traiter sessions, fichiers, tâches et données partagées. Le besoin de réplication, de file de traitement ou de répartition dépend du fonctionnement réel de l’application.
Avant d’automatiser l’ajout de serveurs, contrôlez qu’une instance supplémentaire peut démarrer et rejoindre le service correctement. Un répartiteur de charge ne supprime pas un point de panne dans la base ou le stockage. Comparez coût total, compétences d’exploitation, reprise des données et dépendance au fournisseur, sans promesse de capacité universelle.
Distinguer les caches et protéger les réponses privées
Un cache peut concerner une ressource statique, une page publique ou des objets internes. Pour chaque couche, documentez ce qui est stocké, pendant combien de temps et comment la copie est invalidée après une modification. Testez qu’un changement de prix ou de contenu devient visible comme prévu.
Les directives HTTP ont des effets différents : MDN distingue no-cache, no-store et private. No-cache autorise le stockage avec revalidation ; no-store demande de ne pas stocker la réponse ; private exclut les caches partagés, pas le cache du navigateur. Une configuration de cache doit donc être vérifiée, pas déduite du nom d’une extension.
Comptes, paniers, paiements et réponses contenant des données personnelles ne doivent pas être partagés entre visiteurs. Contrôlez les cookies, les variations de session et les en-têtes à l’origine comme au CDN. Un service de diffusion ne rend pas automatiquement une application privée sûre à mettre en cache.
Organiser traitements, données et sauvegardes
Un traitement long peut être exécuté hors de la requête utilisateur, à condition de rendre son état compréhensible et de gérer ses échecs. Définissez reprises limitées, délais, prévention des doublons et intervention manuelle. Déplacer un traitement dans une file ne dispense pas de vérifier qu’il s’est terminé.
Pour la base, analysez les requêtes et les volumes avant de changer mémoire ou index. Une réplication peut introduire un délai entre écriture et lecture ; il faut vérifier son effet sur commandes et disponibilités. Une sauvegarde présente n’est pas une restauration réussie. Testez une reprise dans un espace isolé, avec contrôle des fichiers, données et accès nécessaires.
Tester la charge sans provoquer un incident
Un essai de charge demande un périmètre autorisé, un environnement choisi, des données de test et des conditions d’arrêt. Ne lancez pas de trafic intensif sur un site client ou une production tierce sans accord. Commencez par vérifier le scénario avec peu de trafic, puis augmentez uniquement dans les limites prévues.
Le guide k6 sur les tests de performance souligne l’importance de scénarios comparables, de critères de fiabilité et d’une possibilité d’arrêt. Mesurez erreurs, temps de réponse et validité des opérations. Une réponse HTTP réussie ne suffit pas si la commande ou la demande n’a pas été enregistrée correctement.
Prévoir le suivi et le retour arrière
Avant publication, conservez configuration, version et procédure de restauration. Après changement, contrôlez les parcours et les dépendances, puis comparez aux mesures précédentes. Le suivi doit préciser qui reçoit une alerte, comment il vérifie l’incident et quelle action lui est autorisée.
Une infrastructure plus grande ne garantit ni ventes supplémentaires ni absence de panne. Une localisation de serveur ne certifie pas à elle seule la conformité des traitements. Les accès, mises à jour et responsabilités d’exploitation restent à cadrer. La maintenance et la création d’un outil web ont des périmètres distincts. Décrivez les ralentissements, les parcours touchés et les mesures disponibles pour préparer une intervention adaptée.
