Comment un site tombe : anatomie illustrée d’une attaque web

Un site ne tombe presque jamais à cause d’un unique geste spectaculaire. Il cède plutôt comme un bâtiment dont plusieurs portes ont été laissées entrouvertes : une technologie trop bavarde révèle sa version, un ancien sous-domaine reste en ligne, une archive de sauvegarde devient publique, un contrôle d’accès n’est effectué que dans l’interface, puis une donnée fournie par un utilisateur atteint un interpréteur qui la prend pour une instruction.

Chaque faiblesse paraît parfois modeste. Ensemble, elles dessinent un itinéraire. C’est ce trajet que nous allons suivre, depuis les premières informations visibles publiquement jusqu’à l’incident, puis dans les premières heures de la réponse. Pour rendre l’ensemble concret, imaginons Maison Aster, une boutique en ligne fictive dotée d’un catalogue, de comptes clients, d’un espace d’administration, d’un formulaire de contact et d’un service de paiement.

Cette enquête n’est pas un manuel d’effraction. Elle décrit les mécanismes, les frontières de confiance, les signaux observables et les mesures capables de rompre la chaîne. L’enjeu n’est pas de mémoriser des charges malveillantes, mais de comprendre pourquoi une application accepte parfois une donnée pour ce qu’elle n’est pas.

Un site est une chaîne de décisions

La page visible n’est que la façade. Derrière elle se trouvent le navigateur, le serveur web, l’application, une ou plusieurs API, le système d’identité, la base de données, le stockage de fichiers, des services tiers, des tâches automatiques et une infrastructure d’administration. Une même action traverse plusieurs de ces couches.

Lorsqu’un client change son adresse de livraison, le navigateur envoie une demande, la session identifie le compte, l’application vérifie les droits, la base enregistre la nouvelle valeur et les journaux consignent l’opération. La sécurité dépend de chaque décision prise le long de ce parcours. Si une couche suppose que la précédente a déjà contrôlé la donnée, un espace s’ouvre entre les deux.

Le scénario classique suit cinq temps : cartographier, vérifier, exploiter une erreur de confiance, élargir l’accès, puis tenter de durer ou de rendre l’enquête plus difficile. Ces étapes ne sont pas obligatoires et leur ordre peut varier. Elles donnent néanmoins une grille de lecture utile : les défenses les plus efficaces sont celles qui empêchent une faiblesse locale de devenir une compromission générale.

Première étape : la reconnaissance, ou l’art de lire ce qui est déjà public

Avant de toucher à une application, un adversaire peut apprendre beaucoup sans lui envoyer la moindre requête inhabituelle. Les noms de domaine et sous-domaines, les offres d’emploi, les documentations publiques, les dépôts de code, les certificats, les mentions légales, les profils professionnels et les fichiers indexés révèlent parfois l’architecture d’une organisation.

Maison Aster communique par exemple sur une migration récente. Une annonce de recrutement cite son framework. Un ancien dépôt contient le nom d’un environnement de préproduction. Une archive créée pendant la migration est restée accessible depuis le serveur public. Aucun de ces éléments ne constitue, à lui seul, une intrusion. Leur rapprochement réduit pourtant l’incertitude : l’adversaire sait quelles portes chercher et quelles hypothèses tester.

La reconnaissance active commence lorsque l’on interroge directement les systèmes : services exposés, réponses HTTP, en-têtes, pages d’erreur, fichiers de découverte, interfaces oubliées ou versions de composants. Une bannière trop précise peut relier un service à une vulnérabilité connue. Un répertoire listé publiquement peut révéler une sauvegarde. Un fichier destiné aux robots d’indexation peut signaler une zone sensible sans la protéger.

La réponse défensive commence par un inventaire réel. Il faut connaître les domaines, les applications, les API, les services d’administration, les dépendances et les environnements encore accessibles. Une surface que l’organisation a oubliée ne reçoit plus de correctifs, mais reste parfaitement visible depuis Internet. Les archives de déploiement, exports de base, fichiers de configuration et anciennes versions doivent quitter la racine web. Les répertoires ne doivent pas être listés. Les messages d’erreur et bannières doivent donner à l’utilisateur ce dont il a besoin sans publier une fiche technique complète.

Le scanner trouve des motifs ; l’humain comprend le métier

