Guides Tutoriel

Optimisation des performances PrestaShop : Accélérer votre boutique

Guide complet d'optimisation des performances : OPcache, MySQL, configuration CCC, optimisation des images, stratégies de cache et Core Web Vitals.

La vitesse est un problème de conversion, pas une métrique de prestige

Nous développons Performance Revolution, notre module de mise en cache, Critters et PurgeCSS, et nous l'utilisons sur les boutiques à fort trafic que nous exploitons nous-mêmes. Le constat est d'une régularité décourageante : la plupart des boutiques PrestaShop sont lentes pour les cinq mêmes raisons, et quatre d'entre elles se corrigent en une après-midi.

La vitesse rapporte sur trois plans :

  • Les conversions. Sur les boutiques Hummingbird que nous exploitons, faire passer le LCP médian de 4 s à 2 s augmente généralement la conversion mobile de 30 à 60 %.
  • Le référencement. Google utilise les Core Web Vitals comme signal de classement depuis 2021. Les boutiques lentes captent moins de trafic organique et paient davantage le trafic payant pour compenser.
  • Le mobile. 70 % du trafic e-commerce est mobile. Une page qui semble correcte sur un MacBook peut rester un écran blanc pendant 6 secondes sur un Android de milieu de gamme.
La vitesse est une discipline d'entretien, pas un projet que l'on termine. Chaque module, chaque retouche du thème, chaque image la fait monter ou descendre. Nous conservons une référence de LCP pour chaque boutique cliente et la vérifions après chaque déploiement. Consultez nos notes d'optimisation des performances pour le travail sur la base de données, le cache et la mesure qui sous-tend ces gains.

Mesurez avant de toucher à quoi que ce soit

Le moyen le plus rapide de gâcher une journée est de commencer à « optimiser » sans chiffres. Chaque boutique que nous auditons reçoit d'abord la même mesure sur trois pages (accueil, catégorie, produit), car chacune sollicite une partie différente de l'environnement technique.

Les outils que nous utilisons réellement

  • Google PageSpeed Insights : Gratuit, s'appuie sur des données réelles d'utilisateurs Chrome (CrUX). Lancez-le sur les trois types de page. Ce sont les pages de catégorie et de produit qui font s'effondrer la plupart des boutiques.
  • GTmetrix : La cascade de requêtes indique quelle requête bloque le rendu, quel module envoie 600 Ko de CSS inutilisé et quel script tiers ajoute 800 ms avant le TTFB.
  • WebPageTest : Vue en pellicule depuis différents continents et profils de connexion. À utiliser quand GTmetrix et PSI ne sont pas d'accord.

Core Web Vitals : ce que chacun vous apprend

  • LCP (Largest Contentful Paint) : Le moment où le plus grand élément visible finit de s'afficher. Visez moins de 2,5 s. Sur la plupart des boutiques PrestaShop, il s'agit de l'image principale ou de la bannière de catégorie, et le coupable est le CSS bloquant le rendu, conjugué à une image non optimisée et sans préchargement.
  • INP (Interaction to Next Paint) : La vitesse à laquelle la page réagit à un appui ou un clic. A remplacé le FID en mars 2024. Visez moins de 200 ms. Suspects habituels : modules lourds en jQuery, gestionnaires de balises et gestionnaires de clic qui en font trop de façon synchrone.
  • CLS (Cumulative Layout Shift) : L'ampleur des sauts de la page pendant le chargement. Visez moins de 0,1. Causé par des images sans largeur/hauteur, des bannières tardives et des permutations de polices sans police de repli adaptée.

Des objectifs réalistes

La logique de panier, la recherche, les modules et le suivi peuvent rendre un score de 100 plus difficile à atteindre sur une vraie boutique PrestaShop. Nos objectifs : 60 à 80 sur mobile, 85 à 95 sur ordinateur, un LCP sous 2,5 s sur mobile / 1,8 s sur ordinateur, un poids total sous 2 Mo, moins de 80 requêtes au premier affichage.

