Une page de phishing a été créée sur mon site WordPress : que faire ?

Vous découvrez qu’une page frauduleuse imitant une banque, un service de livraison, une messagerie, une administration ou une marque connue est hébergée sur votre site WordPress ? Cette situation doit être traitée comme un incident critique. La page peut chercher à voler des identifiants, des coordonnées bancaires ou d’autres informations personnelles, tout en utilisant la réputation de votre domaine pour rassurer les victimes.

La priorité n’est pas seulement de supprimer l’URL visible. Il faut d’abord limiter l’exposition, conserver les éléments nécessaires au diagnostic, identifier le mécanisme qui a créé ou sert la page, contrôler les autres zones du site et déterminer si des visiteurs ont pu transmettre des données. Une suppression isolée peut masquer le symptôme sans fermer l’accès utilisé par l’attaquant.

Google classe ce type de contenu parmi les attaques d’ingénierie sociale. Une page de phishing peut entraîner un avertissement « Site trompeur » ou « Deceptive site ahead » dans le navigateur, une alerte dans Search Console et une forte baisse de confiance. La levée de l’avertissement ne doit être demandée qu’après le nettoyage complet du site.

Ce guide explique quoi faire lorsqu’une page de phishing apparaît sur WordPress, comment protéger les visiteurs et quand demander un nettoyage malware WordPress.

Qu’est-ce qu’une page de phishing hébergée sur un site WordPress ?

Une page de phishing est conçue pour tromper un visiteur afin qu’il communique une information confidentielle ou réalise une action dangereuse. Elle peut reproduire l’apparence d’un service connu, afficher un faux formulaire de connexion, demander une validation de paiement ou prétendre qu’un compte doit être réactivé.

Dans sa documentation sur l’ingénierie sociale et les sites trompeurs, Google explique que le phishing cherche notamment à obtenir des mots de passe, numéros de téléphone ou autres informations personnelles en imitant une entité de confiance. Un site légitime peut être compromis puis utilisé pour héberger ces pages sans que son propriétaire en ait connaissance.

La page frauduleuse peut être visible dans WordPress, mais elle peut aussi être servie par un fichier autonome, une règle de réécriture, une injection dans la base de données, un script distant ou un contenu différent selon le visiteur. Il faut donc distinguer l’URL observée du mécanisme technique qui la produit.

Pourquoi cet incident est-il particulièrement critique ?

Une page de phishing ne se contente pas d’altérer votre site. Elle peut nuire directement à des tiers et engager plusieurs risques simultanés :

• vol d’identifiants de messagerie, banque, espace client ou service professionnel ;
• collecte de données personnelles ou d’informations de paiement ;
• atteinte à la réputation du domaine et de l’entreprise ;
• avertissements navigateur bloquant l’accès à tout ou partie du site ;
• suspension de l’hébergement ou limitation de certains services ;
• propagation par des e-mails, SMS, publicités ou liens diffusés vers la page ;
• récidive si le point d’entrée ou le mécanisme de persistance reste actif ;
• obligations de gestion d’incident si des données personnelles sont effectivement compromises.

Comment qualifier immédiatement le niveau d’urgence ?

Niveau	Exemples	Réaction recommandée
Critique	Page active collectant identifiants ou paiement, diffusion en cours, avertissement navigateur, boutique ou espace client concerné	Limiter l’exposition immédiatement, préserver les preuves et lancer un diagnostic prioritaire
Élevé	Page encore accessible mais diffusion inconnue, plusieurs URL similaires, hébergeur ou Google ayant signalé l’incident	Bloquer le contenu frauduleux, inventorier le périmètre et contrôler toute la compromission
À confirmer rapidement	Ancienne URL renvoyant désormais 404/410, cache ou résultat encore visible, alerte sans exemple précis	Vérifier l’état réel, Search Console, les journaux et l’absence de mécanisme actif
Faux positif possible	Service tiers légitime, page de paiement ou authentification mal identifiée, ressource externe trompeuse	Documenter la relation avec le tiers, corriger les ambiguïtés et demander un examen seulement après vérification

Le niveau d’urgence augmente si la page imite une banque, une administration, un service de santé, un transporteur, une messagerie ou un fournisseur utilisé par vos clients. Il augmente également lorsque le site reçoit beaucoup de trafic, lorsque la page est activement diffusée ou lorsqu’elle a pu enregistrer des soumissions.