Les outils automatiques excellent à reconnaître des signatures : composant obsolète, configuration courante, paramètre qui réagit de façon inhabituelle, en-tête absent ou contenu accidentellement exposé. Ils peuvent examiner rapidement une surface importante et répéter les mêmes vérifications après chaque déploiement.

Leur limite apparaît dès que la vulnérabilité dépend du sens d’une action. Un scanner peut voir qu’une route renvoie un document. Il ne sait pas toujours qu’un client ne devrait jamais pouvoir lire la facture d’un autre. Il peut constater qu’un formulaire accepte une valeur, sans comprendre qu’une remise réservée au personnel devient cumulable avec un remboursement. Les erreurs de logique métier se cachent moins dans la syntaxe que dans les règles implicites.

Maison Aster dispose ainsi d’une page de commande parfaitement valide sur le plan technique. Le navigateur cache le bouton d’annulation après l’expédition, mais le serveur n’applique pas la même règle. L’interface donne l’impression d’un état verrouillé ; l’API continue pourtant d’accepter l’action. Ce type d’écart exige une lecture du parcours complet et des rôles : client, opérateur, administrateur, service automatique.

Une bonne pratique associe donc analyse de dépendances, tests automatisés, revue de configuration et tests manuels fondés sur des scénarios. Elle vérifie aussi les cas négatifs : ce qu’un utilisateur non connecté, un client ordinaire ou un compte appartenant à une autre organisation doit être incapable de faire. Le résultat attendu n’est pas seulement « la fonctionnalité marche », mais « elle refuse correctement tout contexte qui ne satisfait pas ses règles ».

XSS : quand le navigateur imprime une donnée comme une instruction

Le cross-site scripting, ou XSS, apparaît lorsqu’une donnée contrôlée par un tiers est incorporée dans une page de telle sorte que le navigateur l’interprète comme du contenu actif. La frontière de confiance est ici particulièrement délicate : le code s’exécute dans le contexte du site légitime. Pour le navigateur, il partage donc l’origine, l’interface et souvent les droits de la session ouverte.

Dans une XSS stockée, la donnée dangereuse est enregistrée — dans un commentaire, une biographie, une fiche produit ou un ticket — puis servie à chaque lecteur. Dans une XSS réfléchie, elle revient immédiatement dans une réponse, souvent à partir d’un paramètre d’URL ou d’un message d’erreur. Dans une XSS fondée sur le DOM, c’est le code exécuté dans le navigateur qui prélève une valeur et l’insère dans un emplacement dangereux, parfois sans nouveau passage par le serveur.

Imaginons l’éditeur d’avis de Maison Aster. L’interface nettoie le texte avant l’envoi, mais l’API accepte également les demandes directes et enregistre la valeur brute. Lors de l’affichage, la page l’injecte ensuite dans une zone interprétée comme du HTML. Deux contrôles existent, mais aucun n’est placé à la frontière décisive : le serveur fait confiance au navigateur lors de l’entrée, puis le navigateur fait confiance à la donnée lors de la sortie.

Une XSS ne se résume pas au vol d’un cookie. Un cookie de session marqué HttpOnly ne peut pas être lu directement par le script de la page, ce qui réduit un risque important. Le contenu actif peut néanmoins agir depuis la session déjà ouverte : lire ce que l’utilisateur peut lire dans la page, déclencher certaines actions, modifier un formulaire ou présenter une fausse interface. La conséquence dépend donc des droits de la victime et des fonctions accessibles depuis son navigateur.

La protection repose d’abord sur l’encodage adapté au contexte de sortie. Une donnée affichée dans du texte HTML, un attribut, une URL ou une chaîne JavaScript n’obéit pas aux mêmes règles. Les frameworks modernes échappent généralement le texte par défaut ; les fonctions qui insèrent du HTML brut doivent devenir rares, documentées et revues. Lorsque le produit doit accepter du HTML enrichi, une bibliothèque de désinfection maintenue doit appliquer une politique explicite côté serveur et, si utile, côté client.

Une politique de sécurité du contenu peut limiter les sources autorisées et compliquer l’exécution d’un contenu injecté. Elle constitue une couche supplémentaire, pas un remplacement de l’encodage et de la désinfection. Les recommandations détaillées de l’OWASP sur la prévention des XSS insistent précisément sur ces contrôles contextuels et sur le choix de sorties sûres.

