En bref
- Chaque jour : le cron tourne, les files de messages avancent, les index sont à jour, le disque a de la place.
- Chaque mois : les correctifs de sécurité d’Adobe (deuxième mardi), les extensions, les comptes et le certificat.
- Chaque trimestre : une restauration d’essai des sauvegardes. Chaque année : le nom de domaine et la fin de support de Magento et de PHP.
- La surveillance s’automatise. Les décisions, elles, demandent quelqu’un : vous, votre agence ou un contrat de maintenance.
Sommaire
Pourquoi une boutique Magento 2 a besoin de maintenance
Une boutique Magento ne se contente pas d’afficher des pages. En coulisses, des tâches planifiées recalculent les prix, envoient les e-mails, mettent à jour les index de recherche et traitent les exports. Adobe le dit clairement : sans cron bien configuré, Magento ne fonctionne pas comme prévu.
Autour de la boutique, d’autres choses vieillissent : le code reçoit des correctifs chaque mois, les certificats expirent, le disque se remplit, des comptes s’accumulent. La maintenance, c’est vérifier tout cela à temps, avant que le client ne le voie.
Cet article est la page centrale de notre blog : chaque tâche renvoie vers un guide détaillé. Vous avez aussi un site sous WordPress ? Les mêmes réflexes s’appliquent, et repérer un WordPress piraté en reprend les contrôles de sécurité.
La checklist de maintenance Magento 2 en un tableau
| Rythme | Tâche | Guide |
|---|---|---|
| Chaque jour | Cron, files de messages, index | plus bas |
| Chaque jour | Espace disque et taille des logs | Disque plein, rotation des logs |
| Chaque jour | Disponibilité de la boutique et commandes | plus bas |
| Chaque semaine | Erreurs répétées, fichiers de code modifiés | Skimmer Magecart |
| Chaque mois | Correctifs de sécurité Adobe | Correctifs Adobe |
| Chaque mois | Extensions inutiles ou sans mise à jour | Audit de sécurité |
| Chaque mois | Comptes administrateurs et intégrations | Compte suspect |
| Chaque mois | Certificat HTTPS | plus bas |
| Chaque trimestre | Restauration d’essai des sauvegardes | plus bas |
| Chaque trimestre | Réglages de sécurité de l’administration | Sécuriser Magento 2 |
| Chaque année | Nom de domaine, fin de support de Magento et de PHP | plus bas |
| Tout de suite | Correctif de priorité 1, faille critique, départ d’un prestataire | Failles de PHP, Magento piraté |
Chaque jour : vérifier que Magento tourne
Le cron de Magento
Pourquoi. Le cron lance, chaque minute, les tâches planifiées de Magento. Adobe en cite une partie : règles de prix du catalogue, newsletters, plans du site, alertes de prix et de stock, réindexation, mise à jour des taux de change, et tous les e-mails, y compris les confirmations de commande.
Comment vérifier. Depuis l’administration, le message « One or more indexers are invalid. Make sure your Magento cron job is running » est un signe d’alerte. Sur le serveur, la table cron_schedule dit quand le cron a tourné pour la dernière fois (commandes plus bas).
Ce qui est normal. Une dernière exécution datée de la minute en cours ou presque, et des tâches en success. Des tâches en missed ou error qui s’accumulent demandent une enquête.
Les files de messages
Pourquoi. Certaines opérations ne se font pas tout de suite : elles sont mises dans une file d’attente, puis traitées en arrière-plan par des « consommateurs ». C’est le cas des exports, des mises à jour d’attributs en masse, de la génération de codes promo ou du redimensionnement des images. Par défaut, c’est le cron (tâche consumers_runner) qui lance ces consommateurs.
Comment vérifier. Un export qui n’arrive jamais ou une modification en masse qui ne s’applique pas sont les signes visibles. Sur le serveur, on vérifie que les consommateurs tournent.
Ce qui est normal. Les opérations lancées depuis l’administration se terminent en quelques minutes.
Les index
Pourquoi. Les index sont des tables précalculées : prix, catégories, recherche, stocks. Un index en retard, c’est un prix ou un stock faux sur la boutique. Adobe recommande le mode Mise à jour périodique pour les boutiques importantes ou très fréquentées : l’index se met à jour par le cron, en arrière-plan.
Comment vérifier. Système > Outils > Gestion des indexes : chaque index doit être à l’état Prêt. Sur le serveur, bin/magento indexer:status donne aussi le retard (« backlog »).
Ce qui est normal. Tous les index à l’état Prêt, un retard proche de zéro.
L’espace disque et les logs
Pourquoi. Un disque plein arrête la base de données et bloque les commandes. Les logs de Magento grossissent sans fin s’ils ne tournent pas.
Comment vérifier. L’espace libre et son évolution d’une semaine à l’autre. La taille de var/log/system.log et var/log/exception.log. Le détail est dans disque plein sur Magento et rotation des logs.
Ce qui est normal. Plus de 20 % d’espace libre, une croissance régulière et explicable, des logs qui tournent chaque nuit.
La disponibilité et les commandes
Pourquoi. Une boutique peut être en panne sans que personne ne le remarque la nuit ou le week-end. Et une boutique qui répond mais ne prend plus de commandes est aussi en panne.
Comment vérifier. Une sonde qui appelle la boutique à intervalle régulier, et un œil sur le nombre de commandes du jour par rapport aux jours habituels.
Ce qui est normal. La boutique répond, en un temps stable, et les commandes arrivent à leur rythme habituel.
Chaque semaine : lire les erreurs de Magento
- Les erreurs qui se répètent. Les dernières lignes de
exception.loget les rapports devar/report. Une même erreur répétée des milliers de fois cache un bug, et parfois une attaque. - Les fichiers de code modifiés. Un fichier changé hors d’un déploiement connu peut être une porte dérobée ou un skimmer de carte bancaire.
- Les sauvegardes de la semaine. Elles ont bien eu lieu, et une copie est hors du serveur.
Chaque mois : sécurité et mises à jour de Magento
- Les correctifs de sécurité. Adobe publie des correctifs isolés chaque mois, le deuxième mardi. Ils ne changent pas le numéro de version : une boutique peut sembler à jour et rester exposée. La méthode est dans notre guide des correctifs Adobe. PHP a ses propres failles : voir par exemple les failles critiques de PHP d’octobre 2026.
- Les extensions. Chacune est du code à suivre. Retirez celles qui ne servent plus, vérifiez que les autres reçoivent encore des mises à jour. Adobe recommande d’auditer régulièrement le code sur mesure et les extensions tierces. Voir le point 3 de l’audit de sécurité.
- Les comptes et les intégrations. Adobe recommande d’auditer régulièrement les comptes et de retirer ceux qui ne sont plus utilisés. Un compte d’ancien salarié ou d’ancienne agence est une porte ouverte. Voir repérer un compte administrateur suspect.
- Le certificat HTTPS. Les certificats de Let’s Encrypt, très répandus, durent aujourd’hui 90 jours. Let’s Encrypt a annoncé leur réduction : 64 jours à partir du 10 février 2027, puis 45 jours à partir du 16 février 2028. Et depuis le 4 juin 2025, Let’s Encrypt n’envoie plus d’e-mail avant l’expiration. Le renouvellement doit donc être automatique, et surveillé : un renouvellement qui échoue en silence, c’est une boutique affichée « non sécurisée » quelques semaines plus tard.
Chaque trimestre : tester les sauvegardes de la boutique Magento
- Une restauration d’essai des sauvegardes. La CNIL recommande de tester régulièrement l’intégrité des sauvegardes et la capacité à les restaurer. Elle range parmi les erreurs à éviter de ne jamais vérifier si elles sont exploitables, et de garder les sauvegardes sur le même système que les données. L’outil de sauvegarde intégré à Magento est obsolète depuis la version 2.3.0 : la sauvegarde se fait avec les outils du serveur ou de l’hébergeur.
- Les réglages de sécurité de l’administration : double authentification pour tous, adresse de l’administration, verrouillage après échecs. Voir sécuriser Magento 2.
- Un audit complet, avec notre liste de contrôle en 10 points.
Chaque année : les échéances qu’on oublie
- Le nom de domaine. Un domaine expiré, c’est une boutique et des e-mails coupés. Pour un
.com, la politique de l’ICANN impose au bureau d’enregistrement d’envoyer deux rappels, environ un mois puis une semaine avant l’expiration. Encore faut-il que l’adresse de contact soit à jour. Activez le renouvellement automatique et gardez un moyen de paiement valide. Pour un.fr, les conditions sont celles de votre bureau d’enregistrement : vérifiez la date d’expiration dans votre espace client. - La fin de support de Magento et de PHP. Une version hors support ne reçoit plus de correctifs. Les dates sont dans notre guide des correctifs. Notez-les dans l’agenda un an à l’avance : une montée de version se prépare.
- Les accès et les contrats. Qui a encore un accès FTP, SSH, au serveur, à la base ? Quels contrats (hébergement, extensions payantes, certificats non gratuits) arrivent à échéance ?
Maintenance Magento : ce qui s’automatise, ce qui demande un humain
| Tâche | Automatisable | Ce qui reste humain |
|---|---|---|
| Cron, files de messages, index | La surveillance et l’alerte | Comprendre pourquoi ils se sont arrêtés |
| Espace disque, logs | La rotation des logs, l’alerte | Trouver ce qui grossit, agrandir le disque |
| Disponibilité, commandes | La sonde, l’alerte | Diagnostiquer la panne |
| Correctifs de sécurité | La détection des correctifs manquants | Les appliquer, les tester, déployer |
| Extensions | La détection des failles connues | Décider de garder, remplacer ou retirer |
| Comptes et intégrations | La détection des nouveaux comptes | Savoir qui est derrière chaque compte |
| Certificat | Le renouvellement, l’alerte | Réparer un renouvellement en échec |
| Sauvegardes | La sauvegarde elle-même | La restauration d’essai, et son verdict |
| Nom de domaine | Le renouvellement automatique | Garder le contact et le paiement à jour |
Vous gérez la boutique : votre part de la maintenance Magento
Sans terminal, depuis l’administration de Magento :
- Les messages en haut de l’administration. Un message sur les index invalides ou sur le cron se signale tout de suite à votre prestataire.
- L’état des index, dans Système > Outils > Gestion des indexes : tout doit être Prêt.
- Les comptes, dans Système > Permissions > Tous les utilisateurs : chaque compte a une personne derrière, et personne n’est parti.
- La version de Magento, en bas de chaque page de l’administration : comparez-la aux dates de fin de support.
- Le nom de domaine et le certificat : notez leur date d’expiration et vérifiez que le renouvellement est automatique.
Pour le reste, demandez un point régulier à la personne qui gère votre boutique :
Bonjour,
Pour suivre la maintenance de notre boutique Magento, pouvez-vous nous envoyer chaque mois un court point sur :
- le cron et les files de messages : tournent-ils, et des tâches ont-elles échoué ?
- l’état des index et l’espace disque libre ;
- les correctifs de sécurité Adobe appliqués ce mois-ci, et ceux qui restent à appliquer ;
- les extensions à mettre à jour ou à retirer ;
- la date de la dernière restauration d’essai de nos sauvegardes ;
- les dates d’expiration du certificat HTTPS et du nom de domaine.
Merci.
Vous gérez le serveur : les commandes de maintenance Magento
Les commandes bin/magento se lancent depuis le dossier de Magento, ici /var/www/boutique, avec l’utilisateur propriétaire des fichiers (www-data dans l’exemple). Aucune ne modifie la boutique.
-
Le cron est-il installé ? Le bloc de Magento se trouve entre les commentaires
#~ MAGENTO STARTet#~ MAGENTO ENDde la crontab de l’utilisateur.Terminalsudo crontab -l -u www-data -
Le cron tourne-t-il ? Ces requêtes, en lecture seule dans la base de Magento, donnent la dernière exécution et le bilan des dernières 24 heures.
Client MySQL ou MariaDBDernière tâche lancée, à comparer à l'heure actuelle SELECT MAX(executed_at) AS derniere_execution, NOW() AS maintenant FROM cron_schedule; Tâches des dernières 24 heures, par état SELECT status, COUNT(*) AS taches FROM cron_schedule WHERE scheduled_at > NOW() - INTERVAL 1 DAY GROUP BY status;Magento ne garde l’historique des tâches réussies qu’une heure par défaut, et celui des échecs trois jours : ces requêtes ne disent rien d’un passé plus ancien.
-
Les index et les files de messages.
Terminal, depuis le dossier de MagentoÉtat et retard de chaque index bin/magento indexer:status Consommateurs déclarés bin/magento queue:consumers:list Consommateurs en cours d'exécution pgrep -af 'queue:consumers:start'Une colonne Schedule Status qui affiche un gros retard (« 12345 in backlog ») veut dire que le cron ne suit plus.
-
Le disque et les logs.
Terminal, depuis le dossier de Magentodf -h ls -lh var/log/ -
Le certificat HTTPS, depuis n’importe quel ordinateur (remplacez l’adresse par celle de votre boutique) :
Terminal, depuis n'importe quel ordinateurecho | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -enddateLa réponse
notAfter=donne la date d’expiration du certificat présenté. -
Les correctifs et les extensions :
php vendor/bin/patch-statusetcomposer audit --locked, détaillés dans notre guide des correctifs et l’audit de sécurité.
Tocsin24 fait la surveillance, vous gardez les décisions
Avec le module Magento installé, Tocsin24 surveille en continu une bonne partie de cette checklist. La disponibilité et le temps de réponse de la boutique, par une sonde à la fréquence que vous choisissez : un certificat HTTPS qui n’est plus valide fait échouer la sonde, et l’incident « Site injoignable » s’ouvre. L’espace disque et son rythme de remplissage, la taille des logs. Les correctifs mensuels d’Adobe non appliqués et les failles connues de votre version. Les nouveaux comptes administrateurs, les nouvelles intégrations et leurs jetons d’accès. Les fichiers de code modifiés hors déploiement. Les commandes et inscriptions qui s’arrêtent.
Tocsin24 ne surveille pas directement le cron, les files de messages ni les index. Un signe indirect existe : le contrôle du code de Tocsin24 tourne avec le cron de Magento. S’il était actif et que Tocsin24 n’en a plus rien reçu depuis 24 heures, l’incident « Protection disparue » s’ouvre. Tocsin24 ne vérifie ni vos sauvegardes, ni l’échéance de votre nom de domaine, ni la date d’expiration du certificat avant qu’il ne soit invalide : ces points restent dans votre calendrier.
Pour les décisions, notre TMA part de ces alertes : contrat de maintenance ou intervention à la demande, avec une estimation validée avant chaque intervention.
Espace disque
Espace libre sur le serveur du site.
Erreurs de l'application
Logs Magento lus par le module Tocsin24, sans accès à créer chez votre hébergeur.
- var/log/system.log 42 Mo écrit il y a 2 min
- var/log/exception.log 1,8 Go écrit il y a 3 min Rotation absente
Nous en lisons seulement les lignes récentes : la détection n'est pas gênée. Pour éviter de saturer le disque de la boutique, demandez à votre hébergeur ou à votre agence d'activer la rotation des logs Magento (archivage et compression réguliers).
Failles
Inventaire relevé chaque jour par le collecteur « Inventaire des correctifs », et exposition aux failles connues.
Magento
2.4.8-p5
Community
Supportée par Adobe jusqu'au 31 mai 2028
PHP
8.3.27
Correctifs de sécurité seulement, jusqu'au 31 décembre 2027
Module Tocsin24
1.0.2
Dernière vérification
23 octobre 2026 à 09:00
Correctifs de sécurité Adobe
Bulletins Adobe des 6 derniers mois qui visent la version 2.4.8-p5, avec l'archive à télécharger et le fichier de patch qu'elle contient. « Appliqué » quand le module a relevé le patch sur la boutique.
Écrans de l’application avec des valeurs d’exemple.
Questions fréquentes
Qu’est-ce que la maintenance d’une boutique Magento 2 ?
C’est l’ensemble des vérifications et des mises à jour qui gardent la boutique en état de vendre : tâches planifiées (cron), files de messages, index, espace disque, correctifs de sécurité, extensions, comptes, sauvegardes, certificat et nom de domaine. Une partie se surveille chaque jour, une autre se fait chaque mois ou chaque année.
À quelle fréquence mettre à jour Magento 2 ?
Adobe publie des correctifs de sécurité chaque mois, le deuxième mardi. Vérifiez-les chaque mois, et appliquez tout de suite un correctif de priorité 1. Le détail est dans notre guide des correctifs Adobe.
Que se passe-t-il si le cron de Magento ne tourne plus ?
La boutique continue d’afficher ses pages, mais tout ce qui est planifié s’arrête : index, e-mails, règles de prix, files de messages. Les prix et les stocks affichés peuvent devenir faux. Magento affiche alors souvent le message « One or more indexers are invalid. Make sure your Magento cron job is running ».
Un contrat de maintenance Magento est-il obligatoire ?
Non. Mais les tâches de cet article doivent être faites par quelqu’un : vous, votre agence, votre hébergeur ou un prestataire. Un contrat fixe qui s’en charge, à quel rythme, et dans quel délai en cas de panne.
Quelle partie de la maintenance peut-on automatiser ?
La surveillance : cron, files de messages, espace disque, disponibilité, certificat, comptes et fichiers modifiés se contrôlent par un outil, qui alerte. Les décisions restent humaines : appliquer un correctif, retirer une extension, tester une restauration, renouveler un contrat.
Sources
- Adobe : configurer et lancer le cron
- Adobe : gérer les files de messages (consumers_runner)
- Adobe : liste des consommateurs de files de messages
- Adobe : gérer les index (indexer:status)
- Adobe : bonnes pratiques de configuration des index
- Adobe : Index Management (administration)
- Adobe : Advanced > System (historique du cron)
- Adobe : maintenance après le lancement (post-launch)
- Adobe : sauvegardes du système (fonction obsolète depuis 2.3.0)
- Code source de Magento : message « indexers are invalid » (Indexer/Model/Message/Invalid.php)
- CNIL : sauvegarder
- Let's Encrypt : FAQ (durée de validité des certificats)
- Let's Encrypt : fin des e-mails d'expiration (4 juin 2025)
- Let's Encrypt : certificats ramenés à 45 jours d'ici 2028
- ICANN : renouvellement et expiration des noms de domaine