Les actions à mener pendant la première heure

Période	Objectif	Actions prudentes
0 à 10 minutes	Limiter l’exposition	Conserver l’URL et les captures, éviter les saisies, maintenir la suspension ou bloquer la route frauduleuse si cela peut être fait sans effacer les preuves
10 à 20 minutes	Documenter	Relever l’heure, la source du signalement, les pages, domaines externes, messages Google ou hébergeur et les symptômes visibles
20 à 35 minutes	Préserver	Créer ou protéger une copie de l’état actuel, sauvegarder les journaux, exporter les informations Search Console et geler les changements non indispensables
35 à 50 minutes	Qualifier le périmètre	Contrôler d’autres URL, les comptes, les fichiers récents, les tâches, les redirections, les autres sites et les services connectés
50 à 60 minutes	Organiser la réponse	Décider du confinement, désigner les responsables, préparer les accès temporaires et lancer le nettoyage complet

Lorsque le site est activement utilisé pour voler des données, la protection des visiteurs prime. Si vous ne pouvez pas isoler la page avec certitude, une suspension temporaire de la zone concernée ou du site peut être préférable à une remise en ligne partielle mal maîtrisée.

Quelles preuves conserver avant de supprimer la page ?

La documentation aide à comprendre l’origine de l’incident, à vérifier l’étendue du nettoyage et, si nécessaire, à informer un prestataire, un hébergeur, une marque usurpée ou une autorité. Conservez uniquement ce qui est utile, sans recopier ni manipuler les données éventuellement saisies par les victimes.

• l’URL complète, y compris les paramètres ;
• la date, l’heure et le fuseau horaire de la découverte ;
• des captures de la page et de l’avertissement, sans saisir de données ;
• le message reçu de Google, de l’hébergeur, d’un client ou de la marque imitée ;
• les URL ou chemins de fichiers mentionnés dans les alertes ;
• les en-têtes HTTP, redirections et codes de réponse observés ;
• les domaines externes chargés par la page ou utilisés pour envoyer le formulaire ;
• les journaux d’accès, PHP, serveur, pare-feu et authentification disponibles ;
• les dates de modification des fichiers et contenus suspects ;
• la liste des changements récents, mises à jour, comptes et accès créés.

La documentation WordPress consacrée aux sites piratés recommande de documenter les symptômes, les horaires et les changements récents afin de constituer une base d’incident exploitable.

Comment consulter la page sans exposer davantage vos postes ?

N’utilisez jamais vos identifiants réels, une carte bancaire ou un compte de test réutilisé ailleurs. Évitez également d’ouvrir des fichiers téléchargés ou de cliquer sur les boutons de la page depuis un poste contenant vos accès d’administration.

Lorsque l’analyse doit aller plus loin, utilisez un environnement isolé et maîtrisé, ou confiez cette vérification à l’intervenant chargé de la réponse à incident. Google recommande, lorsque Search Console fournit des URL d’exemple, de les examiner depuis un ordinateur qui n’appartient pas au même réseau que celui qui sert le site, car certaines attaques tentent de masquer leur contenu au propriétaire.

Une capture publique, un test externe ou l’Inspection d’URL peuvent parfois suffire à confirmer le comportement sans interagir avec le formulaire frauduleux.

Où une page de phishing peut-elle être cachée dans WordPress ?

Zone	Scénario possible	Contrôle attendu
Pages, articles ou modèles	Contenu créé ou modifié depuis le back-office	Auteurs, révisions, dates, blocs, modèles et métadonnées
Fichiers autonomes	Dossier ou fichier ajouté hors du CMS	Arborescence, dates, propriétaire, permissions et comparaison avec les paquets légitimes
Extensions ou thèmes	Code injecté ou composant compromis	Intégrité, versions, fichiers inhabituels, composants premium et thèmes enfants
Base de données	HTML, scripts, redirections ou options injectés	Contenus, options, widgets, transients et données sérialisées
Règles serveur	URL générée ou redirigée sans page WordPress	.htaccess, configuration Nginx, règles CDN, proxy et cache
Tâches planifiées	Recréation périodique du contenu	WP-Cron, cron serveur, files d’attente et automatisations
Ressource tierce	Annonce, iframe, script ou widget trompeur	Origine, relation avec le prestataire, variantes mobile/desktop et rotation
Autre installation	Sous-domaine, préproduction ou site voisin compromis	Tous les sites du compte, anciennes copies et environnements oubliés