Les signaux incluent des erreurs répétées dans les champs riches, des séquences inhabituelles dans les commentaires, des violations de politique de contenu, des modifications de pages sans action correspondante et des appels internes déclenchés juste après l’affichage d’un contenu. Conserver la valeur brute dans les journaux exige toutefois de l’isoler : un outil d’administration ne doit pas transformer à son tour le journal malveillant en page active.

Injection SQL : la base confond la question et la donnée

Une application interroge sa base pour trouver un compte, enregistrer une commande ou produire une facture. L’injection SQL devient possible lorsqu’elle construit cette requête en concaténant directement une valeur fournie par l’utilisateur. La base ne reçoit plus une instruction fixe accompagnée d’un paramètre ; elle reçoit une seule chaîne dont une partie non fiable peut modifier la structure.

Dans notre boutique fictive, la recherche de commande attend une référence. Si l’application colle cette référence dans la requête, une valeur préparée pour changer le sens de la condition peut contourner le filtre, provoquer une erreur révélatrice ou élargir les données renvoyées. Certaines injections produisent un résultat visible. D’autres sont dites aveugles : l’adversaire déduit une réponse à partir d’une différence de contenu, de statut ou de temps, sans que la base affiche directement ses données.

Les conséquences dépendent du compte utilisé par l’application. Un compte limité à la lecture de quelques tables réduit l’impact. Un compte capable de modifier le schéma, d’accéder à toutes les bases ou d’appeler des fonctions système transforme la même erreur en incident beaucoup plus grave. Le principe du moindre privilège agit donc comme une cloison, même lorsque la première protection a échoué.

La défense principale consiste à utiliser des requêtes préparées paramétrées. Le moteur reçoit séparément la structure de l’opération et les valeurs. Une bibliothèque d’accès aux données ou un ORM ne protège que si son mode sûr est réellement utilisé : une requête brute construite par concaténation reste dangereuse, même à l’intérieur d’un outil réputé.

Les noms de tables, de colonnes ou de directions de tri ne peuvent pas toujours être paramétrés comme des valeurs. Ils doivent alors provenir d’une liste fermée contrôlée par l’application. La validation de format reste utile pour la qualité des données et la réduction de surface, mais elle ne remplace pas la séparation entre commande et paramètre. L’OWASP recommande les requêtes préparées comme défense centrale, complétées par des privilèges minimaux et des listes autorisées lorsque la structure doit varier.

Du côté de la détection, les équipes doivent surveiller les erreurs de base, les requêtes inhabituellement lentes, les accès massifs, les variations soudaines de volume et les lectures qui ne correspondent pas au parcours utilisateur. Les messages d’erreur envoyés au client ne doivent pas dévoiler la requête, le moteur ou la structure interne. Les détails utiles à l’enquête restent dans des journaux protégés.

CSRF : une session authentique, une intention absente

Le cross-site request forgery, ou CSRF, exploite un comportement normal du navigateur : lorsqu’il envoie une demande à un site, il peut joindre automatiquement les cookies de ce site. Si l’utilisateur est connecté à Maison Aster et visite parallèlement une page malveillante, celle-ci peut tenter de provoquer une demande vers la boutique. Le serveur voit une session valide, mais ne sait pas encore si l’utilisateur a voulu l’action.

Cette attaque est différente d’une XSS. Le contenu malveillant n’a pas besoin de s’exécuter dans la page de Maison Aster ; il cherche à faire envoyer une demande depuis une autre origine. Elle devient possible lorsque l’application se contente du cookie et accepte une opération sensible sans preuve supplémentaire de provenance ou d’intention.

Les changements d’état ne doivent jamais dépendre d’une simple consultation en GET. Les formulaires et appels sensibles doivent utiliser les protections CSRF natives du framework, avec un jeton imprévisible lié à la session ou à la requête. Le serveur peut aussi vérifier les en-têtes d’origine lorsque le contexte le permet. L’attribut SameSite des cookies réduit l’envoi automatique entre sites : Strict est le plus restrictif, Lax convient à de nombreux parcours, et None exige une compréhension précise du besoin ainsi qu’un transport sécurisé.

Pour une modification critique — moyen de paiement, adresse de récupération, mot de passe, bénéficiaire — une nouvelle authentification ou une confirmation explicite apporte une barrière supplémentaire. Une API authentifiée par un secret placé volontairement dans un en-tête et non joint automatiquement par le navigateur présente un modèle différent, à condition de ne pas exposer ce secret à un script tiers.

