duxt est une couche, pas un modèle. Vous l’étendez, et chaque fichier qu’elle
fournit devient surchargeable : placez un fichier du même nom dans votre projet
et Nuxt résout le vôtre en premier. Rien n’est copié dans votre dépôt : une mise
à jour est donc un changement de version, pas une fusion.

## Ce que cela signifie en pratique

| Vous voulez                                   | Vous faites                                            |
| :-------------------------------------------- | :----------------------------------------------------- |
| Changer un texte, un lien, une option          | Définir la clé dans votre `app/app.config.ts`          |
| Remplacer un morceau de la mise en page        | Créer `app/components/DuxtFooter.vue` dans votre projet |
| Restyler le thème                              | Redéfinir une variable CSS dans votre feuille de style  |
| Ajouter une page                               | Écrire du Markdown dans `docs/`                         |

L’ordre est délibéré : les trois premiers sont des engagements de plus en plus
lourds, et un composant que vous remplacez est un composant que vous maintenez
désormais. Voir [Surcharger le thème](/guides/override-the-theme).

## Ce qu’elle vous retire

Une couche ne connaît jamais le projet qui repose sur elle. Deux conséquences
que l’on ressent :

- **`@` est à vous, pas à la couche.** L’alias appartient à celui qui étend
  duxt ; les imports de la couche utilisent donc `@duxt`. Le vôtre continue de
  pointer vers votre `app/`.
- **Une collection se résout par rapport à la couche, pas à vous.** Content
  enregistre comme racine de chaque collection la couche qui l’a déclarée : un
  `cwd` relatif dans la configuration de duxt pointerait donc à l’intérieur de
  duxt. La couche calcule pour cette raison un chemin absolu au chargement, ce
  qui fonctionne parce que `content.config.ts` est du code exécuté et non un
  fichier de données — et c’est sur cette jointure que repose tout le raccourci
  `sources`.

## Pourquoi c’est construit ainsi

L’alternative est un modèle de départ : `nuxi init`, et le thème devient une
copie dans votre dépôt. Cela donne une liberté totale et aucun chemin de mise à
jour — chaque amélioration du thème est un diff que quelqu’un doit appliquer à
la main. Une couche inverse cela : vous héritez des améliorations et ne payez
que là où vous n’étiez pas d’accord.

Ce qui fige tout cela, c’est la surface publique. Un composant, une page ou une
clé d’`app.config` que vous pouvez surcharger est un nom dont vous dépendez :
en renommer un est donc un changement cassant de la couche — ce que documente
précisément la [référence](/reference).