Pourquoi mon site Web est-il si lent à charger ?
February 03, 2026
|
11 min de lecture
Les temps de chargement lents ne sont rarement que « techniques » : ils modifient la perception de votre marque par les gens, s’ils vous font confiance – et s’ils restent.
Nous vous montrons comment le temps de chargement se crée, comment bien lire les Core Web Vitals et quelles actions ont vraiment un impact (y compris les gains rapides et la routine à long terme).
Et oui : la performance est aussi une question de durabilité – moins de données, moins d'énergie, plus d'accès pour tous.
LCP
INP
CLS
TTFB
Caching
CDN
Expérience de marque
Mobile
SEO
Accessibilité
CO2
Maintenance
Ça commence rarement par une alarme. C’est souvent une impression : « Ça prend du temps. » Puis viennent les petits signes que vous négligez facilement au quotidien.
Peut-être que le taux de rebond augmente alors que les campagnes fonctionnent bien. Peut-être qu'il y a moins de demandes de contact, même si le contenu est bon. Ou bien, les gens vous écrivent directement : « La page se bloque pour moi. » Sur mobile, c’est particulièrement brutal – car les appareils sont plus faibles, les réseaux fluctuants et la patience limitée.
Nous voyons souvent un schéma typique dans les projets : Le site Web était correct lors de son lancement, puis de nouvelles images, du suivi, un chat, un élément de page-builder « juste pour cette page » ont été ajoutés petit à petit – et soudain, un chargement court devient une attente sensible.
Cela ne se traduit pas seulement par un « plus », mais les chiffres le montrent très clairement : Plus de la moitié des utilisateurs mobiles abandonnent si une page prend plus de trois secondes à charger. <cite data-type="source" data-url="https://www.emit-solution.com/blog/website-zu-langsam#:~:text=,langsame%20Websites">EMIT Solution</cite> Et Think with Google a découvert dans une enquête que pour 75 % des gens, la vitesse de chargement est le facteur le plus important pour leur expérience sur le Web - avant même le design ou le contenu. <cite data-type="source" data-url="https://www.thinkwithgoogle.com/intl/en-emea/marketing-strategies/app-and-mobile/need-speed-evaluating-perception-and-reality-speed-mobile-web/">Think with Google</cite>
Si vous vous demandez si vous « exagérez » : probablement pas. Une page lente est comme une porte qui se coince. Les gens n’accèdent pas à votre contenu, à votre offre ni à votre Purpose.
Notre première perspective fraîche ici : La lenteur est un canal de rétroaction. Ce n’est pas seulement une erreur technique, mais un signal que votre système (Design, Contenu, Outils, Hébergement) s’est discrètement alourdi. Une fois que vous voyez cela comme une question systémique, la solution devient plus claire – et moins frustrante.
Un site Web n'est pas seulement un ensemble de pages. C'est une expérience en temps réel. Et la vitesse est comme le ton : vous la remarquez immédiatement – et vous l’interprétez, même sans en être conscient.
Lorsqu'une page réagit rapidement, cela ressemble à de l'attention. Comme si « nous avions pensé à vous ». Si elle tergiverse, un petit doute s’installe : Cela fonctionne-t-il ici ? Est-ce professionnel ? Est-ce sûr ? Cette chaîne est particulièrement douloureuse pour les Purpose Brands, car la confiance n'est pas un simple ajout, mais un fondement.
Économiquement aussi, la vitesse n'est pas négligeable. Les études montrent qu'environ 70 % des consommateurs disent que la vitesse d'un site Web influence leur disposition à acheter. <cite data-type="source" data-url="https://bluetriangle.com/blog/debunking-7-myths-about-website-speed-and-the-user-experience#:~:text=When%20nearly%C2%A070,decisions%2C%20online%20businesses%20have%20noticed">Blue Triangle</cite> Et les grandes plateformes l'ont depuis longtemps internalisée : Amazon et Walmart sont souvent cités, car même de petites améliorations en millisecondes peuvent apporter des effets mesurables sur la conversion. <cite data-type="source" data-url="https://web.dev/case-studies/milliseconds-make-millions/">web.dev</cite>
Mais notre point le plus important est un autre – et il manque dans de nombreux articles « 10 raisons » : La vitesse est aussi une question d'accessibilité. Pas en tant que critère WCAG, mais dans la vie réelle. Les personnes avec des appareils plus anciens, une connexion faible ou un volume de données limité perçoivent les sites lourds comme une porte fermée. Un site rapide est plus inclusif, car il suppose moins.
Et la vitesse, c’est aussi la durabilité : si vous transférez 5 Mo, vous consommez plus d’énergie que pour 500 Ko – pour chaque appel, sur chaque appareil, dans chaque réseau. On s'aperçoit que dès que les équipes considèrent la performance comme faisant partie de leur promesse de valeur, la conversation devient plus facile. Il ne s’agit plus de « 100 points dans l’outil », mais de respect.
Notre deuxième perspective fraîche : La performance est un travail de marque. Pas seulement une optimisation après le lancement, mais une partie de ce que les gens ressentent à votre sujet, avant même d’avoir lu une phrase.
Vous voulez savoir ce qui ralentit votre site ?
La lenteur est rarement une erreur, mais un ensemble entier
Lorsque nous examinons un site Web lent, nous ne trouvons presque jamais une seule raison. Plutôt quelque chose comme un sac à dos rempli de pierres - et chaque discipline en a ajouté une à un moment donné. C'est pourquoi la priorisation vaut la peine.
Dans la plupart des cas, cinq blocs de freinage reviennent toujours : les médias (surtout les images), trop de JavaScript et CSS, trop de polices, les scripts tiers (suivi, intégrations, chat) et une configuration de serveur/hébergement qui répond trop lentement.
Que les images soient si souvent en haut du classement n'est pas un hasard. Elles représentent souvent la plus grande part des données transférées. <cite data-type="source" data-url="https://www.emit-solution.com/blog/website-zu-langsam#:~:text=Grund%20,h%C3%A4ufigster%20Fehler">EMIT Solution</cite> Et tandis que le HTML et le CSS pensent en kilooctets, les photos pensent rapidement en mégaoctets. Une image d'accueil héroïque qui fonctionne de manière fantastique sur un bureau peut devenir un poids mort sur mobile.
Les scripts tiers sont notre suspect « invisible » préféré. Quelques outils semblent petits individuellement, mais ils apportent des requêtes réseau, des temps d'attente DNS et souvent d'autres chargements supplémentaires. C'est un mythe connu : « Ce ne sont que des extraits ». En pratique, les outils tiers influencent sensiblement le temps de chargement et l'interactivité. <cite data-type="source" data-url="https://bluetriangle.com/blog/debunking-7-myths-about-website-speed-and-the-user-experience#:~:text=Myth%20%234%3A%20Third,tools%20don%27t%20affect%20load%20times">Blue Triangle</cite>
Notre méthode éprouvée n°2 : Vérification des « traces de freinage ». Nous commençons d'abord là où nous gagnons beaucoup avec peu de risque :
1) Zone héroïque (la plus grande image, les polices, les premiers scripts)
2) Tiers (ce qui est chargé en externe, ce qui est réellement nécessaire)
3) Réponse du serveur (TTFB, mise en cache, localisation)
Cette approche évite les erreurs de démarrage typiques, où l'on passe des jours à miniaturiser, tandis qu'une image de 5 Mo dans l'en-tête domine tout.
Et une autre perspective fraîche et importante pour nous : Tout ce qui est à la mode ne doit pas être chargé immédiatement. Certains contenus peuvent arriver plus tard. Si un flux Instagram ou une vidéo n'est chargé qu'après le défilement, le site reste riche – mais l'entrée reste facile. Ce n'est pas une tromperie, mais une conception d'attention.
Les Core Web Vitals ressemblent à une liste de contrôle SEO, mais sont en réalité très humains : Google essaie de mesurer ce qui semble bon aux utilisateurs.
Les trois valeurs les plus importantes que vous voyez au quotidien sont LCP, INP et CLS. LCP (Largest Contentful Paint) demande : Quand l'élément le plus grand et important est-il visible ? Souvent le titre ou l’image héroïque. INP (Interaction to Next Paint) demande : À quelle vitesse le site répond-il lorsqu'une personne clique, tape ou fait défiler ? CLS (Cumulative Layout Shift) demande : Le layout saute-t-il lorsque le contenu se charge, ou tout reste-t-il stable ?
Pour LCP, Google recommande une valeur de référence : en dessous de 2,5 secondes est bon. <cite data-type="source" data-url="https://www.emit-solution.com/blog/website-zu-langsam#:~:text=Google%20empfiehlt%20folgende%20Richtwerte%20f%C3%BCr">EMIT Solution</cite> Ce que nous trouvons important : Ces valeurs ne sont pas des « Notes techniques », mais des notes d'expérience.
Un exemple de notre pratique : Si l'image héroïque est énorme et n'apparaît que tardivement, le site semble vide – même si beaucoup de choses se chargent en arrière-plan. C'est un problème de LCP.
Ou : Si vous exécutez trop de scripts au début (suivi, animations, curseurs), le site est peut-être « en ligne », mais il ne répond pas. Vous cliquez – et rien ne se passe. C'est un problème d'INP.
Et si les boutons ou le texte surgissent pendant le chargement, car les images n'ont pas de place réservée ou des bannières sont ajoutées après coup, c'est un problème de CLS. Cela coûte non seulement des nerfs, mais aussi de vrais clics erronés.
Le contexte est également important : En 2025, moins de la moitié des domaines répondent aux exigences des Core Web Vitals. <cite data-type="source" data-url="https://webless.co/blog/why-core-web-vitals-matter-for-seo-and-user-experience/">webless.co</cite> Vous n'êtes donc pas « seul » avec le problème – mais vous pouvez vous démarquer avec cela.
Si vous avez besoin d'un outil qui vous le montre rapidement : PageSpeed Insights est un bon point de départ. Ne regardez pas seulement le score, mais les temps concrets et si les données de champ (utilisateurs réels) sont bonnes. C'est souvent la vérité la plus honnête.
Parfois, le site n'est objectivement pas encore parfait – mais il semble déjà bon. Et parfois, il est « en théorie rapide », mais semble lent. C'est là qu'un domaine souvent ignoré par les conseils techniques intervient : la performance perçue, la vitesse perçue.
Think with Google a montré que la perception et les mesures peuvent diverger : Les utilisateurs évaluent certains sites comme « assez rapides », bien qu'ils soient techniquement plus lents – si la partie visible montre tôt quelque chose d'utile. <cite data-type="source" data-url="https://www.thinkwithgoogle.com/intl/en-emea/marketing-strategies/app-and-mobile/need-speed-evaluating-perception-and-reality-speed-mobile-web/">Think with Google</cite>
Ce n'est pas un truc pour cacher de la mauvaise technique. C'est un bon travail de UX. Lorsque nous concevons la performance, nous pensons donc à deux niveaux :
Premièrement : L'entrée doit paraître « sûre » immédiatement. Un layout stable (pas de saut), un titre clair, un premier texte rapide – même si les médias continuent de se charger plus bas.
Deuxièmement : La priorisation l'emporte sur la complétude. Une intégration Instagram, une carte, une vidéo : Cela peut venir plus tard, si ce n'est pas crucial pour la première orientation.
Troisièmement : Les micro-attentes nécessitent du langage. Si quelque chose doit vraiment se charger (par exemple, un formulaire, une recherche), une réponse claire et calme aide. Pas « Chargement... », mais « Nous chargeons les résultats » - et l'espace reste stable.
Dans nos projets, c'est souvent le moment où le design et le développement se rejoignent vraiment. Un site rapide ne naît pas uniquement dans le code. Il naît lorsque nous décidons déjà dans le layout ce qui doit être Above-the-Fold et ce qui ne doit pas l'être.
Notre troisième perspective rafraîchissante : La performance est aussi dramaturgie. Vous guidez les gens à travers une première impression. Si l'entrée est facile, ils restent – et vous donnent une chance de convaincre avec le contenu.
Et oui : bien sûr, nous voulons aussi améliorer la technique. Mais la performance perçue est ce que vous pouvez influencer immédiatement, même si une refonte plus importante prend encore du temps.
Voulez-vous examiner l'expérience utilisateur et les performances ensemble ?
De nombreux problèmes de performance ne peuvent pas être « optimisés » car ils découlent de décisions prises bien plus tôt : dans la mise en page, dans la production de contenu, dans la question de ce que doit exprimer une page.
Nous aimons le design esthétique. Et nous aimons les sites Web qui se sentent vivants. Mais nous avons appris : Chaque décision visuelle a un poids. Une vidéo en lecture automatique dans l'en-tête n'est pas seulement un élément de style, mais aussi du volume de données, une charge CPU et souvent une expérience mobile moins bonne. Trois polices Web ne sont pas uniquement de la typographie, mais aussi des requêtes supplémentaires et parfois des fichiers bloquant le rendu.
Notre approche chez Pola est donc : nous réfléchissons à un budget de performance – non pas comme une règle rigide, mais comme une ligne directrice commune. Cela signifie : dès la conception, nous clarifions quels éléments sont vraiment porteurs et lesquels nous pouvons simplifier sans perdre d'impact.
Un exemple que nous rencontrons souvent : une équipe souhaite « plus de ressenti » sur la page d'accueil et propose des animations, des parallaxes et de grandes images de fond. Au lieu de le refuser de manière réflexe, nous demandons : Quel sentiment exactement ? Souvent, la même ambiance peut être atteinte par la composition, l'espace blanc, la photographie et une typographie apaisante – sans scripts supplémentaires. Le minimalisme n'est pas une obligation stylistique, mais une façon de respecter les ressources.
Voici notre quatrième perspective rafraîchissante : La légèreté est une qualité de design. Elle est visible (moins de surcharge visuelle) et invisible (moins de données, moins d'énergie). Et elle convient souvent étonnamment aux marques qui veulent transmettre clarté, responsabilité et confiance.
Si vous pensez à une refonte : n’utilisez pas la performance comme critère de validation à la fin, mais comme partie de la conception. Cela se ressent plus tard comme un cadeau – car vous n’avez pas besoin de « sauver » ce qui a été rendu difficile auparavant.
Si un site Web est lent, il est souvent lourd. Et « lourd » signifie : beaucoup de transferts de données, beaucoup de calculs, beaucoup d'énergie – sur les serveurs et sur les terminaux.
Nous trouvons utile de voir la performance non seulement comme un sujet business, mais comme une conséquence d’une attitude. Si vous êtes une organisation qui accorde de la valeur à la responsabilité, alors cette responsabilité doit également se montrer dans le numérique : par des données réduites, des priorités claires, un site qui reste accessible même dans des conditions difficiles.
Cela a un aspect très pratique : les sites légers fonctionnent mieux dans les réseaux faibles. Et les réseaux faibles ne sont pas seulement « quelque part loin » – ils sont dans le métro, à la campagne, dans des bâtiments anciens, par mauvais temps. Un site rapide signifie : moins de frustration, plus d'accès.
Il y a une autre dimension, souvent négligée : en réduisant le poids des pages, on réduit souvent aussi les coûts d'infrastructure. Moins de trafic, moins de charge, moins de complexité. Ce n'est pas toujours mesurable 1:1, mais en pratique, les équipes le ressentent rapidement – surtout lorsque des pics de campagnes ou des moments de presse arrivent.
Nous associons cela à un principe qui nous tient très à cœur : design vert pour un avenir numérique. Pas parce que chaque site Web doit être « ascétique », mais parce que nous pouvons utiliser les ressources de manière consciente.
Si vous souhaitez approfondir l'impact des sites durables, vous trouverez chez nous une Histoire à ce sujet : Sites Web durables : Impact, Mesurabilité, Mise en œuvre.
Notre cinquième perspective rafraîchissante : La performance est un impact silencieux. Les gens la ressentent, même s'ils ne la nomment pas. Et elle fait partie de la manière dont vous prenez au sérieux vos propres valeurs – pas en tant que message, mais en tant que comportement.
Si vous pensez actuellement : « Ok, compris – mais concrètement, que dois-je faire maintenant ? » Alors nous commençons le plus souvent par des actions qui montrent rapidement un impact, sans que vous deviez toucher à tout votre système.
1) Images: plus petites, correctes, plus tard. Si vous ne faites qu'une chose, faites celle-ci. Convertissez les photos en formats modernes comme WebP ou AVIF et assurez-vous que la taille livrée correspond à l'affichage (pas de 2500px si 600px suffisent). WebP peut être nettement plus petit pour la même qualité. <cite data-type="source" data-url="https://www.emit-solution.com/blog/website-zu-langsam#:~:text=Die%20L%C3%B6sung">EMIT Solution</cite> Pour un démarrage rapide, utilisez Squoosh (en ligne) ou TinyPNG pour JPEG/PNG.
2) Utilisez le cache au lieu de tout refaire. Si vous utilisez WordPress, un cache propre peut faire une différence notable, car les pages ne sont pas recalculées à chaque visite. Une bonne introduction est les plugins comme WP Rocket (payant) ou WP Super Cache (gratuit). (Nous vérifions toujours ce qui convient au setup – le cache peut aussi avoir des effets secondaires s’il est configuré sans précaution.)
3) Réduisez les tiers. Examinez honnêtement ce qui est vraiment nécessaire. Supprimez les anciens scripts de suivi, les widgets et les intégrations rarement utilisés. Nous constatons souvent que cela seul rend des secondes, car les serveurs externes ne sont pas toujours fiables.
4) Activez la compression et la livraison moderne. Brotli ou gzip pour les fichiers texte, HTTP/2 ou HTTP/3 dans l'hébergement, chargement différé des images pour les contenus en dessous de la partie visible – ce sont des classiques, mais ils fonctionnent.
Important : Les gains rapides ne remplacent pas une bonne base. Mais ils sont souvent le moment où les équipes retrouvent du souffle. Et alors, la question plus grande peut être posée : Comment le site reste-t-il rapide lorsqu'il grandit ?
Vous voulez une liste claire des priorités ?
L'erreur de performance la plus fréquente survient après la correction : on se soulage - et on oublie à nouveau le sujet. Jusqu'à ce que le site s'alourdisse à nouveau six mois plus tard.
Ce n’est pas un défaut de caractère, mais normal. Les sites Web sont des systèmes vivants. Le contenu grandit, des outils sont ajoutés, les équipes changent. C'est précisément pourquoi la performance nécessite une petite routine.
Nous recommandons une attitude simple : La performance est un entretien, pas un projet. C'est tout aussi bien prouvé sur le plan scientifique que pratique – le mythe « optimiser une fois suffit » perdure, mais est faux. <cite data-type="source" data-url="https://bluetriangle.com/blog/debunking-7-myths-about-website-speed-and-the-user-experience#:~:text=Myth%20,time%20project">Blue Triangle</cite>
Concrètement, cela signifie :
Premièrement : Définissez un petit budget. Par exemple : « Images dans le Hero maximum 250 Ko » ou « Aucune nouvelle intégration externe sans examen rapide ». Ce n'est pas de la bureaucratie, mais de la protection.
Deuxièmement : Vérifiez régulièrement. Une fois par mois suffit à de nombreuses équipes. Nous aimons pour cela un mélange entre vérification d'outil et intuition : un rapide tour dans Lighthouse plus un test personnel sur smartphone, sans Wi-Fi.
Troisièmement : Nommez une responsabilité. Pas « l'informatique », mais une personne ou un rôle qui peut poser la question : « Cela alourdit-il le site ? » Les décisions marketing (nouveaux tags, nouveaux widgets) ont besoin de cet alter ego.
Quatrièmement : Vérifications de publication. Lorsque vous apportez régulièrement des modifications en direct, un rapide contrôle de la vitesse est un peu comme une ceinture de sécurité.
L’avantage : une fois que la performance est intégrée dans le quotidien, tout devient plus léger. Vous n’avez plus à sauver. Vous construisez comme ça, pour ne pas regretter.
Et : Cette attitude convient à Purpose. Car la durabilité signifie fondamentalement cela : concevoir des choses pour qu'elles fonctionnent encore demain – sans effort continu excessif, sans gaspillage.
Si nous voulons rendre la performance discutable, nous avons besoin de deux choses : une mesure de confiance pour tous - et une présentation compréhensible, pas seulement pour les développeurs.
Pour commencer, quelques outils suffisent, ceux que vous utiliserez vraiment :
1) PageSpeed Insights: Bon pour voir les Core Web Vitals (y compris les données de terrain) et obtenir des premiers indices.
2) WebPageTest: Si vous voulez savoir qu'est-ce qui charge, dans quel ordre. Le diagramme en cascade est inestimable pour trouver un frein « mystérieux ».
3) Lighthouse dans Chrome DevTools : Pratique pour les contrôles rapides en équipe, même avant une publication.
4) Onglet Réseau de Chrome DevTools : Pour nous, souvent le moyen le plus rapide d'obtenir un moment « Aha ». Vous voyez immédiatement si une image fait 4 Mo ou si un script externe attend longtemps.
Pour aller plus loin (surtout avec de plus grands sites) : alors le Real User Monitoring, c'est-à-dire les données d’utilisation réelles, en vaut la peine. C'est la perspective qui complète les tests en laboratoire. Beaucoup d'équipes commencent petit, par exemple avec des mesures récurrentes dans un outil de surveillance.
Et voici une phrase de pratique importante que nous répétons souvent : N’optimisez pas pour le score, optimisez pour les gens. Le score est un guide, pas un verdict.
Si vous devez argumenter en interne, les faits concrets vous aideront : Plus de 3 secondes de temps de chargement signifient souvent de hauts rebonds mobiles. <cite data-type="source" data-url="https://www.emit-solution.com/blog/website-zu-langsam#:~:text=,langsame%20Websites">EMIT Solution</cite> Et la vitesse est perçue par les utilisateurs comme un facteur de qualité essentiel. <cite data-type="source" data-url="https://www.thinkwithgoogle.com/intl/en-emea/marketing-strategies/app-and-mobile/need-speed-evaluating-perception-and-reality-speed-mobile-web/">Think with Google</cite>
Cela suffit généralement pour transformer un « ressenti » en une décision claire : Nous n’investissons pas dans l’optimisation parce que nous sommes des nerds – mais parce que nous prenons le temps, la confiance et les ressources au sérieux.
FAQ sur les sites Web lents
WordPress est-il automatiquement lent ?
Pourquoi mon site Web est-il lent malgré une connexion Internet rapide ?
Quelle vitesse devrait idéalement avoir un site Web en 2026 ?
Quel rôle joue vraiment l'hébergement ?
Comment optimiser correctement les images sans perte de qualité ?
La performance améliore-t-elle vraiment le SEO ?
Combien coûte typiquement une optimisation de performance ?
Envoyez-nous un message ou réservez directement un premier entretien non contraignant – nous sommes impatients de vous rencontrer, vous et votre projet.
Nos plans
Droit d'auteur © 2026 Pola
En savoir plus
Directement vers
TM
De nombreuses tentatives d'optimisation échouent car nous pensons au « chargement » comme à un moment unique. En réalité, c'est une chaîne de petites étapes – et si l'une d'elles trébuche, vous le ressentez dans l'ensemble.
Imaginez l'appel de votre site comme l'arrivée dans un café : D'abord, vous devez trouver l'adresse (DNS), puis la porte s'ouvre et quelqu'un dit « tout de suite » (réponse du serveur, souvent visible sous forme de TTFB – Time to First Byte). Ensuite vient le menu (HTML), puis l'agencement, l'atmosphère, la musique (CSS, images, polices) et enfin, les petits extras qui rendent tout interactif (JavaScript).
C'est ici que réside la cause de nombreux moments « site lent malgré un Internet rapide » : Votre réseau est peut-être rapide, mais la porte s'ouvre tardivement (TTFB élevé) ou il y a trop de choses dans la pièce avant de pouvoir vous asseoir (CSS/JS bloquant le rendu).
Une fois que vous avez compris cela, votre diagnostic change.
Notre méthode éprouvée n°1 : La chaîne des trois questions. Nous l'utilisons dans presque toutes les premières vérifications, car elle permet aux non-techniciens d'agir rapidement :
1) Le navigateur attend-il le serveur ? (TTFB remarquablement élevé)
2) Le navigateur attend-il des fichiers ? (trop de requêtes / trop grandes)
3) Le navigateur attend-il lui-même ? (charge CPU par JavaScript, mauvaise interactivité)
Vous pouvez vérifier cela grossièrement sans connaissances spécialisées : ouvrez Chrome, appuyez sur F12, allez dans « Réseau » et rechargez la page. Si vous avez besoin de soutien, Chrome DevTools est étonnamment accessible.
La plupart des guides passent directement à « compresser les images ». C'est souvent correct - mais pas toujours. Parfois, le frein est un script externe qui bloque brièvement, parfois une configuration d'hébergement qui construit chaque page dynamiquement, alors que cela pourrait être plus rapide.
Lorsque vous voyez le temps de chargement comme une chaîne, vous ne trouvez pas seulement le coupable. Vous trouvez également le bon ordre. Et cela économise du temps, de l'argent et des nerfs.