Lent pour qui, à quel moment, depuis quand ?
Avant toute correction, il faut savoir précisément ce qui est lent, pour qui et depuis quand, car « le logiciel rame » recouvre des causes très différentes. Chez un grossiste, la liste des livraisons du jour met quarante secondes à s'afficher chaque matin à 7 h 30, quand tous les préparateurs se connectent ensemble. Dans un bureau d'études, c'est l'export mensuel des heures qui échoue. Dans un réseau d'agences, seule l'agence la plus éloignée se plaint. Trois symptômes, trois pistes.
| Ce que vous observez | Piste la plus probable |
|---|---|
| Un seul écran est lent, tout le temps | Requête mal écrite ou index manquant sur ce que l'écran recherche |
| Tout ralentit aux mêmes heures | Serveur saturé par les connexions simultanées, ou tâche planifiée lourde au même moment |
| La lenteur s'aggrave de mois en mois | Volume qui grandit sans archivage ni pagination |
| C'est lent depuis une date précise | Mise à jour, import massif ou changement d'hébergement à cette date |
| Seuls certains sites ou postes sont touchés | Réseau local, connexion internet ou matériel, plutôt que le logiciel |
Quelles sont les causes les plus fréquentes ?
Les causes les plus fréquentes se répartissent en cinq familles, et un même logiciel en cumule souvent deux.
La base de données
Une recherche sur une colonne non indexée oblige la base à parcourir toute la table. La documentation de PostgreSQL indique qu'un index permet au serveur de retrouver des lignes précises beaucoup plus vite, mais que les index ajoutent une surcharge à l'ensemble du système et doivent être utilisés avec discernement : en poser partout ralentit les enregistrements. La même documentation précise que les statistiques du planificateur de requêtes sont mises à jour par les commandes ANALYZE et VACUUM ANALYZE et restent toujours approximatives. Après un import massif, des statistiques périmées peuvent conduire la base à choisir un mauvais plan d'exécution.
Le volume
Dix ans d'historique affichés d'un bloc, des pièces jointes stockées dans la base, des tables de journaux jamais purgées : ce qui passait avec mille lignes ne passe plus avec un million.
Le code
Cas typique : un écran affiche cent commandes et lance une requête distincte pour chaque client, soit cent une requêtes au lieu de deux. Autres classiques : des totaux recalculés à chaque affichage, un PDF ou un e-mail générés pendant que l'utilisateur attend.
L'interface
Des pages qui chargent des milliers de lignes ou des images en pleine résolution ralentissent le navigateur, surtout sur les postes anciens et les tablettes.
L'hébergement
Un serveur mutualisé, une mémoire insuffisante ou un disque lent plafonnent tout le reste. Augmenter la machine soulage parfois, mais masque souvent une cause qui reviendra.
Comment se déroule un diagnostic de performance ?
Un diagnostic de performance suit cinq étapes, de la mesure à la preuve du gain.
- Mesurer les temps de réponse par écran et par heure, sur plusieurs jours, à partir des journaux du serveur et de la base. On ne corrige jamais à l'intuition.
- Reproduire la lenteur sur une copie de l'environnement, avec un volume réaliste, pour tester sans toucher à la production.
- Analyser les requêtes. Sous PostgreSQL, la commande EXPLAIN affiche le plan d'exécution choisi par le planificateur ; EXPLAIN ANALYZE exécute réellement la requête et affiche le nombre réel de lignes et le temps passé dans chaque étape. Comme la requête est exécutée, la documentation indique d'encadrer une requête de modification par BEGIN et ROLLBACK pour ne pas en garder les effets.
- Classer les causes trouvées par gain attendu et par risque.
- Corriger, puis mesurer à nouveau avec les mêmes indicateurs, pour prouver le gain et repérer toute régression.
Le diagnostic aboutit à un rapport écrit : causes mesurées, corrections proposées et gain attendu pour chacune. Quand le code a été écrit par d'autres, il s'inscrit dans une reprise de logiciel existant.
À partir de quand un écran est-il assez rapide ?
Un écran est assez rapide quand il ne fait plus attendre la personne dans son geste de travail ; ce seuil se fixe écran par écran, avec les utilisateurs. Pour les applications web, Google publie des repères utiles. Selon web.dev, une page offre une bonne expérience lorsque son élément principal s'affiche en 2,5 secondes au plus (LCP), qu'elle réagit aux interactions en 200 millisecondes au plus (INP) et que sa mise en page reste stable avec un score de 0,1 au plus (CLS), ces valeurs étant mesurées au 75e centile des chargements.
Pour un logiciel métier, nous traduisons ces repères en objectifs écrits dans le cahier de recette, par exemple « la liste des tournées s'affiche en moins de deux secondes avec un an d'historique ». Un objectif chiffré met fin aux débats sur la sensation de lenteur.
Quelles corrections, pour quel effet ?
Chaque cause a sa correction, et chaque correction son revers : l'effet se juge toujours par une nouvelle mesure.
| Correction | Quand elle s'applique | Point de vigilance |
|---|---|---|
| Index ciblé | Recherche ou tri fréquent sur une colonne non indexée | Chaque index ralentit un peu les écritures |
| Réécriture de requête | Requêtes en cascade, jointures inutiles | Vérifier que les résultats restent identiques |
| Pagination et filtres par défaut | Listes qui chargent tout l'historique | Garder une recherche complète accessible |
| Calculs mis en cache | Totaux recalculés à chaque affichage | Définir quand le cache se met à jour |
| Traitement en tâche de fond | PDF, e-mails, imports, exports | Prévenir l'utilisateur quand c'est terminé |
| Archivage | Données anciennes rarement consultées | Respecter les durées de conservation |
| Hébergement revu | Serveur encore saturé après les corrections | Vérifier d'abord que le code n'est pas en cause |
Cap Vert : un rapport PDF passé d'environ 2,6 s à moins d'une seconde
Cap Vert Operations nettoie des stations-service, des stations de lavage et des panneaux solaires ; ses équipes de terrain produisent des rapports d'intervention avec photos et signatures, envoyés au client en PDF. En reprenant le système hérité d'un prestataire précédent, YMHB Web a ramené la génération d'un rapport PDF côté serveur d'environ 2,6 secondes à moins d'une seconde.
La rapidité perçue tient aussi à l'architecture : l'application terrain fonctionne hors ligne, avec des files d'attente pour les photos, les PDF et les e-mails qui repartent automatiquement au retour du réseau. Le technicien n'attend pas la connexion pour passer à l'intervention suivante. Le projet est décrit sur la page Cap Vert.
Corriger ou refaire : où passe la limite ?
Refaire un logiciel lent ne se justifie que lorsque la cause est structurelle. Quatre situations font pencher vers la refonte :
- l'architecture empêche de monter en charge, comme une base Access partagée sur un disque réseau, cas traité dans notre page pour migrer une base Access ou FileMaker ;
- la technologie n'est plus maintenue, et chaque correction devient un pari ;
- le modèle de données est faux à la base, avec des informations dupliquées partout ;
- chaque correction en casse une autre, faute de tests.
Dans les autres cas, des corrections ciblées coûtent moins cher et apportent un gain immédiat. La comparaison détaillée figure dans notre page refonte ou reprise d'un logiciel.
Ce qu'un développeur ne peut pas accélérer
Certaines lenteurs échappent au code et ne se règlent ni par un développement ni par une refonte.
- Un logiciel en abonnement : sur un SaaS, la base et l'hébergement appartiennent à l'éditeur. Documentez les lenteurs (écran, heure, durée) et adressez-les à son support ; si rien ne bouge, la question devient celle du changement d'outil, abordée dans notre comparatif SaaS ou hébergé chez soi.
- Le réseau du site : une connexion saturée ou un Wi-Fi d'entrepôt défaillant relèvent de votre infogérant.
- Les postes : un ordinateur ancien ralentit tout navigateur, quel que soit le logiciel.
- Le processus : si une commande attend cinq validations successives, la lenteur est organisationnelle.
Questions fréquentes
Pourquoi un logiciel devient-il plus lent avec le temps ?
Un logiciel devient plus lent avec le temps surtout parce que ses données grandissent : des requêtes qui parcouraient mille lignes en parcourent un million, sans index adapté, sans pagination et sans archivage. S'y ajoutent des fonctions greffées au fil des années, des statistiques de base de données périmées après de gros imports, et un hébergement resté dimensionné pour les débuts.
Un serveur plus puissant suffit-il à accélérer un logiciel lent ?
Un serveur plus puissant soulage un logiciel lent lorsque la machine est réellement saturée, mais il masque souvent la vraie cause. Une requête qui parcourt toute une table reste coûteuse sur un serveur deux fois plus gros, et la lenteur revient quand le volume continue de croître. Mieux vaut mesurer d'abord, corriger le code et la base, puis ajuster l'hébergement.
Peut-on accélérer un logiciel sans en avoir le code source ?
Sans le code source, les marges de manœuvre sont limitées : on peut parfois agir sur la base de données (index, statistiques, archivage) si vous y avez accès, ou sur l'hébergement. Pour un logiciel en abonnement, seul l'éditeur peut corriger. Si le logiciel a été développé pour votre entreprise, récupérer le code et les accès est la première étape.
Combien de temps dure un diagnostic de performance ?
La durée d'un diagnostic de performance dépend du nombre d'écrans concernés, de l'accès aux journaux du serveur et de la base, et de la possibilité de reproduire la lenteur sur une copie. Le diagnostic inclut une mesure sur plusieurs jours d'utilisation réelle, nécessaire pour capter les pics de charge. Son périmètre est fixé par écrit avant de commencer.
Un logiciel lent peut-il abîmer les données ?
Oui, un logiciel lent peut indirectement abîmer les données. Quand un écran met trop de temps à répondre, les utilisateurs cliquent deux fois et créent des doublons, ou abandonnent une saisie à moitié enregistrée. Des exports interrompus produisent des fichiers incomplets. Corriger la lenteur réduit donc aussi les erreurs, à condition de nettoyer les doublons déjà créés.