Le contenu peut également être conditionnel : uniquement visible sur mobile, depuis un pays, après un clic provenant d’un e-mail, pour un visiteur non connecté ou lorsque certains cookies sont absents. Un contrôle depuis votre navigateur habituel peut donc ne rien montrer.

Faut-il supprimer immédiatement le fichier ou la page signalée ?

La suppression ou le blocage rapide du contenu frauduleux est généralement nécessaire pour protéger les visiteurs. Elle doit toutefois être précédée, autant que possible, par une conservation minimale des preuves et accompagnée d’une recherche de la cause.

Si vous supprimez uniquement l’élément visible sans comprendre comment il a été créé, plusieurs situations peuvent se produire :

• la page est recréée par une tâche planifiée ;
• une autre URL continue de servir le même contenu ;
• le formulaire transmet encore des données à un domaine externe ;
• un compte compromis republie la page ;
• une règle serveur ou un cache continue de la présenter ;
• l’attaquant conserve un accès par un autre fichier ou service.

La bonne séquence est donc : documenter, confiner, supprimer le contenu frauduleux, nettoyer le mécanisme de création, fermer le point d’entrée et vérifier la persistance.

Pourquoi une simple restauration de sauvegarde peut-elle échouer ?

Une sauvegarde peut être antérieure à la découverte mais postérieure à l’intrusion. Elle peut contenir le compte, le fichier ou la vulnérabilité qui a permis l’ajout de la page. À l’inverse, restaurer une base trop ancienne peut effacer des commandes, demandes de contact, comptes ou contenus légitimes.

Avant toute restauration, vérifiez :

• la date probable de création de la page et du point d’entrée ;
• le contenu exact de la sauvegarde : fichiers, base, configuration et médias ;
• l’intégrité de la copie ;
• les données métier créées depuis sa date ;
• la correction du composant ou de l’accès compromis avant la remise en ligne ;
• la possibilité de tester la restauration dans un environnement isolé.

La restauration peut faire partie de la réponse, mais elle ne remplace ni l’analyse de la cause ni le contrôle post-restauration.

Que vérifier dans Google Search Console ?

Le rapport Problèmes de sécurité est le point central lorsque Google a détecté du contenu trompeur. La documentation Google sur les sites de phishing et d’ingénierie sociale recommande notamment de vérifier les URL d’exemple et de s’assurer qu’aucun propriétaire suspect n’a été ajouté.

• la catégorie exacte du problème : contenu trompeur, ressources intégrées trompeuses, malware ou autre signal ;
• les URL d’exemple, qui ne représentent pas toujours la totalité des pages ;
• les propriétaires et utilisateurs de la propriété Search Console ;
• les méthodes de validation, fichiers HTML, balises, DNS et comptes associés ;
• les sitemaps inconnus ou modifiés ;
• les requêtes et pages inhabituelles dans le rapport Performances ;
• l’état des URL après nettoyage avec l’Inspection d’URL.

Une absence d’URL d’exemple ne signifie pas qu’il n’existe aucun problème. À l’inverse, une URL encore listée peut déjà avoir été nettoyée et attendre un nouveau contrôle. Il faut vérifier le comportement actuel et l’ensemble du site.

Le contenu trompeur peut-il provenir d’une ressource tierce ?

Oui. Une page apparemment légitime peut charger une publicité, une iframe, un script, une image ou un widget tiers qui présente un contenu trompeur. Certains réseaux font varier les annonces selon le pays, l’appareil ou le nombre de visites.

Google recommande de contrôler les ressources tierces et de vérifier les variantes mobile et ordinateur. Lorsqu’un service tiers légitime est intégré, la relation entre votre marque et le prestataire doit être compréhensible pour le visiteur afin qu’il sache sur quel service il se trouve.

Ne concluez donc pas trop vite qu’un fichier WordPress est nécessairement la source. Contrôlez aussi les tags publicitaires, gestionnaires de consentement, scripts marketing, outils de chat, formulaires externes, services de paiement et autres dépendances chargées sur la page.

Quel périmètre doit couvrir le nettoyage ?

