Objectif
Cet article explique comment diagnostiquer et corriger un scan Securantis bloqué ou incomplet. Vous apprendrez quelles ressources serveur vérifier (temps d’exécution PHP, mémoire), comment le mécanisme de traitements en lot / tâches planifiées (cron ou workers) intervient selon la plateforme, et comment reprendre proprement un scan interrompu sans risquer de perdre des rapports ou d’isoler des fichiers sans décision humaine.
À qui s’adresse cet article
- Administrateurs de sites WordPress / WooCommerce utilisant l’agent Securantis.
- Administrateurs de boutiques PrestaShop 1.7–9 utilisant le module Securantis.
- Hébergeurs et équipes techniques qui veulent comprendre les limites d’exécution et reprendre un scan.
Principes généraux (applicables à toutes les plateformes)
- Le scanner parcourt de nombreux fichiers et vérifie intégrité et signatures : c’est une opération coûteuse en temps et en I/O.
- Selon l’hébergement, un scan complet peut dépasser les limites par défaut de PHP (max_execution_time, memory_limit), du serveur web ou du gestionnaire de tâches (cron/worker).
- Lorsqu’un scan est interrompu, les résultats partiels sont conservés ; la quarantaine, la restauration ou la suppression de fichiers détectés exigent toujours une action humaine.
Prérequis avant toute manipulation
- Sauvegarde récente du site et des fichiers (copie complète ou snapshot).
- Accès administrateur à l’interface Securantis et à l’hébergement (console, panneau ou SSH selon disponibilité).
- Vérifier que la licence Securantis est active et que l’agent / module est à jour.
Étapes de diagnostic et correction — WordPress / WooCommerce
- Vérifier l’historique et l’état du job dans l’interface Securantis
- Consultez les journaux et l’état du dernier scan (terminé, interrompu, en attente). Notez l’heure d’arrêt et les messages d’erreur éventuels.
- Confirmer le mode d’exécution
- Selon votre installation, le scan peut s’exécuter immédiatement (mode direct) ou en tâches incrémentales (batch/worker). Les tâches incrémentales utilisent des petits lots pour éviter les timeout.
- Contrôler les limites PHP
- Vérifiez max_execution_time et memory_limit. Pour un hébergement mutualisé, les valeurs peuvent être faibles (p.ex. 30 s, 128M). Si possible et sûr, augmentez temporairement (p.ex. 300 s, 512M) pour lancer un scan complet.
- Si vous ne pouvez pas modifier php.ini, préférez le mode par batches incrémentaux.
- Vérifier cron / workers
- Si le scanner s’appuie sur des tâches planifiées, confirmez que le cron système ou la tâche CRON WordPress (WP-Cron) fonctionne et qu’il n’y a pas d’erreurs récurrentes.
- Pour WooCommerce, éviter d’exécuter de grandes tâches pendant les heures de pic pour ne pas impacter la boutique.
- Lancer un scan compatible arrière-plan
- Choisissez le mode « compatible arrière-plan » (ou équivalent) dans l’interface : ce mode envoie le travail en petits lots afin de respecter des limites strictes.
- Surveiller la charge I/O et CPU
- Pendant l’exécution, surveillez l’utilisation CPU et I/O. En cas de spike, choisissez un scan incrémental ou planifiez-le hors-pointe.
Étapes de diagnostic et correction — PrestaShop 1.7–9
- Vérifier l’interface du module
- Dans le module Securantis, notez si le scan est lancé en mode « analyse & durcissement » en arrière-plan, en mode rapide, ou en mode direct. Le module affiche généralement des messages d’état.
- Limites PHP et workers
- Comme pour WordPress, contrôlez max_execution_time et memory_limit. Les hébergements PrestaShop partagés imposent souvent des limites strictes ; activez le mode arrière-plan si disponible.
- Tâches planifiées du serveur
- PrestaShop ne doit pas dépendre de WP-Cron : utilisez le cron système (ou le mécanisme de tâches que le module recommande) pour exécuter les lots.
- Scanner en mode compatible arrière-plan
- Si le module propose un mode compatible arrière-plan, activez-le pour éviter les timeouts. Ce mode fractionne le scan et permet une reprise automatique des lots.
Résultat attendu après correction
- Le scan reprend et progresse jusqu’à 100 % ou jusqu’à ce que tous les lots programmés soient traités.
- Les alertes et les rapports sont synchronisés avec la plateforme SaaS Securantis.
- Aucune action automatique n’est prise sur les fichiers détectés : les éléments suspectés doivent être validés manuellement avant mise en quarantaine ou suppression.
Réglages prudents
- Ne laissez pas une augmentation de memory_limit ou de max_execution_time permanente sans validation de sécurité : augmentez-les temporairement pour le scan, puis remettez des valeurs sûres.
- Limitez les scans complets aux heures creuses sur des boutiques en production.
- Si vous activez un mode arrière-plan, vérifiez la fréquence des tâches pour ne pas surcharger le serveur.
Erreurs fréquentes et leur signification
- Scan interrompu avec « timeout » ou absence de progression : généralement lié à max_execution_time ou à un worker qui meurt.
- Jobs en file d’attente non traités : tâche cron non exécutée, WP-Cron désactivé ou permissions insuffisantes pour exécuter le processus.
- Mémoire insuffisante / processus tué : indique que memory_limit est trop bas ; le système peut aussi killer le processus pour protéger le serveur.
- Rapport partiel sans résultats finaux : le job a été interrompu ; les entrées déjà scannées sont valides mais le travail n’est pas complet.
Dépannage pas-à-pas
- Reproduire le problème en ouvrant le dernier job et en relançant un scan en petit lot (mode arrière-plan). Si le problème ne se produit pas, continuez en surveillant la progression.
- Si le job échoue rapidement, activez les logs détaillés côté agent/module et récupérez les messages d’erreur.
- Vérifiez les logs serveur (web et PHP) pour détections de process killed, erreurs de permissions ou dépassements de ressources.
- Testez un scan sur un sous-ensemble de fichiers (p.ex. dossier thèmes ou modules) pour isoler les fichiers problématiques.
- Si un lot est bloqué sur un fichier réseau (NFS, stockage distant), exécutez le scan en local ou ajustez les timeouts d’I/O.
Précautions importantes
- N’isolez ni ne supprimez des fichiers détectés sans vérification manuelle : toutes les opérations de quarantaine ou suppression requièrent une décision humaine.
- N’envoyez jamais de mots de passe ou d’identifiants par email ou chat. Si un accès est nécessaire pour une intervention payante, il sera demandé via l’espace client sécurisé après paiement.
- Ne supposez pas que tous les hébergements sont compatibles : certaines plates-formes très restreintes peuvent empêcher un scan complet.
Quand contacter le support Securantis
Contactez le support si :
- Vous avez suivi les étapes et le scan reste bloqué sans message clair dans les logs.
- Le job échoue avec des erreurs côté serveur que vous ne pouvez pas corriger (processus tués, permissions système, stockage réseau non fiable).
- Vous observez des détections majeures et avez besoin d’aide pour analyser les fichiers (le support peut conseiller, mais toute action de quarantaine/restauration restera sous votre contrôle).
Que fournir au support (sans mots de passe)
- Captures d’écran de l’état du scan et des messages d’erreur.
- Extraits des logs du module/agent et des logs PHP/web (sans informations sensibles comme mots de passe).
- Description de l’hébergement (mutualisé, VPS, type de stockage) et des limites PHP actuelles.
Conclusion
Un scan interrompu est le plus souvent lié à des limites d’exécution ou à un mécanisme de tâches non opérationnel. Préférez le mode incrémental/compatible arrière-plan sur les hébergements contraints, augmentez temporairement les limites si vous le pouvez, et surveillez la charge. Pour tout blocage persistant, le support Securantis peut vous aider à analyser les logs ; la décision de mettre en quarantaine ou de supprimer des fichiers restera toujours entre vos mains.