Une XSS active dans le même site peut souvent lire un jeton présent dans la page ou déclencher l’action comme l’utilisateur. C’est pourquoi la fiche OWASP sur la prévention du CSRF rappelle que la correction des XSS reste essentielle. Les protections se renforcent entre elles ; aucune case cochée ne rend l’ensemble magique.

IDOR : connaître l’identifiant ne donne pas le droit d’ouvrir le dossier

L’IDOR, ou référence directe non sécurisée à un objet, appartient à la famille des défauts de contrôle d’accès. Une URL ou une requête contient l’identifiant d’une facture, d’un profil, d’un billet ou d’une commande. L’application vérifie que l’utilisateur est connecté, retrouve l’objet demandé, puis le renvoie sans confirmer qu’il appartient bien à cet utilisateur ou à son organisation.

Le problème n’est pas que l’identifiant soit court ou prévisible. Remplacer un nombre séquentiel par un identifiant long rend l’exploration moins commode, mais ne crée pas une autorisation. Si un lien copié vers une autre session affiche encore le document, la règle manque toujours au serveur.

Pour Maison Aster, la bonne question n’est donc pas « cette commande existe-t-elle ? », mais « ce compte a-t-il le droit d’effectuer cette action sur cette commande dans son état actuel ? ». La vérification doit être répétée pour chaque lecture, modification, téléchargement et suppression. Elle ne doit dépendre ni d’un bouton masqué ni d’une liste déjà filtrée dans l’interface.

Les modèles robustes partent du refus. Ils définissent les rôles, les relations entre sujets et objets, ainsi que les états autorisés, puis appliquent la règle dans une couche commune. Les tests doivent croiser au minimum deux comptes ordinaires, deux organisations, un compte privilégié et un compte désactivé. Les téléchargements méritent le même contrôle que les pages HTML : une URL de fichier n’est pas une autorisation.

Les signes d’abus comprennent des séquences rapides d’identifiants, un compte consultant des objets sans relation, des téléchargements en série et des refus répétés suivis d’un succès sur une route voisine. La catégorie Broken Access Control de l’OWASP Top 10 place précisément ces erreurs au cœur du risque applicatif.

Téléversement de fichiers : le colis ne doit jamais entrer directement dans l’atelier

Un avatar, une pièce jointe ou un document importé traverse une frontière puissante. Le fichier vient d’un utilisateur, mais sera stocké, analysé, transformé et parfois servi à d’autres. Vérifier seulement son extension ou le type annoncé par le navigateur revient à croire l’étiquette collée sur le colis.

Une politique sûre commence par une liste des formats réellement nécessaires. Elle contrôle la taille, le nombre de fichiers, le type détecté et, lorsque c’est pertinent, la signature interne. Elle attribue un nouveau nom, supprime les chemins fournis par le client et stocke le contenu hors de la racine publique, dans un emplacement qui ne peut pas exécuter de code. Le téléchargement repasse ensuite par une route qui contrôle les droits et force un type de réponse approprié.

L’analyse antivirus ou la reconstruction de certains documents peut ajouter une couche, mais ne remplace pas l’isolation. Les moteurs d’image, de PDF et d’archive sont eux-mêmes des logiciels à maintenir. Les archives exigent des limites sur leur taille décompressée, leur profondeur et le nombre de fichiers pour éviter qu’un petit envoi n’épuise le stockage ou la mémoire.

Une faiblesse de téléversement devient critique lorsqu’un fichier placé sur le serveur est interprété comme un programme, lorsqu’un format actif est servi dans le contexte du site, ou lorsqu’un traitement privilégié ouvre automatiquement une pièce jointe non fiable. La conception doit donc partir de cette question : quelle est la chose la plus dangereuse que chaque composant pourrait croire à propos de ce fichier ?

Injection de code et de commandes : la seconde interprétation qui n’aurait jamais dû exister

L’injection de commandes survient lorsqu’une application assemble une commande système avec une donnée non fiable. L’injection de code est une famille plus large : la donnée atteint un moteur de modèle, une fonction d’évaluation ou un autre interpréteur qui lui donne le pouvoir de décrire un comportement.

