E-commerce
1 juillet 2026
« Quelqu'un a commandé avec mon compte. » « Mon email de connexion a changé sans moi. » « Je vois une adresse que je n'ai jamais ajoutée. » Trois signaux où un compte client compromis exige réaction immédiate, pas un simple reset mot de passe.
Le support piratage compte e-commerce couvre commandes non autorisées, changement email ou adresse suspect, verrouillage compte et escalade sécurité L3. Complète la 2FA (#839) : ici, le client signale une compromission avérée ou probable, pas un blocage second facteur.
Ce guide #841 déploie policy ACCHACK-SUP, flow AH-1 à AH-8 et matrice ACCHACK-MAP. Paire SAV du futur bot compte piraté (#842).
Summary
Pourquoi la suspicion de piratage exige un protocole dédié ?
Un compte compromis peut générer commandes frauduleuses, fuites données et chargebacks. L'agent reset le mot de passe sans bloquer commandes en cours ni alerter l'équipe sécurité.
Cinq signaux typiques compte piraté
Commande inconnue : achat non reconnu sur historique
Email modifié : notification changement login non initiée
Adresse ajoutée : livraison vers adresse inconnue
Paiement ajouté : carte ou wallet non reconnu
Connexion inconnue : alerte login pays ou appareil inhabituel
La CNIL rappelle qu'une violation de données personnelles doit être évaluée et notifiée selon gravité et délai réglementaire (CNIL, notification violation 2026).
Exemple DTC
Beauté DTC, 9 tickets acchack_/mois. Après ACCHACK-MAP : acchack_incident_resolution_rate 92 %, commandes frauduleuses expédiées 0 post-protocole.
ACCHACK #841 vs TWOFACT #839, ACCTEMAIL #825, ACCTDEL #823 et bot #842
Sept contenus, sept parcours sécurité compte distincts.
Matrice rapide
#841 ACCHACK : compte compromis, commandes suspectes, escalade L3
TWOFACT #839 : 2FA bloquée distinct takeover confirmé
ACCTEMAIL #825 : changer email volontaire distinct piratage
ACCTDEL #823 : suppression compte distinct incident actif
LOGIN #294 : erreurs connexion sans signaux compromission
Chargeback : prévention litige paiement post-incident distinct triage
Bot #842 : triage sécurité tier 1 sans exposer données
#841 = mon compte est piraté ou commande frauduleuse. #839 = ma 2FA me bloque.
Promesse #841
Policy ACCHACK-SUP, arbre ACCHACK-GATE, 8 macros, matrice escalade L3, KPI acchack_incident_resolution_rate.
Quelles typologies acchack_* classifier ?
Classifier oriente action : bloquer commande ≠ verrou compte ≠ fausse alerte rassurance.
Huit typologies ACCHACK-MAP
acchack_unauthorized_order : commande non reconnue en cours ou expédiée
acchack_email_changed : email login modifié sans consentement
acchack_password_changed : mot de passe changé par tiers
acchack_address_added : adresse livraison inconnue ajoutée
acchack_payment_added : moyen paiement non reconnu
acchack_unknown_login : connexion lieu ou appareil suspect
acchack_data_fear : crainte fuite données sans preuve concrète
acchack_false_alarm : famille ou collègue a commandé, pas piratage
Policy ACCHACK-SUP : règles agents et escalade
La policy ACCHACK-SUP fixe la réponse incident sans aggraver l'exposition client.
Six règles ACCHACK-SUP
Priorité L3 si commande en cours : ACCHACK-LOCK immédiat avant investigation
Vérifier identité propriétaire légitime : ACCHACK-ID-CHECK avant restauration accès
Bloquer expédition suspecte : hold commande non reconnue ops fulfillment
Révoquer sessions actives : logout all devices après verrou
Ne pas exposer données pirate : jamais donner email ou adresse ajoutée par attaquant au client
Documenter incident : timeline, actions, escalade L3, commandes impactées
Matrice escalade incident (agent)
N1 triage : qualifier signaux, tag acchack_*, pas de restore accès
L2 ops : hold commande, revoke sessions, ID check propriétaire
L3 sécurité : fraude confirmée, notification DPO, chargeback prep
Flow AH-1 à AH-8 : résolution standard incident
Huit étapes séquentielles, SLA P1 incident < 1 h, L3 alerte immédiate si commande active.
Flow AH-1 à AH-8
AH-1 Triage urgence : commande en cours ? → LOCK prioritaire
AH-2 Lookup : historique connexions, commandes 48 h, changements profil
AH-3 Classify : acchack_* via ACCHACK-MAP
AH-4 Contain : verrou compte, hold commande, revoke sessions
AH-5 Verify owner : ACCHACK-ID-CHECK propriétaire légitime
AH-6 Restore : reset credentials, 2FA force, email restore si hijack
AH-7 Confirm : macro ACCHACK-DONE + ACCHACK-REENABLE-2FA
AH-8 Close : KPI acchack_incident_resolution_rate + L3 report
Huit macros ACCHACK-* prêtes à coller
Macros claires sur verrouillage, rassurance et prochaines étapes.
Bibliothèque ACCHACK-*
ACCHACK-LOCK : « Compte verrouillé par précaution. Commandes non reconnues en cours bloquées. Équipe sécurité intervient sous {{sla}}. »
ACCHACK-ID-CHECK : « Pour confirmer que vous êtes le propriétaire : dernière commande légitime + pièce identité. Délai {{sla_verify}}. »
ACCHACK-HOLD-ORDER : « Commande {{order_id}} mise en attente. Aucune expédition tant que vérification en cours. »
ACCHACK-NO-DATA-LEAK : « Nous ne partageons pas les coordonnées ajoutées par un tiers. Votre compte est sécurisé pendant traitement. »
ACCHACK-RESTORE : « Accès restauré. Nouveau mot de passe requis. Vérifiez historique commandes et moyens de paiement. »
ACCHACK-REENABLE-2FA : « Réactivez la 2FA immédiatement et sauvegardez codes secours. Voir guide #839. »
ACCHACK-FALSE-ALARM : « Commande identifiée comme achat familial sur {{email}}. Compte non compromis. Conseils sécurité optionnels. »
ACCHACK-DONE : « Récap incident : {{actions}}. Prochaine étape {{next}}. Contactez-nous si activité suspecte persiste. »
Arbre ACCHACK-GATE et coordination ops
Arbre décision avant restauration accès non vérifiée.
ACCHACK-GATE
Commande non reconnue active ? → LOCK + HOLD-ORDER L2 immédiat
Email hijacké ? → LOCK + L3 + pas restore avant ID-CHECK
Signaux faibles seulement ? → lookup 48 h puis FALSE-ALARM ou escalate
Propriétaire vérifié ? → RESTORE + REENABLE-2FA + audit paiements
Checklist ops incident
Canal Slack ou PagerDuty L3 sécurité. Procédure hold fulfillment documentée. Sync TWOFACT #839 pour réactivation 2FA post-restore. Tag acchack_* pour audit mensuel.
KPI, QA et handoff vers bot #842
Mesurer ACCHACK détecte expéditions frauduleuses et restaurations non vérifiées.
Quatre KPI ACCHACK
acchack_incident_resolution_rate : incident clos procédure conforme / total
acchack_contain_time : délai LOCK + hold commande suspecte
acchack_fraud_shipped_incidents : commandes frauduleuses expédiées, cible 0
acchack_unverified_restore_incidents : restore sans ID check, cible 0
Handoff bot #842
Exporter ACCHACK-MAP vers intents bot_acchack_triage, bot_acchack_rassure. Guardrail ACCHACK-NO-RESTORE-BOT : jamais restaurer accès ni dévoiler données incident chat.
Cas limites : guest order, Shop Pay, collègue famille
Trois cas hors flow standard.
Commande guest pas compte
Client confond compte et achat invité. Lookup email commande avant LOCK compte.
Shop Pay wallet compromis
Paiement via Shop Pay distinct compte boutique. Router support paiement + L3 si fraude confirmée.
Fausse alerte famille
Conjoint ou enfant a commandé. FALSE-ALARM après vérif, conseil 2FA #839 optionnel.
Formation agents : 30 minutes ACCHACK
Module : LOCK first, ID check avant restore, jamais données attaquant au client.
Exercices
Ticket A : commande inconnue en préparation → LOCK + HOLD-ORDER
Ticket B : email changé → LOCK L3, pas restore N1
Ticket C : « mon fils a commandé » → lookup puis FALSE-ALARM
Comment Qstomy structure ACCHACK dans votre stack
Qstomy route acchack_* P1, déclenche LOCK playbook et bloque restore sans ID check documenté.
Trois briques
Routing : intent account_hacked vs login_issue vs twofact_block
Guardrails : NO-RESTORE-N1 avant close
Bot #842 : triage sécurité tier 1 sans exposer données
FAQ et checklist déploiement ACCHACK
FAQ
Reset mot de passe suffit ?
Non si signaux compromission. LOCK + contain avant restore. ACCHACK-GATE.
Différence #839 takeover ?
#839 twofact_suspected_takeover = signal 2FA. #841 = protocole incident complet commandes profil.
Donner adresse ajoutée par pirate ?
Non. ACCHACK-NO-DATA-LEAK. Risque doxxing et aide attaquant.
Checklist 7 jours
J1 : ACCHACK-SUP + ACCHACK-MAP + matrice escalade L1 L2 L3
J2 : 8 macros helpdesk + canal L3 alerte
J3 : procédure hold fulfillment commande suspecte
J4 : formation 30 min agents drill LOCK
J5 : tags acchack_* + KPI
J6 : test restore avec ID check obligatoire
J7 : brief bot #842 NO-RESTORE-BOT
Maillage
Enzo
1 juillet 2026
