Ce que vous constatez
Vos équipes se plaignent de l'outil qu'elles utilisent du matin au soir : une page qui met plusieurs secondes à s'afficher, une recherche qui fige l'écran, une saisie qui rame en fin de journée. Le temps perdu se compte en heures par personne et par semaine, et il finit en contournements, en fichiers parallèles et en erreurs.
Dans un logiciel de santé, l'outil est celui des soignants : dossier patient, logiciel de pharmacie, outil de cabinet. Chaque seconde d'attente se prend sur le temps passé avec le patient.
On pense d'abord à ajouter des serveurs. Cela a un coût, et reste sans effet quand la lenteur vient du poste de travail, du navigateur, du réseau ou d'une requête mal construite.
Les causes que je rencontre
- Une page qui charge beaucoup trop de données ou de scripts pour ce qu'elle affiche, et que le poste de travail met longtemps à exécuter.
- Des requêtes à la base de données répétées pour chaque ligne d'un écran, ou sans index sur les champs recherchés.
- Un composant intermédiaire (proxy, passerelle, bibliothèque de validation) qui ajoute du temps à chaque appel sans que personne l'ait mesuré.
- Des postes de travail plus anciens ou plus chargés que ceux de l'équipe de développement, sur lesquels personne ne teste.
- Une application testée sur le réseau du siège, utilisée sur celui d'un site distant ou d'un hôpital.
Comment je trouve la cause
J'audite le code, l'architecture et l'infrastructure avec votre équipe, je pars de l'état réel de vos parcours, mesuré avec elle, je trouve la cause et j'aide l'équipe à la corriger.
Je suis un parcours d'utilisateur réel, du clic sur le poste de travail jusqu'au serveur et à la base de données. Le profilage du navigateur et du serveur montre où part le temps à chaque étape, puis je lis le code front et back qui correspond.
Ce que votre équipe obtient
- Le composant responsable de la lenteur, démontré sur vos parcours.
- Des préconisations actionnables, classées par gain et par effort, côté poste comme côté serveur.
- Une note technique de décision quand le choix engage l'architecture, comme une refonte ou un changement de composant.
- Pour vos utilisateurs, un outil qui répond, et du temps rendu au métier.
Une application peut rester lente après correction quand la cause est un choix d'éditeur sur lequel vous n'avez pas la main. Le diagnostic le dit, avec ce qu'il faut demander à l'éditeur.
Ce que j'ai déjà traité
Chez Greenspector, avant Tropis :
- La Poste, application RH MaBoxRH. Une application web utilisée par plus de 140 000 agents. Mesure sur les terminaux et sur les serveurs applicatifs, puis lecture du code front et back : un proxy natif en trop et une bibliothèque de validation trop coûteuse. Temps de réponse de 3 s à 1 s, et jusqu'à 85 % d'énergie en moins.
- Une grande banque française d'envergure internationale. Passage d'un système d'information sur site à une architecture cloud : modélisation des deux architectures et mesure de cas d'usage avant et après.
- PowerAPI, avec l'INRIA. Mise en place d'une mesure logicielle de la consommation sur serveur et sur PC, reliée à des tests automatisés.
Questions fréquentes
Et si l'application vient d'un éditeur ?
Je regarde ce qui dépend de votre installation (postes, réseau, paramétrage, intégrations) et ce qui dépend du produit. Pour la seconde partie, vous repartez avec des faits à présenter à l'éditeur.
Faut-il arrêter le service pendant l'intervention ?
Non. Le travail se fait sur des parcours réels, avec votre équipe, sur l'environnement de production ou sur une copie quand c'est possible.
Mes documents restent-ils confidentiels ?
Oui. Je propose un accord de confidentialité dès le premier échange.
Écoute, cinq à dix jours sur ce problème
Écoute traite un problème précis du produit. Si le diagnostic montre qu'il faut regarder le produit en entier, Sonar prend la suite.
Un blocage qui dure depuis des semaines ? Blocage technique →
Tout ce qui bloque dans un produit → · RAG lent ou qui répond à côté · Terminaux contraints