Un nettoyage sérieux doit confirmer que la page et ses mécanismes associés ont disparu, mais aussi vérifier comment l’attaquant a obtenu la capacité de publier ou de servir ce contenu.

• fichiers du cœur WordPress et fichiers ajoutés ;
• extensions, thèmes, composants premium et développements spécifiques ;
• base de données, contenus, options, widgets et scripts injectés ;
• utilisateurs, administrateurs, rôles, sessions et mots de passe d’application ;
• accès hébergement, SFTP, SSH, base de données, panneau de contrôle et DNS ;
• tâches planifiées WordPress et serveur ;
• règles serveur, CDN, proxy, cache et redirections ;
• formulaires, destinations, webhooks, API et services connectés ;
• autres installations, sous-domaines, préproductions et anciennes copies ;
• journaux et chronologie permettant d’identifier le point d’entrée ;
• sauvegardes disponibles et risque de réintroduction.

Pour comprendre les grandes étapes de cette intervention, consultez également le guide Nettoyer un site WordPress piraté.

Quels accès et comptes faut-il sécuriser ?

Une page de phishing suppose qu’un mécanisme de publication ou de modification a été détourné. Contrôlez tous les accès susceptibles d’avoir permis cette action, pas seulement le compte WordPress utilisé au quotidien.

• administrateurs et gestionnaires de contenu WordPress ;
• sessions actives et mots de passe d’application ;
• compte client de l’hébergeur ;
• SFTP, FTP, SSH et gestionnaires de fichiers ;
• base de données et outils d’administration ;
• dépôt de code, CI/CD et plateformes de déploiement ;
• DNS, CDN, proxy, pare-feu et certificats ;
• comptes des agences, prestataires et anciens collaborateurs ;
• services de formulaires, e-mails, paiement, marketing et automatisation.

Les changements de mots de passe doivent être effectués depuis un appareil fiable et idéalement après avoir contenu le site. Révoquez les accès inutiles et activez la double authentification lorsqu’elle est disponible. Une seconde rotation après le nettoyage peut être nécessaire si des secrets étaient présents dans les fichiers ou la base compromise.

Comment savoir si des données ont été réellement collectées ?

La présence d’un formulaire frauduleux ne prouve pas automatiquement que des victimes l’ont utilisé. Il faut rechercher des indices sans manipuler inutilement les données :

• requêtes POST vers la page ou son endpoint ;
• fichiers, tables ou journaux dans lesquels des soumissions ont pu être enregistrées ;
• appels vers un domaine externe, une API, un webhook ou une messagerie ;
• messages reçus dans une boîte e-mail compromise ;
• témoignages de visiteurs ou de la marque usurpée ;
• période pendant laquelle la page était accessible et volume de trafic ;
• campagnes d’e-mails ou de SMS pointant vers l’URL.

L’absence de journal ne permet pas toujours de conclure qu’aucune donnée n’a été transmise. Documentez les limites de l’analyse et évitez toute affirmation définitive qui ne serait pas supportée par des preuves.

Faut-il notifier la CNIL ou informer des personnes ?

Un site utilisé pour du phishing ne déclenche pas automatiquement une notification à la CNIL. La question juridique porte sur l’existence d’une violation de données personnelles, les catégories de données concernées, les personnes touchées et le niveau de risque.

La CNIL rappelle que le responsable de traitement doit notifier une violation susceptible d’engendrer un risque pour les droits et libertés et informer les personnes lorsque ce risque est élevé. L’incident doit être documenté même lorsqu’une notification n’est finalement pas requise.

Il peut également être nécessaire de prévenir :

• la marque, la banque ou l’organisme imité ;
• les personnes dont les identifiants ou données ont pu être saisis ;
• le prestataire de paiement ou de messagerie concerné ;
• l’assureur cyber, le délégué à la protection des données ou le conseil juridique ;
• les équipes internes susceptibles de recevoir des appels de victimes.

Le contenu, le délai et les destinataires doivent être décidés à partir des faits établis. Ne publiez pas d’hypothèse non confirmée et ne transmettez pas de données personnelles dans un signalement public.

Comment traiter l’URL après suppression du phishing ?

Le traitement HTTP dépend de la nature de l’URL :

