Réparation site internet HCM en urgence : 500/404, piratage, interface cassée, erreur de paiement

Lorsque le site Web « tombe malade » au milieu de la diffusion d'annonces ou des heures de pointe des ventes, chaque minute qui passe est de l'argent. Cet article est un guide d'intervention d'urgence standard P1 pour les entreprises d'Hô Chi Minh-Ville : comment identifier les incidents, les procédures de « lutte contre les incendies » dans les 2 premières heures, le contrôle des risques liés aux données et la feuille de route de reprise durable.

1) Identification rapide : à quelle situation êtes-vous confronté ?

Groupe P1 - doit gérer immédiatement

• HTTP 500 : page blanche/« Serveur interne Erreur", le journal signale PHP fatal/timeout, service backend mort.

• Batch HTTP 404/Soft 404 : mauvaise redirection, slug modifié après déploiement/migration, erreur de plan du site.

• Code piraté/malveillant : popup étrange, redirigé vers un autre domaine, fichier .php étrange, Google met un avertissement "Ce site peut être piraté".

• Interface cassée : CSS/JS ne se charge pas, conflit de scripts tiers, erreur de mise à jour du thème/plugin.

• Erreur de paiement : expiration du délai d'attente du webhook/passerelle de paiement, double facturation, non-création de commandes dans le CMS.

Signes à suivre

• Sessions GA4 tomber soudainement; Le taux de sortie a augmenté anormalement.

• Le moniteur de disponibilité a été signalé en panne, le CPU/RAM a grimpé en flèche.

• La Search Console a augmenté l'erreur 5xx/404 ; Merchant Center rejette le produit.

2) Règle des « 2 heures d'or » (perte maximale)

1. Geler les modifications : suspendre tous les déploiements importants/mises à jour de plugins/crons.

2. Activer le mode de maintenance sécurisé : uniquement lorsque cela est nécessaire (par exemple, les données sont exposées/piratées).

3. Aperçu du produit actuel statut : exporter la base de données + le fichier de sauvegarde wp-content/app avant de toucher.

4. Activer le journal et le moniteur : journal du serveur (Nginx/Apache), PHP-FPM, application (error.log), journal de la passerelle.

5. Priorité P1 d'abord P2 : restaurer l'accès, le paiement, la page de destination des annonces → puis optimiser magnifiquement.

Si vous avez besoin d'un processus de garde 24h/24 et 7j/7 avec un SLA clair, consultez le Service de maintenance du site Web de Ho Chi Minh (article principal, description complète du processus de sauvetage P1, liste de contrôle et affectation des équipes) sur Tan Phat Digital : Service de maintenance du site Web d'Ho Chi Minh.

3) Processus de gestion des incidents

A. HTTP 500 / page blanche

• Activer le débogage et la journalisation : WP_DEBUG_LOG (WP), APP_DEBUG (Laravel), vérifier la trace des erreurs.

• Restauration rapide : revenir à la build/sauvegarde la plus récente si 500 après déploiement.

• Libérer l'original du compte : redémarrez PHP-FPM, videz OPcache, vérifiez la connexion à la base de données (max_connections).

• Désactivez temporairement le plugin/thème : renommez le dossier à l'origine de l'erreur afin que le site soit actif en premier, corrigez l'original plus tard.

B. Bulk 404/Soft 404

• Restaurer le lien permanent (WP), reconstruire les itinéraires (framework).

• Mappage 1–1 301 pour les URL modifiées après la migration/la restructuration.

• Plan du site propre : contient uniquement les URL 200 – indexables – canonique ; soumettre à nouveau GSC.

Dans le cas de « migrer et supprimer le trafic », gérer selon P1–P3 (robots, carte 301, canonique, plan du site) le tout inclus dans le processus de maintenance mensuel (SOP pour surveiller les erreurs répétées et la prévention) que l'équipe a standardisé : Processus de maintenance mensuel du site Web.

C. Hack/malware

• Mettre en quarantaine et modifier tous les mots de passe (hébergement, base de données, administrateur, SFTP, API).

• Analyser et nettoyer : trouver des fichiers étranges, masquer les signatures (base64/gzinflate/eval) ; remplacez le noyau propre, conservez wp-content/uploads.

• Mise à jour et patch : version CMS/plugin/theme, ancien type de plugin anonyme, verrouillage en écriture wp-config.php.

• WAF/CDN : activer le pare-feu (limite de débit, règles de bot), bloquer l'adresse IP de la source d'attaque ; Activez l'administration 2FA.

• Demandez un nouvel examen si vous êtes averti dans la recherche.

D. Interface cassée (CSS/JS)

• Purger le cache/CDN ; vérifiez 404 statiques, les bundles sont en conflit avec la version.

• Version du thème/plugin de restauration ; verrouillage temporaire de la mise à jour automatique.

• Détachez/désactivez les scripts en conflit (chat, pixel, tests A/B) → chargement conditionnel.