Ne courez pas après un 98 en supprimant ce qui vous fait gagner de l'argent. Un 65 avec une conversion saine vaut mieux qu'un 98 sur une page où personne n'achète.

Le serveur : là où se cache le plus de latence

Aucune astuce côté interface ne vous sauvera d'un backend lent. Si PrestaShop met 800 ms à produire le HTML avant la moindre requête d'actif, c'est votre plancher.

PHP OPcache : non négociable

OPcache conserve en mémoire le bytecode PHP compilé pour que l'interpréteur ne réanalyse pas les mêmes fichiers à chaque requête. PrestaShop charge des centaines de fichiers PHP par page. Sans OPcache, vous payez ce coût d'analyse à chaque fois.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

Les valeurs par défaut sont mauvaises pour PrestaShop. Régler max_accelerated_files sur 20 000 vous laisse une marge. Une installation PS typique comporte de 10 à 15 k fichiers PHP ; la valeur par défaut est de 10 000, arrondie en interne à 16 229 clés. memory_consumption devrait être de 128 à 256 Mo. Si le cache se remplit, OPcache évince des entrées et vous perdez silencieusement le bénéfice.

Sur les hébergements cPanel avec validate_timestamps=0, OPcache ne relira jamais les fichiers PHP depuis le disque de lui-même. Vous devez le réinitialiser via une requête web après chaque déploiement, une réinitialisation en CLI ne vide que le pool CLI, pas le pool web. Nous avons débogué des tickets « mon correctif ne se déploie pas » qui se révélaient être exactement cela.

MySQL / MariaDB : le seul réglage qui compte

Une page produit PrestaShop exécute généralement de 80 à 200 requêtes SQL. Une page de catégorie avec filtres peut dépasser 400. La variable la plus importante est innodb_buffer_pool_size :

[mysqld]
# À régler entre 50 et 70 % de la RAM disponible sur un serveur de base de données dédié
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# MySQL 5.7 / MariaDB uniquement (supprimé dans MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Repérer les requêtes problématiques
slow_query_log = 1
long_query_time = 1

# Paramètres de connexion
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Si votre base de données fait 500 Mo et votre buffer pool 1 Go, la plupart des requêtes sont servies depuis la RAM. Activez le journal des requêtes lentes et lisez-le chaque semaine. Une requête qui prend 1,2 s au repos prend 12 s sous charge, et c'est ainsi que le Black Friday tourne mal. La plupart des requêtes lentes que nous trouvons proviennent du contrôleur de recherche, des filtres de navigation à facettes sur les pages de catégorie et de modules de statistiques qui auraient dû être désactivés depuis des années.

Niveaux d'hébergement : soyez honnête avec vous-même

  • Mutualisé (5 à 15 $/mois) : Vous partagez le CPU et la RAM avec des centaines de voisins. Convenable pour une boutique de test de 200 produits, pas pour une vraie entreprise.
  • VPS (20 à 60 $/mois) : Là où se trouvent presque toutes les boutiques que nous exploitons. 4 Go de RAM au minimum, 2 cœurs, SSD NVMe. Idéal jusqu'à quelques centaines de commandes par jour.
  • Dédié (80 à 300 $/mois) : 1 000 commandes quotidiennes ou plus, ou des catalogues de plus de 100 k produits. Aussi pour quiconque fait tourner sa propre pile Varnish / Redis.
Si vous êtes sur un hébergement mutualisé et que c'est lent, passer à un VPS correct vous apporte plus de vitesse que toutes les autres astuces de cette page réunies. Nous avons vu le LCP chuter de 6 s à 2,2 s rien qu'avec le changement d'hébergement, sans rien d'autre.

PHP-FPM et Redis