• si l’URL a été créée uniquement par l’attaquant et n’a aucun équivalent légitime, elle doit généralement renvoyer un véritable 404 ou 410 ;
• si une page légitime a été détournée, restaurez son contenu propre et conservez une réponse 200 ;
• si une ressource légitime a réellement changé d’adresse, utilisez une 301 vers son équivalent exact ;
• n’utilisez pas une redirection générale vers l’accueil pour toutes les URL frauduleuses ;
• retirez les URL des sitemaps, menus, contenus et liens internes éventuels ;
• ne bloquez pas prématurément leur exploration si Google doit encore constater la réponse 404, 410 ou le contenu corrigé.

Une balise noindex ne remplace pas la suppression d’une page de phishing. Le contenu ne doit plus être servi et le mécanisme qui le générait doit être supprimé.

Quand demander un réexamen à Google ?

La demande doit être envoyée lorsque toutes les catégories de problèmes identifiées ont été corrigées et que vous avez vérifié plusieurs URL représentatives. Ne demandez pas l’examen simplement parce que la page d’exemple a disparu.

1. vérifiez que la page frauduleuse et ses variantes ne sont plus accessibles ;
2. confirmez que le point d’entrée, les comptes et la persistance ont été traités ;
3. contrôlez les ressources tierces, les versions mobile et ordinateur et les autres installations ;
4. vérifiez les propriétaires et méthodes de validation Search Console ;
5. rédigez une explication précise des causes identifiées, zones nettoyées et mesures prises ;
6. demandez l’examen dans le rapport Problèmes de sécurité.

Google indique qu’un examen de sécurité peut prendre plusieurs jours. Évitez les demandes répétées avant le résultat. Les sites qui alternent rapidement entre états conformes et non conformes peuvent être classés comme récidivistes par Safe Browsing, ce qui bloque temporairement de nouvelles demandes d’examen.

Faut-il signaler la page à Google Safe Browsing ?

Si une page de phishing active n’est pas encore détectée et ne peut pas être retirée immédiatement, elle peut être signalée à l’équipe Google Safe Browsing via le formulaire officiel de signalement du phishing. Ce signalement vise à protéger les utilisateurs ; il ne remplace ni le nettoyage du site ni la demande d’examen destinée au propriétaire.

Pour votre propre site, le canal principal après correction reste le rapport Problèmes de sécurité de Search Console. Conservez la distinction entre :

• signaler une page dangereuse afin d’aider les systèmes de protection ;
• demander un examen du site après avoir supprimé le problème ;
• demander une nouvelle exploration pour mettre à jour l’index d’une URL propre ou supprimée.

Pourquoi l’avertissement peut-il rester après le nettoyage ?

Les navigateurs et moteurs ne constatent pas instantanément chaque correction. L’URL peut être en cache, attendre une nouvelle exploration ou rester associée au site tant que la demande d’examen n’est pas terminée.

Avant de conclure à un retard normal, vérifiez toutefois :

• que la page répond réellement 404/410 ou sert un contenu propre ;
• qu’aucune variante, sous-page ou ressource tierce ne reste active ;
• que le cache du site, du CDN et du navigateur a été purgé ;
• que le domaine principal, les sous-domaines et les versions HTTP/HTTPS sont contrôlés ;
• que Search Console ne liste pas une autre catégorie de problème ;
• que la demande d’examen a bien été envoyée après la correction complète.

Ne promettez pas une disparition immédiate de l’avertissement. Le délai dépend du nouveau contrôle et du résultat de l’examen.

Les erreurs qui aggravent ou prolongent l’incident

Supprimer uniquement l’URL signalée

Les exemples fournis par Google, l’hébergeur ou une victime ne sont pas exhaustifs. Recherchez les modèles, variantes et mécanismes de génération.

Restaurer sans corriger le point d’entrée

La page peut réapparaître si l’extension vulnérable, le compte ou l’accès compromis reste actif.

Réactiver le site avant les contrôles métier

Une page disparue ne prouve pas que les formulaires, comptes, paiements, e-mails et API sont fiables.

Bloquer les URL uniquement avec robots.txt

Le contenu reste potentiellement accessible aux visiteurs et Google ne peut plus toujours constater la suppression ou la correction.

Rediriger toutes les URL vers l’accueil

Cette réponse ne correspond pas à un déplacement réel et masque l’état des pages frauduleuses.

Demander plusieurs examens successifs

