Un objectif de temps de réponse doit préciser l’action, le volume, l’environnement et le percentile observé pour être vérifiable.
Dire qu’un logiciel doit être rapide ne guide ni le développement ni la recette. Un écran de recherche, un export et une validation n’ont pas la même durée acceptable. Commencez par les opérations qui interrompent le travail.
Définir l’expérience attendue
Décrivez l’action et la réponse attendue. Une recherche peut afficher un résultat initial puis charger les détails. Un export peut créer une tâche et informer l’utilisateur à la fin. Un indicateur de progression est parfois plus utile qu’un écran bloqué.
Mesurez des percentiles plutôt qu’une moyenne seule. Quelques réponses très lentes peuvent bloquer un parcours même si la moyenne paraît correcte. Enregistrez le volume et le contexte de mesure.
Identifier le coût
Séparez le temps du navigateur, du réseau, de l’API, de la base et d’un fournisseur externe. Une trace de corrélation aide à attribuer la durée. Les indicateurs d’observabilité doivent relier cette mesure au parcours métier.
Tester les volumes
Un écran rapide avec dix lignes peut devenir lent avec dix mille dossiers. Utilisez un jeu représentatif et testez les filtres, les droits, les index et les caches. Vérifiez que l’optimisation ne partage pas une réponse entre entreprises.
Fixer une décision
Un seuil doit déclencher une action : indexer, paginer, déplacer le traitement en arrière-plan ou revoir le parcours. Documentez le compromis et vérifiez la qualité fonctionnelle après l’optimisation.
Sources : Google SRE, latence, Web Vitals.
Un objectif de performance doit rester compatible avec la qualité du résultat. Une réponse vide ou partielle n’est pas une optimisation acceptable si elle provoque une correction manuelle. Mesurez la réussite métier avec le temps, les erreurs, les reprises et les dossiers réellement traités.
Testez les parcours avec plusieurs volumes, rôles et entreprises. Un cache peut accélérer une page tout en servant une donnée dépassée. Vérifiez l’invalidation, les exports, les permissions et les reprises avant d’accepter le gain de performance.
Documentez le volume de référence et le percentile utilisé. Une moyenne seule masque les utilisateurs qui attendent le plus longtemps.
Rejouez la mesure après une modification de base, d’index ou de fournisseur. Comparez aussi le taux d’erreur et la qualité de la donnée retournée.
Un seuil doit conduire à une action attribuée, avec une date de vérification et un résultat attendu pour l’utilisateur.
Le support conserve le scénario et son volume.
La mesure est répétée après déploiement.
Décomposer le parcours
Mesurez le temps entre l’action et le premier retour, puis le temps avant la fin de l’opération. Une recherche peut afficher des résultats partiels, alors qu’une validation doit attendre une écriture confirmée. Chaque étape a une tolérance différente.
Reliez la requête, la base, le cache et les services externes avec un identifiant de corrélation. Les données d’observabilité doivent éviter les informations personnelles tout en permettant de trouver l’opération.
Tester les cas difficiles
Utilisez plusieurs volumes, rôles et entreprises. Une requête rapide pour un administrateur peut être lente pour un rôle limité qui applique un filtre complexe. Testez également une base avec un historique long, des fichiers volumineux et une file de tâches remplie.
Un cache peut réduire la durée mais servir une donnée ancienne. Le cache métier doit définir la fraîcheur et l’invalidation. Mesurez le temps de calcul et le temps ajouté par le réseau.
Choisir une action
Un seuil de latence doit conduire à une décision : paginer, déplacer l’opération en arrière-plan, ajouter un index ou revoir le parcours. Vérifiez l’effet sur les droits, les exports et les reprises. Une optimisation qui déplace l’erreur vers un traitement silencieux n’améliore pas le service.
Après déploiement, comparez les percentiles et les erreurs avec la version précédente. Conservez le scénario, le volume et l’environnement afin que l’équipe puisse confirmer une amélioration.
Distinguer attente et progression
Une opération longue doit afficher son état et le résultat attendu. Un export peut être demandé puis téléchargé plus tard. Une génération de document peut montrer les étapes terminées et celles qui restent. Cette information évite que l’utilisateur répète une demande et crée un doublon.
Les notifications doivent pointer vers l’état actuel. Un message reçu après la fin du traitement ne doit pas déclencher une seconde action. Testez une fermeture de session, une perte de réseau et une reprise du navigateur.
Protéger la mesure
Les métriques de latence peuvent contenir un identifiant de compte ou une requête. Limitez les attributs et définissez une durée de conservation. Une mesure utile n’exige pas le contenu complet d’un dossier.
Après une optimisation, vérifiez les droits, la cohérence et la charge. Un cache ou une pagination peut réduire le temps tout en affichant une donnée dépassée. Le résultat doit être validé avec le métier.