But

Ce guide explique comment diagnostiquer et corriger l’absence d’emails d’alerte envoyés par Securantis. Il couvre les causes fréquentes : adresse d’expédition, filtrage anti-spam, tâches planifiées (cron), fonctions d’envoi natives de WordPress et PrestaShop, configuration SMTP et lecture des logs. Vous trouverez des procédures distinctes pour WordPress/WooCommerce et PrestaShop.

Prérequis

• Accès administrateur au panneau Securantis (SaaS) pour vérifier les adresses d’alerte configurées.
• Accès administrateur au site WordPress ou PrestaShop (backoffice).
• Accès FTP/SFTP ou à l’hébergement pour consulter les logs PHP/mail si nécessaire.
• Pas d’envoi de mots de passe par email : suivez les procédures pour donner accès sécurisé si une intervention payante est nécessaire.

Vue d’ensemble des étapes à suivre

1. Vérifier l’adresse destinataire et l’adresse d’expédition dans l’interface Securantis.
2. Contrôler les dossiers spam / quarantaine du destinataire.
3. Vérifier que la tâche planifiée (cron) côté CMS / hébergeur s’exécute.
4. Tester la fonction d’envoi native du CMS (wp_mail pour WordPress, système Mail de PrestaShop).
5. Tester ou configurer un relais SMTP fiable.
6. Consulter les logs d’envoi côté CMS et côté serveur.

Vérifications générales (toutes plateformes)

• Adresse destinataire : assurez-vous que l’email indiqué dans Securantis est correct, sans faute de frappe, et autorise la réception de notifications (inbox non pleine, pas d’auto-répondeur qui bloque).
• Spam / quarantaine : demandez au destinataire de vérifier le dossier spam, les filtres, et la quarantaine côté fournisseur (par ex. Office 365, Google Workspace). Ajoutez l’adresse d’expédition à la liste d’expéditeurs approuvés.
• Filtres / règles de messagerie : certains comptes redirigent ou suppriment automatiquement des emails selon des règles (surtout en entreprise). Vérifiez avec l’administrateur mail.
• Blocage côté hébergeur : si des envois PHP natifs sont utilisés, certains hébergeurs limitent ou bloquent les emails sortants pour lutte contre le spam.

WordPress / WooCommerce

But spécifique : vérifier que les alertes déclenchées par le plugin Securantis atteignent le serveur d’envoi du site.

Étapes détaillées :

1. Tester l’envoi natif : installez temporairement un plugin de test d’email (test SMTP / mail) et envoyez un email de test depuis l’administration. Si le test échoue, le problème vient du service d’envoi du site.
2. Vérifier cron WP : de nombreuses alertes sont déclenchées par des tâches planifiées. Confirmez que wp-cron est exécuté régulièrement. Sur hébergement mutualisé, préférez une tâche cron système déclenchant wp-cron en URL toutes les 5–15 minutes.
3. Examiner les paramètres du plugin Securantis dans WordPress : vérifier que l’activation des notifications est bien cochée et que l’adresse destinataire est la bonne.
4. Logs : consultez les logs d’erreurs PHP ou les logs du plugin s’ils sont fournis dans l’interface. Recherchez erreurs liées à wp_mail ou timeouts.
5. Si l’envoi natif est bloqué, configurer un relais SMTP : installez un plugin SMTP réputé, configurez un compte SMTP (fournisseur externe : SendGrid, Mailgun, SMTP de l’hébergeur ou Microsoft/Google via relais). Testez l’envoi via ce relais.

Réglages prudents :

• Utilisez un relais SMTP authentifié plutôt que l’envoi PHP natif pour de la fiabilité.
• N’activez pas de relais SMTP sans vérifier les limites d’envoi du fournisseur.

Erreurs fréquentes et dépannages :

• Test d’email échoue : vérifier identifiants SMTP et port (25/587/465), chiffrement TLS/SSL.
• Emails envoyés mais jamais reçus : vérifier les headers retournés par le test SMTP (réponse 250 OK ou message d’erreur). Contacter l’administrateur mail si rejection par le destinataire.
• Cron interne (wp-cron) non déclenché : mettre en place une tâche cron système.

PrestaShop (1.7 à 9)

