# Paramètres généraux (/fr/docs/platform/websites/general-settings)



**Paramètres** > **Général** contient le nom et l'URL du site web ainsi que les deux actions destructrices. Il vous faut le rôle **Gestionnaire** sur le site web pour modifier les détails, et **Administrateur** pour réinitialiser ou supprimer.

## Détails du site web [#détails-du-site-web]

Le **Nom** est le libellé utilisé dans les listes, les fils d'Ariane et les notifications d'alerte. Renommer est sans risque et n'affecte que l'affichage.

L'**URL** est l'adresse publique du site. La changer ne déplace pas votre endpoint de reporting et n'invalide rien de ce qui a déjà été collecté, corriger une faute de frappe ne présente donc aucun risque.

Sélectionnez **Enregistrer les modifications** quand vous avez terminé.

## Réinitialiser les reports [#réinitialiser-les-reports]

Supprime tous les reports stockés pour ce site web.

<Callout type="error" title="La réinitialisation des reports est irréversible">
  Il n'y a pas d'étape d'export ni de récupération possible. Exportez d'abord ce dont vous avez besoin, depuis l'export CSV disponible sur chaque page de report ou depuis le dossier de preuves PCI DSS.
</Callout>

Le détail important : **la réinitialisation ne remet pas la consommation à zéro.** Les reports déjà ingérés sur la période comptent toujours dans votre quota mensuel. Réinitialiser libère du stockage et vide les dashboards, pas votre allocation, ce n'est donc pas un moyen de rattraper un dépassement.

Les usages raisonnables sont l'effacement des données de test avant une mise en production, ou la suppression d'une salve de bruit qui rend les dashboards illisibles une fois sa cause corrigée. Si votre objectif est d'arrêter le bruit plutôt que de le cacher, les [filtres d'ingestion](/fr/docs/platform/websites/reporting-settings) sont le bon outil.

Ce qui survit à une réinitialisation : vos décisions de revue PCI DSS et leur registre d'audit. Ils vivent séparément du stockage des reports, ce qui garde les preuves utiles une fois les reports sous-jacents expirés.

## Supprimer le site web [#supprimer-le-site-web]

Supprime définitivement le site web, sa configuration et ses reports.

<Callout type="error" title="La suppression du site web est irréversible">
  Tout disparaît : les paramètres, les filtres d'ingestion, les canaux et règles d'alerte, le périmètre PCI DSS et la revue de scripts, les accès accordés et les reports. Recréer un site avec le même nom et la même URL n'en ramène rien.
</Callout>

La suppression libère aussi l'endpoint de reporting. Si le site avait un sous-domaine personnalisé, ce hostname entre en quarantaine pour 90 jours avant que quiconque puisse le réserver de nouveau, vous compris. Voir [Sous-domaine personnalisé](/fr/docs/platform/websites/custom-subdomain).

Avant de supprimer, demandez-vous si l'une des options plus douces ne suffirait pas :

* **Pour arrêter la collecte tout en gardant l'historique**, retirez les headers de votre site. Le site web reste, ses reports restent, et rien de nouveau n'arrive.
* **Pour empêcher un site emballé de consommer le quota**, définissez plutôt une limite de reports pour ce site web. Voir [Consommation et limites](/fr/docs/platform/websites/usage-and-limits).
* **Pour confier un site à une autre équipe**, modifiez ses accès plutôt que de le supprimer et de le recréer. Voir [Contrôle d'accès](/fr/docs/platform/websites/access-control).

La suppression est enregistrée dans le journal d'audit de l'espace de travail, avec qui l'a faite et quand. Voir [Journaux d'audit](/fr/docs/platform/security/audit-log).

## Étapes suivantes [#étapes-suivantes]

* [Contrôle d'accès](/fr/docs/platform/websites/access-control)
* [Consommation et limites](/fr/docs/platform/websites/usage-and-limits)
* [Vue d'ensemble des sites web](/fr/docs/platform/websites)