L'élément le plus lent de votre application peut être... l'humain.
Lorsqu'une entreprise dit que son application est lente, la première réaction est généralement très technique. Il faut vérifier le serveur. La base de données. L'API. Les requêtes SQL. Le cache. L'infrastructure. La taille des fichiers. Le JavaScript. Le temps de réponse des différents services.
Et à juste titre. La performance technique a une importance énorme.
Sauf que parfois tous les graphiques sont bons, le serveur répond rapidement, l'application se charge en un temps raisonnable, et les utilisateurs disent toujours : « Ça prend trop de temps. »
Et là apparaît une question plus intéressante. Peut‑être que l'application n'est pas lente du tout. Peut‑être qu'elle force simplement l'humain à attendre.
2 secondes de réponse, 20 minutes de travail
Imaginez un employé qui doit préparer une offre pour un client.
Le système fonctionne correctement. Chaque écran s'ouvre vite. Il n'y a pas d'erreurs. Le serveur répond presque instantanément.
Sauf que pour préparer l'offre, l'employé doit : ouvrir le client, aller à la commande, copier le numéro du produit, ouvrir un second module, chercher le produit, recopier les données, revenir au premier écran, choisir la catégorie, aller dans un autre onglet, récupérer les prix, vérifier manuellement la remise, copier le résultat dans Excel, puis le ressaisir dans le système.
Chaque opération individuelle peut durer quelques secondes.
Techniquement tout fonctionne parfaitement. Mais l'ensemble du processus prend 20 minutes.
Et c'est précisément là que la compréhension classique de la performance cesse d'être suffisante.
Parce que l'utilisateur ne s'intéresse pas en premier lieu au temps de réponse de l'API. Il s'intéresse au temps nécessaire pour accomplir la tâche.
La performance technique n'est que le début
La performance d'un système peut se mesurer de plusieurs manières.
On peut analyser le temps de réponse du serveur, le temps de chargement d'une vue, les requêtes à la base, l'utilisation de la mémoire, la charge processeur ou la latence entre services.
Ce sont des métriques très importantes. Mais il existe une seconde couche.
La performance perçue, c'est‑à‑dire la performance telle que l'utilisateur la ressent.
Et plus largement on peut regarder l'performance opérationnelle — c'est‑à‑dire la rapidité et l'efficacité avec lesquelles une personne peut accomplir une tâche réelle en utilisant le système.
Et c'est précisément à ce dernier niveau que les entreprises perdent souvent le plus de temps. Parce qu'on peut construire une application extrêmement rapide qui restera néanmoins un outil de travail lent.
Le système le plus lent, ce sont parfois sept écrans
Supposons qu'un employé gère une réclamation.
Le système exige sept étapes.
D'abord l'ouverture du client.
Puis la commande.
Puis le produit.
Puis le formulaire de réclamation.
Puis la catégorie du problème.
Puis la décision.
Enfin la confirmation.
Chaque écran se charge en 0,5 seconde.
Du point de vue du développeur tout peut sembler très bien. Mais l'utilisateur a effectué sept transitions, a changé de contexte sept fois et a dû sept fois réfléchir à la suite des opérations.
Si de telles opérations sont réalisées des dizaines de fois par jour, le problème cesse d'être une question de confort. Il devient un coût. Et pas seulement en temps passé devant l'écran. S'ajoutent la fatigue, le nombre d'erreurs, la nécessité de corriger les données, les tâches interrompues et la charge croissante sur l'employé.
Un formulaire de 40 champs n'est pas rapide simplement parce qu'il s'ouvre vite
C'est un exemple classique.
Le formulaire s'ouvre instantanément. — Parfait.
Sauf que l'utilisateur doit remplir 40 champs.
Une partie des informations est déjà en possession de l'entreprise.
Une partie peut être récupérée depuis le CRM.
Une partie peut être calculée.
Une partie dépend des réponses précédentes.
Et pourtant le système redemande tout à l'humain une nouvelle fois.
Alors le problème n'est pas la performance de l'application.
Le problème est le design du processus et de l'interface.
Un bon système doit réutiliser les données qu'il possède déjà.
Si le client a donné une adresse de livraison lors d'une commande précédente, pourquoi l'employé devrait‑il la retaper ? Si le système connaît la société du client, pourquoi l'utilisateur doit‑il sélectionner à nouveau ses coordonnées ? Si la réponse à la première question exclut la moitié des champs suivants, pourquoi tous sont‑ils visibles dès le départ ?
Parfois, le meilleur moyen d'accélérer l'application n'est pas d'optimiser le code. C'est supprimer le travail que l'utilisateur ne devrait pas faire.
Le plus coûteux est le temps humain multiplié par l'échelle
Une minute supplémentaire peut sembler insignifiante.
Un employé exécute l'opération 5 fois par jour. — 5 minutes.
Sur un mois, cela représente plus d'1,5 heure.
Mais que se passe‑t‑il si 20 personnes font la même opération ? Et si l'opération a lieu 30 fois par jour ? Et si elle concerne tout un département ? Et si le système est utilisé pendant les cinq années à venir ?
Alors la minute individuelle cesse d'être une minute. Elle devient un coût opérationnel.
C'est pourquoi, en concevant un système pour une entreprise, il est utile de demander non seulement : « Combien de temps met le serveur à répondre ? »
mais aussi : « Combien de temps une personne met‑elle pour terminer la tâche ? »
Ce sont deux questions complètement différentes.
Le système peut être rapide et le processus lent
C'est encore un problème plus large.
Imaginez un processus d'achat dans une entreprise.
- L'employé soumet une demande.
- Le système l'enregistre immédiatement.
- Mais ensuite il doit attendre l'approbation du manager.
- Le manager reçoit une notification.
- Il ouvre le système.
- Vérifie le document.
- Le transmet aux finances.
- Les finances contrôlent le budget.
- Puis quelqu'un doit approuver la commande.
Techniquement l'application peut fonctionner parfaitement. Et le processus durer trois jours.
Pouvons‑nous dire que l'application est rapide ?
Techniquement — peut‑être.
Côté business — l'employé attend trois jours.
Et c'est justement pour cela que la conception de systèmes métiers demande de regarder au‑delà de l'interface elle‑même. Il faut voir l'ensemble du flux de travail.
« Veuillez patienter » fait aussi partie de l'UX
Il y a encore un cas intéressant.
Parfois le système exécute réellement une opération longue.
Il génère un rapport.
Il traite un gros fichier.
Il synchronise des données.
Il envoie de nombreux enregistrements vers une API externe.
Il lance un processus complexe.
On ne peut pas toujours faire en sorte que cela dure une seconde. Mais on peut faire en sorte que l'utilisateur sache ce qui se passe.
Il y a une énorme différence.
Le message : « Chargement... »
n'est pas du tout la même chose que : « Nous préparons le rapport. 72% des données traitées. Vous pouvez fermer la fenêtre — le rapport sera prêt en arrière‑plan. »
Dans le second cas l'utilisateur reçoit de l'information, du contrôle et de la prévisibilité.
C'est justement un des éléments de la performance perçue.
Le système peut toujours effectuer la même opération pendant 20 secondes. Mais l'expérience utilisateur est complètement différente.
Le pire, c'est attendre sans information
L'humain perçoit beaucoup plus négativement l'attente quand il ne sait pas si le système fait quelque chose.
On clique. - Rien.
On clique une seconde fois. - Toujours rien.
Le système fonctionne‑t‑il ?
S'est‑il planté ?
Faut‑il rafraîchir ?
Le formulaire a‑t‑il été envoyé ?
Pouvons‑nous fermer la fenêtre ?
C'est le moment où l'utilisateur commence à se battre contre l'application.
Et quand l'utilisateur se bat avec le système, surgissent d'autres problèmes.
Rafraîchissements intempestifs.
Ressaisies de formulaires.
Doublons.
Appels au support.
Erreurs.
Tickets inutiles.
Et du temps de travail supplémentaire pour d'autres personnes...
C'est pourquoi informer l'utilisateur de l'état d'une opération n'est pas un ajout cosmétique. C'est une partie intégrante de la conception d'un système performant.
Et parfois l'application attend à la place de l'humain
C'est probablement le cas le plus intéressant.
Le système exige que l'humain exécute une tâche que la technologie pourrait automatiser.
L'employé récupère des données d'un système.
Les transfère vers un autre.
Vérifie une condition.
Copie le résultat.
Envoie un message.
Change un statut.
Attend.
Confirme.
Transfère encore les données.
Et fait cela des dizaines de fois par jour.
Il n'y a pas de panne.
Il n'y a pas d'erreur.
Le système fonctionne comme prévu.
Mais les attentes étaient mal conçues.
L'automatisation ne nécessite pas forcément l'intelligence artificielle.
Parfois, la plus grande automatisation consiste simplement à faire en sorte que les systèmes n'obligent plus l'humain à transférer manuellement des informations d'un endroit à un autre.
L'architecture influence directement le temps d'attente de l'utilisateur
À ce stade nous arrivons aux questions techniques.
Si l'application est composée de nombreux services, chaque appel peut introduire une latence. Si le système récupère à chaque fois les mêmes données depuis une API externe, on peut envisager un cache. Si un rapport recalcule à chaque fois des millions d'enregistrements depuis le début, peut‑être faut‑il une autre stratégie de génération des données. Si l'utilisateur doit attendre une opération qui n'a pas besoin d'être exécutée immédiatement, on peut envisager un traitement asynchrone. Si plusieurs processus effectuent le même travail, le problème peut venir de l'architecture.
C'est précisément là que l'UX, la performance et l'architecture logicielle commencent à se rejoindre.
Le designer voit le problème utilisateur.
L'analyste voit le processus.
Le développeur voit le code.
L'architecte voit les dépendances.
Un bon système doit combiner ces quatre perspectives.
Il n'est pas nécessaire d'accélérer chaque opération
C'est aussi important.
Parfois une entreprise investit beaucoup d'argent pour optimiser une opération qui n'arrive qu'une fois par jour.
Tandis qu'une autre tâche, effectuée par 50 personnes des dizaines de fois par jour, reste pratiquement intacte.
C'est pourquoi avant d'optimiser il est utile de savoir : quoi optimisons‑nous et pour qui ?
Il ne s'agit pas que chaque écran s'ouvre en 100 millisecondes.
Il s'agit que le système soit rapide là où la rapidité compte pour le business.
Si un rapport financier peut se générer en 15 secondes une fois par jour, peut‑être que ce n'est pas un problème. Si le moteur de recherche des clients répond en 4 secondes à chaque opération d'un commercial, la situation est tout autre.
La performance doit être évaluée dans le contexte de la fréquence, de la criticité et du coût d'une action donnée.
Comment trouver le vrai goulot d'étranglement ?
Plutôt que de demander seulement aux développeurs : « Pourquoi l'application est lente ? »
il vaut mieux commencer par les utilisateurs : « Montrez‑moi comment vous faites votre travail. »
Pas : « Qu'est‑ce qui est inconfortable pour vous ? »
Mais :
« Montrez‑moi comment vous préparez une offre. »
« Montrez‑moi comment vous traitez une réclamation. »
« Montrez‑moi comment vous saisissez un nouveau client. »
« Montrez‑moi comment vous finalisez une commande. »
Et souvent apparaissent des choses invisibles dans le code.
Excel.
Bloc‑notes.
Deuxième moniteur.
Copie‑collages de données.
Vérifications manuelles.
Appels téléphoniques.
Ouverture de cinq onglets.
Rafraîchissements de page.
Attente d'un e‑mail.
Demande à un collègue.
C'est souvent là que se trouve le vrai goulot d'étranglement.
Une bonne application ne se contente pas de répondre vite
Une bonne application permet de réaliser le travail rapidement.
C'est une différence subtile mais fondamentale.
On peut avoir une application très performante techniquement qui demande à l'utilisateur une douzaine de clics. On peut avoir une interface superbe qui masque un processus compliqué. On peut avoir une excellente architecture qui ne résout pas le vrai problème business. Et on peut avoir un système qui n'est pas un champion de benchmark, mais qui permet à un employé d'accomplir en cinq minutes ce qui prenait auparavant une demi‑heure.
C'est pourquoi une société de développement ne devrait pas regarder une application uniquement à travers le prisme du code.
Le code est un moyen. Le but est un business qui fonctionne efficacement.
Avant d'optimiser le serveur, mesurez l'humain
Cette phrase mérite d'être retenue.
Si les utilisateurs se plaignent que l'application est lente, ne commencez pas automatiquement par augmenter la puissance du serveur.
Vérifiez d'abord l'ensemble du processus.
Combien de temps prend la tâche ?
Combien d'écrans faut‑il traverser ?
Combien de données l'utilisateur saisit‑il manuellement ?
Combien de fois retape‑t‑il les mêmes informations ?
Sur combien de systèmes doit‑il basculer ?
Combien de fois attend‑il ?
À quoi attend‑il ?
Sait‑il que le système travaille toujours ?
Une partie du travail peut‑elle être automatisée ?
Les données que nous possédons déjà sont‑elles redemandées à l'humain ?
Ce n'est qu'ensuite qu'il vaut la peine de descendre d'un niveau et d'examiner l'API, la base de données, l'infrastructure, le cache, les queues ou l'architecture de l'application.
Parce que parfois le problème se trouve réellement dans le code.
Mais parfois il se situe entre l'écran et la chaise.
Et dans ce cas, la meilleure optimisation n'est pas un serveur plus rapide.
C'est un système mieux conçu.
L'élément le plus lent de votre application peut être l'humain.
Et le rôle d'un bon logiciel n'est pas de faire cliquer l'humain plus vite.
Le rôle d'un bon logiciel est de faire en sorte que l'humain ait moins à cliquer.