But spécifique : vérifier le système d’envoi intégré et la configuration du module Securantis pour envoyer des rapports et alertes.

Étapes détaillées :

1. Tester l’envoi via le backoffice PrestaShop : dans la configuration des emails de PrestaShop, utilisez la fonction de test pour envoyer un message. Si le test échoue, le problème est côté messagerie du site.
2. Vérifier la configuration du module Securantis : assurez-vous que l’envoi d’événements/alertes est activé et que l’adresse destinataire est correcte.
3. Cron et tâches programmées : certains rapports peuvent dépendre de tâches planifiées côté module ou hébergement. Vérifiez que les CRON externes configurés chez l’hébergeur s’exécutent.
4. Logs : consultez les logs du serveur et ceux fournis par PrestaShop (si activés). Recherchez erreurs SMTP ou timeouts lors de l’envoi.
5. Si l’envoi natif échoue, configurez un relais SMTP dans la configuration des emails de PrestaShop (Paramètres > E-mail). Utilisez un fournisseur fiable et testez l’envoi.

Réglages prudents :

• Préférez un SMTP externe authentifié avec limitation connue plutôt que l’envoi via mail() si l’hôte le restreint.
• Activez TLS quand le fournisseur le demande.

Erreurs fréquentes et dépannages :

• PrestaShop indique « échec d’envoi » : notez le message d’erreur exact et testez les mêmes identifiants via un client mail.
• Emails partent mais sont marqués spam : vérifier SPF, DKIM, DMARC du domaine d’expédition (voir précautions ci‑dessous).

SMTP, SPF, DKIM, DMARC et réputation d’envoi

• Si vous utilisez votre domaine pour envoyer des alertes, vérifiez les enregistrements DNS : SPF doit autoriser le relais SMTP ; DKIM signé si disponible ; DMARC pour reporting. L’absence de ces enregistrements augmente les risques d’être marqué comme spam.
• Si vous utilisez un service tiers (Mailgun, SendGrid, etc.), suivez leur procédure d’authentification de domaine.

Lecture des logs et informations à collecter

Avant de contacter le support, rassemblez :

• Date/heure précise des alertes manquantes.
• Adresse expéditeur configurée et adresse destinataire.
• Résultats des tests d’envoi depuis WordPress/PrestaShop (captures ou messages d’erreur).
• Réponse SMTP ou extrait de headers si disponibles.
• Indication si vous avez changé récemment de fournisseur SMTP ou modifié DNS (SPF/DKIM).

Précautions et bonnes pratiques

• Ne supprimez pas automatiquement les alertes : en cas d’événement de sécurité, la quarantaine, la restauration et la suppression doivent faire l’objet d’une décision humaine.
• Ne communiquez jamais de mots de passe par email ou chat. Pour toute intervention payante, utilisez l’espace client sécurisé pour transmettre les accès après paiement.
• Testez toute modification sur un site de préproduction si possible afin d’éviter des interruptions sur la production.

Quand contacter le support Securantis

Contactez le support si :

• Les étapes ci‑dessus ne permettent pas d’identifier la cause.
• Les logs montrent des erreurs internes du plugin/module ou des échecs d’authentification côté Securantis.
• Vous suspectez que Securantis n’envoie pas les notifications malgré des tests SMTP réussis côté site.

Informations à fournir au support :

• Description des vérifications déjà effectuées (tests SMTP, cron, logs).
• Les logs d’erreur pertinents et les captures d’écran des messages de test.
• Horodatage et identifiants (sans mots de passe) : licence et nom de site.

Récapitulatif (action rapide)

1. Vérifiez destinataire et dossier spam. 2. Envoyez un test depuis WordPress/PrestaShop. 3. Vérifiez/exécutez cron. 4. Configurez un relais SMTP authentifié si l’envoi natif échoue. 5. Validez SPF/DKIM/DMARC pour le domaine d’envoi. 6. Collectez les logs et contactez le support si nécessaire.

En suivant ces étapes vous résoudrez la grande majorité des problèmes d’emails d’alerte. Si vous avez besoin d’aide pour la configuration SMTP ou l’analyse des logs, préparez les éléments listés et contactez notre support via l’espace client sécurisé.