Utilisez PHP-FPM plutôt que mod_php, pool de processus séparé, meilleur comportement mémoire, plus facile à régler pour les pics de trafic. Utilisez Redis pour le stockage des sessions et du cache plutôt que le système de fichiers. La configuration se trouve dans app/config/parameters.php :

'ps_cache_enable' => true,
'ps_caching' => 'CacheRedis',

Les interrupteurs intégrés de PrestaShop

La page Performances dans le back-office de PrestaShop 8.

C'est là que se trouvent le cache Smarty, le mode débogage, le CCC et le moteur de mise en cache. La plupart des optimisations de performances commencent ici.

Page Performances du back-office de PrestaShop 8 affichant les réglages Smarty, Mode débogage, CCC et Mise en cache

CCC (Combiner, Compresser, Mettre en cache)

Sous Paramètres avancés → Performances. Le CCC concatène et minifie vos fichiers CSS et JS. À activer systématiquement en production. Ce qui nous a déjà piégés :

  • Les fichiers marqués defer ou async restent séparés, par conception.
  • Les ressources externes (Google Fonts, Stripe.js, scripts Cloudflare) ne sont jamais combinées.
  • Les modules qui injectent des balises <link> brutes via displayHeader au lieu de actionFrontControllerSetMedia contournent entièrement le CCC. Chaque audit en révèle au moins un. Notre page sur les hooks détaille le correctif.
  • Si le CCC casse le tunnel de commande ou un widget, c'est que le module fait quelque chose de dépendant de l'ordre. Trouvez-le, corrigez-le ou remplacez-le, ne laissez pas le CCC désactivé.

Réglages des templates Smarty

Réglez la mise en cache des templates sur « Recompiler les templates si les fichiers ont été modifiés » en production. Jamais « Forcer la compilation », cela recompile chaque template à chaque requête, le pire mode Smarty possible.

Mode débogage : à vérifier en premier, à chaque fois

Le mode débogage désactive la plupart des mises en cache, force la recompilation et journalise abondamment. En production, la seule valeur correcte est false :

// Dans app/config/defines.inc.php : DOIT être false en production
define('_PS_MODE_DEV_', false);

Nous avons hérité de boutiques tournant en mode débogage depuis des mois. La « lenteur mystérieuse » disparaît dès que l'on bascule le drapeau. Vérifiez-le toujours dès la première passe d'audit.

Désactivez les modules que vous n'utilisez pas

Chaque module activé vous coûte : entrées d'autochargeur, fonctions de rappel de hooks, parfois du CSS/JS sur chaque page, parfois des requêtes en base de données même quand il n'y a rien à afficher. Une installation neuve s'accompagne d'une longue liste de modules, vous n'avez pas besoin de la plupart d'entre eux.

Parcourez Modules → Gestionnaire de modules et désinstallez (et pas seulement désactivez) tout ce que vous n'utilisez pas activement. Trois modules d'analyse faisant le même travail ? Gardez-en un. Si vous avez besoin d'un nettoyage structuré avant le réglage, Cleanup Revolution aide à éliminer les scories opérationnelles avant de commencer à mesurer.

Les images : généralement 60 à 80 % du poids de votre page

Les gains de LCP les plus importants et les plus faciles se trouvent ici. Nous avons vu le LCP de la page d'accueil chuter de 4,2 s à 1,6 s sur une seule boutique, simplement en régénérant les images aux bonnes dimensions et en servant du WebP.

WebP et des dimensions sensées

Le WebP est 25 à 35 % plus léger que le JPEG sans perte de qualité visible. PrestaShop 8+ le prend en charge nativement ; sur les versions plus anciennes, utilisez une conversion côté serveur ou un module.

Le gaspillage le plus courant : des fichiers source de 2000×2000 px servis dans un emplacement de vignette de 300 px. Configurez les types d'images sous Apparence → Paramètres d'image pour qu'ils correspondent à ce que votre thème affiche réellement. Ne téléversez pas de masters de 4000 px « au cas où », 1200 px suffisent pour un zoom produit en résolution retina.