E. Erreur de paiement

• Contrôle du journal : webhook (200/400/500), état de la commande dans le CMS, file d'attente cron.

• Sécurité : si le paiement réussit mais que la commande n'est pas créée, compensez la commande manuelle + informez le client.

• Augmentez le délai d'attente et réessayez : au niveau de la passerelle/du webhook, vérifiez Liste autorisée SSL/TLS et IP.

4) Liste de contrôle "respirer de l'oxygène" pour les sites commerciaux (WordPress/Woo, Shopify, Custom)

Plateforme WordPress/WooCommerce

• Désactivez les plugins "étranges", annulez la version récemment mise à jour.

• Régénérez .htaccess/permalink.

• Supprimez l'injection des plugins mu, analysez wp-content/uploads pour les shells.

• Vérifiez la file d'attente Woo (Action Scheduler) et le webhook.

Shopify

• Version du thème de restauration ; Désactivez l'application nouvellement installée → testez à nouveau le panier/le paiement.

• Vérifiez le ScriptTag/l'application injecté dans checkout.liquid (Shopify Plus).

Custom/Laravel/Next.js

• Healthcheck DB/cache/queue ; version de restauration ; vérifiez la variable de connexion .env.

• Vérifiez SSR/CSR : erreur de bundle, réécriture de route sur Nginx.

5) Communiquez et minimisez les dégâts (ne restez pas silencieux)

• Message d'état sur la bannière/FAQ/fanpage FB : temps de réparation estimé.

• Pause Annonces sur la page d'erreur ; Transférer le budget vers la hotline/le canal de chat.

• Service client pour les commandes en attente : engagement à une compensation raisonnable (bon d'achat/livraison gratuite).

6) Clôture du livre des incidents : RCA et durcissement (24 à 72 heures plus tard)

1. RCA – Analyse des causes profondes : chronologie, cause profonde, impact et dommages nuisible.

2. SOPification : 500/404/hack/paiement playbook selon votre environnement.

3. Durcissement :

   • 2FA, décentralisation selon le principe du minimum.

   • 3–2–1 sauvegarde : 3 copies, 2 supports, 1 hors site ; testez la restauration tous les mois.

   • Surveillance de la disponibilité et des Core Web Vitals.

4. Journée du chaos tous les mois : exercice de restauration/retour en arrière de 30 minutes.

Besoin d'une équipe de « prise en charge » pour opérer périodiquement afin d'éviter toute récidive ? Vous pouvez passer au package de maintenance Web (incluant un audit de vitesse/sécurité, un service de service et un rapport d'incident) : Services de maintenance Web.

7) Suggestions SLA pour « l'équipe de réponse rapide »

• P1 – Site en panne/piratage/erreur de paiement : accepter les quarts de travail ≤ 15 minutes, restaurer l'accès de base ≤ 120 minutes.

• P2 – Interface cassée, 404 petits groupes : ≤ 24 heures.

• P3 – Optimisation de la vitesse, référencement technique : sprint de 1 à 2 semaines.

• Canal de communication : groupe Slack/Zalo, planning d'astreinte 24h/24 et 7j/7, mis à jour chaque jour 30 à 60 minutes pendant P1.

8) Foire aux questions

Combien de temps faut-il pour restaurer le site P1 ?
Généralement 30 à 120 minutes s'il y a une sauvegarde et un accès au serveur à proximité. Le piratage/piratage approfondi des données peut prendre >4 heures.

Est-il possible de diffuser des publicités tout en appliquant un correctif au site ?
Vous devez mettre en pause les publicités sur la page qui échoue ; conserver temporairement la campagne pour la hotline/le canal de chat ou la page de destination.

Comment savoir si le malware est propre ?
Analyser la signature, nettoyer les différences de base, vérifier le point d'entrée cron/admin, surveiller la connexion sortante et réanalyser après 24 à 48 heures.

Pourquoi, après une correction technique, le trafic n'est toujours pas renvoyé immédiatement ?
Le référencement a besoin de temps pour que Google explore/indexe à nouveau ; Avec les sites Web de vente, les revenus seront récupérés avant le trafic global.

9) "Le minimum doit être" défini après l'incident

• Sauvegarde automatique quotidienne + instantané lors du déploiement.

• Staging requis, vérifiez la liste de contrôle avant de la publier en production.

• Surveillance : disponibilité, journal des erreurs, CWV, taux de paiement réussi.

• Autorisations et journaux : propriétaire, gestionnaire, développeur ; log modifier le code/la configuration.

Les pannes du site sont inévitables — mais les dégâts peuvent être contrôlés si vous disposez d'un manuel de jeu P1 clair, d'un accès adéquat, d'habitudes de sauvegarde/surveillance et de discipline lors du déploiement. En traitant dans le bon ordre (restaurer l'accès → anti-infection → réparer → durcir), vous amènerez le système à un état stable dans les 2 premières heures et éviterez les répétitions.