CTO ou responsable des opérations d’une entreprise en croissance
“Le site rame exactement quand on est le plus occupé”
Est-ce que ça vous ressemble?
- La performance se dégrade de façon prévisible aux heures de pointe ou en fin de mois
- La base de données est le coupable évident mais personne ne sait quelle requête
- Redémarrer le serveur « règle » le problème pour un temps
- Vos développeurs disent qu’il faut tout réécrire
- Les coûts montent parce que la réponse jusqu’ici a été un serveur plus gros
Ce que coûte l’inaction
Les ralentissements en période de pointe sont des pertes de revenus — ils surviennent précisément quand les clients tentent d’acheter. Pendant ce temps, le remède par défaut, une instance plus grosse, achète quelques mois et augmente la facture de façon permanente sans traiter la cause. Une réécriture proposée à ce stade prend généralement bien plus longtemps que prévu sans livrer de valeur nouvelle.
Comment se déroule le mandat
- 1
Mesurer avant de toucher à quoi que ce soit
Instrumenter l’application et la base pour voir où le temps passe réellement. Les intuitions de performance sont fausses plus souvent qu’autrement, les nôtres incluses — nous ne devinons donc pas.
- 2
Trouver le vrai goulot
Généralement des index manquants ou inadéquats, des requêtes en N+1, des jeux de résultats non bornés, ou un pool de connexions épuisé. Parfois c’est architectural. La mesure tranche.
- 3
Corriger sur place d’abord
Index, réécriture de requêtes, pagination, couches de cache, gestion du pool. Des changements à faible risque, à grand effet, et réversibles.
- 4
Ajouter cache et files là où c’est justifié
Redis pour les lectures chaudes, les sessions et la limitation de débit. Files d’arrière-plan pour le travail qui n’a pas à se faire dans une requête web.
- 5
Puis seulement, envisager l’architecture
Si la limite est réellement structurelle, vous obtenez une évaluation honnête avec le raisonnement montré — pas une affirmation qu’il faut tout reconstruire.
Mesurer d’abord, sérieusement
L’habitude la plus coûteuse en performance est la devinette confiante. Quelqu’un se rappelle un problème semblable, un changement est fait, rien ne s’améliore, et une semaine est perdue.
Nous instrumentons donc d’abord : temps de requête, journaux de requêtes lentes, comportement du pool de connexions, taux de succès du cache. Puis nous regardons où le temps passe vraiment. C’est régulièrement là où personne ne l’avait prédit.
Ce que c’est habituellement
Par ordre de fréquence :
- Un index manquant ou inadéquat. Une requête faisant un balayage complet sur une table devenue très grosse.
- Des requêtes en N+1. La page charge cinquante enregistrements, puis émet une requête par enregistrement. Correct à cinquante lignes, fatal à cinquante mille.
- Des jeux de résultats non bornés. Une requête sans limite, correcte quand la table était petite.
- Un pool de connexions épuisé. Tout attend une connexion; la base elle-même travaille à peine.
- Aucun cache là où il s’impose. La même requête coûteuse exécutée des milliers de fois pour un résultat identique.
Les cinq se corrigent sur place. Aucune n’exige une réécriture.
Quand une réécriture est justifiée
Cela arrive. Si l’architecture ne peut pas supporter ce que l’entreprise exige maintenant — du temps réel là où c’était conçu par lots, du multilocataire là où c’était unique — c’est structurel et aucun réglage n’y changera rien.
Vous obtiendrez cette évaluation avec le raisonnement montré. Nous n’avons aucune reconstruction à vous vendre, et notre pratique en génie logiciel traite la réécriture comme un dernier recours.
Ce que vous obtenez
- Des mesures avant et après, non des affirmations
- Le vrai goulot identifié avec preuves
- Corrections de requêtes, d’index et de cache appliquées
- Surveillance et alertes pour voir la prochaine régression tôt
- Une évaluation écrite indiquant si l’architecture est vraiment la limite
Questions fréquentes
Nos développeurs disent qu’il faut réécrire. Ont-ils raison?
Parfois, mais bien moins souvent qu’on ne le propose. Les réécritures prennent régulièrement deux à trois fois l’estimation, et pendant ce temps vous maintenez deux systèmes sans livrer de valeur. Nous mesurons d’abord. Dans la grande majorité des cas, le problème tient à quelques requêtes, un index manquant ou un jeu de résultats non borné — corrigeables en semaines, sur place. Si c’est vraiment architectural, nous montrerons les preuves.
Un serveur plus gros ne réglerait-il pas la question?
Cela achète du temps et augmente durablement votre facture. C’est une mesure d’urgence raisonnable et une mauvaise stratégie, car la plupart de ces problèmes ne s’échelonnent pas linéairement avec le matériel — une requête sans index empire à mesure que les données croissent, peu importe le processeur ajouté.
En combien de temps verra-t-on une amélioration?
La mesure prend quelques jours. Les premiers gains significatifs arrivent souvent dans la première semaine, car les index manquants et les motifs N+1 sont à la fois très fréquents et rapides à corriger. Le travail plus profond s’étale sur deux à quatre semaines.
Pouvez-vous travailler sur un système en production?
Oui, prudemment. Mesure en lecture seule d’abord, changements testés en préproduction, déploiement avec chemin de retour. Nous n’expérimentons pas en production, et la plupart de ce travail n’exige aucune interruption.
Et si le problème n’est pas la base de données?
Alors la mesure le dira, et nous la suivons — appels d’API externes sans délai d’expiration, pression mémoire, saturation disque, serveur web mal configuré, ou un CDN qui ne sert à rien. La discipline est de mesurer plutôt que de reconnaître un motif, et c’est précisément pourquoi on commence là.
Services mobilisés
Infrastructure et sauvegarde
Serveurs, grappes et sauvegardes conçus pour que la panne soit survivable et ennuyeuse.
En savoir plusGénie logiciel
Architecture, plateformes d’abonnement et pipelines de données — conçus pour être maintenus.
En savoir plusDites-nous ce qui ne fonctionne pas — ou ce que vous voulez bâtir.
Dès le premier appel, vous parlez à un ingénieur principal, pas à un vendeur. Si nous ne sommes pas le bon choix, nous vous le dirons et vous orienterons ailleurs.
Incident en cours? Inscrivez « URGENT » dans votre message et nous priorisons votre dossier.