Configurer le cron, lire les rapports et lancer une réparation contrôlée (PrestaShop)

But de cet article

Ce guide explique comment configurer et vérifier le cron Securantis sur une boutique PrestaShop, où consulter les rapports et alertes, et comment lancer des actions de diagnostic et de réparation contrôlée depuis le module. L’objectif est de vous permettre d’automatiser la collecte d’informations et d’appliquer des corrections sûres sans interrompre la boutique.

Prérequis

1. PrestaShop 1.7 à 9 installé et accessible en tant qu’administrateur.
2. Module Securantis installé et activé dans le back‑office.
3. Licence Securantis active (les fonctions avancées de rapport et réparation peuvent être bloquées sans licence).
4. Accès SSH ou à l’interface d’administration de votre hébergement pour créer une tâche cron (si vous ne pouvez pas utiliser le planificateur du panneau d’hébergement, contactez votre hébergeur).
5. PHP à jour et extensions requises par PrestaShop (versions compatibles vérifiées dans votre espace client si nécessaire).

Vue d’ensemble du fonctionnement

• Le cron exécute périodiquement les contrôles locaux : inventaire, intégrité des fichiers, tables de quarantaine, token cron et collecte de diagnostics.
• Le module envoie des rapports et des événements au SaaS Securantis si l’envoi est activé. Vous pouvez recevoir des alertes automatiques par email ou via l’espace SaaS.
• Les réparations proposées par le module sont contrôlées : Securantis prépare et applique des correctifs comme la restauration de valeurs de configuration, la restitution de hooks et menus back‑office, la régénération d’un token cron ou les réparations des tables de quarantaine. La décision finale (quarantaine, suppression, restauration) reste humaine.

Étapes détaillées

1. Configurer la tâche cron (recommandé : 1 fois / heure ou 1 fois / jour)

   a. Ouvrez le panneau de gestion de votre hébergement ou utilisez SSH. b. Créez une tâche cron qui exécute l’URL publique fournie par le module Securantis ou la commande indiquée dans la page de configuration du module. Si le module propose un token cron, utilisez l’URL complète incluant ce token. c. Fréquence recommandée : une exécution par heure pour les boutiques à fort trafic ou à risque, une fois par jour pour les boutiques à faibles changements.

   Résultat attendu : le cron s’exécute sans erreur et le module enregistre des événements de collecte périodique.

2. Vérifier que la collecte et l’envoi des rapports sont activés

   a. Dans les réglages du module Securantis, activez l’envoi des rapports et des événements si nécessaire (option d’activation présente dans le module). b. Assurez‑vous que la licence est activée et que le domaine est bien lié dans votre compte Securantis.

   Résultat attendu : après la première exécution du cron, vous devez voir des rapports générés et, si activé, réception d’un premier événement dans l’interface SaaS ou par email.

3. Consulter les diagnostics et journaux depuis le back‑office

   a. Ouvrez la page de diagnostic / maintenance du module. b. Vérifiez l’heure de la dernière exécution, les éléments contrôlés (fichiers/éléments), et l’état des composants (2FA, pare‑feu, reCAPTCHA, protections de contenu) indiqués par le module.

   Résultat attendu : liste des contrôles exécutés et état général du module. Les traductions affichent des libellés comme « Activer le pare‑feu » ou « Activer la protection admin » selon les protections disponibles.

4. Lancer une réparation contrôlée depuis le back‑office

   a. Depuis la page maintenance du module, utilisez la fonction de réparation contrôlée. Celle‑ci exécute plusieurs étapes automatisées : restauration de configurations par défaut, réparation des hooks et menus back‑office, correction du token cron et vérification des tables de quarantaine. b. Confirmez uniquement les actions que vous comprenez. Le module doit afficher un compte rendu des sous‑actions (par exemple : « Table quarantaine », « Configuration par défaut », « Hooks PrestaShop », « Menus back‑office », « Token cron »).

   Résultat attendu : Série de résultats indiquant succès ou échec pour chaque sous‑action. Un journal de maintenance est généré.

Réglages prudents et recommandations

• Sauvegarde : effectuez toujours une sauvegarde complète (fichiers + base de données) avant d’appliquer des réparations qui modifient la base ou restaurent des tables.
• Quarantaine : toute mise en quarantaine, suppression ou restauration d’un fichier détecté comme suspect doit être décidée manuellement. Securantis préparera les opérations mais ne doit pas supprimer automatiquement des fichiers critiques sans votre approbation.
• Fréquence du cron : augmentez la fréquence si vous détectez des comportements suspects fréquents, baissez‑la si votre hébergement est limité en ressources.
• Journalisation : conservez les journaux locaux au moins 30 jours pour pouvoir revenir sur des événements antérieurs.