Un cas subtil apparaît avec le double rendu. Maison Aster autorise quelques variables simples dans un modèle de courrier. Le premier moteur remplace ces variables et produit du texte. Pour gagner du temps, un second mécanisme traite ensuite ce résultat comme un nouveau modèle plus puissant. Une valeur qui aurait dû rester du contenu devient alors une instruction pour le deuxième interpréteur. La faille se situe dans la décision de réinterpréter la sortie.

La meilleure défense est de supprimer ce passage : produire du texte ou une structure de données, puis l’afficher sans évaluation supplémentaire. Pour une opération système, une API spécialisée est préférable au lancement d’un shell. Si aucun remplacement n’existe, le programme doit séparer l’exécutable de ses arguments, choisir les opérations dans une liste fermée, valider chaque paramètre et fonctionner avec un compte très limité. Échapper une chaîne pour un shell reste fragile parce que plusieurs couches peuvent l’analyser différemment.

Les processus web ne devraient pas pouvoir écrire dans leur propre code, modifier les journaux centraux ou lancer des outils sans rapport avec leur fonction. Les conteneurs limitent certaines conséquences, mais ne corrigent pas l’injection : secrets montés, réseau interne, volumes partagés et interfaces d’orchestration déterminent l’ampleur réelle de l’accès. La fiche OWASP consacrée à l’injection de commandes privilégie l’évitement des appels système, puis la séparation stricte des paramètres et les listes autorisées.

Les vulnérabilités deviennent graves lorsqu’elles se répondent

Une organisation peut corriger chaque anomalie selon une note isolée et sous-estimer la chaîne. L’ancien sous-domaine révèle une version. Une archive publique expose un secret de test réutilisé. Ce compte ouvre une interface interne. Un IDOR donne accès à un document d’administration. Une XSS stockée atteint ensuite le navigateur d’un opérateur. Enfin, un téléversement trop permissif ou une injection permet d’agir sur le serveur.

Chaque maillon change la valeur du suivant. Une XSS sur une page anonyme est déjà un défaut ; sur une console consultée par les administrateurs, son impact potentiel augmente. Une injection SQL sous un compte de lecture limité reste grave ; sous un compte propriétaire de toutes les bases, elle peut devenir systémique. Un accès à un conteneur isolé ne vaut pas un accès à l’hôte ; un socket d’orchestration monté dans ce conteneur peut effacer cette frontière.

Le remède est architectural. Les secrets de test ne doivent pas fonctionner en production. Les comptes techniques n’obtiennent que les droits nécessaires. Les interfaces d’administration utilisent une identité renforcée et un réseau contrôlé. Les sorties réseau sont limitées selon le besoin. Les environnements sont séparés. Les sauvegardes et journaux ne sont pas modifiables par le même compte que l’application.

Cette logique transforme la défense en profondeur en quelque chose de concret : même après une erreur dans le code, les autres couches continuent à limiter les données accessibles, les actions possibles, la durée de l’accès et la capacité à dissimuler l’incident.

Après l’accès : persistance, traces et point de vue de l’enquêteur

Une compromission ne se termine pas au premier accès. Un adversaire peut chercher d’autres identifiants, créer un chemin de retour, modifier une tâche automatique ou profiter d’une intégration de déploiement. Décrire les procédés de dissimulation comme une recette serait irresponsable ; pour le défenseur, l’essentiel est de reconnaître leurs effets : trous dans la chronologie, journaux locaux vidés, dates incohérentes, nouveaux comptes, tâches inconnues, fichiers système modifiés et services qui redémarrent sans changement prévu.

Si l’application peut effacer ses propres journaux, un attaquant ayant pris son identité le peut aussi. Les événements importants doivent donc quitter rapidement l’hôte vers une plateforme séparée. Les droits d’écriture doivent être append-only lorsque c’est possible ; la consultation, la suppression et la modification obéissent à des rôles distincts. Les horloges doivent être synchronisées afin de relier une connexion, une requête API, une requête de base et une action d’administration.

Tout enregistrer n’est pas la solution. Un journal utile répond à des questions : qui a demandé quoi, sur quel objet, avec quel résultat, depuis quel contexte et à quel moment ? Il évite les mots de passe, jetons de session et données personnelles inutiles. Il protège l’intégrité des éléments nécessaires à l’enquête et déclenche des alertes sur les comportements à forte valeur : élévation de privilège, création de compte administratif, export massif, modification de règles ou effacement de traces.

