Un directeur e-commerce migre une boutique Magento 2 vers le même serveur privé virtuel que l'ancien site WordPress « qui marchait très bien ». Indexation bloquée, paiement à douze secondes, tâches planifiées en retard. Ce n'est pas Magento « mal optimisé » : c'est Magento sur une stack pensée pour un CMS léger. Magento n'est pas un WordPress lourd. C'est une plateforme commerce avec indexeurs, cache multi-couches et modes d'exécution qui punissent toute approximation.
Architecture Magento : ce qui consomme vraiment
| Composant | Rôle | Sans lui |
|---|---|---|
| Indexeurs | Prix, stock, recherche catalogue | Données périmées, lenteur admin |
| Redis | Sessions, cache backend | Sessions fichiers, entrées-sorties disque |
| Varnish / cache page | Pages catalogue | Rendu PHP chaque visite |
| Elasticsearch | Recherche catalogue | Requêtes LIKE insupportables |
| Cron / consommateurs | Files asynchrones | Courriels, index bloqués |
| Mode production | Code compilé, caches chauds | Mode développeur = catastrophe |
Mettre Magento en mode développeur en production, c'est garer un poids lourd en côte sans moteur.
Dimensionner l'hébergement sans marketing
Petite boutique B2C. Serveur huit gigaoctets, Redis, cache page, PHP récent, cron fiable.
Catalogue moyen plus promos. Seize gigaoctets, Elasticsearch dédié ou managé, séparer admin et frontend si possible.
Adobe Commerce / enterprise. Cloud Adobe, grappe ou bare metal avec équipe exploitation vingt-quatre heures sur vingt-quatre.
Comparez via annuaire en filtrant offres compatibles PHP long-running et Redis.
Signaux d'un hébergeur Magento-ready
Cache opcode PHP et extensions requises documentées. Redis managé ou installable. Cron chaque minute ou workers file. Elasticsearch disponible ou connectable faible latence. Préproduction clone complet. Support qui connaît index bloqué et compilation.
Un hébergeur « PHP générique » vous laisse seul sur indexation bloquée un dimanche — budgétez un intégrateur ou choisissez un acteur habitué au commerce.
La préproduction doit reproduire modules, volume médias et configuration cache : une stack allégée masque les échecs checkout jusqu'au go-live.
Erreurs classiques de migration
Copier configuration sans adapter Redis/Elasticsearch. Oublier permissions répertoires générés. Médias volumineux sans réseau de diffusion. Modules custom incompatibles PHP 8. Tester performances en mode développeur.
Le sommet : Magento exige une stack
Si votre besoin est une boutique simple, PrestaShop ou WooCommerce bien exploités peuvent suffire — voir PrestaShop et gros catalogue.
Décider et avancer sans angle mort
Passez en mode production avec caches chauds avant go-live. Vérifiez indexeurs et cron sous charge simulée. Configurez Redis et cache page minimum. Dimensionnez mémoire selon références produits et modules. Planifiez préproduction identique production. Consultez le comparateur pour croiser hébergeurs et usages e-commerce.
Questions fréquentes
Quelle configuration minimum pour Magento Open Source ?
Quatre à huit gigaoctets petite boutique, seize plus catalogue moyen. Jamais mode développeur en prod.
Redis et Varnish sont-ils obligatoires ?
Redis quasi standard ; cache page fortement recommandé pour trafic non trivial.
Peut-on héberger Magento en mutualisé ?
Non pour boutique sérieuse — serveur haut de gamme ou cloud dédié minimum.
Magento Cloud vaut-il le surcoût ?
Oui si stack préconfigurée et SLA Adobe ; comparez coût total versus exploitation interne.
Magento ne demande pas « un peu plus de RAM ». Il demande une stack pensée pour lui — ou une facture d'incident qui le rappellera.