Étape 5Dès quelques jours
Suivre et améliorer
Mesurer, trouver ce qui bloque, corriger et suivre.
- Diagnostic chiffré, mesures à l’appui
- Recommandations classées par impact
- Mise en place des plus utiles et suivi
Étude de cas · performance
SNCF Gares & Connexions : l’API des écrans en gare, 10 fois plus rapide.
Quand la charge montait, l’API qui alimente les écrans d’information voyageurs des grandes gares ralentissait et renvoyait des erreurs. Mesurer, trouver les causes, corriger, mesurer à nouveau : le temps de réponse moyen a été divisé par 10.
- Client
- SNCF Gares & Connexions
- Secteur
- Transport · information voyageurs dans les grandes gares
- Besoin
- Fiabiliser une API sous forte charge : temps de réponse et erreurs
- Étape
- Suivre et améliorer
- Mission
- Deux études de performance
- Technologies
- API web, mesures sous charge, tests de charge en préproduction. Le détail de l’architecture n’est pas publié.
÷ 10
Temps de réponse moyen, de 1,1 s à 0,1 s
0 %
D’erreurs sous forte charge, contre 52 % avant
+47 %
De requêtes traitées, dans les mêmes conditions
Chiffres mesurés sous forte charge, avant et après les correctifs.
01Contexte
Des voyageurs qui cherchent leur quai ne peuvent pas attendre.
Dans les grandes gares, les écrans d’information voyageurs affichent les départs, les voies et les retards. Derrière, une API leur fournit ces informations, en continu.
Les écrans l’interrogent sans arrêt, et les pics de charge arrivent au moment où les voyageurs en ont le plus besoin. C’est là qu’elle décrochait.
Temps moyen1,1 s
Erreurs52 %
02Enjeu
Sous forte charge, plus de la moitié des demandes échouaient.
Pour un écran qui doit afficher le bon quai, au bon moment, c’est trop. Il fallait corriger sans rien changer à ce qu’affichent les écrans.
Avant · temps
1,1 seconde par réponse, en moyenne.
Chaque écran attend l’API, et les demandes s’accumulent quand la charge monte.
Avant · erreurs
52 % des demandes en erreur.
Une information qui n’arrive pas, c’est un écran qui ne se met pas à jour.
Contrainte
Aucun changement visible.
Des corrections ciblées, sans toucher à ce que les voyageurs voient à l’écran.
03Approche
Mesurer d’abord, corriger ensuite.
Des études de performance menées de bout en bout : chaque étape est écrite, avec les chiffres avant et après, pour que l’équipe du client puisse tout vérifier.
Mesurer
Sous forte charge, dans des conditions réelles.
Comprendre
Mesurer chaque étape d’une réponse pour trouver où part le temps.
Corriger
Des correctifs ciblés, vérifiés un par un.
Prouver
Mesurer à nouveau dans les mêmes conditions, puis en test de charge.
Livrables
Deux études de performance rédigées, remises au client.
- Les mesures avant et après, dans les mêmes conditions de charge
- Les chiffres de chaque correctif
- La validation en test de charge sur l’environnement de préproduction
04Résultats
Dix fois plus rapide. Plus aucune erreur.
Temps de réponse moyen · sous forte charge
Les deux barres avancent à la même échelle de temps.
Taux d’erreur · sous forte charge
Avant52 %
Après0 %
Plus aucune demande en échec.
Requêtes traitées · mêmes conditions
+47 %
L’API absorbe davantage de demandes, plus vite.
Erreurs de l’API÷ 10
Temps d’une écriture× 4 plus rapide
Les études sont des documents internes au client : l’architecture, les outils et le détail des correctifs ne sont pas publiés ici. Seuls les chiffres ci-dessus le sont.
05Pour vous
Votre application ralentit sous la charge ? Le même travail s’applique.
Un produit qui ralentit, renvoie des erreurs aux heures de pointe ou coûte trop cher sur AWS : la démarche est la même. Mesurer, trouver ce qui bloque, corriger ce qui compte, et le prouver avec des chiffres.
Pour un produit construit par Elia Interactive ou ailleurs.
Wooskill
Le produit d’une startup de la formation en ligne, construit et enrichi brique par brique.
Votre projet