L’OWASP classe les défaillances de journalisation et d’alerte parmi les risques majeurs : un événement non détecté donne à l’adversaire le temps de transformer une faiblesse ponctuelle en présence durable.

Les premières vingt-quatre heures d’un incident

La précipitation peut détruire la preuve ou laisser l’accès ouvert. La première décision consiste à qualifier ce qui est certain, probable et encore inconnu. L’équipe conserve les journaux, captures d’état et artefacts volatils utiles avant de reconstruire. Elle limite l’accès au système touché, sans couper aveuglément les sources qui permettent encore de comprendre la chronologie.

La réponse peut suivre sept mouvements :

• ouvrir une chronologie commune et nommer un responsable de décision ;
• préserver les journaux distants, l’état des comptes, les déploiements et les images des systèmes concernés ;
• isoler le composant compromis et bloquer le vecteur confirmé ;
• révoquer les sessions, clés et secrets exposés selon leur portée réelle ;
• rechercher le même indicateur dans les autres environnements et chez les services dépendants ;
• reconstruire depuis une base connue, corriger la cause et vérifier les contrôles voisins ;
• évaluer les obligations de notification, puis informer avec des faits datés plutôt qu’avec des suppositions.

Changer tous les mots de passe ne corrige pas une injection. Mettre un serveur hors ligne ne supprime pas un accès persistant ailleurs. Restaurer une sauvegarde sans fermer le point d’entrée rejoue l’incident. La remédiation doit relier la cause technique, les privilèges obtenus, les mouvements possibles et les données effectivement touchées.

Après le retour au service, l’organisation transforme l’enquête en changements vérifiables : test de non-régression, règle de détection, réduction de privilèges, propriétaire désigné et date de contrôle. Un rapport utile ne cherche pas un coupable commode. Il explique quelles décisions du système ont permis la chaîne et comment chacune sera rendue plus difficile à reproduire.

Le contrôle décisif pour chaque frontière

La sécurité web devient plus lisible lorsque chaque composant répond à une question précise :

• inventaire : connaissons-nous toutes les surfaces accessibles et leur propriétaire ?
• identité : la session correspond-elle encore à un compte actif et au bon niveau d’assurance ?
• autorisation : ce sujet peut-il effectuer cette action sur cet objet dans cet état ?
• rendu : cette valeur restera-t-elle une donnée dans le contexte où elle est placée ?
• base : la requête et ses paramètres sont-ils séparés jusqu’au moteur ?
• navigateur : l’opération prouve-t-elle l’intention et l’origine attendues ?
• fichier : son contenu réel est-il vérifié, isolé, renommé et servi sans exécution ?
• interpréteur : pouvons-nous supprimer l’évaluation ou remplacer le shell par une API ?
• privilèges : que peut encore atteindre ce composant si son code est compromis ?
• journalisation : la chronologie survivra-t-elle à la perte de l’hôte ?

Ces questions doivent apparaître dans les revues de conception, les tests et les procédures d’incident. Elles évitent de réduire la sécurité à un scanner ou à une liste de correctifs. Un outil signale une anomalie ; une architecture décide jusqu’où elle peut se propager.

Rompre la chaîne avant qu’elle ne devienne une histoire

Le récit d’une attaque réussie paraît souvent inévitable après coup. Les indices étaient publics, l’archive était là, le contrôle manquait, le journal n’a pas alerté. Avant l’incident, ces mêmes éléments vivaient dans des équipes et des outils différents. Personne ne voyait la trajectoire complète.

La maturité consiste à rendre cette trajectoire visible plus tôt. Elle associe inventaire, sorties sûres, requêtes paramétrées, autorisation par objet, protection de l’intention, traitement isolé des fichiers, suppression des interprétations inutiles, moindre privilège et journaux indépendants. Aucun de ces contrôles ne promet l’invulnérabilité. Ensemble, ils retirent des maillons, réduisent l’impact et accélèrent la détection.

Un site solide n’est pas celui qui ne contient jamais d’erreur. C’est celui où une erreur ne suffit pas à ouvrir la pièce suivante, où les actions anormales laissent une trace fiable et où l’équipe sait précisément quoi préserver, isoler et reconstruire lorsqu’une alerte devient un incident.