Attendez le résultat de la demande en cours et corrigez toute nouvelle cause avant de soumettre à nouveau.

Communiquer trop tôt une cause certaine

La chronologie et le point d’entrée peuvent rester inconnus faute de journaux. Distinguez faits confirmés, hypothèses et limites.

Quels critères vérifier avant de remettre le site en ligne ?

• toutes les URL frauduleuses connues sont supprimées ou restaurées proprement ;
• aucun nouveau contenu similaire n’est recréé après plusieurs cycles de tâches et de cache ;
• les fichiers, la base, les comptes, les sessions et les accès techniques ont été contrôlés ;
• le point d’entrée probable est corrigé ou compensé ;
• les autres installations et sous-domaines du compte sont vérifiés ;
• les formulaires, paiements, e-mails, API et fonctions métier ont été testés ;
• les sauvegardes sont identifiées, isolées et leur risque évalué ;
• les journaux et alertes nécessaires à la surveillance sont actifs ;
• l’évaluation des données personnelles est documentée ;
• la demande d’examen Google est prête ou déjà soumise lorsque le site est signalé.

La remise en ligne peut être progressive lorsque l’architecture le permet : pages publiques, formulaires, comptes, boutique ou espace client peuvent nécessiter des validations distinctes.

Les informations à transmettre pour accélérer le diagnostic

• l’URL principale du site et l’URL exacte de la page frauduleuse ;
• la date de découverte et la source du signalement ;
• les captures et messages Google, navigateur ou hébergeur ;
• la marque ou le service imité ;
• l’état actuel de l’URL et du site ;
• les éventuels autres chemins ou domaines observés ;
• les actions déjà réalisées ;
• la date des sauvegardes disponibles ;
• les changements, installations ou accès récents ;
• l’impact sur les formulaires, commandes, paiements et comptes ;
• les propriétés Search Console disponibles.

Ne transmettez aucun mot de passe dans le formulaire initial. Les accès temporaires doivent être demandés et communiqués par un canal adapté, limités au strict nécessaire puis révoqués après intervention.

Questions fréquentes

Une page de phishing signifie-t-elle que tout le site est piraté ?

Elle confirme au minimum qu’un contenu frauduleux a pu être servi depuis votre domaine. L’étendue exacte doit être vérifiée : la compromission peut être limitée à un compte ou une zone, mais elle peut aussi concerner les fichiers, la base, l’hébergement ou d’autres sites.

Puis-je simplement supprimer la page dans WordPress ?

Vous devez supprimer ou bloquer rapidement le contenu actif, mais aussi conserver les éléments utiles et rechercher son origine. Si un compte, une tâche ou un fichier peut la recréer, la suppression seule ne résout pas l’incident.

Dois-je mettre tout le site hors ligne ?

Pas systématiquement. Si la page peut être isolée de manière fiable, le reste du site peut parfois rester disponible. Si le checkout, les comptes, plusieurs pages ou le mécanisme de publication sont compromis, une suspension plus large peut être nécessaire.

Pourquoi Google affiche-t-il « Site trompeur » alors que la page a été supprimée ?

L’avertissement peut attendre un nouveau contrôle ou une demande d’examen. Vérifiez d’abord qu’aucune variante, ressource tierce ou page en cache ne reste active, puis demandez l’examen dans Search Console.

Combien de temps prend le réexamen Google ?

Google indique qu’un examen de sécurité peut prendre plusieurs jours. Le délai n’est pas garanti. Ne soumettez la demande qu’après avoir corrigé l’ensemble du problème.

Faut-il prévenir la marque imitée ?

Oui, lorsque la page usurpe clairement une banque, une administration ou une entreprise, un signalement peut l’aider à protéger ses utilisateurs. Transmettez des faits vérifiés et évitez de partager des données personnelles ou des identifiants de victimes.

Faut-il notifier automatiquement la CNIL ?

Non. Il faut déterminer si des données personnelles ont été affectées et si la violation présente un risque pour les personnes. L’incident doit néanmoins être documenté, y compris lorsque la notification n’est pas requise.

Une analyse antivirus ou un plugin de sécurité suffit-il ?

Non. Un scanner peut repérer certains fichiers ou signatures, mais il ne couvre pas nécessairement les comptes, la base de données, les règles serveur, les services tiers, les autres installations et la chronologie de l’incident.