Erreurs fréquentes et solutions

1. Cron ne s’exécute pas

   • Cause courante : URL incorrecte, token cron absent, permissions d’accès bloquées par le firewall serveur.
   • Vérification : appelez l’URL du cron manuellement depuis votre navigateur (en local si nécessaire) et vérifiez la réponse HTTP. Consultez les logs d’accès web (ex. access.log).
   • Solution : corrigez l’URL ou régénérez le token cron depuis le module, vérifiez la configuration du firewall serveur.

2. Rapport non envoyé au SaaS

   • Cause courante : licence non activée, envoi de rapports désactivé, restrictions outbound sur l’hébergement.
   • Vérification : assurez‑vous que l’option d’envoi des rapports est activée et que la licence est validée. Testez la connectivité sortante vers les services Securantis depuis votre serveur.
   • Solution : activez la licence, autorisez les connexions sortantes ou demandez à l’hébergeur d’ouvrir l’accès.

3. Échec d’une sous‑action de réparation (ex. hooks, menus)

   • Cause courante : droits insuffisants en base de données, tables modifiées par d’autres modules, version PrestaShop non compatible.
   • Vérification : consultez le journal de la réparation pour l’erreur détaillée. Vérifiez les privilèges MySQL du compte utilisé par PrestaShop.
   • Solution : corrigez les privilèges, restaurez une sauvegarde si nécessaire, et relancez la réparation.

Dépannage avancé

• Nettoyage des journaux et du cache : si l’interface indique que les journaux locaux ont été nettoyés et le cache régénéré, relancez le cron et observez si le problème persiste.
• Forcer une réparation partielle : si une réparation globale échoue, lancez les réparations une à une (tables de quarantaine, configuration, hooks, menus, token) pour isoler l’étape problématique.
• Vérifier les modules complémentaires : certaines classes optionnelles (pare‑feu, protection admin, reCAPTCHA, protection de contenu) disposent de routines ensureDefaults. Si une de ces classes est absente ou incompatible, la réparation relative peut être ignorée ou générer un avertissement.

Précautions de sécurité et conformité

• Ne communiquez jamais vos mots de passe par email ou chat. Si une intervention payante est nécessaire, les accès vous seront demandés (ou fournis) via l’espace client sécurisé après paiement.
• Securantis ne supprime pas automatiquement les malwares : la quarantaine, la restauration ou la suppression exigent une décision humaine. Le module vous aidera à isoler les éléments suspects.
• Conservez des sauvegardes avant toute action de réparation affectant la base de données ou les fichiers.

Quand contacter le support Securantis

Contactez le support si :

• Le cron est correctement configuré mais les rapports n’apparaissent pas et la licence est valide.
• La réparation échoue de façon répétée sur une même étape et le journal ne permet pas de corriger le problème.
• Vous observez des fichiers suspects et vous souhaitez de l’aide pour décider d’une restauration, quarantaine ou suppression.

Dans votre demande, fournissez :

• Description précise du problème et des actions déjà réalisées.
• Copie du journal de maintenance généré par le module (ne pas envoyer de mots de passe).
• Mention de la version de PrestaShop et de PHP utilisée.

Résultat final attendu

Après configuration correcte du cron et, si nécessaire, après une réparation contrôlée :

• Exécutions périodiques visibles dans les journaux du module.
• Rapports et alertes transmis au SaaS (si activés) et/ou récapitulatifs disponibles dans le back‑office.
• Éléments réparés listés avec statut pour chaque sous‑action (succès/échec) et journal d’opération.

Si un élément critique reste non réparé, conservez la sauvegarde et contactez le support pour une intervention guidée.

Annexe : bonnes pratiques rapides

• Toujours sauvegarder avant réparation.
• Préférer une réparation graduelle (sous‑actions une par une) en cas de doute.
• Conserver les journaux et noter toute modification manuelle.
• Ne pas automatiser la suppression de fichiers suspects sans examen humain.

Si vous avez besoin d’aide pour vérifier la configuration du cron ou transmettre le journal de maintenance, ouvrez un ticket depuis votre espace client Securantis. Le support vous indiquera la marche à suivre sans jamais demander vos mots de passe par email ou chat.