Securantis

Dépannage et compatibilité

Dépannage — l’agent Securantis : mise à jour échouée

Que faire lorsqu’une mise à jour de l’agent Securantis échoue : vérifications de licence, permissions, ZIP, espace disque, procédure de rollback et quand contacter le support.

← Retour au centre d’aide

Guide pratique Securantis

But

Cet article explique comment diagnostiquer et corriger une mise à jour de l’agent Securantis qui échoue sur WordPress/WooCommerce ou PrestaShop. Il couvre les contrôles de licence, les permissions, l’intégrité du ZIP, l’espace disque, la remise en état (rollback) et les informations à fournir au support.

Prérequis et précautions générales

  • Avoir accès FTP/SFTP ou SSH au serveur et, si nécessaire, à l’espace d’administration du CMS.
  • Ne jamais transmettre de mots de passe par e-mail ou chat. Utilisez l’espace client sécurisé pour partager des accès temporaires après contractualisation d’une intervention payante.
  • Effectuer une sauvegarde complète des fichiers et de la base de données avant toute manipulation (les actions sur les fichiers peuvent rendre le site indisponible).
  • Les opérations de quarantaine, restauration ou suppression de fichiers suspects demandent une décision humaine ; Securantis n’efface pas automatiquement les fichiers malveillants.

Contrôles initiaux (à réaliser avant toute modification)

  1. Vérifier le statut de licence
  • Confirmez que la licence attachée au site est active et n’a pas atteint son quota de sites. Une licence inactive ou non liée empêchera souvent les mises à jour privées.
  • Si vous avez récemment changé de domaine ou cloné le site, détachez/attachez proprement la licence via l’espace d’administration Securantis ou le SaaS.
  1. Vérifier l’espace disque
  • Assurez-vous que la partition contenant le webroot a suffisamment d’espace libre. Les opérations d’extraction de ZIP et de sauvegarde temporaires requièrent de l’espace (prévoir au moins 50–100 MB libres pour des sites petits à moyens, plus selon la taille du ZIP).
  1. Vérifier les permissions de fichiers et dossiers
  • L’utilisateur du serveur web doit pouvoir écrire dans les dossiers où l’agent est installé ainsi que dans les dossiers temporaires utilisés pour extraire les ZIP. Si vous utilisez FTP/SFTP, vérifiez que l’utilisateur technique possède les permissions en écriture.
  • Pour WordPress : vérifiez que le dossier contenant le plugin est modifiable par le processus web (ou par l’utilisateur CLI si vous utilisez WP-CLI).
  • Pour PrestaShop : vérifiez que le dossier du module et le dossier des modules temporaires sont modifiables.
  1. Intégrité du fichier ZIP de mise à jour
  • Si la mise à jour provient d’un upload manuel, le ZIP peut être corrompu. Téléchargez à nouveau le ZIP depuis l’espace client Securantis et comparez la taille/empreinte si possible.
  • Évitez d’essayer d’ouvrir le ZIP sur le serveur avec des outils limités : téléchargez-le localement pour vérifier l’ouverture et le contenu.

Étapes de dépannage — WordPress/WooCommerce

  1. Reproduire l’erreur et récupérer les logs
  • Déclenchez la mise à jour puis récupérez les messages d’erreur affichés dans l’administration, les logs PHP/serveur et, si disponible, les logs de l’agent. Notez l’heure exacte de l’échec.
  1. Tentative d’installation via méthode alternative
  • Si l’installation via l’interface échoue, utilisez WP-CLI (si disponible) pour installer ou mettre à jour le plugin : cela élimine des problèmes liés au navigateur ou à des limitations de l’interface.
  • Si WP-CLI n’est pas possible, procédez par FTP/SFTP : renommez l’ancien dossier du plugin (ex : plugin_old), téléversez et extrayez le nouveau dossier, puis vérifiez les permissions.
  1. Vérifier les hooks de sécurité et WAF
  • Si un WAF/pare-feu applicatif bloque l’action (règles modifiant les uploads ou exécution de scripts PHP), mettez temporairement l’interface en mode observation si possible, ou demandez au support d’hébergeur d’autoriser l’opération.

Étapes de dépannage — PrestaShop (1.7 à 9)

  1. Observer le comportement du back-office
  • Lors d’un échec via la page de gestion des modules, notez le message retourné. PrestaShop effectue parfois des contrôles qui empêchent l’extraction si le module ZIP n’est pas conforme ou si les permissions sont incorrectes.
  1. Installation manuelle par FTP/SFTP
  • Téléversez le dossier du module décompressé dans le répertoire des modules. Vérifiez ensuite dans l’administration que le module est détecté et procédez à la mise à jour depuis l’interface.
  • Si le module n’apparaît pas, videz le cache du thème et les caches PrestaShop avant de réessayer.

