# En ligne > Les deux adresses à poser, la génération qui tourne toute seule, et le contrôle qui arrête une mauvaise publication. Leçon 3 sur 3 — la dernière du cours. Le site est un dossier de fichiers HTML. Le mettre en ligne, c'est copier ce dossier quelque part — le travail est dans les deux adresses que vous posez avant, et dans le contrôle qui vient après. ## Les deux adresses Elles répondent à des questions différentes, et les confondre est la façon la plus courante de publier un site cassé : | Champ | Répond à | Ressemble à | | --------- | ------------------------------------- | ------------------------------- | | `baseUrl` | Où le site se trouve chez l'hébergeur | `/` ou `/mon-cours/` | | `siteUrl` | L'adresse publique complète du site | `https://example.com/mon-cours` | ```js siteUrl: 'https://example.com/mon-cours', baseUrl: '/mon-cours/', ``` `baseUrl` préfixe tous les liens internes. Servi depuis un sous-dossier sans lui, chaque lien pointe un niveau trop haut — le site marche sur votre machine et casse à l'instant où il est en ligne. `siteUrl` est ce qui permet à la génération d'écrire un plan du site, des adresses canoniques et des aperçus de partage. `npx docpensieve dev` sert à la racine : un mauvais `baseUrl` ne s'y voit jamais. Générez et ouvrez `dist/` comme le fera l'hébergeur — c'est la seule répétition honnête. ## À vous : générer et relire ```bash npx docpensieve build npx docpensieve check ``` La première écrit le site. La seconde le relit et **sort en code 1** si un lien ne mène nulle part — c'est ce qui la rend utile dans une chaîne d'intégration : une génération réussie ne dit rien d'un lien qui ne l'est pas.
`check` règle la deuxième jauge. La troisième est la vôtre — rien n'automatise la relecture de vos propres pages. ## Une génération qui tourne toute seule La forme de la chaîne compte plus que son dialecte. Chaque hébergeur l'écrit à sa façon ; tous font les mêmes quatre choses : ```yaml - run: npx docpensieve build # Une génération réussie ne dit rien d'un lien mort. - run: npx docpensieve check ``` Un projet créé par `init` n'a pas de `package.json` : `npx` prend donc la dernière version publiée — pratique au début, surprenant plus tard. Déclarez l'outil dans un `package.json` et lancez `npm ci` avant la génération, et deux générations à un mois d'écart produisent le même site. ## Ce que télécharge le lecteur Un fichier HTML Complet à lui seul, servi tel quel — aucun framework à démarrer. Une feuille de style Par version, minifiée, ne portant que les règles qu'emploient les pages. Aucun script Hormis la page de recherche, et le bouton clair / sombre si vous le gardez. ## Vérifiez par vous-même
Votre site est servi depuis `example.com/docs/` et tous les liens tombent en 404. Qu'avez-vous oublié ? `baseUrl: '/docs/'`. Sans lui, les liens sont écrits depuis la racine du domaine et pointent un niveau au-dessus du site.
Pourquoi lancer `check` dans la chaîne alors que la génération est déjà passée ? Parce qu'ils regardent des choses différentes. La génération compile les pages ; `check` relit le site produit et suit ses liens. Une page renommée compile parfaitement et laisse morts tous les liens qui la visaient.
## Séance en direct **La séance en direct a lieu aujourd'hui.** Apportez vos questions. Prochaine séance en direct : **15 octobre**. Apportez le site construit pendant le cours. La séance est passée — ses questions et réponses sont ci-dessous. ## Vous y êtes Vous avez terminé le cours. Votre site est généré, relu, à vos couleurs, et prêt à être mis en ligne. Retour au cours Tous les modules, et ce que chacun couvre. Le guide de déploiement La chaîne complète, une génération programmée, et garder les versions passées en ligne.