Chargement différé

Différez tout ce qui se trouve sous la ligne de flottaison :

<img src="product.jpg" loading="lazy" width="300" height="300" alt="Product Name">

Ne différez pas le chargement du logo d'en-tête, de la bannière principale ou de la première rangée de produits. Ce sont des candidats au LCP, les charger en différé indique à Chrome de déprioriser l'élément même sur lequel il vous mesure. Nous avons vu cette seule erreur coûter 1,5 s de LCP à une boutique. Pour les catalogues où les templates du thème sont incohérents, Automatic SEO Images Lazy Tags peut appliquer le motif sous la ligne de flottaison à grande échelle.

Régénérer après une modification

Après avoir modifié les dimensions d'un type d'image, régénérez via le back-office ou la CLI :

php bin/console prestashop:image:regenerate --type=products

Les optimisations côté interface qui font vraiment la différence

Réduire les requêtes HTTP

Ouvrez votre cascade de requêtes. Au-delà de 100 requêtes, il y a un problème. Coupables habituels : chaque module chargeant son propre petit fichier CSS/JS, Google Fonts avec quatre graisses et des italiques, des widgets de partage social tirant leurs propres SDK, deux gestionnaires de balises qui se disputent.

CSS critique

Les navigateurs bloquent le rendu jusqu'à ce que chaque fichier CSS du <head> soit téléchargé. Le CSS critique intègre les styles nécessaires à la zone d'affichage initiale directement dans le HTML, puis charge la feuille de style complète de façon asynchrone. Sur mobile, cela nous fait régulièrement gagner 1 à 2 s de LCP. Performance Revolution génère le CSS critique automatiquement via Critters et le maintient à jour quand le CSS du thème change, le faire à la main à chaque retouche du thème est une corvée qui n'est jamais réalisée.

JavaScript : defer est votre allié

Utilisez defer pour presque tout, le script se télécharge en parallèle mais ne s'exécute qu'une fois le HTML analysé. Réservez async aux scripts réellement indépendants comme l'analyse d'audience. Dans PrestaShop 1.7+ :

$this->context->controller->registerJavascript(
    'module-my-script',
    'modules/mymodule/views/js/front.js',
    ['position' => 'bottom', 'priority' => 200, 'attribute' => 'defer']
);

Polices

Les polices personnalisées ajoutent discrètement 200 à 400 Ko. Ce que nous faisons sur chaque boutique :

  • Héberger soi-même plutôt que de tirer depuis Google Fonts, cela économise une résolution DNS et une poignée de main TLS.
  • Sous-ensembler aux caractères dont vous avez besoin. Le latin seul est 60 à 80 % plus léger que l'Unicode complet.
  • font-display: swap pour que le texte visible n'attende jamais une police.
  • Deux graisses au maximum. 400 et 700 couvrent presque tous les thèmes.
  • WOFF2 uniquement : meilleure compression, prise en charge universelle des navigateurs modernes.