Rollback (revenir à la version précédente)

  1. Préparer la version antérieure
  • Si vous avez conservé une copie du ZIP ou du dossier du plugin/module précédemment fonctionnel, préparez-le localement.
  1. Procédure par FTP/SFTP
  • Renommez le dossier actuel de l’agent (par exemple .old) afin de conserver une copie.
  • Téléversez et restaurez la version antérieure du plugin/module.
  • Vérifiez les permissions et redémarrez le service web si nécessaire.
  1. Vérification après rollback
  • Vérifiez la disponibilité du site, la connexion avec la plateforme Securantis et lancez un scan de test.
  • Notez que certains paramètres récents peuvent ne pas être compatibles avec la version antérieure ; testez les fonctionnalités critiques (connexion, firewall, scan).

Erreurs fréquentes et solutions rapides

  • Erreur d’espace disque pendant l’extraction : libérez de l’espace (logs, sauvegardes temporaires), puis relancez l’installation.
  • Permissions refusées lors de l’écriture des fichiers : appliquez les permissions correctes pour l’utilisateur web ou effectuez l’opération en tant qu’utilisateur ayant les droits suffisants via SSH.
  • ZIP corrompu ou incomplet : retéléchargez depuis l’espace client Securantis et vérifiez l’intégrité localement.
  • Conflit avec un autre plugin/module : désactivez temporaiement les extensions de sécurité tierces susceptibles d’interférer (après sauvegarde) et réessayez.
  • Rejet par le WAF : demandez une temporisation des règles ou exécutez la mise à jour en dehors des heures critiques après avoir informé l’hébergeur.

Dépannage avancé (si les actions précédentes échouent)

  • Collecte des logs : récupérez les logs PHP, Nginx/Apache, et tout log fourni par l’agent Securantis. Notez les erreurs SQL éventuelles et les exceptions PHP.
  • Mode debug temporaire : activez le debug PHP ou du CMS pour obtenir une trace plus complète (n’oubliez pas de désactiver ensuite).
  • Vérification de la compatibilité PHP : assurez-vous que la version de PHP est compatible avec la version de l’agent et du CMS (Securantis supporte spécifiquement certaines plages — vérifiez la documentation de compatibilité).

Quand contacter le support Securantis et quelles informations fournir

Contactez le support si :

  • Vous avez suivi les étapes ci-dessus et la mise à jour échoue toujours.
  • L’agent renvoie des erreurs internes ou ne se reconnecte pas après la mise à jour.
  • Vous suspectez un conflit sophistiqué avec l’infrastructure d’hébergement (permissions système, SELinux, chroot, readonly FS).

Informations à fournir au support (utile et accélère le traitement)

  • URL du site et identifiant de licence (sans mots de passe).
  • Horodatage (UTC) des tentatives de mise à jour et des logs récupérés.
  • Extraits de logs pertinents (messages d’erreur PHP, erreurs d’échec d’extraction, réponse HTTP si applicable).
  • Description précise des actions déjà effectuées (rollback tenté, méthodes d’installation essayées).
  • En cas d’intervention payante, n’envoyez jamais d’accès par e-mail : utilisez l’espace client sécurisé et ne fournissez des accès qu’après accord et paiement.

Réglages prudents et recommandations

  • Testez les mises à jour sur un environnement de préproduction lorsque cela est possible.
  • Conservez toujours la version précédente du plugin/module pendant au moins 48 heures après mise à jour en production pour pouvoir effectuer un rollback rapide.
  • Planifiez les mises à jour hors des pics de trafic et informez l’hébergeur si des opérations pouvant être bloquées par le WAF sont prévues.

Résultat attendu après correction

  • L’agent Securantis est mis à jour et se reconnecte au SaaS.
  • Les fonctionnalités (scanner, quarantine, firewall, rapports) sont disponibles et les scans s’exécutent normalement.
  • En cas de rollback, le site retrouve son état fonctionnel antérieur et l’agent reprend son comportement attendu.

Remarque finale

Securantis fournit des mises à jour privées et une assistance pour l’installation ; cependant, certaines opérations nécessitent des droits d’hébergement ou une intervention de l’hébergeur. Si vous n’êtes pas à l’aise avec les opérations serveur, sollicitez l’aide du support Securantis pour une intervention guidée ou planifiée.

Cookies

Nous utilisons des cookies nécessaires au fonctionnement du site. Avec votre accord, nous pouvons aussi utiliser des cookies de mesure d’audience et de personnalisation. En savoir plus.

Nécessaires

Indispensables au site et à l’espace client.

Actif