Santé et maintenance · Magento 2

Maintenance Magento 2 : les tâches quotidiennes, mensuelles et annuelles

Une boutique Magento 2 ne tombe presque jamais en panne d’un coup. Un cron qui s’arrête, un correctif oublié, un certificat qui expire, un disque qui se remplit : chaque panne commence par une tâche de maintenance sautée. Voici la checklist de maintenance Magento 2 rangée par fréquence, du quotidien à l’annuel, avec pour chaque tâche pourquoi elle compte et comment la vérifier. Et ce qui peut être automatisé, ou non.

Illustration : la cloche bleue de Tocsin24 sonne au-dessus d'un serveur sur lequel un mécanicien en bleu de travail, clé à la main, pose la main, devant un calendrier aux cases cochées.

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.log et les rapports de var/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 :

  1. Les messages en haut de l’administration. Un message sur les index invalides ou sur le cron se signale tout de suite à votre prestataire.
  2. L’état des index, dans Système > Outils > Gestion des indexes : tout doit être Prêt.
  3. Les comptes, dans Système > Permissions > Tous les utilisateurs : chaque compte a une personne derrière, et personne n’est parti.
  4. La version de Magento, en bas de chaque page de l’administration : comparez-la aux dates de fin de support.
  5. 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 :

Message à votre agence ou à votre prestataire

Bonjour,

Pour suivre la maintenance de notre boutique Magento, pouvez-vous nous envoyer chaque mois un court point sur :

  1. le cron et les files de messages : tournent-ils, et des tâches ont-elles échoué ?
  2. l’état des index et l’espace disque libre ;
  3. les correctifs de sécurité Adobe appliqués ce mois-ci, et ceux qui restent à appliquer ;
  4. les extensions à mettre à jour ou à retirer ;
  5. la date de la dernière restauration d’essai de nos sauvegardes ;
  6. 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.

  1. Le cron est-il installé ? Le bloc de Magento se trouve entre les commentaires #~ MAGENTO START et #~ MAGENTO END de la crontab de l’utilisateur.

    Terminal
    sudo crontab -l -u www-data
  2. 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 MariaDB
    Derniè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.

  3. 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.

  4. Le disque et les logs.

    Terminal, depuis le dossier de Magento
    df -h ls -lh var/log/
  5. Le certificat HTTPS, depuis n’importe quel ordinateur (remplacez l’adresse par celle de votre boutique) :

    Terminal, depuis n'importe quel ordinateur
    echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -enddate

    La réponse notAfter= donne la date d’expiration du certificat présenté.

  6. Les correctifs et les extensions : php vendor/bin/patch-status et composer 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.

Disque du serveur racine du site À surveiller
16 Go libres sur 100 Go 84 % utilisé
+2,5 Go par semaine · plein dans environ 6 semaines Relevé le 23/10 09:00

Erreurs de l'application

Logs Magento lus par le module Tocsin24, sans accès à créer chez votre hébergeur.

Récupérés
  • 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
exception.log fait 1,8 Go et remonte au 4 mars 2025 : la rotation des logs n'est pas en place.

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.

1 patch à appliquer
Octobre 2026
APSB26-153 · bulletin mensuel du 13 octobre 2026 Télécharger 2-4-8-p5-oct-2026.zip, puis appliquer 248p5-2026-10-001-CE.patch 11 failles exposées, dont 1 critique. À appliquer après les patchs des mois précédents (cumulatifs).
À appliquer
Septembre 2026
APSB26-138 · bulletin mensuel du 8 septembre 2026 Archive 2-4-8-p5-sep-2026.zip · patch 248p5-2026-09-001-CE.patch 4 failles corrigées
Appliqué
Septembre 2026
APSB26-146 · hors calendrier du 7 septembre 2026 Exploitée activement Correctif VULN-39341, publié par une annonce Adobe à part 1 faille corrigée
Appliqué

É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.

Portrait de Cédric Michel

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Badge Adobe Commerce Developer Expert Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Sources

  1. Adobe : configurer et lancer le cron
  2. Adobe : gérer les files de messages (consumers_runner)
  3. Adobe : liste des consommateurs de files de messages
  4. Adobe : gérer les index (indexer:status)
  5. Adobe : bonnes pratiques de configuration des index
  6. Adobe : Index Management (administration)
  7. Adobe : Advanced > System (historique du cron)
  8. Adobe : maintenance après le lancement (post-launch)
  9. Adobe : sauvegardes du système (fonction obsolète depuis 2.3.0)
  10. Code source de Magento : message « indexers are invalid » (Indexer/Model/Message/Invalid.php)
  11. CNIL : sauvegarder
  12. Let's Encrypt : FAQ (durée de validité des certificats)
  13. Let's Encrypt : fin des e-mails d'expiration (4 juin 2025)
  14. Let's Encrypt : certificats ramenés à 45 jours d'ici 2028
  15. ICANN : renouvellement et expiration des noms de domaine