@font-face {
    font-family: 'YourFont';
    src: url('/themes/your-theme/assets/fonts/yourfont.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

Les bases du CDN

Un CDN sert les fichiers statiques depuis des serveurs proches de vos visiteurs. Cloudflare est le point de départ gratuit le plus évident. Pointez les images, le CSS et le JS vers le domaine du CDN via Paramètres avancés → Performances → Serveurs de médias.

Optimisation de la base de données

Les bases de données PrestaShop gonflent en silence. Des tables qui allaient bien au lancement deviennent des boulets après deux ans d'abandons de panier, de trafic de robots et de journaux de modules que personne ne lit.

Nettoyer les anciens paniers

ps_cart et ps_cart_product reçoivent une ligne par visiteur, y compris chaque robot ayant exploré le catalogue. Au bout d'un an, ces tables atteignent couramment des millions de lignes, et chaque jointure contre elles ralentit.

-- Supprimer les produits de panier pour les anciens paniers abandonnés (non liés à des commandes)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Supprimer les paniers vides
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
LEFT JOIN ps_cart_product cp ON c.id_cart = cp.id_cart
WHERE o.id_order IS NULL AND cp.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);
Sauvegardez d'abord, passez par un environnement de préproduction d'abord. Le motif LEFT JOIN + IS NULL est ce qui protège les paniers devenus des commandes, faites-le mal et vous orphelinez l'historique des commandes.

Journaux et connexions

-- Journaux applicatifs
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Suivi des visiteurs
DELETE FROM ps_connections_page WHERE id_connections IN (
    SELECT id_connections FROM ps_connections
    WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Enregistrements invités orphelins
DELETE g FROM ps_guest g
LEFT JOIN ps_connections c ON g.id_guest = c.id_guest
WHERE c.id_guest IS NULL;

-- Statistiques de recherche, journaux 404, journaux d'e-mails
DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Index de recherche

Si vous utilisez Elasticsearch, Algolia ou tout moteur de recherche externe, les tables de recherche intégrées sont du poids mort que PrestaShop reconstruit pourtant :

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Optimiser les tables et ajouter des index

Après de grosses suppressions, récupérez l'espace :

OPTIMIZE TABLE ps_cart, ps_cart_product, ps_connections,
    ps_connections_page, ps_guest, ps_log;

Les index que nous avons ajoutés sur presque toutes les boutiques que nous auditons :

-- Vérifier d'abord les index existants : SHOW INDEX FROM ps_cart;
ALTER TABLE ps_cart ADD INDEX idx_cart_date (date_add);
ALTER TABLE ps_connections ADD INDEX idx_conn_date (date_add);
ALTER TABLE ps_orders ADD INDEX idx_orders_ref (reference);
ALTER TABLE ps_product ADD INDEX idx_product_ref (reference);

Lancez EXPLAIN sur les requêtes de votre journal des requêtes lentes. Si type indique ALL, la base de données fait un balayage complet. Le bon index transforme généralement une requête de 4 secondes en 12 ms.

Stratégies de mise en cache

Cache de page complet

Le plus grand levier dont vous disposez. Sans lui, chaque requête anonyme exécute l'ensemble de l'environnement technique, des centaines de fichiers PHP, plus de 100 requêtes, 200 à 500 ms de rendu. Avec lui, la même page part en 5 à 20 ms. Sur les boutiques Hummingbird que nous exploitons, l'activation du FPC réduit généralement le LCP mobile de 1,2 à 1,8 s en plus de tout le reste.

Varnish est la référence du secteur. Le cache FastCGI de nginx est plus simple si vous utilisez déjà nginx :

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PS:100m inactive=60m;

set $skip_cache 0;
if ($http_cookie ~* "PrestaShop-") { set $skip_cache 1; }
if ($request_uri ~* "/cart|/order|/my-account|/admin") { set $skip_cache 1; }

location ~ \\.php$ {
    fastcgi_cache PS;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

Le difficile n'est pas de l'activer, c'est l'invalidation. Quand un prix change, qu'un stock baisse ou qu'un administrateur modifie une catégorie, les bonnes pages mises en cache doivent être abandonnées. C'est cette complexité qui fait que tant de boutiques n'activent jamais le FPC. C'est aussi ce dont Performance Revolution se charge pour vous sur PrestaShop.

Cache d'objets et cache navigateur

Le cache d'objets (Redis) conserve les résultats de requêtes en mémoire entre les requêtes. Gain plus modeste que le FPC (généralement 30 à 50 % de temps de requête en moins), mais l'invalidation est automatique, ce qui en fait la première étape sûre.

Les en-têtes de cache navigateur indiquent aux navigateurs des visiteurs de conserver les fichiers statiques localement :

# Apache (.htaccess)
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Ce qui détruit discrètement les performances

  • Trop de modules activés. Chacun vous coûte, entrées d'autochargeur, fonctions de rappel de hooks, souvent du CSS/JS, souvent des requêtes. Une boutique sobre l'emporte presque toujours sur une boutique surchargée à matériel identique. Aucun module n'est gratuit.
  • Des modules chargeant des actifs sur chaque page. Un module de pop-up qui ne se déclenche que sur la page d'accueil mais envoie 150 Ko de JS sur chaque page produit est du pur gaspillage. Examinez votre cascade de requêtes à la recherche de chemins d'actifs de modules là où ils ne devraient pas être.
  • Les carrousels d'accueil. 3 à 5 images haute résolution plus une bibliothèque JS de carrousel, souvent 1 à 5 Mo au total, pour un composant avec lequel moins de 1 % des utilisateurs interagissent au-delà de la première diapositive. Nous les remplaçons par une bannière statique unique sur presque chaque refonte.
  • Des thèmes livrés sans revue de performances. Bootstrap complet pour trois composants, bundles non minifiés, aucune dimension d'image, scripts synchrones. Demandez aux développeurs de thèmes un score Lighthouse sur la démo avant d'acheter.
  • Des index manquants. Une requête avec le bon index s'exécute en 10 ms ; sans lui, la même requête en pic de trafic tourne pendant 5 s et fait la queue à toutes les requêtes derrière elle. Vous ne le remarquerez pas avant le Black Friday.

Liste de contrôle du suivi des performances

Vérifications rapides (5 minutes)

  • PageSpeed Insights sur l'accueil, la catégorie, le produit
  • _PS_MODE_DEV_ est à false
  • Smarty n'est pas sur « Forcer la compilation »
  • CCC activé
  • OPcache actif selon phpinfo()

Entretien mensuel (30 minutes)

  • Nettoyer les paniers abandonnés de plus de 3 mois
  • Nettoyer ps_log, ps_connections, ps_connections_page, ps_guest
  • Lancer OPTIMIZE TABLE sur les tables nettoyées
  • Examiner le journal des requêtes lentes
  • Désinstaller tout module inutilisé

Revue trimestrielle (2 heures)

  • Test GTmetrix complet depuis plusieurs emplacements, comparé au trimestre précédent
  • Examiner les Core Web Vitals dans Google Search Console
  • Auditer les actifs des modules à la recherche de CSS/JS superflus
  • Vérifier la taille des images pour repérer les téléversements surdimensionnés
  • Examiner l'utilisation des ressources serveur (CPU, RAM, E/S disque)
  • Tester sur un vrai mobile de milieu de gamme, pas sur l'émulateur de Chrome
  • Vérifier que les en-têtes de cache navigateur sont toujours en place
  • Vérifier les journaux d'erreurs PHP (les exceptions consomment des ressources même quand personne ne les voit)

Après chaque déploiement

  • Vider le cache de PrestaShop
  • Réinitialiser le pool web d'OPcache si validate_timestamps=0
  • Test PageSpeed rapide pour repérer les régressions
  • Vérifier la console du navigateur pour les erreurs JS
  • Parcourir le tunnel de commande de bout en bout

Par où commencer

Quatre choses, dans l'ordre : corriger la configuration du serveur (OPcache + buffer pool InnoDB + PHP-FPM), régénérer et servir les images aux bonnes dimensions en WebP, désinstaller les modules que vous n'utilisez pas, nettoyer la base de données. Cela couvre l'essentiel des problèmes de performances que nous trouvons lors des audits.

Mesurez avant et après chaque modification. Tenez un court journal de ce que vous avez fait et de l'évolution des chiffres. L'optimisation qui compte est celle que vos clients ressentent : des pages produit plus rapides, un tunnel de commande réactif. Cela se traduit par de la confiance, un taux de rebond plus faible et une conversion plus élevée.

Lectures complémentaires

Questions liées

Retour en haut