@hgdc/docs 0.4.2 → 0.4.3

package/template/.build/_hgdc/corpus.json

@@ -1 +1 @@
-{"format":1,"project":"js743wp3001k1jvrdad0fwcjx18gc789","name":"Host","language":"fr","builtAt":"2026-10-17T17:09:36.273Z","theme":{"primary":"#194ff7","logo":"/docs/images/logo.svg"},"versions":[{"id":null,"label":null,"isDefault":true}],"pages":[{"path":"/docs/concepts/confidentialite/","title":"Sécurité et confidentialité","description":"Ce que Host fait pour protéger tes projets, tes secrets, tes sites et les visiteurs, et comment signaler une faille.","version":null,"markdown":"Cette page décrit ce que Host fait pour protéger tes projets, tes secrets, les sites qu’il sert et les visiteurs de ces sites. Elle ne remplace pas ton analyse de risque. Pour une question précise sur le traitement de tes données personnelles, écris à <support@hgdc.ch>.\n\n## Accès\n\n- La connexion passe uniquement par HGDC. Host ne garde aucun mot de passe.\n- Chaque action vérifie ton rôle dans l’organisation : propriétaire, admin ou membre. Voir [Organisations et rôles](/docs/concepts/organisations-et-roles/).\n- Une clé d’API ne donne accès qu’à une organisation. Une clé posée dans un dépôt ne donne accès qu’à son projet.\n- Les dépôts GitHub ne s’importent que si tu as le droit d’écriture. L’app GitHub ne demande que les droits dont le workflow a besoin.\n\n## Secrets\n\n- Les valeurs des variables sont chiffrées dans un coffre. Chaque organisation a sa propre clé. Voir [Secrets et coffre](/docs/concepts/secrets-et-coffre/).\n- Les clés d’API ne sont stockées que sous forme d’empreinte SHA-256. La clé complète ne s’affiche qu’une fois.\n- Une variable sensible ne se relit jamais après l’enregistrement, et ne part que vers le build du dépôt.\n- Le journal du coffre garde qui a créé, modifié, lu ou téléchargé une variable. Il ne garde jamais la valeur.\n\n## Sites servis\n\n- HTTPS partout, avec un certificat automatique pour chaque domaine vérifié. Un certificat n’est émis que pour un domaine vérifié.\n- Chaque réponse porte l’en-tête `X-Content-Type-Options: nosniff`.\n- Les fichiers cachés, comme `.env` ou `.git`, ne sont jamais servis, sauf `.well-known`.\n- Les configurations et les sources d’un framework ne sont jamais servies. Seul le résultat du build l’est.\n\n## Données et journaux\n\n- Les logs des requêtes ne gardent ni adresse IP, ni en-têtes, ni paramètres d’URL. Ils disparaissent après trois jours.\n- Les logs de build restent tant que le projet existe.\n- Les valeurs des variables ne figurent dans aucun journal.\n\n## Signaler une faille\n\nTu penses avoir trouvé une faille ? Écris à <support@hgdc.ch>, avec les étapes pour la reproduire. Pour rester dans le cadre de la divulgation responsable :\n\n- n’accède pas aux données d’une autre organisation, même pour démontrer la faille ;\n- ne teste pas la charge de la plateforme ;\n- ne publie pas la faille avant qu’elle soit corrigée."},{"path":"/docs/concepts/deploiements/","title":"Déploiements","description":"Preview, production, adresse de production, adresse de déploiement, statuts et retour arrière. Le cycle de vie d'une version de ton site.","version":null,"markdown":"Un déploiement est une version figée de ton site. Il ne change plus après sa publication : une nouvelle version crée un nouveau déploiement, avec sa propre adresse.\n\nCette page explique ce modèle. Pour les actions pas à pas, voir [Revenir en arrière, redéployer ou annuler](/docs/guides/revenir-en-arriere/).\n\n## Preview et production\n\nChaque déploiement est soit une **preview**, soit une **production**.\n\n| Cible      | Créée par                                               | Servie sur                                                                                  |\n| ---------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------- |\n| Preview    | `vercel deploy`, ou une branche autre que la production | Son adresse de déploiement, et les domaines de branche qui la suivent                       |\n| Production | `vercel deploy --prod`, ou la branche de production     | Son adresse de déploiement, l’adresse de production du projet et ses domaines de production |\n\nAvec l’intégration GitHub, la branche de production part en production, et toutes les autres en preview. Le dernier déploiement de production prêt est celui que servent tes domaines de production.\n\n## Adresse de production\n\nChaque projet reçoit à sa création une adresse qui suit toujours sa production, de la forme `https://<projet>.hgdc.cloud`. C’est l’équivalent de `<projet>.vercel.app`.\n\n- Elle ne change jamais : ni à une nouvelle mise en production, ni si tu renommes le projet.\n- Elle sert le déploiement de production du moment. Une nouvelle production ou un retour arrière la déplace tout de suite, sans nouveau certificat ni réglage DNS.\n- Si `<projet>` est déjà pris par une autre organisation, l’adresse devient `<projet>-<organisation>.hgdc.cloud`. La console affiche celle de ton projet dans la carte de production, sous **Domaines**.\n- Elle n’est pas indexée par les moteurs de recherche. Pour un site public, branche ton propre domaine : voir [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n\nDonne cette adresse à un outil qui doit toujours viser ta production : un proxy, une sonde de disponibilité, une console Docs. Elle est aussi la valeur de `VERCEL_PROJECT_PRODUCTION_URL` tant que le projet n’a pas de domaine.\n\n## Adresse de déploiement\n\nChaque déploiement reçoit une adresse unique, de la forme `https://<projet>-<suffixe>.hgdc.cloud`. Elle reste valable tant que le déploiement existe.\n\nPartage cette adresse pour faire valider une version avant de la passer en production. Une preview se valide ainsi, sans toucher au site en ligne.\n\n## Statuts\n\n| Statut     | Libellé dans la console | Signification                                                                |\n| ---------- | ----------------------- | ---------------------------------------------------------------------------- |\n| `QUEUED`   | En file                 | Le déploiement attend son tour de publication                                |\n| `BUILDING` | Build en cours          | Le build tourne dans la CI, ou les fichiers sont en cours de publication     |\n| `READY`    | Prêt                    | Le site est en ligne sur son adresse                                         |\n| `ERROR`    | Erreur                  | Le build ou la publication a échoué. La cause est sur la page du déploiement |\n| `CANCELED` | Annulé                  | Annulé dans la console, ou dans GitHub Actions                               |\n\nPour corriger une version en ligne, déploie une nouvelle version : elle reçoit son propre déploiement et sa propre adresse.\n\n## Vue d’ensemble du projet\n\nLa vue d’ensemble montre le déploiement de production : un aperçu du site, son adresse, l’adresse de production du projet et ses domaines, le commit et son auteur. Le projet reprend le favicon de son site.\n\nLes previews actives listent la dernière adresse de chaque branche.\n\n## Revenir en arrière\n\nRevenir en arrière remet en ligne un déploiement de production précédent, tout de suite et sans nouveau build. L’adresse de production et les domaines le servent aussitôt. Seul un déploiement **prêt** peut passer en production.\n\nLe déploiement remis en ligne garde les variables qu’il a reçues à son build. Une variable modifiée depuis ne s’y applique pas.\n\n## Redéployer\n\n- Projet relié à GitHub : reconstruit le même commit, avec les variables d’aujourd’hui.\n- Projet envoyé par la CLI : republie les fichiers du déploiement choisi, sans rien reconstruire. Pour une nouvelle version, relance `vercel deploy`.\n\n## Annuler\n\nUn déploiement **en file** ou **en cours de build** peut être annulé. Un déploiement prêt ne s’annule pas : reviens en arrière à la place.\n\n## Logs de build\n\nLa page de chaque déploiement affiche la sortie du build, en direct pendant le build avec l’intégration GitHub. Voir [Lire les logs](/docs/guides/lire-les-logs/)."},{"path":"/docs/concepts/organisations-et-roles/","title":"Organisations et rôles","description":"Une organisation regroupe des personnes, des projets et des clés d'API. Qui peut faire quoi, et où se gèrent les membres.","version":null,"markdown":"Une organisation regroupe des personnes, des projets et des clés d’API. Tu peux appartenir à plusieurs organisations, et passer de l’une à l’autre depuis la barre latérale, ou avec `Ctrl+K`.\n\nL’organisation se crée et se gère dans Account. Son slug apparaît dans l’adresse de l’app : `host.hgdc.ch/o/<slug>/…`.\n\n## Rôles\n\n| Action                                                             | Propriétaire | Admin | Membre |\n| ------------------------------------------------------------------ | ------------ | ----- | ------ |\n| Voir les projets, déploiements et logs                             | Oui          | Oui   | Oui    |\n| Voir les noms des variables                                        | Oui          | Oui   | Oui    |\n| Voir les valeurs des variables non sensibles                       | Oui          | Oui   | Oui    |\n| Créer et déployer des projets, gérer les variables et les domaines | Oui          | Oui   | Oui    |\n| Créer et révoquer des clés d’API                                   | Oui          | Oui   | Non    |\n| Supprimer un projet                                                | Oui          | Oui   | Non    |\n| Gérer l’organisation elle-même, dans Account                       | Oui          | Non   | Non    |\n\nUne valeur sensible ne s’affiche jamais, quel que soit le rôle. Voir [Secrets et coffre](/docs/concepts/secrets-et-coffre/).\n\nLe rôle lecture seule n’existe plus : les anciens membres en lecture seule sont passés membres.\n\n## Inviter et retirer\n\nLes invitations, les membres et les rôles se gèrent dans Account, pas dans Host. Le guide pas à pas est sur [Inviter une personne](/docs/guides/inviter-une-personne/).\n\nQuand une personne rejoint l’organisation, elle se connecte avec son compte HGDC, avec la même adresse e-mail vérifiée. Son compte est lié, et ses projets restent en place.\n\n## Membres dans Host\n\nHost affiche la liste des membres en lecture seule, avec un bouton vers Account. Un changement fait dans Account arrive dans Host à la prochaine connexion de la personne. Une session dure 7 jours au plus, sans prolongation.\n\n## Quitter ou être retiré\n\nQuand une personne quitte l’organisation, les clés d’API qu’elle a créées cessent de fonctionner. Les projets, les déploiements et les variables restent dans l’organisation.\n\n## Les clés d’API et l’organisation\n\nUne clé d’API appartient à une organisation. L’organisation vient toujours de la clé : une option `--scope` ou `--team` de la CLI est ignorée. Voir [Clés d’API](/docs/guides/cle-d-api/)."},{"path":"/docs/concepts/preversion/","title":"Préversion et rendu à la demande","description":"Ce qui s'exécute en préversion (rendu à la demande, routes d'API, ISR, crons), comment ça se comporte et ce qui reste en ligne.","version":null,"markdown":"Host sert toujours les fichiers statiques et les pages pré-rendues. Les fonctions, c’est-à-dire le rendu à la demande, les routes d’API, les Server Actions, le proxy, le runtime edge, l’ISR et les crons, sont en préversion. Cette page explique comment elles se comportent, et ce que tu observes.\n\n## Ce qui est en ligne dans tous les cas\n\nUn site construit avec `vercel build` produit deux sortes de contenu :\n\n- les fichiers statiques et les pages pré-rendues au build. Ils sont servis dès le déploiement, sans fonction ;\n- les pages et les routes qui ont besoin d’une fonction. Elles passent par l’exécution en préversion.\n\nUne organisation qui n’a pas encore accès à l’exécution des fonctions voit ses pages statiques en ligne normalement. Seule une adresse qui demande une fonction répond `501`, avec le message « Rendu à la demande pas encore servi ».\n\n## Ouvert organisation par organisation\n\nL’exécution des fonctions est ouverte organisation par organisation. Si une de tes adresses répond `501`, demande l’activation à <support@hgdc.ch>, avec le nom de ton organisation.\n\n## Comportement des fonctions\n\n- Chaque déploiement a son environnement d’exécution, isolé des autres, avec les variables de son environnement.\n- Une fonction dispose de 512 Mo de mémoire par défaut, et de 1 Go au plus.\n- Une requête dure 30 secondes au plus par défaut. Tu peux allonger jusqu’à 60 secondes avec `maxDuration`.\n- Après une période sans trafic, l’environnement s’arrête. La première requête suivante prend quelques secondes ; les suivantes sont immédiates.\n\n## Runtime edge\n\nUne fonction marquée `runtime: \"edge\"` tourne dans un contexte isolé, avec les API Web, comme chez Vercel.\n\n## ISR\n\nUne page avec une durée de revalidation est rendue une fois, puis gardée. Une fois la durée écoulée, elle est régénérée en arrière-plan. Le visiteur reçoit toujours une réponse immédiate.\n\nLe cache de l’ISR est tenu en mémoire par serveur. Il repart à vide quand le serveur redémarre : la page suivante est rendue à nouveau.\n\n## Crons\n\nLes `crons` de `vercel.json` appellent leur chemin en GET, à l’heure indiquée en UTC, sur le déploiement de production uniquement. Un déploiement de preview n’a jamais de cron.\n\nSi tu définis la variable `CRON_SECRET` pour la production, chaque appel porte `Authorization: Bearer <CRON_SECRET>`. Vérifie cet en-tête dans ta route avant d’agir.\n\n## Proxy et middleware\n\nLe proxy, anciennement middleware, et le middleware Node.js s’exécutent en préversion, comme les fonctions.\n\n## Pour une page qui ne peut pas attendre\n\nSi une page a besoin d’une fonction alors que l’exécution n’est pas encore ouverte à ton organisation, tu peux la pré-rendre au build. Elle est alors servie comme une page statique.\n\n## Voir aussi\n\n- [Compatibilité](/docs/reference/compatibilite/) : la liste complète, fonction par fonction.\n- [Limites](/docs/reference/limites/) : mémoire, durée et débits."},{"path":"/docs/concepts/secrets-et-coffre/","title":"Secrets et coffre","description":"Comment Host protège les valeurs de tes variables et tes clés d'API, qui peut les lire et ce qui reste dans le journal.","version":null,"markdown":"Les valeurs de tes variables sont des secrets : mots de passe, clés de service, jetons. Host les garde dans un coffre, les chiffre, et ne les renvoie jamais en clair à quiconque n’en a pas besoin.\n\nCette page explique le modèle. Pour les règles chiffrées, voir [Variables : référence](/docs/reference/variables/).\n\n## Le coffre\n\n- Chaque organisation a sa propre clé de chiffrement, AES-GCM 256 bits.\n- Cette clé est elle-même chiffrée par une clé maîtresse, gardée hors de la base de données.\n- Chaque valeur est liée à son projet. Une valeur recopiée dans un autre projet ne se déchiffre pas.\n\n## Qui lit quoi\n\n| Donnée                             | Qui la voit                                                          |\n| ---------------------------------- | -------------------------------------------------------------------- |\n| Nom d’une variable                 | Tous les membres de l’organisation                                   |\n| Valeur d’une variable non sensible | Tous les membres de l’organisation                                   |\n| Valeur d’une variable sensible     | Personne, après l’enregistrement. Elle peut seulement être remplacée |\n\nUne variable sensible ne part que vers le build du dépôt GitHub, par une clé limitée au projet. Un `vercel pull` depuis un poste de développement ne la télécharge pas.\n\n## Le journal du coffre\n\nLe journal, en bas de l’onglet **Variables d’environnement**, garde les 50 derniers gestes sur le coffre :\n\n- qui a créé, modifié ou supprimé une variable ;\n- qui a affiché une valeur non sensible ;\n- quelle clé d’API a téléchargé les variables, avec `vercel pull` ou un build ;\n- quand Doppler a synchronisé une valeur.\n\nLe journal ne garde jamais une valeur.\n\n## Les clés d’API\n\nHost ne garde qu’une empreinte SHA-256 de chaque clé d’API. La clé complète ne s’affiche qu’une fois, à sa création. Si tu la perds, aucune copie n’est possible : crée une nouvelle clé, puis révoque l’ancienne.\n\nUne clé posée dans un dépôt GitHub ne donne accès qu’à son projet. Une clé d’organisation donne accès à tous les projets de l’organisation, avec les variables non sensibles.\n\n## Les secrets des intégrations\n\nLes jetons Doppler et les secrets des webhooks sont chiffrés de la même façon, et ne sont jamais renvoyés par la console ni par l’API. Chaque webhook Doppler est vérifié par sa signature HMAC.\n\n## Ce que le site publie\n\nLe coffre protège les valeurs dans Host. Il ne protège pas un secret qui finit dans le site. Tout ce que le build écrit dans les fichiers du site est public, même si la variable d’origine était sensible.\n\nUne variable lue dans le navigateur, comme celles qui commencent par `PUBLIC_`, `VITE_` ou `NEXT_PUBLIC_`, ne doit jamais contenir un secret.\n\n## Voir aussi\n\n- [Gérer les variables d’environnement](/docs/guides/variables-d-environnement/)\n- [Synchroniser depuis Doppler](/docs/guides/synchroniser-doppler/)\n- [Confidentialité](/docs/concepts/confidentialite/)"},{"path":"/docs/demarrer/depuis-github/","title":"Déployer un site depuis GitHub","description":"Importe un dépôt GitHub. La branche principale part en production, les autres reçoivent une preview.","version":null,"markdown":"Dans ce parcours, tu importes un dépôt GitHub dans Host. À la fin, un `git push` sur la branche principale met ton site en production, et chaque autre branche reçoit sa propre preview.\n\n**Avant de commencer** :\n\n- un compte HGDC et une organisation dans Account ;\n- un dépôt GitHub avec un site qui se construit (Astro, Vite, Next.js ou un site statique) ;\n- le droit d’écriture (push) sur ce dépôt. Un dépôt où tu n’as que la lecture ne s’importe pas.\n\n1. **Ouvre un nouveau projet**\n\n   Dans ton organisation, clique **Nouveau projet**, puis **Importer depuis GitHub**.\n\n   **Vérification** : la liste des dépôts accessibles s’affiche, ou Host te propose d’installer l’app GitHub.\n\n2. **Installe l'app GitHub**\n\n   Installe l’app **Host** sur ton compte GitHub ou sur celui de ton organisation. Tu peux la limiter à quelques dépôts.\n\n   L’app ne demande que les droits dont le workflow a besoin. Le détail est dans [Déployer depuis GitHub](/docs/guides/deployer-depuis-github/).\n\n   **Vérification** : le dépôt choisi apparaît dans la liste de Host.\n\n3. **Choisis le dépôt et vérifie les réglages**\n\n   Sélectionne le dépôt. Host lit le projet et propose le framework, les commandes d’installation et de build, la version de Node.js et la branche de production.\n\n   Si le site est dans un sous-dossier ou dans un monorepo, choisis le dossier de l’app. Voir [Monorepo et sous-dossier](/docs/guides/monorepo/).\n\n   **Vérification** : le framework détecté correspond à ton site. Corrige les réglages qui ne correspondent pas.\n\n4. **Fusionne la PR d'installation**\n\n   L’import ouvre une pull request qui ajoute le fichier `.github/workflows/hgdc-host.yml` et pose le secret `HGDC_HOST_TOKEN` dans le dépôt. Relis-la, puis fusionne-la sur la branche principale.\n\n   Le secret est une clé limitée à ce projet. Elle ne peut ni créer de projet ni lire les autres.\n\n   **Vérification** : la PR est fusionnée, et le fichier `hgdc-host.yml` existe sur la branche principale.\n\n5. **Pousse une modification**\n\n   Modifie une page du site, puis pousse-la sur la branche principale :\n\n   ```bash\n   git add .\n   git commit -m \"docs: ajoute une page de test\"\n   git push\n   ```\n\n   **Vérification** : l’onglet **Déploiements** du projet affiche un déploiement en cours, puis **Prêt**. L’adresse de production affiche la modification.\n\n6. **Ouvre une preview**\n\n   Crée une branche, pousse-la, puis ouvre une pull request sur la branche principale. Host construit la branche et publie une preview.\n\n   **Vérification** : le commit affiche le statut du déploiement avec son lien. La preview répond sur son adresse `hgdc.cloud`.\n\n## Et après\n\n- Pour mettre le site sur ton domaine, suis [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n- Pour les variables de build, comme une clé publique ou l’adresse d’une API, suis [Variables d’environnement](/docs/guides/variables-d-environnement/).\n- Pour comprendre ce qui se passe à chaque push, lis [Déploiements](/docs/concepts/deploiements/).\n\n## Si ça ne marche pas\n\n- Le build n’apparaît pas après le push : vérifie que la PR d’installation est fusionnée. Voir [Dépannage](/docs/guides/depannage/#le-build-github-est-absent).\n- Le build échoue : ouvre le déploiement dans Host, la sortie du build y est affichée en direct."},{"path":"/docs/demarrer/premier-site/","title":"Mettre un premier site en ligne","description":"Du compte à une preview, puis à la production, avec la CLI Vercel, en une quinzaine de minutes.","version":null,"markdown":"À la fin de ce parcours, ton site répond sur une adresse de preview, puis sur une adresse de production. Tu auras créé une clé d’API, installé la CLI et déployé un dossier de fichiers, sans étape de build.\n\n**Avant de commencer** : Node.js et npm, et un compte HGDC. Sans compte, la page [Demander un accès](https://host.hgdc.ch/acces) envoie ta demande à l’équipe, qui t’invite depuis Account.\n\n1. **Connecte-toi**\n\n   Ouvre [host.hgdc.ch](https://host.hgdc.ch) et clique **Se connecter avec HGDC**. Le même compte sert à Account, Mail et les autres produits de la famille.\n\n   Tu arrives sur le tableau de bord. Si tu n’as pas encore d’organisation, crée-la dans Account. Son slug apparaît dans l’adresse de l’app : `host.hgdc.ch/o/<slug>`.\n\n   **Vérification** : le tableau de bord affiche le nom de ton organisation.\n\n2. **Crée une clé d'API**\n\n   Dans ton organisation, ouvre l’onglet **Clés d’API** et crée une clé. Elle commence par `ah_` et ne s’affiche qu’une fois : copie-la tout de suite.\n\n   La clé remplace le mot de passe de la CLI. Le détail est dans [Clés d’API](/docs/guides/cle-d-api/).\n\n   **Vérification** : la clé apparaît dans la liste, avec le nom que tu lui as donné.\n\n3. **Installe la CLI Vercel**\n\n   ```bash\n   npm install --global vercel@63\n   ```\n\n   Host est testé avec la version 63 de la CLI. Une autre version peut fonctionner, mais ce n’est pas garanti.\n\n   **Vérification** : `vercel --version` affiche une version 63.x.\n\n4. **Donne la clé et l'adresse de l'API à la CLI**\n\n   Dans le terminal, exporte la clé, puis passe l’adresse de l’API à chaque commande avec `--api`. La CLI lit la clé dans `VERCEL_TOKEN`.\n\n   ```bash\n   export VERCEL_TOKEN=ah_…\n   vercel --api https://api.host.hgdc.ch whoami\n   ```\n\n   **Vérification** : la commande affiche ton identifiant, sans demander de connexion dans le navigateur. Pour ne pas retaper l’adresse, voir [Configurer la CLI](/docs/reference/cli/#configurer-la-cli).\n\n5. **Prépare un site**\n\n   Crée un dossier `mon-site` avec un fichier `index.html` à sa racine :\n\n   ```html\n   <!doctype html>\n   <html lang=\"fr\">\n     <head>\n       <meta charset=\"utf-8\" />\n       <title>Mon premier site</title>\n     </head>\n     <body>\n       <h1>Bonjour depuis Host</h1>\n     </body>\n   </html>\n   ```\n\n   **Vérification** : `index.html` se trouve directement dans `mon-site`, pas dans un sous-dossier.\n\n6. **Déploie une preview**\n\n   Depuis le dossier du site :\n\n   ```bash\n   cd mon-site\n   vercel --api https://api.host.hgdc.ch deploy\n   ```\n\n   Au premier envoi, la CLI crée le projet sous le nom du dossier et le relie au dossier dans `.vercel/project.json`. Elle affiche ensuite l’adresse du déploiement, de la forme `https://mon-site-abc123xyz.hgdc.cloud`.\n\n   **Vérification** : ouvre l’adresse affichée. La page « Bonjour depuis Host » s’affiche. Le déploiement apparaît aussi dans l’onglet **Déploiements** du projet, avec l’état **Prêt**.\n\n7. **Passe en production**\n\n   ```bash\n   vercel --api https://api.host.hgdc.ch deploy --prod\n   ```\n\n   Le déploiement devient la production du projet. La CLI affiche l’adresse de production du projet, `https://mon-site.hgdc.cloud`, qui suivra chaque mise en production. Les domaines de production du projet le servent aussi.\n\n   **Vérification** : l’onglet **Vue d’ensemble** du projet montre ce déploiement comme production.\n\n## Et après\n\n- Pour mettre le site sur ton propre domaine, suis [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n- Pour déployer à chaque `git push`, suis [Déployer depuis GitHub](/docs/demarrer/depuis-github/).\n\n## Si ça ne marche pas\n\n- La CLI répond `403` : la clé est mal copiée, ou elle ne commence pas par `ah_`. Voir [Dépannage](/docs/guides/depannage/#la-cli-renvoie-403).\n- La page affiche `404` : le dossier envoyé n’a pas d’`index.html` à sa racine."},{"path":"/docs/guides/brancher-un-domaine/","title":"Brancher un domaine","description":"Sers ton site sur ton propre domaine, avec HTTPS automatique, en quelques minutes de configuration DNS.","version":null,"markdown":"Ce guide sert ton site sur `www.exemple.ch` ou `exemple.ch`. Host vérifie que le domaine est à toi, attend que le trafic arrive, puis obtient le certificat HTTPS.\n\n**Résultat attendu** : le domaine affiche le statut **Vérifié** et le certificat HTTPS, et ton site répond sur ce domaine.\n\n**Avant de commencer** :\n\n- un projet déployé en production ;\n- l’accès à la zone DNS du domaine chez ton hébergeur. Le DNS d’Infomaniak, de Cloudflare ou d’un autre hébergeur fonctionne de la même façon.\n\n1. **Ajoute le domaine au projet**\n\n   Dans le projet, ouvre l’onglet **Domaines** et clique **Ajouter un domaine**. Saisis le nom, par exemple `www.exemple.ch` ou `exemple.ch`.\n\n   Choisis ce que le domaine sert, dans **Mise en ligne du domaine** :\n\n   - la production, pour le site principal ;\n   - une branche, par exemple `staging.exemple.ch` pour la branche `staging` ;\n   - une redirection vers un autre domaine du même projet.\n\n   Pour un domaine racine, la case **Ajouter aussi [www](http://www).** crée `www` en redirection permanente vers le domaine racine.\n\n   **Vérification** : le domaine apparaît dans la liste avec le statut **En attente des DNS**.\n\n2. **Prouve que le domaine est à toi**\n\n   Chez ton hébergeur DNS, crée un enregistrement **TXT** avec le nom et la valeur affichés sous **Prouver que le domaine est à toi (TXT)**.\n\n   Le nom commence toujours par `_agenthost.`, suivi du domaine. Certains hébergeurs ajoutent le domaine tout seul : saisis alors seulement la partie avant le domaine, par exemple `_agenthost.www`.\n\n3. **Dirige le trafic vers Host**\n\n   Sous **Diriger le trafic vers Host**, crée l’enregistrement indiqué :\n\n   | Domaine                                    | Type      | Nom   | Valeur                                  |\n   | ------------------------------------------ | --------- | ----- | --------------------------------------- |\n   | Sous-domaine, par exemple `www.exemple.ch` | **CNAME** | `www` | La cible affichée dans la console       |\n   | Domaine racine, `exemple.ch`               | **A**     | `@`   | L’adresse IPv4 affichée dans la console |\n\n   Un CNAME ne peut pas être posé sur la racine d’un domaine. Pour un domaine racine, utilise donc le A.\n\n   > **Attention**\n   >\n   > Supprime les anciens enregistrements A, AAAA ou CNAME qui pointent vers un autre hébergeur sur le même nom. Un enregistrement qui reste peut masquer le nouveau.\n\n4. **Attends la vérification**\n\n   Host revérifie le domaine toutes les 15 minutes tant qu’il n’est pas vérifié. Clique **Vérifier** pour lancer la vérification tout de suite.\n\n   Chaque étape s’affiche : la preuve TXT, le trafic, puis le certificat.\n\n   **Vérification** : le statut passe à **Vérifié**, puis le certificat HTTPS apparaît avec sa date d’échéance.\n\nOuvre le domaine dans un navigateur : ton site répond en HTTPS.\n\n## Ce que tu n’as pas à faire\n\n- Téléverser un certificat. Host le demande dès que le domaine est vérifié, et le renouvelle seul.\n- Redéployer. Un domaine de production sert le dernier déploiement de production prêt.\n\n## Statuts d’un domaine\n\n| Statut                      | Signification                                                                       |\n| --------------------------- | ----------------------------------------------------------------------------------- |\n| **En attente des DNS**      | La preuve TXT ou le trafic manque encore. Le domaine n’est pas servi.               |\n| **Vérifié**                 | La preuve est là et le trafic arrive. Le domaine est servi.                         |\n| **Ne pointe pas vers nous** | La preuve TXT est là, mais le trafic n’arrive pas à Host. Corrige le CNAME ou le A. |\n\nUn domaine vérifié est revérifié chaque jour. Si la preuve TXT disparaît, une seconde vérification a lieu une heure plus tard. Si elle échoue aussi, le domaine repasse en attente et n’est plus servi. Garde donc le TXT en place.\n\n## Si ça ne marche pas\n\n- Le domaine reste **En attente des DNS** : vérifie le nom du TXT, qui doit commencer par `_agenthost.`. Un ancien enregistrement peut aussi retarder la propagation. Voir [Dépannage](/docs/guides/depannage/#mon-domaine-reste-en-attente).\n- Host refuse le nom avec « Ce domaine appartient à la plateforme » : les domaines de Host et ceux de la plateforme de déploiement ne peuvent pas être utilisés comme domaine client.\n- Le certificat n’est pas encore émis : attends que le statut soit **Vérifié**, puis patiente quelques minutes. Si l’erreur « Le certificat HTTPS n’a pas encore pu être émis » persiste, écris à <support@hgdc.ch>.\n\n## Voir aussi\n\n- [Domaines : référence](/docs/reference/domaines/) : les enregistrements, les codes de redirection et les limites.\n- [Migrer depuis Vercel](/docs/guides/migrer-depuis-vercel/) : changer le DNS sans coupure."},{"path":"/docs/guides/cle-d-api/","title":"Créer et révoquer une clé d'API","description":"Crée une clé pour la CLI ou ton intégration, choisis sa portée et révoque-la quand elle ne sert plus.","version":null,"markdown":"Une clé d’API authentifie la CLI et l’API. Ce guide crée une clé, la range au bon endroit, puis la révoque.\n\n**Résultat attendu** : une clé qui commence par `ah_`, visible dans la liste **Clés actives** de ton organisation, et révocable depuis la liste.\n\n**Avant de commencer** : être admin ou propriétaire de l’organisation. Les membres ne voient pas l’onglet **Clés d’API**.\n\n## Créer une clé\n\n1. **Ouvre l'onglet Clés d'API**\n\n   Dans ton organisation, ouvre **Clés d’API**, puis clique **Créer une clé**.\n\n2. **Donne-lui un nom parlant**\n\n   Choisis un nom qui dit où la clé sert, par exemple `Poste de Léa` ou `CI GitHub`. Il t’aidera à savoir quelle clé révoquer.\n\n3. **Copie la clé tout de suite**\n\n   La fenêtre **Nouvelle clé d’API** affiche la clé complète une seule fois. Clique **Copier la clé** et range-la dans un gestionnaire de mots de passe.\n\n   Host ne garde qu’une empreinte de la clé. Si tu la perds, aucune copie n’est possible : crée une nouvelle clé et révoque l’ancienne.\n\n   **Vérification** : la clé apparaît dans **Clés actives** avec son nom et la date de création.\n\n## Choisir la bonne portée\n\n| Sorte de clé       | Qui la crée                                  | Ce qu’elle peut faire                                            |\n| ------------------ | -------------------------------------------- | ---------------------------------------------------------------- |\n| Clé d’organisation | Un admin ou un propriétaire, dans la console | Tous les projets de l’organisation, et créer de nouveaux projets |\n| Clé de projet      | L’app GitHub, à l’import d’un dépôt          | Un seul projet. Tout autre projet répond `404`                   |\n\nPour ton poste de développement, prends une clé d’organisation. Pour un dépôt, laisse l’app GitHub poser sa clé de projet.\n\n> **Attention**\n>\n> Une clé d’organisation lit les variables non sensibles de tous les projets avec `vercel pull`. Ne la mets jamais dans un dépôt, ni dans du code envoyé au navigateur.\n\n## Utiliser la clé\n\nLa CLI lit la clé dans la variable `VERCEL_TOKEN`, qui évite de l’écrire dans l’historique du shell :\n\n```bash\nexport VERCEL_TOKEN=ah_…\nvercel --api https://api.host.hgdc.ch deploy\n```\n\nPour une requête HTTP, envoie-la dans l’en-tête `Authorization` :\n\n```bash\ncurl https://api.host.hgdc.ch/v2/user \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\n## Révoquer une clé\n\n1. **Repère la clé**\n\n   Dans **Clés actives**, regarde la date de **Dernière utilisation**. Une clé inutilisée depuis longtemps peut être révoquée sans risque.\n\n2. **Révoque-la**\n\n   Clique **Révoquer la clé**, puis confirme.\n\n   **Vérification** : la clé disparaît de **Clés actives**. Une requête avec cette clé répond `403` avec le code `forbidden`.\n\nUne clé cesse aussi de fonctionner quand la personne qui l’a créée quitte l’organisation dans Account. Une clé n’expire pas d’elle-même.\n\n## Si ça ne marche pas\n\n- La CLI répond `403`, avec le message « Clé d’API absente ou invalide » : la clé est mal copiée, ou elle a été révoquée. Voir [Dépannage](/docs/guides/depannage/#la-cli-renvoie-403).\n- Le message « Cette clé est limitée à un autre projet » apparaît : tu utilises la clé d’un dépôt pour un autre projet. Crée une clé d’organisation.\n\n## Voir aussi\n\n- [Clés d’API et sécurité](/docs/concepts/secrets-et-coffre/) : ce que Host garde et ce qu’il ne garde pas.\n- [Référence de l’API](/docs/reference/api/introduction/#authentification) : l’en-tête, la portée et les limites."},{"path":"/docs/guides/depannage/","title":"Dépannage","description":"Les problèmes les plus fréquents avec la CLI, GitHub, les déploiements et les domaines, et comment les résoudre.","version":null,"markdown":"Ce guide liste les problèmes fréquents, classés par symptôme. Chaque section donne les causes probables, dans l’ordre où les vérifier.\n\nSi rien ne correspond, écris à <support@hgdc.ch> avec l’adresse du déploiement concerné.\n\n## La CLI renvoie 403\n\nLa clé est absente, mal copiée, révoquée, ou elle appartient à une organisation qui n’existe plus.\n\n- Vérifie qu’elle commence par `ah_` et qu’elle est passée par `VERCEL_TOKEN` ou `--token`.\n- Vérifie qu’elle n’a pas été révoquée dans **Clés actives**. Une clé cesse aussi de fonctionner quand la personne qui l’a créée quitte l’organisation.\n- Vérifie que `--api https://api.host.hgdc.ch` est présent. Sans lui, la CLI parle à Vercel, pas à Host.\n\nLe message « Cette clé est limitée à un autre projet » signifie que tu utilises la clé posée dans un dépôt pour un autre projet. Crée une clé d’organisation, voir [Créer et révoquer une clé d’API](/docs/guides/cle-d-api/).\n\n## La CLI affiche missing_files\n\nC’est normal : Host demande les fichiers qu’il n’a pas encore, la CLI les envoie puis rappelle l’API. Si l’erreur persiste, un fichier n’a pas pu partir : il dépasse 20 Mo, ou le réseau a coupé. Relance le déploiement.\n\n## vercel login ne fonctionne pas\n\nC’est voulu : la connexion passe toujours par une clé d’API. Exporte la clé dans `VERCEL_TOKEN`, puis lance la commande avec `--api`, voir [Configurer la CLI](/docs/reference/cli/#configurer-la-cli).\n\n## Le build GitHub est absent\n\nUn push ne déclenche aucun build dans Host.\n\n- La pull request d’installation est-elle fusionnée sur la branche poussée ? Le fichier `.github/workflows/hgdc-host.yml` doit exister sur cette branche.\n- Ouvre l’onglet **Actions** du dépôt : le run y apparaît, avec son erreur.\n- Le secret `HGDC_HOST_TOKEN` manque ou a été supprimé. Débranche le dépôt, puis relie-le pour poser un nouveau secret.\n- Le projet a été importé avant une évolution du workflow. Utilise **Mettre à jour le workflow** dans l’onglet **Git**.\n\n## Mon site affiche 404\n\n- Le dossier envoyé n’a pas d’`index.html` à sa racine, ou le dossier de sortie configuré est faux. Voir [Déployer un site statique](/docs/guides/site-statique/).\n- La page est rendue à la demande, et l’exécution des fonctions n’est pas encore ouverte à ton organisation : la page répond alors `501`. Pré-rends-la, ou consulte [Préversion](/docs/concepts/preversion/).\n- Sans `cleanUrls`, `/a-propos` ne trouve pas `a-propos.html`. Ajoute `\"cleanUrls\": true` à `vercel.json`.\n- La page de déploiement liste les fichiers et les fonctions ignorés à la publication, avec un avertissement. Vérifie-la.\n\n## Mon domaine reste en attente\n\n- Vérifie le nom du TXT : `_agenthost.` suivi de ton domaine, pas `_agenthost` seul. Certains hébergeurs ajoutent le domaine tout seul : saisis alors seulement `_agenthost.www` pour `www.exemple.ch`.\n- Pour un domaine racine, il faut un enregistrement A, pas un CNAME.\n- Un ancien enregistrement A ou AAAA vers un autre hébergeur peut masquer le nouveau : supprime-le.\n- La propagation peut prendre quelques heures. Clique **Vérifier**, ou attends la vérification automatique, toutes les 15 minutes.\n\nTu peux contrôler les enregistrements depuis un terminal :\n\n```bash\ndig +short TXT _agenthost.www.exemple.ch\ndig +short CNAME www.exemple.ch\n```\n\nVoir [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n\n## Ma variable sensible n’apparaît pas dans vercel pull\n\nC’est voulu : une variable sensible ne part que vers le build du dépôt, par la clé limitée au projet. Depuis ton poste, utilise une valeur de développement, dans une variable non sensible visant l’environnement Développement. Voir [Variables d’environnement](/docs/guides/variables-d-environnement/).\n\n## Une fonction répond 501\n\nLe rendu à la demande, les routes d’API et les Server Actions sont en préversion. L’exécution est ouverte organisation par organisation. Les pages statiques et pré-rendues de ton site restent en ligne. Voir [Préversion](/docs/concepts/preversion/).\n\n## Le build échoue\n\n- Ouvre le déploiement : la sortie du build est affichée, avec la première erreur. Voir [Lire les logs](/docs/guides/lire-les-logs/).\n- Reproduis le build sur ton poste avec `vercel build`, puis vérifie que la version de Node.js du projet correspond à celle de ton poste.\n- Une variable manque au build : ajoute-la à l’environnement visé, voir [Variables d’environnement](/docs/guides/variables-d-environnement/)."},{"path":"/docs/guides/deployer-depuis-github/","title":"Déployer depuis GitHub","description":"Importe un dépôt, suis chaque build dans Host et mets le workflow à jour quand Host le fait évoluer.","version":null,"markdown":"L’intégration GitHub construit ton site dans GitHub Actions, sur les minutes de ton compte, et publie le résultat. Chaque push sur la branche principale part en production. Chaque autre branche reçoit une preview.\n\n**Résultat attendu** : un push déclenche un build visible dans Host, avec sa sortie en direct, puis un déploiement **Prêt**.\n\n**Avant de commencer** : un dépôt où tu as le droit d’écriture, et un site qui se construit avec une commande de build.\n\n## Importer un dépôt\n\n1. **Installe l'app GitHub**\n\n   Dans **Nouveau projet**, choisis **Importer depuis GitHub** et installe l’app **Host** sur ton compte GitHub ou sur celui de ton organisation. Tu peux la restreindre à certains dépôts.\n\n   Host s’en sert pour lire la liste des dépôts, ouvrir la pull request d’installation et déclencher les builds.\n\n2. **Choisis le dépôt**\n\n   Seuls les dépôts où tu peux pousser apparaissent. Un dépôt où tu n’as que la lecture ne s’importe pas : l’import ouvre une pull request et pose un secret dans le dépôt.\n\n3. **Vérifie les réglages détectés**\n\n   Host propose le framework, les commandes d’installation et de build, la version de Node.js et la branche de production. Corrige ce qui ne correspond pas avant de continuer.\n\n   Pour un site dans un sous-dossier, voir [Monorepo et sous-dossier](/docs/guides/monorepo/).\n\n4. **Fusionne la pull request**\n\n   L’import ouvre une pull request qui ajoute `.github/workflows/hgdc-host.yml` et pose le secret `HGDC_HOST_TOKEN`.\n\n   **Vérification** : une fois la PR fusionnée, un push sur la branche principale déclenche un build.\n\n## Ce que fait le workflow\n\n1. Il annonce le build à Host. Le déploiement apparaît dans la console dès le début, avec sa sortie en direct.\n2. Il restaure le cache du run précédent : `node_modules` tant que ton fichier de verrouillage ne change pas, le cache de ton framework et la CLI Vercel.\n3. Il lance `vercel pull` pour récupérer les réglages et les variables, puis `vercel build`.\n4. Il envoie le résultat avec `vercel deploy --prebuilt`, avec `--prod` sur la branche de production.\n5. En cas d’échec ou d’annulation, il le signale. Le déploiement passe à **Erreur** ou **Annulé**.\n\nDeux pushes sur la même branche : le premier build est annulé au profit du second. Le premier build d’une branche remplit le cache, les suivants vont plus vite.\n\nPour repartir d’un cache propre, supprime les caches `hgdc-host-*` dans l’onglet **Actions** du dépôt.\n\n## Déployer sans pousser\n\nDans Host, deux actions relancent un build sans nouveau commit :\n\n- **Déployer en production** lance le workflow sur la branche de production.\n- **Redéployer**, sur un déploiement, reconstruit le même commit avec les variables d’aujourd’hui.\n\nLe build passe par GitHub Actions, comme pour un push.\n\n## Mettre le workflow à jour\n\nQuand Host fait évoluer son workflow, l’onglet **Git** du projet propose **Mettre à jour le workflow**. Host ouvre une pull request qui remplace le fichier. Fusionne-la, puis déploie.\n\n## Débrancher le dépôt\n\nDans l’onglet **Git**, **Débrancher** révoque la clé posée dans le dépôt. Les pushes suivants n’arrivent plus à Host. Supprime ensuite le fichier `.github/workflows/hgdc-host.yml` du dépôt. Les dépôts branchés avant le changement de nom gardent `.github/workflows/smartflow-host.yml` et le secret `SMARTFLOW_HOST_TOKEN` : ils continuent de fonctionner, sans rien changer de ton côté.\n\nLes variables du projet restent en place, devenues manuelles. Aucun build ne les perd d’un coup.\n\n> **Astuce**\n>\n> Tu préfères écrire ton propre workflow ? Voir [GitHub Actions sans l’application](/docs/guides/github-actions-sans-application/).\n\n## Si ça ne marche pas\n\nVoir [Dépannage](/docs/guides/depannage/#le-build-github-est-absent) pour le build qui n’apparaît pas, et la sortie du run dans l’onglet **Actions** du dépôt pour le build qui échoue."},{"path":"/docs/guides/deployer-un-framework/","title":"Déployer un framework","description":"Construis ton site avec vercel build, puis envoie le résultat. Astro, Vite, Next.js, SvelteKit, Nuxt et les autres.","version":null,"markdown":"Host sert ce que `vercel build` produit : les fichiers statiques, les pages pré-rendues et, en préversion, les fonctions Node. Tu construis en local ou en CI, puis tu envoies le résultat. Les sources de ton projet ne sont jamais servies.\n\n**Résultat attendu** : un déploiement **Prêt** dont la page affiche ton site construit.\n\n**Avant de commencer** : une commande de build qui fonctionne sur ton poste, et une clé d’API dans `VERCEL_TOKEN`. Pour la liste des frameworks et de ce qui est servi pour chacun, voir [Compatibilité](/docs/reference/compatibilite/).\n\n## Construire puis envoyer\n\n1. **Construis le projet**\n\n   Depuis le dossier du projet :\n\n   ```bash\n   export VERCEL_TOKEN=ah_…\n   vercel --api https://api.host.hgdc.ch build\n   ```\n\n   La commande détecte le framework, installe les dépendances, lance le build, et écrit le résultat dans `.vercel/output`. Elle télécharge aussi les variables de l’environnement visé. Voir [vercel build](/docs/reference/cli/#vercel-build).\n\n   **Vérification** : le dossier `.vercel/output/static` contient les fichiers de ton site.\n\n2. **Envoie le résultat**\n\n   ```bash\n   vercel --api https://api.host.hgdc.ch deploy --prebuilt\n   ```\n\n   L’option `--prebuilt` envoie `.vercel/output` tel quel, sans reconstruire.\n\n   **Vérification** : l’adresse du déploiement répond avec ton site, et le déploiement passe à **Prêt**.\n\n3. **Passe en production**\n\n   Utilise la même cible des deux côtés. Pour la production :\n\n   ```bash\n   vercel --api https://api.host.hgdc.ch build --prod\n   vercel --api https://api.host.hgdc.ch deploy --prebuilt --prod\n   ```\n\n   > **Attention**\n   >\n   > La CLI refuse l’envoi si la cible du build et celle du déploiement ne correspondent pas. Une preview se construit sans `--prod`, et se déploie sans `--prod`.\n\n## Ce qui est servi, par framework\n\n| Framework                  | Servi tel quel                           | Préversion                                                                |\n| -------------------------- | ---------------------------------------- | ------------------------------------------------------------------------- |\n| Astro                      | Les pages générées                       | Rendu à la demande, routes d’API, middleware, ISR                         |\n| Vite (React, Vue, Svelte…) | Le build de l’application                |                                                                           |\n| SvelteKit                  | Les pages pré-rendues                    | Rendu à la demande, routes d’API, actions de formulaire, ISR              |\n| Nuxt                       | Les pages générées                       | Rendu à la demande, routes d’API, middleware serveur, ISR                 |\n| TanStack Start             | Les pages pré-rendues                    |                                                                           |\n| React Router               | Les pages pré-rendues                    |                                                                           |\n| Next.js                    | Les pages pré-rendues et leur navigation | Rendu à la demande, routes d’API, Server Actions, proxy, ISR, routes edge |\n\nLe tableau complet, avec les fonctions de la plateforme, est dans [Compatibilité](/docs/reference/compatibilite/).\n\n## Next.js\n\n- `next/image` sert l’image d’origine, sans redimensionnement. Optimise tes images avant le build.\n- La page `not-found` sert de 404.\n- Une page rendue à la demande, une route d’API ou une Server Action tourne dans une fonction. Elle demande la préversion, voir [Préversion](/docs/concepts/preversion/).\n\n## Un site de documentation\n\nUn dossier avec un `docs.json` et le paquet `@hgdc/docs` dans son `package.json` est reconnu comme une documentation, sans `vercel.json`. Le build lance `hgdc-docs build` et publie le dossier `dist`. Les pages `.md` sont servies en `text/markdown`.\n\n## Si ça ne marche pas\n\n- Le déploiement répond `404` : la sortie de build ne contient pas de `index.html` à la racine, ou le dossier de sortie est faux. Voir [Dépannage](/docs/guides/depannage/#mon-site-affiche-404).\n- Une page répond `501` : le rendu à la demande n’est pas encore ouvert à ton organisation. Pré-rends la page, ou consulte [Préversion](/docs/concepts/preversion/)."},{"path":"/docs/guides/github-actions-sans-application/","title":"Déployer avec GitHub Actions, sans l'application","description":"Écris ton propre workflow avec la CLI Vercel, sans passer par l'app GitHub de Host.","version":null,"markdown":"Tu préfères garder la main sur ton workflow, ou tu utilises une autre CI ? L’app GitHub n’est pas nécessaire : la CLI suffit. Ce guide met en place un workflow qui construit et déploie à chaque push.\n\n**Résultat attendu** : un push sur la branche principale publie en production, et un push sur une autre branche publie une preview.\n\n**Ce que tu perds par rapport à l’app** : le déploiement n’apparaît dans Host qu’à l’envoi, sans sortie de build en direct, et le statut du commit n’est pas mis à jour.\n\n## Relier le dossier au projet\n\n1. **Lance un premier déploiement en local**\n\n   Depuis le dossier du projet, avec ta clé d’organisation :\n\n   ```bash\n   export VERCEL_TOKEN=ah_…\n   vercel --api https://api.host.hgdc.ch deploy --yes\n   ```\n\n   La commande crée `.vercel/project.json`, qui contient `orgId` et `projectId`.\n\n   **Vérification** : le fichier `.vercel/project.json` existe, et le projet apparaît dans Host.\n\n2. **Ajoute les secrets au dépôt**\n\n   Dans le dépôt GitHub, ouvre **Settings → Secrets and variables → Actions** et crée trois secrets :\n\n   | Secret              | Valeur                                          |\n   | ------------------- | ----------------------------------------------- |\n   | `VERCEL_TOKEN`      | Une clé d’API `ah_…` d’organisation             |\n   | `VERCEL_ORG_ID`     | La valeur `orgId` de `.vercel/project.json`     |\n   | `VERCEL_PROJECT_ID` | La valeur `projectId` de `.vercel/project.json` |\n\n   Ne mets ni la clé ni les identifiants dans le fichier de workflow.\n\n3. **Ajoute le workflow**\n\n   Crée `.github/workflows/deploy.yml` :\n\n   ```yaml\n   name: Déploiement\n\n   on:\n     push:\n       branches: [main]\n     pull_request:\n\n   permissions:\n     contents: read\n\n   env:\n     VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}\n     VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}\n     VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}\n     API: https://api.host.hgdc.ch\n\n   jobs:\n     deploy:\n       runs-on: ubuntu-latest\n       steps:\n         - uses: actions/checkout@v7\n         - uses: actions/setup-node@v7\n           with:\n             node-version: 24\n         - run: npm install --global vercel@63\n         - name: Production\n           if: github.ref == 'refs/heads/main'\n           run: |\n             vercel pull --yes --environment=production --api \"$API\"\n             vercel build --prod --api \"$API\"\n             vercel deploy --prebuilt --prod --api \"$API\"\n         - name: Preview\n           if: github.ref != 'refs/heads/main'\n           run: |\n             vercel pull --yes --environment=preview --api \"$API\"\n             vercel build --api \"$API\"\n             vercel deploy --prebuilt --api \"$API\"\n   ```\n\n   La CLI lit `VERCEL_TOKEN`, `VERCEL_ORG_ID` et `VERCEL_PROJECT_ID` dans l’environnement. Le projet n’a pas besoin d’un dossier `.vercel` dans le dépôt.\n\n   Adapte `node-version` à la version de Node.js de ton projet. Pour un site qui n’a pas de build, supprime les étapes `vercel build`.\n\n   **Vérification** : le run **Déploiement** apparaît dans l’onglet **Actions**, et son job se termine en vert. Le déploiement apparaît dans le projet Host.\n\n## Variables sensibles\n\nUne variable sensible n’est livrée qu’à une clé limitée au projet, celle que pose l’app GitHub. Avec une clé d’organisation, `vercel pull` ne la récupère pas.\n\nSi ton build a besoin d’un secret, passe-le par un secret du dépôt, puis expose-le au build avec `env:`. Ne le mets pas dans une variable publique du projet. Voir [Secrets et coffre](/docs/concepts/secrets-et-coffre/).\n\n## Si ça ne marche pas\n\n- Le job échoue sur `vercel pull` avec un `403` : la clé `VERCEL_TOKEN` est mal copiée ou révoquée. Voir [Dépannage](/docs/guides/depannage/#la-cli-renvoie-403).\n- Le job tourne, mais aucun déploiement n’apparaît : vérifie que `VERCEL_PROJECT_ID` et `VERCEL_ORG_ID` viennent bien de `.vercel/project.json`."},{"path":"/docs/guides/inviter-une-personne/","title":"Inviter une personne dans une organisation","description":"Ajoute un collègue à ton organisation depuis Account, et choisis son rôle pour qu'il accède aux projets.","version":null,"markdown":"Les membres d’une organisation se gèrent dans Account, pas dans Host. Ce guide invite une personne, puis vérifie qu’elle accède aux projets.\n\n**Résultat attendu** : la personne se connecte à Host, voit l’organisation et ses projets, avec le rôle que tu lui as donné.\n\n**Avant de commencer** : être propriétaire ou admin de l’organisation dans Account. Les rôles sont décrits dans [Organisations et rôles](/docs/concepts/organisations-et-roles/).\n\n1. **Invite depuis Account**\n\n   Ouvre la page de ton organisation dans [Account](https://account.hgdc.ch). Invite la personne par son adresse e-mail, et choisis son rôle : **membre**, **admin** ou **propriétaire**.\n\n   **Vérification** : l’invitation apparaît dans la liste des invitations en attente d’Account.\n\n2. **La personne se connecte**\n\n   La personne se connecte à Host avec **Se connecter avec HGDC**, avec la même adresse e-mail vérifiée. Son compte est lié à l’organisation, et ses projets restent en place.\n\n   Une personne qui n’a pas encore de compte demande d’abord un accès sur la page **Demander un accès** de Host. L’invitation suit.\n\n3. **Vérifie l'accès**\n\n   Demande à la personne d’ouvrir son tableau de bord.\n\n   **Vérification** : elle voit ton organisation dans le sélecteur de la barre latérale, et les projets qu’elle peut voir. Un membre n’a pas accès à l’onglet **Clés d’API**.\n\n## Changer un rôle ou retirer une personne\n\nModifie le rôle ou retire la personne dans Account. Host ne garde pas sa propre liste de membres : la liste affichée dans Host est une copie en lecture seule, mise à jour à la prochaine connexion de la personne.\n\nUne session dure 7 jours au plus, sans prolongation. Un changement de rôle ou un retrait peut donc prendre effet jusqu’à la prochaine connexion, au plus tard à la fin de la session.\n\nLes clés d’API créées par une personne cessent de fonctionner quand elle quitte l’organisation. Révoque-les si tu veux agir tout de suite. Voir [Créer et révoquer une clé d’API](/docs/guides/cle-d-api/).\n\n## Si ça ne marche pas\n\n- L’organisation n’apparaît pas pour la personne : vérifie que l’adresse e-mail de l’invitation est la même que celle de son compte HGDC, et qu’elle est vérifiée.\n- La personne ne peut pas faire une action : son rôle ne le permet pas (voir le tableau des rôles). Vérifie son rôle dans Account."},{"path":"/docs/guides/lire-les-logs/","title":"Lire les logs","description":"Suis les requêtes servies par ton site, puis la sortie de tes builds, pour trouver la cause d'une erreur.","version":null,"markdown":"Les logs répondent à deux questions : qu’est-ce que les visiteurs ont reçu, et qu’est-ce qui s’est passé pendant le build. Ce guide montre où les trouver et comment les filtrer.\n\n**Résultat attendu** : tu identifies la requête ou la ligne de build à l’origine d’un problème.\n\n## Les requêtes servies\n\n1. **Ouvre l'onglet Logs du projet**\n\n   Les requêtes apparaissent en direct. Pour chacune, tu vois l’heure, le statut HTTP, la méthode, le domaine, le chemin, la durée de traitement et la taille de la réponse.\n\n2. **Isole les erreurs**\n\n   Clique **Erreur** pour ne garder que les réponses `5xx`. Clique **Alerte** pour les réponses `4xx`. La recherche lit le chemin et le domaine.\n\n3. **Garde la vue à jour**\n\n   **Suivre** garde les dernières requêtes en vue. Sous la liste, un compteur donne le nombre de réponses par classe : 2xx, 3xx, 4xx et 5xx.\n\n4. **Copie ce qui t'intéresse**\n\n   **Tout copier** copie toutes les requêtes reçues, une par ligne. L’icône de copie ne copie que les lignes affichées.\n\nLes requêtes ne gardent ni adresse IP, ni en-têtes, ni paramètres d’URL (la partie après `?`). Elles disparaissent après trois jours. Voir [Confidentialité](/docs/concepts/confidentialite/).\n\n## La sortie d’un build\n\nLa page de chaque déploiement affiche la sortie du build : installation, `vercel build`, puis publication.\n\n- Avec l’intégration GitHub, les lignes arrivent en direct pendant le build.\n- Cherche dans les lignes, ou filtre les erreurs et les alertes.\n- Ouvre le run GitHub Actions pour la sortie complète, si ton build passe par GitHub.\n- **Tout copier** copie la sortie entière. L’icône de copie ne copie que les lignes affichées.\n\n## Suivre un déploiement depuis le terminal\n\n`vercel deploy` suit la publication jusqu’à la fin, pendant 9 minutes au plus, puis rend la main :\n\n```bash\nvercel --api https://api.host.hgdc.ch deploy --prod\n```\n\n## Si ça ne marche pas\n\n- Un build n’a pas de sortie : il est peut-être en file, ou il a été annulé avant de démarrer. Vérifie l’état du déploiement.\n- Un problème de page n’apparaît pas dans les logs de requêtes : les requêtes sont gardées trois jours seulement. Reproduis le problème, puis regarde tout de suite.\n- Pour une erreur de build, commence par la première ligne d’erreur du filtre **Erreur**, puis remonte la sortie jusqu’à elle. Voir [Dépannage](/docs/guides/depannage/)."},{"path":"/docs/guides/migrer-depuis-vercel/","title":"Migrer un projet depuis Vercel","description":"Déplace un projet de Vercel vers Host sans changer tes outils, avec une bascule DNS sans coupure.","version":null,"markdown":"Host reprend les outils que tu utilises déjà : la CLI Vercel, `vercel.json` et le format Build Output API. Migrer revient à recréer le projet, reprendre ses variables, puis changer le DNS.\n\n**Résultat attendu** : ton domaine sert le site depuis Host, et le projet Vercel n’envoie plus de déploiement.\n\n**Avant de commencer** : vérifie que ton site n’utilise que des fonctions prises en charge. Les fonctions, le runtime edge, l’ISR et les crons sont en préversion, voir [Compatibilité](/docs/reference/compatibilite/).\n\n1. **Crée le projet sur Host**\n\n   Importe le dépôt depuis GitHub, voir [Déployer depuis GitHub](/docs/guides/deployer-depuis-github/). Ou lance `vercel deploy` depuis le dossier du projet avec une clé Host.\n\n   Supprime d’abord le dossier `.vercel` s’il existe : il pointe vers le projet Vercel.\n\n   ```bash\n   rm -rf .vercel\n   vercel --api https://api.host.hgdc.ch deploy\n   ```\n\n   **Vérification** : un déploiement de preview est **Prêt**.\n\n2. **Reprends les variables**\n\n   Sur Vercel, `vercel env pull .env.production --environment=production` écrit les variables lisibles dans un fichier.\n\n   Colle le contenu de ce fichier dans **Ajouter**, dans l’onglet **Variables d’environnement** de Host, en choisissant l’environnement Production. Les variables marquées « Sensitive » sur Vercel ne se relisent pas : saisis-les à nouveau.\n\n   **Vérification** : le nombre de variables correspond à celui de Vercel.\n\n3. **Vérifie la preview**\n\n   Ouvre l’adresse du déploiement et parcours le site : pages, redirections, page 404 et ressources.\n\n   **Vérification** : aucune page ne répond `404` ou `501` de façon inattendue.\n\n4. **Ajoute le domaine et change le DNS**\n\n   Ajoute le domaine au projet, pose le TXT de propriété, puis remplace les enregistrements qui pointaient vers Vercel par le CNAME ou le A indiqué. Le détail est dans [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n\n5. **Retire le projet de Vercel**\n\n   Une fois le trafic arrivé et le certificat émis, débranche le dépôt côté Vercel. Tu évites ainsi deux déploiements à chaque push.\n\n> **Astuce**\n>\n> Pose d’abord le TXT : il ne change rien au trafic. Ne change le CNAME ou le A que quand le domaine est prêt côté Host. Baisse le TTL de l’enregistrement quelques heures avant la bascule, pour revenir vite en arrière si besoin.\n\n## Si ça ne marche pas\n\n- La preview affiche une page `501` : une fonction n’est pas encore ouverte à ton organisation. Voir [Préversion](/docs/concepts/preversion/).\n- Le site répond encore depuis Vercel : le DNS n’est pas propagé, ou un ancien enregistrement subsiste. Voir [Dépannage](/docs/guides/depannage/#mon-domaine-reste-en-attente)."},{"path":"/docs/guides/monorepo/","title":"Déployer une app dans un monorepo","description":"Déploie une app qui vit dans un sous-dossier, et plusieurs sites d'un même dépôt.","version":null,"markdown":"Ton site peut vivre dans un sous-dossier, comme `apps/web` ou `site/`, dans un dépôt qui contient d’autres applications. Indique à Host le dossier racine du projet : c’est là que le build s’exécute.\n\n**Résultat attendu** : le build s’exécute depuis le dossier de ton app, et seule cette app est publiée.\n\n## Détection à l’import\n\nÀ l’import GitHub, Host lit tout le dépôt et cherche les dossiers qui contiennent un `package.json`, jusqu’à quatre niveaux de profondeur. Il préfère, dans l’ordre :\n\n1. un framework reconnu ;\n2. un dossier qui a un script `build` ;\n3. un nom usuel : `web`, `site`, `www`, `frontend`, `app`, `landing`, `marketing` ;\n4. le dossier le moins profond.\n\nLa racine d’un monorepo, avec un champ `workspaces`, un `pnpm-workspace.yaml`, un `turbo.json` ou un `nx.json`, n’est jamais choisie seule. Si le dépôt contient plusieurs applications, choisis celle à déployer. Les dossiers `node_modules`, `dist`, `build` et les caches sont ignorés.\n\nPour changer le dossier après l’import, modifie le **dossier racine** dans les réglages du projet.\n\n## Le fichier de verrouillage\n\nDans un monorepo, le fichier de verrouillage, comme `pnpm-lock.yaml` ou `bun.lock`, est souvent à la racine. Il compte pour toutes les applications : la commande d’installation suit le gestionnaire qu’il désigne.\n\n## Plusieurs sites dans un dépôt\n\nImporte le dépôt une fois par site, en choisissant à chaque fois un dossier différent. Chaque projet a ses domaines, ses variables et son historique.\n\n## Avec la CLI\n\nLance la CLI depuis le dossier de l’app :\n\n```bash\ncd apps/web\nvercel --api https://api.host.hgdc.ch deploy\n```\n\nAvec `vercel build` et `--prebuilt`, la même règle s’applique : construis depuis le dossier de l’app. Voir [Déployer un framework](/docs/guides/deployer-un-framework/).\n\n## Si ça ne marche pas\n\n- Le build ne trouve pas tes dépendances : ton dossier est sans doute le mauvais. Vérifie que le dossier racine contient le `package.json` de l’app, et que le fichier de verrouillage est bien à la racine du dépôt.\n- Host propose la racine du monorepo : choisis le dossier de l’application, pas la racine."},{"path":"/docs/guides/revenir-en-arriere/","title":"Revenir en arrière, redéployer ou annuler","description":"Remets en ligne une version précédente, relance un build ou annule un déploiement en cours.","version":null,"markdown":"Une mise en production s’est mal passée ? Ce guide remet en ligne une version précédente, relance un build, ou annule un déploiement en cours. Aucune de ces actions ne demande de nouveau commit.\n\n**Résultat attendu** : ton domaine de production sert la version choisie, ou le déploiement en cours s’arrête.\n\n**Avant de commencer** : une version précédente **Prête**. Un déploiement en erreur ne peut pas redevenir la production.\n\n## Revenir à une version précédente\n\n1. **Ouvre la liste des déploiements**\n\n   Dans le projet, ouvre l’onglet **Déploiements**. Chaque ligne montre l’état, la cible et le commit, quand il est connu.\n\n2. **Choisis la version à remettre en ligne**\n\n   Ouvre un déploiement de production précédent, qui est **Prêt**, puis clique **Revenir en arrière**.\n\n   Le retour est immédiat : aucun build ne tourne.\n\n3. **Vérifie le site**\n\n   **Vérification** : tes domaines de production répondent avec la version choisie. L’onglet **Vue d’ensemble** l’affiche comme production.\n\nLe déploiement remis en ligne garde les variables qu’il a reçues à son build. Une variable modifiée depuis ne s’y applique pas. Pour appliquer une variable à la version remise en ligne, reconstruis-la : la section **Redéployer** plus bas explique comment.\n\n## Mettre une preview en production\n\nDepuis la page d’une preview prête, clique **Mettre en production**. Cette preview sert alors tes domaines de production, avec les variables de preview qu’elle a reçues. La console te le rappelle avant de confirmer.\n\nUtilise cette action pour valider une version sur son adresse de preview, puis la passer en production sans la reconstruire.\n\n## Redéployer\n\nRedéployer reconstruit une version avec les variables d’aujourd’hui :\n\n- **Projet relié à GitHub** : reconstruit le même commit dans GitHub Actions, avec les variables actuelles. Le bouton **Redéployer la production** le fait pour la production.\n- **Projet envoyé par la CLI** : republie les fichiers du déploiement choisi, sans rien reconstruire. Pour une nouvelle version, relance `vercel deploy`.\n\n## Annuler un déploiement\n\nUn déploiement **En file** ou **En cours de build** peut être annulé, avec **Annuler**. Un déploiement **Prêt** ne s’annule pas : reviens en arrière à la place.\n\n**Vérification** : le déploiement passe à **Annulé**, et la production n’a pas changé.\n\n## Si ça ne marche pas\n\n- **Revenir en arrière** est absent : le déploiement n’est pas **Prêt**, ou il n’est pas de production.\n- Le site répond encore avec l’ancienne version : le cache de ton navigateur ou de ton réseau peut retenir la page. Recharge la page sans cache, puis patiente quelques minutes.\n- Pour comprendre le cycle de vie d’un déploiement, lis [Déploiements](/docs/concepts/deploiements/)."},{"path":"/docs/guides/site-statique/","title":"Déployer un site statique","description":"Mets un dossier de HTML, CSS et images en ligne en une commande, sans étape de build.","version":null,"markdown":"Un site statique est un dossier de fichiers déjà prêts : HTML, CSS, JavaScript et images. Aucun build n’est nécessaire. Une seule commande suffit.\n\n**Résultat attendu** : une adresse de production qui sert ton dossier, avec une page 404 personnalisée si tu en fournis une.\n\n**Avant de commencer** : une clé d’API dans `VERCEL_TOKEN`, et un dossier qui contient un `index.html` à sa racine.\n\n## Déployer le dossier\n\n```bash\ncd mon-site\nvercel --api https://api.host.hgdc.ch deploy --prod\n```\n\nLe premier déploiement crée le projet, sous le nom du dossier, et relie le dossier au projet. Les suivants republient ce qui a changé : un fichier déjà connu de l’organisation n’est jamais renvoyé.\n\n**Vérification** : l’adresse de production répond avec `index.html`.\n\n## Structure attendue\n\n```text\nmon-site/\n├── index.html\n├── a-propos.html\n├── 404.html\n├── styles.css\n└── images/\n    └── logo.svg\n```\n\n- Le dossier doit contenir un `index.html` à sa racine.\n- Un dossier qui ressemble à des sources, avec un `package.json` mais sans `index.html`, est refusé. Construis-le avec `vercel build` et envoie-le avec `--prebuilt`. Voir [Déployer un framework](/docs/guides/deployer-un-framework/).\n- Les fichiers et dossiers cachés, comme `.env` ou `.git`, ne sont jamais servis.\n- `404.html` sert de page d’erreur.\n\n## Servir un sous-dossier\n\nSi les fichiers à publier sont dans un sous-dossier, comme `public/` ou `dist/`, lance la commande depuis ce sous-dossier (`cd dist`, puis `deploy`). Avec un projet relié à GitHub, indique le dossier de sortie dans les réglages de build du projet.\n\n## URL propres et redirections\n\nAjoute un `vercel.json` à la racine du dossier pour servir `/a-propos` sans `.html`, ou pour rediriger une ancienne adresse :\n\n```json\n{\n  \"cleanUrls\": true,\n  \"redirects\": [\n    { \"source\": \"/ancienne-page\", \"destination\": \"/a-propos\", \"permanent\": true }\n  ]\n}\n```\n\nToutes les options sont dans [vercel.json](/docs/reference/vercel-json/).\n\n## Si ça ne marche pas\n\n- Le site répond `404` : le dossier envoyé n’a pas d’`index.html` à sa racine. Voir [Dépannage](/docs/guides/depannage/#mon-site-affiche-404).\n- `/a-propos` répond `404` alors que `a-propos.html` existe : active `cleanUrls` dans `vercel.json`."},{"path":"/docs/guides/synchroniser-doppler/","title":"Synchroniser les variables depuis Doppler","description":"Garde tes secrets dans Doppler. Chaque changement arrive dans le projet Host tout seul, et peut redéployer la production.","version":null,"markdown":"Si tes secrets vivent déjà dans Doppler, relie une de tes configs à un environnement du projet. Doppler reste la source de vérité : chaque changement arrive dans Host sans copie à la main.\n\n**Résultat attendu** : les variables de la config apparaissent dans l’environnement choisi, avec le badge **Doppler**, et ne se modifient plus que dans Doppler.\n\n**Avant de commencer** : un projet Host, et un compte Doppler avec accès à la config à synchroniser.\n\n## Relier une config\n\n1. **Crée un jeton de service dans Doppler**\n\n   Dans Doppler, ouvre la config, par exemple `prd`, onglet **Access**, et génère un jeton de service en lecture seule. Il commence par `dp.st.`.\n\n2. **Relie la config au projet**\n\n   Dans l’onglet **Variables d’environnement** du projet, section **Synchroniser depuis Doppler**, clique **Relier une config Doppler**. Choisis l’environnement, nomme la config, puis colle le jeton.\n\n   Host essaie le jeton, le chiffre et ne l’affiche plus jamais. La première synchronisation part tout de suite.\n\n   **Vérification** : les variables de la config apparaissent avec le badge **Doppler**.\n\n3. **Ajoute le webhook dans Doppler**\n\n   Host affiche une adresse et un secret de signature, une seule fois. Dans Doppler, ouvre **Webhooks**, ajoute un webhook avec cette adresse, coche la config et colle le secret.\n\n   Chaque changement est alors signé, puis appliqué en quelques secondes.\n\n   **Vérification** : modifie une valeur de test dans Doppler. Elle apparaît dans Host en quelques secondes.\n\n## Ce qui est synchronisé\n\n- Toutes les variables de la config, sauf les métadonnées de Doppler, comme `DOPPLER_PROJECT` ou `DOPPLER_CONFIG`.\n- Les noms réservés, qui commencent par `VERCEL_` ou `AGENTHOST_`, ne sont pas synchronisés. Les valeurs de plus de 64 Ko non plus. La console les signale.\n- 300 variables au plus par config.\n- En production et en preview, les variables sont **sensibles** : elles ne descendent pas sur un poste par `vercel pull`. En développement, elles sont ordinaires. Voir [Variables](/docs/guides/variables-d-environnement/#marquer-une-variable-comme-sensible).\n\n## Ce qui se passe quand une valeur change\n\n- Une variable retirée de Doppler disparaît du projet au passage suivant.\n- Une config devenue vide d’un coup ne retire rien : la console signale l’erreur. C’est une protection contre un accident de configuration.\n- Une variable manuelle du même nom, sur le même environnement, l’emporte et n’est jamais écrasée. La console liste ces noms : supprime la variable manuelle pour que Doppler prenne le relais.\n- Sans webhook, ou si un appel se perd, la synchronisation repasse toute seule toutes les six heures. Clique **Synchroniser** pour la lancer tout de suite.\n\n## Redéployer à chaque changement\n\nPour un projet relié à GitHub et la config de production, active **Redéployer la production à chaque changement**. Quand une valeur change dans Doppler, le workflow du dépôt reconstruit la production avec les nouvelles valeurs.\n\nUne synchronisation sans changement ne redéploie rien.\n\n## Débrancher\n\n**Débrancher** garde les variables dans le projet, redevenues manuelles. Aucun build ne les perd d’un coup. Retire ensuite le webhook et révoque le jeton dans Doppler.\n\n> **Astuce**\n>\n> Le jeton de service et le secret du webhook sont chiffrés, liés au projet, et ne sont jamais renvoyés. Si tu perds le secret, clique **Générer un nouveau secret** sous l’adresse du webhook, puis remplace-le dans Doppler.\n\n## Si ça ne marche pas\n\n- La synchronisation affiche une erreur à la connexion : le jeton n’est pas un jeton de service de la config, ou il est révoqué. Crée-en un nouveau.\n- Une variable n’arrive pas : elle porte un nom réservé, ou sa valeur dépasse 64 Ko. Vérifie la liste signalée dans la console.\n- Le webhook ne déclenche rien : vérifie que l’adresse et le secret collés dans Doppler sont ceux affichés à la création du webhook. Sinon, génère un nouveau secret."},{"path":"/docs/guides/variables-d-environnement/","title":"Gérer les variables d'environnement","description":"Ajoute des variables par environnement, marque les secrets comme sensibles et applique un changement à ton site.","version":null,"markdown":"Les variables d’environnement passent des réglages à ton build : l’adresse d’une API, un identifiant public, une clé de service. Ce guide les ajoute, les rend sensibles si besoin, et les applique à ton site.\n\n**Résultat attendu** : une variable visible dans l’onglet **Variables d’environnement** du projet, utilisée par le prochain build de l’environnement visé.\n\n**Avant de commencer** : être membre de l’organisation. Modifier une variable demande le rôle membre ou plus.\n\n## Ajouter une variable\n\n1. **Ouvre Ajouter**\n\n   Dans l’onglet **Variables d’environnement** du projet, clique **Ajouter**.\n\n2. **Remplis le nom et la valeur**\n\n   Le nom ne contient que des lettres, des chiffres et `_`, et ne commence pas par un chiffre. Il fait 256 caractères au plus. Les noms qui commencent par `VERCEL_` ou `AGENTHOST_` sont réservés à la plateforme.\n\n   La valeur fait 64 Ko au plus. Une note facultative rappelle à quoi sert la variable : 500 caractères au plus.\n\n3. **Choisis les environnements**\n\n   Chaque variable vise un ou plusieurs environnements :\n\n   | Environnement     | Utilisé par                                                              |\n   | ----------------- | ------------------------------------------------------------------------ |\n   | **Production**    | Les builds de production, avec `vercel build --prod`                     |\n   | **Preview**       | Les builds de preview, donc toutes les branches autres que la production |\n   | **Développement** | `vercel pull` depuis ton poste                                           |\n\n   Un même nom peut exister une fois par environnement, avec une valeur différente. Par exemple, `API_URL` pointe vers l’API de production en production, et vers l’API de test en preview.\n\n4. **Ou colle un fichier .env**\n\n   Colle le contenu d’un fichier `.env` dans le champ du nom : chaque ligne devient une variable.\n\n   ```text\n   PUBLIC_API_URL=https://api.exemple.ch\n   PUBLIC_ANALYTICS_ID=abc123\n   ```\n\n   **Vérification** : chaque variable apparaît dans la liste, avec ses environnements.\n\n## Marquer une variable comme sensible\n\nUne clé secrète ou un mot de passe se déclare **sensible**. Une variable sensible :\n\n- ne s’affiche plus jamais après l’enregistrement, ni dans la console ni dans la CLI. Tu peux seulement la remplacer ;\n- vise la production ou la preview, jamais le développement ;\n- n’est livrée qu’au build du dépôt GitHub, par la clé limitée au projet que pose l’app GitHub. Un `vercel pull` depuis ton poste ne la télécharge pas.\n\nPour une valeur sensible utilisée par un build hors GitHub, voir [GitHub Actions sans l’application](/docs/guides/github-actions-sans-application/#variables-sensibles).\n\n> **Attention**\n>\n> Tout ce que le build écrit dans les fichiers du site est public. Une variable lue dans le navigateur, comme celles qui commencent par `PUBLIC_`, `VITE_` ou `NEXT_PUBLIC_`, ne doit jamais contenir un secret, sensible ou non.\n\n## Appliquer un changement\n\nUne variable est lue au build. Les déploiements déjà en ligne gardent les valeurs de leur propre build, et une modification ne les touche pas.\n\n- Pour un projet relié à GitHub, clique **Redéployer la production** pour relancer le build avec les valeurs actuelles.\n- Pour un projet déployé avec la CLI, relance le déploiement de production depuis ton dossier ou ta CI :\n\n```bash\nvercel --api https://api.host.hgdc.ch pull --environment=production\nvercel --api https://api.host.hgdc.ch build --prod\nvercel --api https://api.host.hgdc.ch deploy --prebuilt --prod\n```\n\nL’onglet signale une variable modifiée depuis le dernier build de production.\n\n**Vérification** : le nouveau déploiement de production affiche la nouvelle valeur. Le déploiement précédent ne la montre pas.\n\n## Récupérer les variables sur ton poste\n\n```bash\nvercel --api https://api.host.hgdc.ch pull\n```\n\nPar défaut, la commande télécharge l’environnement **Développement** dans `.vercel/.env.development.local`. Ajoute `--environment=preview` ou `--environment=production` pour un autre environnement. Le dossier `.vercel` est ajouté au `.gitignore` : ne le commite pas.\n\n## Si ça ne marche pas\n\n- Une variable sensible n’apparaît pas dans `vercel pull` : c’est voulu. Utilise une valeur de développement, dans une variable non sensible visant l’environnement Développement.\n- Le site n’a pas changé après la modification : le déploiement n’a pas été relancé. Voir [Appliquer un changement](#appliquer-un-changement).\n- La variable ne peut pas être créée : son nom est réservé, ou sa valeur dépasse 64 Ko. Voir [Variables : référence](/docs/reference/variables/).\n\n## Voir aussi\n\n- [Secrets et coffre](/docs/concepts/secrets-et-coffre/) : comment les valeurs sont chiffrées et qui peut les lire.\n- [Synchroniser depuis Doppler](/docs/guides/synchroniser-doppler/) : garder les secrets dans Doppler."},{"path":"/docs/","title":"Host","description":"Host publie tes sites sur ton domaine, avec la CLI Vercel, depuis l'Union européenne.","version":null,"markdown":"Host déploie tes sites. Chaque modification donne une version en ligne, avec sa propre adresse, et la production reste sur ton domaine.\n\nTu gardes tes outils : la CLI Vercel, `vercel.json` et le format Build Output API. Seule l’adresse de l’API change.\n\n## Par où commencer\n\n[Mettre un premier site en ligne](/docs/demarrer/premier-site/)\n\n[Du compte à une preview, puis à la production, avec la CLI. Une quinzaine de minutes.](/docs/demarrer/premier-site/)\n\n[Déployer depuis GitHub](/docs/demarrer/depuis-github/)\n\n[Importe un dépôt : chaque push construit le site et le publie.](/docs/demarrer/depuis-github/)\n\n[Référence de la CLI](/docs/reference/cli/)\n\n[Les commandes `deploy`, `build`, `pull` et `link`, avec leurs options.](/docs/reference/cli/)\n\n[Référence de l'API](/docs/reference/api/introduction/)\n\n[Les endpoints compatibles Vercel, leurs paramètres et leurs réponses.](/docs/reference/api/introduction/)\n\n## Ce que Host fait\n\n- **Des sites statiques et des frameworks** : un dossier de fichiers, ou le résultat de `vercel build` pour Astro, Vite, Next.js, SvelteKit, Nuxt, TanStack Start et React Router. Voir [Compatibilité](/docs/reference/compatibilite/).\n- **Une URL par version** : chaque déploiement a sa propre adresse, à faire valider avant de passer en production.\n- **Un domaine à toi** : tu ajoutes ton domaine, Host vérifie qu’il t’appartient et obtient le certificat HTTPS. Voir [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n- **Des variables par environnement** : production, preview et développement, avec des variables sensibles jamais relues. Voir [Variables d’environnement](/docs/guides/variables-d-environnement/).\n- **Une organisation et des rôles** : les membres se gèrent dans Account. Voir [Organisations et rôles](/docs/concepts/organisations-et-roles/).\n\n## Ce qui arrive en préversion\n\nLe rendu à la demande (SSR), les routes d’API, le proxy, le runtime edge, l’ISR et les crons s’exécutent en préversion, organisation par organisation. Les fichiers statiques et les pages pré-rendues sont servis dans tous les cas. Le détail est sur [Préversion](/docs/concepts/preversion/).\n\n## Les autres produits de la famille\n\n[Account](https://account.hgdc.ch/docs/)\n\n[![](/docs/images/famille/account.svg)](https://account.hgdc.ch/docs/)\n\n[Un seul compte pour toute la famille, avec « Se connecter avec HGDC ».](https://account.hgdc.ch/docs/)\n\n[Mail](https://mail.hgdc.ch/docs/)\n\n[![](/docs/images/famille/mail.svg)](https://mail.hgdc.ch/docs/)\n\n[Tes e-mails, newsletters et formulaires, envoyés depuis ton adresse.](https://mail.hgdc.ch/docs/)\n\n[Portal](https://portal.hgdc.ch/docs/)\n\n[![](/docs/images/famille/portal.svg)](https://portal.hgdc.ch/docs/)\n\n[Un espace partagé où ton client suit son projet, signe et paie.](https://portal.hgdc.ch/docs/)\n\n[Status](https://status.hgdc.ch/docs/)\n\n[![](/docs/images/famille/status.svg)](https://status.hgdc.ch/docs/)\n\n[Surveillance de tes services, heartbeats et page de statut.](https://status.hgdc.ch/docs/)\n\n[Analytics](https://analytics.hgdc.ch/docs/)\n\n[![](/docs/images/famille/analytics.svg)](https://analytics.hgdc.ch/docs/)\n\n[Tes visiteurs mesurés, sans cookies ni bannière.](https://analytics.hgdc.ch/docs/)\n\n[Docs](https://docs.hgdc.ch/docs/)\n\n[![](/docs/images/famille/docs.svg)](https://docs.hgdc.ch/docs/)\n\n[Ta documentation en MDX, avec un assistant IA qui cite ses sources.](https://docs.hgdc.ch/docs/)"},{"path":"/docs/reference/api/deploiements/","title":"Déploiements","description":"Créer un déploiement, lire son état, suivre ses logs en direct. Corps de requête, champs de l'objet déploiement et erreurs.","version":null,"markdown":"Un déploiement est une version figée de ton site, avec sa propre adresse. Créer un déploiement est l’appel central de `vercel deploy`.\n\n## Déroulement d’une création\n\n1. Envoie la liste des fichiers avec leur empreinte SHA1.\n2. Si des fichiers manquent, l’API répond `400 missing_files`, avec leurs empreintes dans `missing`. Envoie-les par [`/v2/files`](/docs/reference/api/fichiers/).\n3. Renvoie exactement la même requête. Elle crée le déploiement.\n\nLes petits fichiers peuvent aussi être inclus directement dans le corps, dans le champ `data`, sans passer par `/v2/files`. La limite de 20 Mo vaut alors pour l’ensemble des fichiers inclus.\n\n## POST `/v13/deployments`\n\n```bash\ncurl -X POST https://api.host.hgdc.ch/v13/deployments \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"name\": \"site-atelier\",\n    \"target\": \"production\",\n    \"files\": [\n      { \"file\": \"index.html\", \"data\": \"<h1>Bonjour</h1>\" }\n    ]\n  }'\n```\n\n### Corps\n\n| Champ                       | Type                     | Requis                  | Description                                                                                                                |\n| --------------------------- | ------------------------ | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `name`                      | `string`                 | Si `project` est absent | Nom du projet. Le projet est créé s’il n’existe pas                                                                        |\n| `project`                   | `string`                 | Non                     | Identifiant ou nom du projet. Prioritaire sur `name`                                                                       |\n| `target`                    | `\"production\"` ou `null` | Non                     | `production` pour la production. Toute autre valeur crée une preview                                                       |\n| `files`                     | `object[]`               | Oui                     | Fichiers du déploiement, 15 000 au plus. Voir ci-dessous                                                                   |\n| `projectSettings.framework` | `string` ou `null`       | Non                     | Framework, enregistré si le déploiement crée le projet                                                                     |\n| `gitMetadata`               | `object`                 | Non                     | `commitRef` (branche), `commitSha` et `commitMessage`, affichés dans la console                                            |\n| `meta`                      | `Record<string, string>` | Non                     | Métadonnées libres. `githubCommitRef`, `githubCommitSha` et `githubCommitMessage` remplacent `gitMetadata` quand il manque |\n\nChaque élément de `files` prend l’une de ces formes :\n\n- `{ \"file\", \"sha\", \"size\" }` : chemin relatif, empreinte SHA1 et taille en octets, pour un fichier déjà envoyé par `/v2/files` ;\n- `{ \"file\", \"data\", \"encoding\" }` : contenu inclus. `encoding` vaut `utf-8` (par défaut) ou `base64`.\n\n`mode` (permissions Unix) est accepté et conservé. Un dossier vide, `{ \"file\", \"mode\" }`, est ignoré.\n\n### Réponse\n\nRéponse `200` : l’objet déploiement. Le déploiement naît le plus souvent à l’état `QUEUED`. Suis-le avec `GET /v13/deployments/:id`, plus bas sur cette page, ou avec le flux de logs `GET /v3/deployments/:id/events`.\n\n### Erreurs\n\n| Statut | Code                | Cause                                                              |\n| ------ | ------------------- | ------------------------------------------------------------------ |\n| `400`  | `bad_request`       | Corps invalide, ou nom de projet absent. Le message nomme le champ |\n| `400`  | `missing_files`     | Des fichiers sont à envoyer avant de créer le déploiement          |\n| `403`  | `forbidden`         | La clé est limitée à un autre projet                               |\n| `409`  | `deployment_closed` | Le déploiement a été annulé ou a échoué : rien n’est publié        |\n| `413`  | `payload_too_large` | Les fichiers inclus dépassent 20 Mo au total                       |\n\n## GET `/v13/deployments/:id`\n\nLit un déploiement.\n\n```bash\ncurl https://api.host.hgdc.ch/v13/deployments/jd7f2k9m3x8q1p5s6t4v0w7y2z \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nRéponse `200` :\n\n```json\n{\n  \"id\": \"jd7f2k9m3x8q1p5s6t4v0w7y2z\",\n  \"uid\": \"jd7f2k9m3x8q1p5s6t4v0w7y2z\",\n  \"url\": \"site-atelier-h3k9x2.hgdc.cloud\",\n  \"name\": \"site-atelier\",\n  \"projectId\": \"j97d3k2m8x1q4p6s7t9v0w2y5z\",\n  \"ownerId\": \"k57a1b2c3d4e5f6g7h8j9k0m1n\",\n  \"readyState\": \"READY\",\n  \"status\": \"READY\",\n  \"target\": \"production\",\n  \"type\": \"LAMBDAS\",\n  \"createdAt\": 1760259600000,\n  \"buildingAt\": 1760259601000,\n  \"ready\": 1760259604000,\n  \"alias\": [\"site-atelier.hgdc.cloud\"],\n  \"aliasAssigned\": true,\n  \"aliasAssignedAt\": 1760259604000,\n  \"aliasError\": null,\n  \"errorMessage\": null,\n  \"inspectorUrl\": \"https://host.hgdc.ch/atelier/site-atelier/deployments/jd7f2k9m3x8q1p5s6t4v0w7y2z\",\n  \"meta\": {\n    \"branch\": \"main\",\n    \"commitSha\": \"4c3e2f1a9b8d7c6e5f4a3b2c1d0e9f8a7b6c5d4e\",\n    \"commitMessage\": \"Nouvelle page Tarifs\"\n  },\n  \"creator\": { \"uid\": \"u1a2b3c4d5\" }\n}\n```\n\n| Champ             | Type                     | Description                                                                                                                                                           |\n| ----------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `id`              | `string`                 | Identifiant du déploiement. `uid` porte la même valeur                                                                                                                |\n| `url`             | `string`                 | Adresse du déploiement, sans `https://`. Elle reste valable tant que le déploiement existe                                                                            |\n| `name`            | `string`                 | Nom du projet                                                                                                                                                         |\n| `projectId`       | `string`                 | Identifiant du projet                                                                                                                                                 |\n| `ownerId`         | `string`                 | Identifiant de l’organisation                                                                                                                                         |\n| `readyState`      | `string`                 | État : `QUEUED`, `BUILDING`, `READY`, `ERROR` ou `CANCELED`. `status` porte la même valeur                                                                            |\n| `target`          | `\"production\"` ou `null` | `production`, ou `null` pour une preview                                                                                                                              |\n| `createdAt`       | `number`                 | Date de création, en millisecondes                                                                                                                                    |\n| `buildingAt`      | `number`                 | Début du traitement, en millisecondes                                                                                                                                 |\n| `ready`           | `number` ou `null`       | Fin du traitement. `null` tant que le déploiement n’est pas prêt                                                                                                      |\n| `alias`           | `string[]`               | Adresse de production du projet (`<projet>.hgdc.cloud`), une fois un déploiement de production prêt. Vide pour une preview. La CLI l’affiche sur la ligne « Aliased » |\n| `aliasAssigned`   | `boolean`                | `true` quand le déploiement est prêt                                                                                                                                  |\n| `aliasAssignedAt` | `number` ou `null`       | Moment où l’adresse de production lui a été attribuée. `null` pour une preview                                                                                        |\n| `aliasError`      | `null`                   | Toujours `null`                                                                                                                                                       |\n| `errorMessage`    | `string` ou `null`       | Cause de l’échec, quand `readyState` vaut `ERROR`                                                                                                                     |\n| `inspectorUrl`    | `string`                 | Page du déploiement dans la console                                                                                                                                   |\n| `type`            | `\"LAMBDAS\"`              | Valeur fixe, pour la CLI                                                                                                                                              |\n| `meta`            | `object`                 | Informations Git connues : `branch`, `commitSha`, `commitMessage`                                                                                                     |\n| `creator.uid`     | `string`                 | Personne qui a créé la clé utilisée                                                                                                                                   |\n\n### Attendre la fin\n\nPour attendre qu’un déploiement soit prêt, interroge cet endpoint toutes les secondes jusqu’à `READY`, `ERROR` ou `CANCELED`. Tu peux aussi ouvrir le flux `GET /v3/deployments/:id/events` décrit plus bas, qui se ferme tout seul à la fin.\n\n| Erreur | Code        | Cause                                                                         |\n| ------ | ----------- | ----------------------------------------------------------------------------- |\n| `404`  | `not_found` | Déploiement inconnu, d’une autre organisation, ou hors de la portée de la clé |\n\n## GET `/v3/deployments/:id/events`\n\nRenvoie les logs de build d’un déploiement, un événement JSON par ligne (NDJSON). Avec `follow=1`, la connexion reste ouverte et reçoit les nouvelles lignes au fil de l’eau.\n\n```bash\ncurl -N \"https://api.host.hgdc.ch/v3/deployments/jd7f2k9m3x8q1p5s6t4v0w7y2z/events?follow=1\" \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\n| Paramètre | Valeur | Rôle                                                                        |\n| --------- | ------ | --------------------------------------------------------------------------- |\n| `follow`  | `1`    | Garde la connexion ouverte jusqu’à la fin du déploiement, 9 minutes au plus |\n\nLe type de réponse est `application/x-ndjson`. Chaque ligne de log ressemble à ceci :\n\n```json\n{\"type\":\"stdout\",\"created\":1760259601000,\"date\":1760259601000,\"deploymentId\":\"jd7f2k9m3x8q1p5s6t4v0w7y2z\",\"id\":\"l3k…\",\"text\":\"Publication de 42 fichiers\",\"payload\":{\"id\":\"l3k…\",\"text\":\"Publication de 42 fichiers\",\"date\":1760259601000,\"deploymentId\":\"jd7f2k9m3x8q1p5s6t4v0w7y2z\"}}\n```\n\n| Champ     | Type                     | Description                                                        |\n| --------- | ------------------------ | ------------------------------------------------------------------ |\n| `type`    | `\"stdout\"` ou `\"stderr\"` | `stderr` pour une ligne d’erreur                                   |\n| `text`    | `string`                 | Texte de la ligne                                                  |\n| `date`    | `number`                 | Date de la ligne, en millisecondes. `created` porte la même valeur |\n| `payload` | `object`                 | Les mêmes champs, au format historique de la CLI                   |\n\nUne fois le déploiement terminé, une dernière ligne donne son état, puis le flux se ferme :\n\n```json\n{\"type\":\"state\",\"event\":\"state\",\"date\":1760259604000,\"payload\":{\"value\":\"READY\"}}\n```\n\nLes lignes du build GitHub Actions ne sont pas renvoyées ici : elles sont dans le run GitHub, et la console les affiche sur la page du déploiement.\n\nLe même endpoint répond aussi sous `/v3/now/deployments/:id/events`.\n\n| Erreur | Code        | Cause                                               |\n| ------ | ----------- | --------------------------------------------------- |\n| `404`  | `not_found` | Déploiement inconnu, ou hors de la portée de la clé |"},{"path":"/docs/reference/api/erreurs/","title":"Erreurs de l'API","description":"Format des erreurs de l'API Host, liste des codes, leur cause et la conduite à tenir.","version":null,"markdown":"Une erreur répond avec un statut HTTP `4xx` ou `5xx`, et un objet `error`. Le champ `code` est stable : teste-le dans ton code. Le champ `message` est en français et s’affiche à une personne.\n\n```json\n{\n  \"error\": {\n    \"code\": \"not_found\",\n    \"message\": \"Projet introuvable.\"\n  }\n}\n```\n\n## Codes\n\n| Statut | Code                    | Cause                                                                                                    | Que faire                                                                               |\n| ------ | ----------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `400`  | `bad_request`           | Corps ou paramètre invalide. Le message nomme le champ en cause                                          | Corrige la requête                                                                      |\n| `400`  | `missing_files`         | Des fichiers du déploiement ne sont pas encore envoyés. La réponse liste leurs empreintes dans `missing` | Envoie-les par [`/v2/files`](/docs/reference/api/fichiers/), puis recrée le déploiement |\n| `400`  | `invalid_digest`        | Le contenu envoyé ne correspond pas à l’empreinte annoncée                                               | Recalcule le SHA1 du fichier                                                            |\n| `403`  | `forbidden`             | Clé absente, inconnue ou révoquée. Ou clé de projet utilisée pour un autre projet                        | Vérifie la clé et sa portée                                                             |\n| `404`  | `not_found`             | Ressource introuvable, ou hors de la portée de la clé                                                    | Vérifie l’identifiant ou le nom                                                         |\n| `409`  | `conflict`              | Un projet porte déjà ce nom                                                                              | Choisis un autre nom, ou utilise le projet existant                                     |\n| `409`  | `deployment_closed`     | Le déploiement a été annulé ou a échoué : rien n’est publié                                              | Crée un nouveau déploiement                                                             |\n| `413`  | `file_too_large`        | Un fichier dépasse 20 Mo                                                                                 | Allège le fichier, ou sers-le autrement                                                 |\n| `413`  | `payload_too_large`     | Les fichiers inclus dans le corps dépassent 20 Mo au total                                               | Envoie-les par [`/v2/files`](/docs/reference/api/fichiers/)                             |\n| `429`  | `rate_limited`          | Trop de requêtes pour cette clé                                                                          | Attends un instant, puis réessaie                                                       |\n| `500`  | `internal_server_error` | Erreur de la plateforme. Elle est signalée automatiquement                                               | Réessaie. Si elle persiste, écris à <support@hgdc.ch>                                   |\n\nToutes les routes peuvent répondre `403 forbidden`, `429 rate_limited` et `500 internal_server_error`.\n\nLe message d’une erreur `500` ne donne jamais de détail technique. Ne compte pas sur son texte, seulement sur son code.\n\n## Le cas de missing_files\n\n`missing_files` n’est pas une panne : c’est l’étape normale d’un déploiement. La CLI la traite toute seule. Si tu écris ton propre client, voici la réponse :\n\n```json\n{\n  \"error\": {\n    \"code\": \"missing_files\",\n    \"message\": \"Fichiers à envoyer avant de créer le déploiement.\",\n    \"missing\": [\n      \"2ef7bde608ce5404e97d5f042f95f89f1c232871\"\n    ]\n  }\n}\n```\n\nEnvoie chaque fichier listé, puis renvoie exactement la même requête de [création de déploiement](/docs/reference/api/deploiements/)."},{"path":"/docs/reference/api/fichiers/","title":"Envoyer un fichier","description":"Envoyer le contenu d'un fichier à Host, adressé par son empreinte SHA1, avant de créer un déploiement.","version":null,"markdown":"Un fichier s’envoie par son empreinte SHA1. Host ne stocke jamais deux fois le même contenu pour une organisation : tu n’envoies que les fichiers que [Créer un déploiement](/docs/reference/api/deploiements/) signale comme manquants.\n\n## POST `/v2/files`\n\n```bash\nSHA=$(sha1sum index.html | cut -d' ' -f1)\ncurl -X POST https://api.host.hgdc.ch/v2/files \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\" \\\n  -H \"x-vercel-digest: $SHA\" \\\n  -H \"Content-Type: application/octet-stream\" \\\n  --data-binary @index.html\n```\n\nEn Node.js, calcule l’empreinte avant l’envoi :\n\n```javascript\nimport { createHash } from \"node:crypto\"\nimport { readFile } from \"node:fs/promises\"\n\nconst bytes = await readFile(\"index.html\")\nconst sha = createHash(\"sha1\").update(bytes).digest(\"hex\")\n\nawait fetch(\"https://api.host.hgdc.ch/v2/files\", {\n  method: \"POST\",\n  headers: {\n    Authorization: `Bearer ${process.env.VERCEL_TOKEN}`,\n    \"x-vercel-digest\": sha,\n    \"Content-Type\": \"application/octet-stream\",\n  },\n  body: bytes,\n})\n```\n\n### En-têtes\n\n| En-tête           | Valeur                                                   | Requis                                |\n| ----------------- | -------------------------------------------------------- | ------------------------------------- |\n| `Authorization`   | `Bearer ah_…`                                            | Oui                                   |\n| `x-vercel-digest` | Empreinte SHA1 du contenu, en hexadécimal, 40 caractères | Oui. `x-now-digest` est aussi accepté |\n| `Content-Type`    | `application/octet-stream`                               | Recommandé                            |\n\n### Corps\n\nLe contenu brut du fichier, 20 Mo au plus.\n\n### Réponse\n\nRéponse `200` avec un objet vide, `{}`.\n\n### Erreurs\n\n| Statut | Code             | Cause                                                                  |\n| ------ | ---------------- | ---------------------------------------------------------------------- |\n| `400`  | `bad_request`    | En-tête `x-vercel-digest` absent ou mal formé                          |\n| `400`  | `invalid_digest` | Le contenu ne correspond pas à l’empreinte annoncée. Recalcule le SHA1 |\n| `413`  | `file_too_large` | Le fichier dépasse 20 Mo                                               |\n\n## Limites\n\nL’envoi de fichiers a son propre débit : 6 000 par minute, avec des rafales de 3 000 par clé. Un site Next.js compte souvent des milliers de fichiers : envoie-les en parallèle, mais sans dépasser ce débit. Voir [Limites](/docs/reference/limites/)."},{"path":"/docs/reference/api/introduction/","title":"Introduction à l'API","description":"Adresse de base, authentification par clé, portée des clés, versions des chemins et limites de débit de l'API Host.","version":null,"markdown":"L’API de Host reprend le sous-ensemble de l’API Vercel qu’utilise la CLI pour relier un dossier, construire et déployer. Elle accepte du JSON, renvoie du JSON, et s’authentifie par une clé d’API.\n\nUtilise l’API si tu écris ton propre outil. Pour déployer depuis un poste ou une CI, la [CLI](/docs/reference/cli/) suffit.\n\n## Adresse de base\n\n```text\nhttps://api.host.hgdc.ch\n```\n\nToutes les requêtes passent en HTTPS.\n\n## Authentification\n\nEnvoie ta clé dans l’en-tête `Authorization`. Les clés commencent par `ah_` et se créent dans l’onglet **Clés d’API** de l’organisation. Voir [Créer et révoquer une clé d’API](/docs/guides/cle-d-api/).\n\n```http\nAuthorization: Bearer ah_…\n```\n\n```bash\ncurl https://api.host.hgdc.ch/v2/user \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nIl existe deux sortes de clés :\n\n| Clé                                                       | Portée                                                           | Variables sensibles      |\n| --------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------ |\n| Clé d’organisation, créée par un admin ou un propriétaire | Tous les projets de l’organisation, création de projets comprise | Jamais renvoyées         |\n| Clé de projet, posée par l’app GitHub dans le dépôt       | Ce seul projet. Tout autre projet répond `404`                   | Renvoyées, pour le build |\n\n> **Attention**\n>\n> Une clé donne accès aux variables d’environnement de tes projets. Garde-la dans un gestionnaire de secrets, jamais dans le code ni dans le navigateur.\n\n## L’organisation vient de la clé\n\nChaque clé appartient à une organisation, et chaque requête s’exécute dans cette organisation. Un identifiant d’organisation dans l’URL, ou un paramètre `teamId` ou `slug`, que la CLI ajoute parfois, est ignoré.\n\n## Versions dans le chemin\n\nLes chemins gardent les numéros de version de l’API Vercel, comme `/v2`, `/v9` ou `/v13`, pour que la CLI fonctionne sans modification. Plusieurs versions d’un même endpoint renvoient la même réponse : `/v9/projects` et `/v10/projects` par exemple.\n\n## Pagination\n\nLes listes ne sont pas paginées. Elles renvoient un objet `pagination` pour la compatibilité, avec `next` toujours à `null`.\n\n## Limites de débit\n\nChaque clé dispose de 600 requêtes par minute, avec des rafales de 120. L’envoi de fichiers a son propre budget : 6 000 par minute, avec des rafales de 3 000.\n\nAu-delà, l’API répond `429` avec le code `rate_limited` :\n\n```json\n{\n  \"error\": {\n    \"code\": \"rate_limited\",\n    \"message\": \"Trop de requêtes, réessaie dans un instant.\"\n  }\n}\n```\n\nLa réponse porte un en-tête `retry-after` quand l’attente est connue. La création de déploiements est aussi limitée par organisation : voir [Limites](/docs/reference/limites/).\n\n## Endpoints\n\n| Méthode | Chemin                                                            | Rôle                                  |\n| ------- | ----------------------------------------------------------------- | ------------------------------------- |\n| `GET`   | [`/v2/user`](/docs/reference/api/utilisateur/)                    | Personne qui a créé la clé            |\n| `GET`   | [`/v2/teams`](/docs/reference/api/utilisateur/)                   | Organisation de la clé                |\n| `GET`   | [`/v2/teams/:idOrSlug`](/docs/reference/api/utilisateur/)         | Lire l’organisation                   |\n| `GET`   | [`/v9/projects`](/docs/reference/api/projets/)                    | Lister les projets                    |\n| `GET`   | [`/v9/projects/:idOrName`](/docs/reference/api/projets/)          | Lire un projet                        |\n| `POST`  | [`/v11/projects`](/docs/reference/api/projets/)                   | Créer un projet                       |\n| `POST`  | [`/v2/files`](/docs/reference/api/fichiers/)                      | Envoyer un fichier                    |\n| `POST`  | [`/v13/deployments`](/docs/reference/api/deploiements/)           | Créer un déploiement                  |\n| `GET`   | [`/v13/deployments/:id`](/docs/reference/api/deploiements/)       | Lire un déploiement                   |\n| `GET`   | [`/v3/deployments/:id/events`](/docs/reference/api/deploiements/) | Suivre les logs                       |\n| `GET`   | [`/v3/env/pull/:project/:target`](/docs/reference/api/variables/) | Lire les variables d’un environnement |\n\nLes erreurs et leurs codes sont sur [Erreurs](/docs/reference/api/erreurs/)."},{"path":"/docs/reference/api/projets/","title":"Projets","description":"Lister, lire et créer des projets avec l'API Host. Champs de l'objet projet et erreurs.","version":null,"markdown":"Un projet correspond à un site. Il a ses variables, ses domaines et son historique de déploiements.\n\n## GET `/v9/projects`\n\nListe les projets de l’organisation. Avec une clé de projet, la liste ne contient que ce projet. La liste compte 100 projets au plus.\n\n```bash\ncurl https://api.host.hgdc.ch/v9/projects \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nRéponse `200` :\n\n```json\n{\n  \"projects\": [\n    {\n      \"id\": \"j97d3k2m8x1q4p6s7t9v0w2y5z\",\n      \"name\": \"site-atelier\",\n      \"accountId\": \"k57a1b2c3d4e5f6g7h8j9k0m1n\",\n      \"framework\": \"astro\",\n      \"rootDirectory\": null,\n      \"buildCommand\": null,\n      \"installCommand\": null,\n      \"outputDirectory\": null,\n      \"nodeVersion\": \"24.x\",\n      \"createdAt\": 1760259600000,\n      \"updatedAt\": 1760259600000\n    }\n  ],\n  \"pagination\": { \"count\": 1, \"next\": null, \"prev\": null }\n}\n```\n\nLe même endpoint répond aussi sous `/v10/projects`.\n\n## GET `/v9/projects/:idOrName`\n\nLit un projet, par son identifiant ou son nom, sans tenir compte de la casse.\n\n```bash\ncurl https://api.host.hgdc.ch/v9/projects/site-atelier \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nRéponse `200` : l’objet projet, décrit ci-dessous. Les routes `/v9` et `/v10` renvoient la même réponse.\n\n| Erreur | Code        | Cause                                                                             |\n| ------ | ----------- | --------------------------------------------------------------------------------- |\n| `404`  | `not_found` | Aucun projet de ce nom dans l’organisation, ou projet hors de la portée de la clé |\n\n## POST `/v11/projects`\n\nCrée un projet. Tu peux aussi t’en passer : le premier déploiement sur un nom inconnu crée le projet.\n\n```bash\ncurl -X POST https://api.host.hgdc.ch/v11/projects \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"name\":\"site-atelier\",\"framework\":\"astro\"}'\n```\n\n| Champ       | Type               | Requis | Description                                                                                                                                        |\n| ----------- | ------------------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `name`      | `string`           | Oui    | Nom du projet, 100 caractères au plus. Il devient le nom dans l’URL, en minuscules                                                                 |\n| `framework` | `string` ou `null` | Non    | `nextjs`, `astro`, `vite`, `sveltekit`, `nuxt`, `tanstack-start` ou `react-router`. Une autre valeur, ou `null`, enregistre un site sans framework |\n\nRéponse `200` : l’objet projet créé.\n\n| Erreur | Code          | Cause                                              |\n| ------ | ------------- | -------------------------------------------------- |\n| `400`  | `bad_request` | Nom absent ou trop long                            |\n| `403`  | `forbidden`   | La clé est limitée à un projet : elle ne crée rien |\n| `409`  | `conflict`    | Un projet porte déjà ce nom                        |\n\n## L’objet projet\n\n| Champ                | Type                 | Description                                                                                                                                                                                                                                                            |\n| -------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `id`                 | `string`             | Identifiant du projet. C’est la valeur de `VERCEL_PROJECT_ID`                                                                                                                                                                                                          |\n| `name`               | `string`             | Nom du projet, dans l’URL de la console                                                                                                                                                                                                                                |\n| `accountId`          | `string`             | Identifiant de l’organisation propriétaire                                                                                                                                                                                                                             |\n| `framework`          | `string` ou `null`   | Framework enregistré, ou `null` pour un site sans framework                                                                                                                                                                                                            |\n| `rootDirectory`      | `string` ou `null`   | Dossier de l’app dans le dépôt, pour un monorepo                                                                                                                                                                                                                       |\n| `buildCommand`       | `string` ou `null`   | Commande de build imposée. `null` : celle détectée par `vercel build`                                                                                                                                                                                                  |\n| `installCommand`     | `string` ou `null`   | Commande d’installation imposée                                                                                                                                                                                                                                        |\n| `outputDirectory`    | `string` ou `null`   | Dossier de sortie imposé                                                                                                                                                                                                                                               |\n| `nodeVersion`        | `\"22.x\"` ou `\"24.x\"` | Version de Node.js du build                                                                                                                                                                                                                                            |\n| `createdAt`          | `number`             | Date de création, en millisecondes depuis l’époque Unix                                                                                                                                                                                                                |\n| `updatedAt`          | `number`             | Même valeur que `createdAt`                                                                                                                                                                                                                                            |\n| `link`               | `object`             | Présent seulement pour un projet relié à GitHub : `type` (`github`), `repo` (`propriétaire/dépôt`) et `productionBranch`                                                                                                                                               |\n| `alias`              | `object[]`           | Adresse de production du projet : `domain` (`<projet>.hgdc.cloud`), `target` (`PRODUCTION`), `environment` (`production`), `createdAt`, `deployment` (`null`). Les domaines personnalisés n’y figurent pas                                                             |\n| `targets.production` | `object`             | Présent une fois une production en ligne : le déploiement servi, avec `id`, `url`, `alias` (`[\"<projet>.hgdc.cloud\"]`), `aliasAssigned` (moment de la mise en ligne), `readyState`, `createdAt`, `readyAt` et `meta`. `targets` vaut `{}` avant la première production |\n\nPour un projet dont le framework n’est pas reconnu, `framework` vaut `null`.\n\n## Voir aussi\n\n- [Déploiements](/docs/reference/api/deploiements/) : créer un déploiement pour ce projet.\n- [Erreurs](/docs/reference/api/erreurs/) : la liste des codes."},{"path":"/docs/reference/api/utilisateur/","title":"Lire le propriétaire de la clé et l'organisation","description":"Renvoie la personne qui a créé la clé, puis l'organisation de la clé. Les routes utilisées par la CLI pour se connecter.","version":null,"markdown":"Ces trois endpoints disent qui utilise la clé, et dans quelle organisation elle travaille. La CLI les appelle au premier contact.\n\n## GET `/v2/user`\n\nRenvoie la personne qui a créé la clé.\n\n```bash\ncurl https://api.host.hgdc.ch/v2/user \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nRéponse `200` :\n\n```json\n{\n  \"user\": {\n    \"id\": \"u1a2b3c4d5\",\n    \"uid\": \"u1a2b3c4d5\",\n    \"email\": \"camille@atelier.ch\",\n    \"name\": \"Camille Rochat\",\n    \"username\": \"atelier\",\n    \"defaultTeamId\": \"k57a1b2c3d4e5f6g7h8j9k0m1n\",\n    \"version\": \"northstar\"\n  }\n}\n```\n\n| Champ                | Type     | Description                                                                 |\n| -------------------- | -------- | --------------------------------------------------------------------------- |\n| `user.id`            | `string` | Identifiant de la personne. `uid` porte la même valeur                      |\n| `user.email`         | `string` | Adresse e-mail de la personne, tant qu’elle est membre de l’organisation    |\n| `user.name`          | `string` | Nom affiché de la personne. À défaut, l’adresse e-mail                      |\n| `user.username`      | `string` | Slug de l’organisation de la clé                                            |\n| `user.defaultTeamId` | `string` | Identifiant de l’organisation de la clé. C’est la valeur de `VERCEL_ORG_ID` |\n| `user.version`       | `string` | Valeur fixe : `northstar`                                                   |\n\nErreurs : `403 forbidden` si l’organisation de la clé n’existe plus.\n\n## GET `/v2/teams`\n\nRenvoie l’organisation de la clé. La liste ne contient jamais qu’une seule organisation : une clé n’ouvre qu’une organisation.\n\n```bash\ncurl https://api.host.hgdc.ch/v2/teams \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nRéponse `200` :\n\n```json\n{\n  \"teams\": [\n    {\n      \"id\": \"k57a1b2c3d4e5f6g7h8j9k0m1n\",\n      \"slug\": \"atelier\",\n      \"name\": \"Atelier Rochat\",\n      \"avatar\": null,\n      \"membership\": { \"role\": \"OWNER\" }\n    }\n  ],\n  \"pagination\": { \"count\": 1, \"next\": null, \"prev\": null }\n}\n```\n\n> **Note**\n>\n> `membership.role` vaut toujours `OWNER` pour la CLI, quel que soit le rôle réel de la personne. Les vrais rôles se gèrent dans Account, voir [Organisations et rôles](/docs/concepts/organisations-et-roles/).\n\n## GET `/v2/teams/:idOrSlug`\n\nRenvoie l’organisation seule, sans liste. Le paramètre est l’identifiant ou le slug de l’organisation de la clé.\n\n```bash\ncurl https://api.host.hgdc.ch/v2/teams/atelier \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\nToute autre organisation répond `404 not_found`. Les deux routes répondent aussi sous `/v1`.\n\n## Erreurs\n\n| Statut | Code        | Cause                                                                          |\n| ------ | ----------- | ------------------------------------------------------------------------------ |\n| `403`  | `forbidden` | Pour `/v2/user` : l’organisation de la clé n’existe plus                       |\n| `404`  | `not_found` | Pour `/v2/teams/:idOrSlug` : l’organisation demandée n’est pas celle de la clé |\n\nVoir la liste complète sur [Erreurs](/docs/reference/api/erreurs/)."},{"path":"/docs/reference/api/variables/","title":"Lire les variables d'un environnement","description":"Renvoie les variables d'un environnement au format de vercel pull, avec les règles de visibilité des variables sensibles.","version":null,"markdown":"Cet endpoint renvoie les variables d’un environnement, au format attendu par `vercel pull` et `vercel build`. Les valeurs sont renvoyées déchiffrées : elles ne doivent jamais partir vers le navigateur.\n\n## GET `/v3/env/pull/:project/:target`\n\n```bash\ncurl https://api.host.hgdc.ch/v3/env/pull/site-atelier/production \\\n  -H \"Authorization: Bearer $VERCEL_TOKEN\"\n```\n\n```bash\n# Équivalent avec la CLI\nvercel --api https://api.host.hgdc.ch pull --environment=production\n```\n\n### Paramètres de chemin\n\n| Paramètre | Type                                           | Requis | Description                               |\n| --------- | ---------------------------------------------- | ------ | ----------------------------------------- |\n| `project` | `string`                                       | Oui    | Identifiant ou nom du projet              |\n| `target`  | `\"production\"`, `\"preview\"` ou `\"development\"` | Non    | Environnement. Par défaut : `development` |\n\n### Réponse\n\nRéponse `200` :\n\n```json\n{\n  \"env\": {\n    \"PUBLIC_API_URL\": \"https://api.atelier.ch\",\n    \"CONTACT_EMAIL\": \"bonjour@atelier.ch\"\n  },\n  \"buildEnv\": {\n    \"PUBLIC_API_URL\": \"https://api.atelier.ch\",\n    \"CONTACT_EMAIL\": \"bonjour@atelier.ch\"\n  }\n}\n```\n\n`env` et `buildEnv` contiennent les mêmes variables. Si le projet a un domaine de production, `VERCEL_PROJECT_PRODUCTION_URL` figure aussi dans la réponse. Voir [Variables : référence](/docs/reference/variables/#variables-fournies-par-la-plateforme).\n\nLa réponse n’est jamais mise en cache : elle porte `cache-control: no-store`.\n\n## Variables sensibles\n\nUne variable sensible n’est renvoyée qu’à une clé limitée au projet, celle que l’app GitHub pose dans le dépôt. Avec une clé d’organisation, elle est absente de la réponse.\n\nChaque lecture d’une variable par une clé est consignée dans le journal du coffre, sans la valeur. Voir [Secrets et coffre](/docs/concepts/secrets-et-coffre/).\n\n## Erreurs\n\n| Statut | Code          | Cause                                          |\n| ------ | ------------- | ---------------------------------------------- |\n| `400`  | `bad_request` | Environnement inconnu                          |\n| `404`  | `not_found`   | Projet inconnu, ou hors de la portée de la clé |\n\nVoir la liste complète sur [Erreurs](/docs/reference/api/erreurs/)."},{"path":"/docs/reference/cli/","title":"CLI","description":"Référence des commandes de la CLI Vercel prises en charge par Host, avec leurs options et leurs exemples.","version":null,"markdown":"Host accepte la CLI Vercel officielle, version 63. Cette page décrit les commandes prises en charge, leurs options et ce qui n’est pas encore pris en charge.\n\n## Configurer la CLI\n\nHost n’utilise pas la connexion par navigateur de la CLI. Chaque commande reçoit l’adresse de l’API par `--api` et la clé par la variable `VERCEL_TOKEN`.\n\n```bash\nnpm install --global vercel@63\nexport VERCEL_TOKEN=ah_…\nvercel --api https://api.host.hgdc.ch deploy\n```\n\nPour ne pas retaper l’adresse, crée un alias dans ton profil de shell :\n\n```bash\n# ~/.bashrc ou ~/.zshrc\nalias vh=\"vercel --api https://api.host.hgdc.ch\"\n\n# Ensuite\nvh deploy --prod\n```\n\nEn PowerShell, dans `$PROFILE` :\n\n```powershell\nfunction vh { vercel --api https://api.host.hgdc.ch @args }\n```\n\n> **Attention**\n>\n> Sans `--api`, la CLI parle à Vercel. Si une commande te demande de te connecter dans le navigateur, vérifie que l’option est bien présente.\n\n### Options globales\n\n| Option    | Valeur | Rôle                                                                                         |\n| --------- | ------ | -------------------------------------------------------------------------------------------- |\n| `--api`   | URL    | Adresse de l’API : `https://api.host.hgdc.ch`                                                |\n| `--token` | `ah_…` | Clé d’API. Préfère la variable `VERCEL_TOKEN`, qui n’apparaît pas dans l’historique du shell |\n\n### Ce qui n’est pas pris en charge\n\n| Commande ou option  | État                                                                                         |\n| ------------------- | -------------------------------------------------------------------------------------------- |\n| `vercel login`      | Non : la connexion passe par la clé                                                          |\n| `vercel env`        | Pas encore : gère les variables dans la console                                              |\n| `vercel domains`    | Pas encore : gère les domaines dans la console                                               |\n| `vercel logs`       | Pas encore : les logs sont dans la console                                                   |\n| `vercel alias`      | Pas encore : utilise la console, voir [Revenir en arrière](/docs/guides/revenir-en-arriere/) |\n| `--scope`, `--team` | Ignorés : l’organisation vient de la clé                                                     |\n\n## vercel deploy\n\nEnvoie un dossier, ou un build déjà construit, et crée un déploiement. Sans option, la commande crée une preview. Avec `--prod`, elle part en production.\n\n```bash\n# Preview du dossier courant\nvercel --api https://api.host.hgdc.ch deploy\n\n# Production\nvercel --api https://api.host.hgdc.ch deploy --prod\n```\n\nDans un script, l’adresse du déploiement est écrite seule sur la sortie standard :\n\n```bash\nURL=$(vercel --api https://api.host.hgdc.ch deploy --yes)\necho \"Preview : $URL\"\n```\n\n| Option                | Rôle                                                                                        |\n| --------------------- | ------------------------------------------------------------------------------------------- |\n| `--prod`              | Déploie en production                                                                       |\n| `--prebuilt`          | Envoie `.vercel/output`, produit par `vercel build`, sans reconstruire                      |\n| `--yes`               | Répond oui à toutes les questions : relie le dossier et crée le projet. Indispensable en CI |\n| `--cwd <chemin>`      | Dossier à déployer, s’il n’est pas le dossier courant                                       |\n| `--meta <clé=valeur>` | Métadonnée attachée au déploiement                                                          |\n\nLa commande affiche l’adresse du déploiement, suit la publication, puis rend la main quand le déploiement est prêt ou en erreur. Le suivi dure 9 minutes au plus.\n\nPour un framework, construis d’abord avec `vercel build`, puis envoie le résultat avec `--prebuilt`. Utilise la même cible des deux côtés : `build --prod` avec `deploy --prebuilt --prod`, ou aucune des deux pour une preview. Sinon, la CLI refuse l’envoi.\n\n## vercel build\n\nConstruit le projet en local ou en CI, au format Build Output API. Le résultat va dans `.vercel/output`, prêt pour `vercel deploy --prebuilt`.\n\n```bash\n# Build de preview\nvercel --api https://api.host.hgdc.ch build\n\n# Build de production\nvercel --api https://api.host.hgdc.ch build --prod\n```\n\nAvant de construire, la commande télécharge les variables de l’environnement visé : preview par défaut, production avec `--prod`. Une variable sensible n’est pas téléchargée depuis un poste, seulement depuis le build du dépôt GitHub.\n\n| Option           | Rôle                                                                      |\n| ---------------- | ------------------------------------------------------------------------- |\n| `--prod`         | Construit pour la production, avec les variables de production            |\n| `--yes`          | Télécharge les réglages du projet sans rien demander. Indispensable en CI |\n| `--cwd <chemin>` | Dossier du projet, s’il n’est pas le dossier courant                      |\n\n## vercel pull\n\nTélécharge les réglages du projet et les variables d’un environnement. `vercel build` s’en sert ensuite.\n\n```bash\n# Variables de développement, par défaut\nvercel --api https://api.host.hgdc.ch pull\n\n# Variables de preview ou de production\nvercel --api https://api.host.hgdc.ch pull --environment=preview\nvercel --api https://api.host.hgdc.ch pull --environment=production\n```\n\nLes variables sont écrites dans `.vercel/.env.<environnement>.local`. La CLI ajoute ce dossier au `.gitignore` : ne le commite pas.\n\n| Option           | Valeur                                   | Rôle                                                 |\n| ---------------- | ---------------------------------------- | ---------------------------------------------------- |\n| `--environment`  | `development`, `preview` ou `production` | Environnement à lire. Par défaut : `development`     |\n| `--yes`          |                                          | Relie le dossier sans rien demander                  |\n| `--cwd <chemin>` |                                          | Dossier du projet, s’il n’est pas le dossier courant |\n\nCe que reçoit la commande dépend de la clé :\n\n| Clé                                   | Variables normales | Variables sensibles |\n| ------------------------------------- | ------------------ | ------------------- |\n| Clé d’organisation                    | Oui                | Non                 |\n| Clé de projet, posée par l’app GitHub | Oui                | Oui                 |\n\n## vercel link\n\nRelie un dossier local à un projet. Les autres commandes savent ensuite à quel projet s’adresser.\n\n```bash\nvercel --api https://api.host.hgdc.ch link\n\n# Sans question, avec le nom du dossier\nvercel --api https://api.host.hgdc.ch link --yes\n```\n\nLa liaison est écrite dans `.vercel/project.json`, qui contient `orgId` et `projectId`. Le premier `link` ou `deploy` sur un nom inconnu crée le projet, sous le nom du dossier.\n\n| Option            | Rôle                                                                     |\n| ----------------- | ------------------------------------------------------------------------ |\n| `--yes`           | Relie le dossier sans rien demander, et crée le projet s’il n’existe pas |\n| `--project <nom>` | Nom du projet à relier, s’il n’est pas celui du dossier                  |\n| `--cwd <chemin>`  | Dossier à relier, s’il n’est pas le dossier courant                      |\n\nEn CI, sans dossier `.vercel`, donne les deux identifiants par variables d’environnement, avec la clé :\n\n```bash\nexport VERCEL_ORG_ID=…\nexport VERCEL_PROJECT_ID=…\nexport VERCEL_TOKEN=ah_…\nvercel --api https://api.host.hgdc.ch deploy --prod --yes\n```\n\n`VERCEL_ORG_ID` est la valeur renvoyée par [GET /v2/user](/docs/reference/api/utilisateur/). Le workflow posé par l’app GitHub contient déjà les bonnes valeurs.\n\nPour délier un dossier, supprime son dossier `.vercel`. Le prochain déploiement te redemandera le projet.\n\n## Voir aussi\n\n- [Référence de l’API](/docs/reference/api/introduction/) : les mêmes opérations, sans la CLI.\n- [Compatibilité](/docs/reference/compatibilite/) : la liste des fonctions de la CLI et de la plateforme."},{"path":"/docs/reference/compatibilite/","title":"Compatibilité avec Vercel","description":"Ce que la CLI et la plateforme prennent en charge aujourd'hui, ce qui est en préversion et ce qui n'existe pas encore.","version":null,"markdown":"Host implémente la partie de l’API Vercel qu’utilise la CLI pour relier un projet, récupérer ses variables, construire et déployer. La CLI officielle, version 63, est la référence de test.\n\nCette page dit ce qui marche aujourd’hui. Elle distingue trois états :\n\n- **Pris en charge** : utilisable en production.\n- **En préversion** : utilisable, mais ouvert organisation par organisation. Une organisation qui n’en profite pas encore reçoit une réponse `501`.\n- **Pas encore** : absent de Host pour le moment.\n\n## Commandes de la CLI\n\n| Commande                                       | État                                                                  |\n| ---------------------------------------------- | --------------------------------------------------------------------- |\n| `vercel deploy`, avec `--prod` et `--prebuilt` | Pris en charge                                                        |\n| `vercel build`                                 | Pris en charge : télécharge les variables de l’environnement visé     |\n| `vercel pull`                                  | Pris en charge : réglages et variables                                |\n| `vercel link`                                  | Pris en charge                                                        |\n| `vercel login`                                 | Non : la connexion passe par la clé, dans `VERCEL_TOKEN` ou `--token` |\n| `vercel env`                                   | Pas encore : gère les variables dans la console                       |\n| `vercel domains`                               | Pas encore : gère les domaines dans la console                        |\n| `vercel logs`                                  | Pas encore : les logs sont dans la console                            |\n| `vercel env add`                               | Pas encore : ajoute les variables dans la console                     |\n\n## Fonctions de la plateforme\n\n| Fonction                                               | État                                                                   |\n| ------------------------------------------------------ | ---------------------------------------------------------------------- |\n| Fichiers statiques, Build Output API v3                | Pris en charge                                                         |\n| Routage de `vercel.json` et de `config.json`           | Pris en charge, voir [vercel.json](/docs/reference/vercel-json/)       |\n| Pages pré-rendues de Next.js                           | Prises en charge                                                       |\n| Draft mode                                             | Pris en charge                                                         |\n| Domaines, redirections, certificats                    | Pris en charge                                                         |\n| Réécritures vers une URL externe                       | Prises en charge                                                       |\n| Variables d’environnement, variables sensibles         | Prises en charge                                                       |\n| Rendu à la demande (SSR), routes d’API, Server Actions | En préversion : fonctions Node, ouvertes organisation par organisation |\n| Proxy (ex-middleware) et middleware Node.js            | En préversion                                                          |\n| Fonctions et middleware en runtime edge                | En préversion                                                          |\n| ISR (régénération incrémentale)                        | En préversion : cache par serveur, vidé à son redémarrage              |\n| Optimisation d’images                                  | Pas encore : l’image d’origine est servie, sans redimensionnement      |\n| Crons                                                  | En préversion : production seulement, avec `CRON_SECRET`               |\n\nLe détail du fonctionnement de la préversion est dans [Préversion et rendu à la demande](/docs/concepts/preversion/).\n\n## Frameworks\n\n| Framework                     | Ce qui est servi                                                                                                                                  | Commande de build        |\n| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------ |\n| Site statique (HTML, CSS, JS) | Le dossier tel quel                                                                                                                               | Aucune : `vercel deploy` |\n| Astro                         | Les pages générées, et en préversion le rendu à la demande, les routes d’API, le middleware et l’ISR                                              | `vercel build`           |\n| Vite (React, Vue, Svelte…)    | Le build de l’application                                                                                                                         | `vercel build`           |\n| SvelteKit                     | Les pages pré-rendues, et en préversion le rendu à la demande, les routes d’API, les actions de formulaire et l’ISR                               | `vercel build`           |\n| Nuxt                          | Les pages générées, et en préversion le rendu à la demande, les routes d’API, le middleware serveur et l’ISR                                      | `vercel build`           |\n| TanStack Start                | Les pages pré-rendues                                                                                                                             | `vercel build`           |\n| React Router                  | Les pages pré-rendues                                                                                                                             | `vercel build`           |\n| Next.js                       | Les pages pré-rendues et leur navigation, et en préversion le rendu à la demande, les routes d’API, le proxy, l’ISR et les routes en runtime edge | `vercel build`           |\n| Documentation `@hgdc/docs`    | Le site de documentation, chaque page en Markdown (`.md`), `llms.txt` et le corpus de l’assistant                                                 | `hgdc-docs build`        |\n\nPour tout framework, la séquence est la même : construis, puis envoie le résultat avec `--prebuilt`. Voir [Déployer un framework](/docs/guides/deployer-un-framework/).\n\n## Ce que cette page ne couvre pas\n\n- Ce qui n’est pas listé ici n’est pas garanti. Ne suppose pas qu’une fonctionnalité de Vercel marche sur Host sans l’avoir testée.\n- Les limites chiffrées, comme la taille des fichiers ou les débits, sont sur [Limites](/docs/reference/limites/)."},{"path":"/docs/reference/domaines/","title":"Domaines","description":"Enregistrements DNS, statuts, usages, codes de redirection et règles de propriété des domaines.","version":null,"markdown":"Cette page donne les valeurs exactes des enregistrements, les statuts et les règles de propriété. Pour brancher un domaine pas à pas, voir [Brancher un domaine](/docs/guides/brancher-un-domaine/).\n\n## Enregistrements DNS\n\nDeux enregistrements, chez ton hébergeur DNS : un TXT de preuve, et un trafic qui arrive sur Host.\n\n| Enregistrement | Nom                    | Valeur                                  | Quand                                         |\n| -------------- | ---------------------- | --------------------------------------- | --------------------------------------------- |\n| **TXT**        | `_agenthost.<domaine>` | Le jeton affiché dans la console        | Toujours : prouve que le domaine t’appartient |\n| **CNAME**      | `<sous-domaine>`       | La cible affichée dans la console       | Pour un sous-domaine, comme `www`             |\n| **A**          | `<domaine racine>`     | L’adresse IPv4 affichée dans la console | Pour un domaine racine, comme `exemple.ch`    |\n\nLe CNAME ne peut pas être posé sur la racine d’un domaine : le DNS l’interdit. Pour un domaine racine, utilise le A.\n\nLes valeurs peuvent changer. La console affiche toujours les valeurs à utiliser : suis-les plutôt qu’une valeur copiée d’une ancienne page.\n\n## Statuts\n\n| Statut                      | Signification                                     | Servi ? |\n| --------------------------- | ------------------------------------------------- | ------- |\n| **En attente des DNS**      | Le TXT ou le trafic manque                        | Non     |\n| **Vérifié**                 | Le TXT est là et le trafic arrive                 | Oui     |\n| **Ne pointe pas vers nous** | Le TXT est là, mais le trafic n’arrive pas à Host | Non     |\n\nUn domaine vérifié est revérifié chaque jour. Si le TXT disparaît, une seconde vérification a lieu une heure plus tard. Si elle échoue aussi, le domaine repasse en attente et n’est plus servi.\n\nLa vérification se relance toutes les 15 minutes tant que le domaine n’est pas vérifié. **Vérifier** la relance tout de suite.\n\n## Certificat HTTPS\n\nDès qu’un domaine est **Vérifié**, Host demande un certificat HTTPS. Le certificat affiche sa date d’échéance dans la console, et se renouvelle seul. Un certificat n’est émis que pour un domaine vérifié.\n\n## Usages\n\n| Usage       | Ce qui est servi                                                                  |\n| ----------- | --------------------------------------------------------------------------------- |\n| Production  | Le dernier déploiement de production prêt                                         |\n| Branche     | La dernière preview prête de la branche choisie, par exemple `staging.exemple.ch` |\n| Redirection | Un autre domaine du même projet, chemin conservé                                  |\n\nUne redirection vise un domaine du même projet qui sert un site. Une redirection ne peut pas pointer vers une autre redirection.\n\nPour un domaine racine, la case **Ajouter aussi [www](http://www).** crée `www` en redirection permanente vers le domaine racine.\n\n## Codes de redirection\n\n| Code  | Type                    | Méthode conservée |\n| ----- | ----------------------- | ----------------- |\n| `308` | Permanente (par défaut) | Oui               |\n| `301` | Permanente              | Non               |\n| `307` | Temporaire              | Oui               |\n| `302` | Temporaire              | Non               |\n\nPréfère `308` ou `307` : elles conservent la méthode et le corps de la requête.\n\n## Propriété\n\n- La preuve TXT l’emporte. Une revendication non prouvée par une autre organisation ne bloque pas le propriétaire réel : l’organisation qui pose le TXT obtient le domaine.\n- Deux TXT prouvés en même temps : le premier prouvé garde le domaine.\n- Les noms de la plateforme ne peuvent pas être ajoutés comme domaine client : Host répond « Ce domaine appartient à la plateforme. »\n\n## Limites\n\n| Limite                                    | Valeur                               |\n| ----------------------------------------- | ------------------------------------ |\n| Domaines par organisation                 | 50                                   |\n| Vérifications de domaine                  | 20 par minute, avec des rafales de 5 |\n| Revendications concurrentes d’un même nom | 10 au plus                           |\n\nVoir [Limites](/docs/reference/limites/).\n\n## Propagation DNS\n\nUn enregistrement neuf peut mettre de quelques minutes à quelques heures à apparaître. La vérification interroge des résolveurs DNS publics. Si aucun résolveur ne répond, le statut ne change pas."},{"path":"/docs/reference/limites/","title":"Limites","description":"Tailles, débits, quotas et durées de conservation de Host.","version":null,"markdown":"Ces limites protègent la plateforme et les autres organisations. Une requête qui dépasse une limite de débit reçoit `429` avec le code `rate_limited`. Attends quelques secondes, puis réessaie.\n\nBesoin d’une limite plus haute ? Écris à <support@hgdc.ch>.\n\n## Déploiements et fichiers\n\n| Limite                                                     | Valeur                                                       |\n| ---------------------------------------------------------- | ------------------------------------------------------------ |\n| Taille d’un fichier                                        | 20 Mo                                                        |\n| Fichiers inclus directement dans la requête de déploiement | 20 Mo au total. Au-delà, envoie les fichiers par `/v2/files` |\n| Fichiers par déploiement                                   | 15 000                                                       |\n| Déploiements par organisation                              | 60 par heure, avec des rafales de 10                         |\n| Suivi de la publication par la CLI                         | 9 minutes au plus par connexion                              |\n\n## Fonctions (préversion)\n\n| Limite                                   | Valeur                                                  |\n| ---------------------------------------- | ------------------------------------------------------- |\n| Mémoire par fonction                     | 512 Mo par défaut, 1 Go au plus                         |\n| Durée par requête                        | 30 secondes par défaut, 60 secondes au plus             |\n| Première requête après une période calme | Quelques secondes, le temps de démarrer l’environnement |\n\nLa durée peut être réglée par fonction avec `maxDuration`, dans la limite de 60 secondes. Voir [Préversion](/docs/concepts/preversion/).\n\n## API\n\n| Limite                          | Valeur                                      | Compté par   |\n| ------------------------------- | ------------------------------------------- | ------------ |\n| Requêtes à l’API                | 600 par minute, avec des rafales de 120     | Clé d’API    |\n| Envoi de fichiers (`/v2/files`) | 6 000 par minute, avec des rafales de 3 000 | Clé d’API    |\n| Vérifications de domaine        | 20 par minute, avec des rafales de 5        | Organisation |\n\nLes rafales sont le nombre de requêtes acceptées d’un coup, avant que la limite par minute ne s’applique.\n\n## Projets, domaines et variables\n\n| Limite                                                                            | Valeur         |\n| --------------------------------------------------------------------------------- | -------------- |\n| Domaines par organisation                                                         | 50             |\n| Nom d’une variable                                                                | 256 caractères |\n| Valeur d’une variable                                                             | 64 Ko          |\n| Note d’une variable                                                               | 500 caractères |\n| Variables synchronisées par configuration Doppler                                 | 300            |\n| Entrées par liste de `vercel.json` (`redirects`, `rewrites`, `headers`, `routes`) | 1024           |\n\n## Journaux\n\n| Limite                               | Valeur                    |\n| ------------------------------------ | ------------------------- |\n| Conservation des logs des requêtes   | 3 jours                   |\n| Lignes de logs de requêtes affichées | 1000 au plus              |\n| Conservation des logs de build       | Tant que le projet existe |\n\nLes minutes de GitHub Actions dépendent de ton compte GitHub, pas de Host."},{"path":"/docs/reference/variables/","title":"Variables d'environnement","description":"Noms, valeurs, environnements, variables réservées et variables sensibles, avec les règles exactes.","version":null,"markdown":"Cette page donne les règles qui s’appliquent aux variables d’environnement. Pour les gérer pas à pas, voir [Gérer les variables](/docs/guides/variables-d-environnement/).\n\n## Nom\n\n| Règle                | Valeur                                            |\n| -------------------- | ------------------------------------------------- |\n| Caractères autorisés | Lettres, chiffres et `_`                          |\n| Premier caractère    | Une lettre ou `_`, pas un chiffre                 |\n| Longueur             | 256 caractères au plus                            |\n| Noms réservés        | Ceux qui commencent par `VERCEL_` ou `AGENTHOST_` |\n\nUn même nom peut exister une fois par environnement.\n\n## Valeur et note\n\n| Champ  | Limite                 |\n| ------ | ---------------------- |\n| Valeur | 64 Ko au plus          |\n| Note   | 500 caractères au plus |\n\n## Environnements\n\n| Environnement | Utilisé par                                                | Télécharge avec `vercel pull` |\n| ------------- | ---------------------------------------------------------- | ----------------------------- |\n| Production    | `vercel build --prod`, les déploiements de production      | `--environment=production`    |\n| Preview       | Les builds de toutes les branches autres que la production | `--environment=preview`       |\n| Développement | Ton poste de développement                                 | Par défaut, sans option       |\n\n## Variables fournies par la plateforme\n\nHost ajoute ces variables au build, sans que tu les crées :\n\n| Variable                        | Valeur                                                                                                                                             |\n| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `VERCEL_PROJECT_PRODUCTION_URL` | Le domaine de production du projet, sans `https://`, à défaut son adresse de production `<projet>.hgdc.cloud`. Toujours présente, en preview aussi |\n\nLes noms `VERCEL_` sont réservés : tu ne peux pas en créer, et une variable du projet du même nom n’écrase pas celle de la plateforme.\n\n## Variables sensibles\n\n| Propriété      | Comportement                                                                                                                    |\n| -------------- | ------------------------------------------------------------------------------------------------------------------------------- |\n| Affichage      | Jamais affichée après l’enregistrement, ni dans la console ni dans la CLI. Elle peut seulement être remplacée                   |\n| Environnements | Production ou preview uniquement. Jamais le développement                                                                       |\n| Téléchargement | Livrée uniquement au build du dépôt GitHub, par une clé limitée au projet. Absente de `vercel pull` avec une clé d’organisation |\n\n## Synchronisation avec Doppler\n\n| Règle                       | Valeur                                                      |\n| --------------------------- | ----------------------------------------------------------- |\n| Variables par configuration | 300 au plus                                                 |\n| Métadonnées Doppler         | Exclues : `DOPPLER_PROJECT`, `DOPPLER_CONFIG` et similaires |\n| Noms réservés               | Ignorés                                                     |\n| Valeurs de plus de 64 Ko    | Ignorées et signalées                                       |\n| Synchronisation de secours  | Toutes les six heures, sans webhook                         |\n\nVoir [Synchroniser depuis Doppler](/docs/guides/synchroniser-doppler/).\n\n## Ce que le site publie\n\nTout ce que le build écrit dans les fichiers du site est public. Une variable lue dans le navigateur, comme celles qui commencent par `PUBLIC_`, `VITE_` ou `NEXT_PUBLIC_`, ne doit jamais contenir un secret."},{"path":"/docs/reference/vercel-json/","title":"vercel.json","description":"Les options de vercel.json que Host applique, leurs limites, et ce qui est filtré à la publication.","version":null,"markdown":"Host applique le routage de ton site comme Vercel. Pour un site statique sans build, il lit `vercel.json` à la racine du dossier envoyé. Pour un site construit avec `vercel build`, il lit `.vercel/output/config.json`. Les options décrites ici sont converties par la bibliothèque de routage de Vercel, avec les mêmes règles.\n\n## Options prises en charge\n\n| Option          | Effet                                                                      |\n| --------------- | -------------------------------------------------------------------------- |\n| `cleanUrls`     | Sert `/a-propos` pour `a-propos.html`, sans extension                      |\n| `trailingSlash` | Ajoute ou retire la barre oblique finale, par redirection                  |\n| `redirects`     | Redirige un chemin vers un autre, avec le code 301, 302, 307 ou 308        |\n| `rewrites`      | Sert un autre fichier, ou une URL externe, sans changer l’adresse affichée |\n| `headers`       | Ajoute des en-têtes de réponse à certains chemins                          |\n| `routes`        | Le format de routes historique de Vercel, pour les cas avancés             |\n\nChaque liste (`redirects`, `rewrites`, `headers`, `routes`) accepte 1024 entrées au plus.\n\n## Exemple\n\n```json\n{\n  \"cleanUrls\": true,\n  \"redirects\": [\n    { \"source\": \"/blog/:slug\", \"destination\": \"/articles/:slug\", \"permanent\": true }\n  ],\n  \"headers\": [\n    {\n      \"source\": \"/assets/(.*)\",\n      \"headers\": [\n        { \"key\": \"Cache-Control\", \"value\": \"public, max-age=31536000, immutable\" }\n      ]\n    }\n  ]\n}\n```\n\n## Build Output API\n\nPour un site envoyé avec `vercel deploy --prebuilt`, Host lit `.vercel/output/config.json` (version 3) et sert le dossier `.vercel/output/static`. Les routes passent par les mêmes phases que chez Vercel : routes principales, système de fichiers, `miss`, `rewrite`, puis `error`.\n\nLes conditions `has` et `missing` sont prises en compte. Elles portent sur l’hôte, un en-tête, un cookie ou un paramètre.\n\n## Ce qui est filtré\n\n- Les en-têtes `set-cookie` d’une route ne sont pas servis.\n- Les fichiers et dossiers qui commencent par un point (`.env`, `.git`) ne sont jamais servis. Seul `.well-known` fait exception.\n- Une expression régulière jugée dangereuse ou trop longue fait échouer la publication. Le message désigne la route en cause. Un exemple de motif dangereux : des quantificateurs imbriqués, comme `(a+)+`.\n\n## Pages introuvables\n\nUn fichier `404.html` à la racine du site sert de page d’erreur. Sans lui, Host affiche sa propre page 404."}]}
+{"format":1,"project":"jn7dj6vzkgs7n2d16kqjtb99yd8gbdw0","name":"Docs","language":"fr","builtAt":"2026-10-17T23:31:54.239Z","theme":{"primary":"#7c3aed","logo":"/images/logo-clair.svg"},"versions":[{"id":null,"label":null,"isDefault":true}],"pages":[{"path":"/demarrer/premiere-doc/","title":"Ta première doc en cinq minutes","description":"Créer le dossier, écrire docs.json et une page, puis voir le site en local.","version":null,"markdown":"Il te faut Node.js 22 ou plus récent, ou Bun. Tout le reste s’installe avec le paquet `@hgdc/docs`.\n\n1. **Créer le dossier**\n\n   Un dépôt Git à part, ou un dossier `docs/` dans le dépôt de ton produit.\n\n   ```bash\n   mkdir docs && cd docs\n   npm init -y\n   npm install --save-dev @hgdc/docs\n   ```\n\n2. **Écrire docs.json**\n\n   À la racine du dossier. Seuls `name` et `navigation` sont obligatoires.\n\n   ```json\n   {\n     \"name\": \"Documentation Acme\",\n     \"colors\": { \"primary\": \"#0f766e\" },\n     \"navigation\": {\n       \"groups\": [{ \"group\": \"Démarrer\", \"pages\": [\"index\", \"installation\"] }]\n     }\n   }\n   ```\n\n3. **Écrire les pages**\n\n   Une page par entrée de la navigation : `index.mdx` et `installation.mdx`. Chaque page commence par un titre.\n\n   ```mdx\n   ---\n   title: Installation\n   description: Installer Acme en deux minutes.\n   ---\n\n   Lance la commande suivante :\n   ```\n\n4. **Voir le site**\n\n   Ajoute les scripts dans `package.json`, puis lance `npm run dev`.\n\n   ```json\n   {\n     \"scripts\": {\n       \"dev\": \"hgdc-docs dev\",\n       \"build\": \"hgdc-docs build\"\n     }\n   }\n   ```\n\n   Le site s’ouvre sur `http://localhost:4321` et se recharge à chaque modification.\n\n> **Note**\n>\n> `hgdc-docs build` écrit le site dans `dist/`. Ajoute `dist/` et `.hgdc-docs/` à ton `.gitignore`.\n\n## Et ensuite\n\n- [Publier avec Host](/guides/publier/) pour mettre le site en ligne.\n- [Écrire en MDX](/guides/ecrire/) pour les titres, les liens, les images et le code.\n- [docs.json](/reference/docs-json/) pour toutes les options."},{"path":"/explications/donnees/","title":"Données et confidentialité","description":"Ce qui est stocké, où, combien de temps, et qui y accède.","version":null,"markdown":"## Ce qui est stocké\n\n| Donnée                                           | Où                 | Durée                          |\n| ------------------------------------------------ | ------------------ | ------------------------------ |\n| Pages publiées, en Markdown, et passages indexés | Base de la console | Tant que le projet existe      |\n| Questions des visiteurs, réponses, sources       | Base de la console | 90 jours                       |\n| Consommation mensuelle de l’assistant            | Base de la console | Tant que l’organisation existe |\n\nLa console ne stocke ni l’adresse IP ni l’identité des visiteurs. L’IP sert seulement, le temps de la requête, à limiter le nombre de questions par minute et par jour.\n\n## Qui traite quoi\n\n- **Le site** est servi par Host.\n- **La recherche du site** tourne dans le navigateur du visiteur : aucune requête ne part.\n- **Les embeddings** des passages et des questions sont calculés par Mistral AI, dans l’Union européenne.\n- **Les réponses** sont rédigées par Claude, le modèle d’Anthropic, appelé directement ou par OpenRouter. La question et les passages trouvés lui sont envoyés.\n\nSans clé d’embeddings, la recherche de l’assistant reste en plein texte : rien ne part chez Mistral.\n\n## Ce que voit l’assistant\n\nUniquement ce que ton site publie : il lit le corpus du site public. Une page qui n’est pas publiée n’existe pas pour lui. Il ne peut ni naviguer sur le web, ni agir : il lit des passages et écrit une réponse.\n\n## Supprimer\n\nSupprimer un projet dans la console efface son index, ses pages et son journal. Le site publié et ton dépôt ne sont pas touchés."},{"path":"/explications/fonctionnement/","title":"Comment ça marche","description":"Du push au site publié, puis à l'assistant qui répond.","version":null,"markdown":"Docs tient en trois pièces : un modèle de site, Host qui le publie, et la console qui l’indexe pour l’assistant.\n\n## 1. Le modèle de site\n\nLe paquet `@hgdc/docs` contient un site Astro Starlight complet. `hgdc-docs build` lit ton `docs.json`, prend tes pages MDX et construit un site statique. Rien ne tourne côté serveur : le site est rapide et ne tombe pas en panne avec la console.\n\nPendant le build, chaque page est aussi convertie en Markdown à partir du HTML final. Les composants sont donc déjà rendus : ce que lit un agent est exactement ce que voit un visiteur.\n\n## 2. La publication par Host\n\nHost lance le build dans GitHub Actions à chaque push, puis sert le dossier `dist/` sur ton domaine. La doc est une source comme une autre : préversion par branche, retour arrière, domaine.\n\n## 3. L’indexation par la console\n\nLa console relit `/_hgdc/corpus.json` sur le site publié : tous les quarts d’heure, ou quand tu cliques sur **Synchroniser**. Elle vérifie que le corpus porte bien l’identifiant du projet, puis :\n\n1. découpe chaque page en passages, un par section (titre `##` ou plus fin) ;\n2. compare avec l’index existant, passage par passage : seuls les passages nouveaux sont traités ;\n3. calcule leur représentation vectorielle (embedding), qui permet de retrouver une reformulation ;\n4. supprime les passages qui ne sont plus publiés.\n\nUn build identique au précédent ne change rien à l’index.\n\n## 4. La réponse\n\nUne question passe par deux recherches : par mots (les termes exacts, comme `docs.json`) et par sens (les reformulations). Les deux classements sont fusionnés, les six meilleurs passages sont donnés au modèle Claude, qui répond en citant ceux qu’il utilise.\n\n> **Note**\n>\n> L’index d’un projet est fermé aux autres : une recherche ne voit que les passages de son propre projet, vérifiés deux fois."},{"path":"/guides/agents/","title":"llms.txt et MCP","description":"Rendre la doc lisible par les outils d'IA, avec llms.txt, des pages en Markdown et un serveur MCP.","version":null,"markdown":"Les assistants de code et les agents lisent la documentation pour écrire du code juste. Docs leur donne trois portes d’entrée, sans rien à configurer.\n\n## llms.txt\n\nChaque site publie à sa racine :\n\n- `/llms.txt` : l’index de la doc au format [llmstxt.org](https://llmstxt.org), une ligne par page avec sa description, rangées par onglet et par groupe. Le même fichier répond aussi sur `/.well-known/llms.txt`.\n- `/llms-full.txt` : toute la doc en un seul fichier Markdown.\n\n## Une page en Markdown\n\nChaque page existe aussi en Markdown à la même adresse suivie de `.md` : `/guides/publier.md` pour `/guides/publier/`. Les pages l’annoncent dans leur `<head>` avec `rel=\"alternate\"`.\n\nEn haut de chaque page, **Copier pour un LLM** copie ce Markdown. Le menu à côté ouvre la page dans Claude ou ChatGPT, ou affiche le Markdown.\n\n## Serveur MCP\n\nChaque projet a un serveur MCP en lecture seule. L’adresse est dans l’aperçu du projet, dans la console :\n\n```text\nhttps://docs.hgdc.ch/mcp/<identifiant du projet>\n```\n\nDans Claude Code :\n\n```bash\nclaude mcp add --transport http acme-docs https://docs.hgdc.ch/mcp/<identifiant du projet>\n```\n\nDans Cursor (`.cursor/mcp.json`) :\n\n```json\n{ \"mcpServers\": { \"acme-docs\": { \"url\": \"https://docs.hgdc.ch/mcp/<identifiant du projet>\" } } }\n```\n\nDans VS Code (`.vscode/mcp.json`) :\n\n```json\n{ \"servers\": { \"acme-docs\": { \"type\": \"http\", \"url\": \"https://docs.hgdc.ch/mcp/<identifiant du projet>\" } } }\n```\n\nL’aperçu du projet donne ces lignes déjà remplies. Le serveur reste ouvert quand l’assistant du site est coupé : il ne fait que chercher, sans modèle.\n\nLe serveur propose trois outils :\n\n| Outil         | Rôle                                                                                         |\n| ------------- | -------------------------------------------------------------------------------------------- |\n| `search_docs` | Cherche dans la doc et rend les passages les plus proches, avec l’adresse de chaque section. |\n| `get_page`    | Rend une page complète en Markdown, à partir de son chemin.                                  |\n| `list_pages`  | Liste les pages avec leur titre et leur chemin.                                              |\n\nLe détail du protocole est dans la [référence MCP](/reference/mcp/)."},{"path":"/guides/assistant/","title":"L'assistant IA","description":"Ce que fait l'assistant, d'où viennent ses réponses, et comment le régler.","version":null,"markdown":"L’assistant ajoute un bouton **Demander à l’IA** en bas à droite de chaque page, et `Ctrl I` l’ouvre au clavier. Le visiteur pose sa question ; l’assistant cherche dans ta doc et répond en quelques phrases, avec des renvois numérotés vers les sections utilisées.\n\n## D’où viennent les réponses\n\n1. La question est cherchée dans les pages publiées de ta doc, et seulement là.\n2. Les passages les plus proches sont donnés au modèle Claude, avec une consigne : répondre à partir de ces passages, citer chaque affirmation, ne rien inventer.\n3. Seuls les passages réellement cités deviennent des sources sous la réponse.\n\nSi rien dans la doc ne correspond, l’assistant répond qu’il ne trouve pas, sans appeler le modèle. Une réponse sans aucune source est traitée de la même façon.\n\n> **Les réponses restent générées par IA**\n>\n> Le widget le rappelle sous chaque échange. Une source citée se vérifie en un clic.\n\n## Activer et désactiver\n\nL’assistant est actif dès que `docs.json` porte l’identifiant `project` et que la console a indexé le site. Pour le couper :\n\n- dans la console, **Assistant › Assistant sur le site** (effet immédiat) ;\n- ou dans `docs.json`, `\"assistant\": { \"enabled\": false }` (au prochain build).\n\n## Quota\n\nChaque organisation dispose d’un nombre de questions par mois, toutes docs confondues : 500 dans l’offre de départ. La console affiche la consommation. Au-delà, l’assistant répond qu’il a atteint sa limite, et HGDC relève le plafond sur demande.\n\nPour éviter qu’un seul visiteur ou un script épuise le quota, chaque visiteur a droit à 6 questions par minute et 40 par jour, et chaque doc à 30 par minute et 200 par jour. HGDC relève le plafond journalier d’une doc sur demande.\n\n## Tester et lire le journal\n\nEn haut de la page **Assistant**, les 30 derniers jours : nombre de questions, part de réponses sourcées, et les **questions sans réponse**, regroupées et classées de la plus posée à la moins posée. Chacune ouvre le journal filtré : c’est la liste des pages à écrire.\n\n**Assistant › Tester l’assistant** pose une question comme un visiteur. Le **journal** garde les questions des 90 derniers jours avec leur état :\n\n| État     | Ce que ça veut dire                                               |\n| -------- | ----------------------------------------------------------------- |\n| Répondu  | L’assistant a répondu en citant la doc.                           |\n| Hors doc | Rien dans la doc ne répond. Souvent une page à écrire.            |\n| Erreur   | Le modèle n’a pas répondu ; le visiteur a été invité à réessayer. |\n\nAu-dessus du journal, cherche une question par ses mots, ou filtre par état : **État › Hors doc** ne garde que les questions sans réponse. Les filtres restent dans l’adresse de la page : tu peux la garder en favori ou l’envoyer à un collègue.\n\n> **Astuce**\n>\n> Lis les questions « hors doc » une fois par semaine : c’est la liste des pages qui manquent, écrite par tes visiteurs."},{"path":"/guides/composants/","title":"Composants","description":"Encadrés, étapes, cartes, onglets et accordéons, disponibles dans chaque page sans import.","version":null,"markdown":"Ces composants s’utilisent directement dans une page `.mdx`, sans `import`. Ils portent les mêmes noms que chez Mintlify.\n\n## Encadrés\n\n> **Note**\n>\n> Une information utile à côté du texte.\n\n> **Astuce**\n>\n> Un conseil qui fait gagner du temps.\n\n> **Attention**\n>\n> Un piège à éviter.\n\n> **Danger**\n>\n> Une action qui détruit des données.\n\n```mdx\n<Note>Une information utile à côté du texte.</Note>\n<Tip title=\"Astuce\">Un conseil qui fait gagner du temps.</Tip>\n<Warning>Un piège à éviter.</Warning>\n<Danger>Une action qui détruit des données.</Danger>\n```\n\n`<Info>` et `<Check>` existent aussi. Chacun accepte un `title`.\n\n## Étapes\n\n1. **Installer**\n\n   Ajoute le paquet.\n\n2. **Configurer**\n\n   Écris `docs.json`.\n\n```mdx\n<Steps>\n  <Step title=\"Installer\">Ajoute le paquet.</Step>\n  <Step title=\"Configurer\">Écris `docs.json`.</Step>\n</Steps>\n```\n\n## Cartes\n\n[Avec un lien](/guides/publier/)\n\n[Toute la carte est cliquable.](/guides/publier/)\n\nSans lien\n\nPour présenter une idée.\n\n```mdx\n<CardGroup cols={2}>\n  <Card title=\"Avec un lien\" href=\"/guides/publier/\">Toute la carte est cliquable.</Card>\n  <Card title=\"Sans lien\">Pour présenter une idée.</Card>\n</CardGroup>\n```\n\n`cols` va de 1 à 4. Sur téléphone, les cartes passent l’une sous l’autre.\n\n## Onglets\n\n```bash\nnpm install --save-dev @hgdc/docs\n```\n\n```bash\nbun add --dev @hgdc/docs\n```\n\n```mdx\n<Tabs>\n  <Tab title=\"npm\">…</Tab>\n  <Tab title=\"Bun\">…</Tab>\n</Tabs>\n```\n\n## Accordéons\n\nFaut-il un compte HGDC pour écrire ?\n\nNon. Le site se construit sans compte. Le compte sert à la console : publication suivie et assistant.\n\nPuis-je garder mes composants Mintlify ?\n\nCeux de cette page, oui. Les autres s’affichent comme du texte : remplace-les ou écris-nous.\n\n```mdx\n<AccordionGroup>\n  <Accordion title=\"Question\">Réponse.</Accordion>\n</AccordionGroup>\n```\n\n## Dans le Markdown publié\n\nChaque composant a une forme Markdown : un encadré devient une citation qui commence par son titre en gras, une étape devient un élément de liste numérotée. C’est cette forme que lisent l’assistant, `llms.txt` et les outils d’IA."},{"path":"/guides/ecrire/","title":"Écrire en MDX","description":"Titres, liens, images, code et métadonnées d'une page.","version":null,"markdown":"Chaque page est un fichier `.mdx` (ou `.md`) : du Markdown, plus des composants. Le chemin du fichier donne l’adresse de la page : `guides/publier.mdx` devient `/guides/publier/`.\n\n## Métadonnées\n\nLe haut de la page, entre deux lignes `---`, décrit la page.\n\n```mdx\n---\ntitle: Publier avec Host\nsidebarTitle: Publier\ndescription: Mettre la doc en ligne et brancher l'assistant.\n---\n```\n\n| Champ          | Rôle                                                                         |\n| -------------- | ---------------------------------------------------------------------------- |\n| `title`        | Titre de la page, obligatoire. Aussi le titre de l’onglet du navigateur.     |\n| `sidebarTitle` | Libellé plus court dans la barre latérale.                                   |\n| `description`  | Une phrase. Reprise par les moteurs de recherche, `llms.txt` et l’assistant. |\n\n## Titres et sections\n\nCommence les sections à `##`. Chaque titre reçoit une ancre (`#publier-avec-host`) : c’est elle que l’assistant cite dans ses sources. Un titre clair donne donc une source claire.\n\n> **Astuce**\n>\n> Une section par question qu’on te pose. L’assistant découpe la doc par titre : une section courte et nommée simplement est retrouvée plus souvent.\n\n## Liens\n\nLes liens internes s’écrivent avec le chemin de la page : `[Publier](/guides/publier/)`. Pour une section : `[le domaine](/guides/publier/#ton-domaine)`.\n\n## Images\n\nRange les images dans `images/`, `img/`, `logo/`, `assets/` ou `static/`, et cite-les avec un chemin qui commence par `/`. Seuls les médias de ces dossiers, le logo et le favicon de `docs.json`, et tout le dossier `public/` (servi à la racine) sont publiés : un fichier oublié ailleurs dans le dépôt ne part jamais en ligne.\n\n```mdx\n![Le tableau de bord](/images/tableau-de-bord.png)\n```\n\nPour une légende, entoure l’image d’un cadre :\n\n```mdx\n<Frame caption=\"Le tableau de bord après la première publication\">\n  ![Le tableau de bord](/images/tableau-de-bord.png)\n</Frame>\n```\n\n## Code\n\nLes blocs de code sont colorés et ont un bouton Copier. Indique le langage après les trois accents graves :\n\n````mdx\n```bash\nnpm run build\n```\n````\n\n## Ce qui n’est pas publié\n\nLes fichiers qui commencent par `_` (comme `_brouillon.mdx`), `README.md`, `CHANGELOG.md` et les dossiers `node_modules`, `dist` ou cachés ne deviennent pas des pages."},{"path":"/guides/navigation/","title":"Navigation, onglets et versions","description":"Organiser les pages en groupes, en onglets et en versions dans docs.json.","version":null,"markdown":"La navigation se décrit dans `docs.json`, sous `navigation`. Choisis **une** forme : `pages`, `groups`, `tabs` ou `versions`.\n\n## Pages et groupes\n\nPour une petite doc, une liste de groupes suffit. Un groupe peut contenir d’autres groupes.\n\n```json\n{\n  \"navigation\": {\n    \"groups\": [\n      { \"group\": \"Démarrer\", \"pages\": [\"index\", \"installation\"] },\n      {\n        \"group\": \"Guides\",\n        \"pages\": [\"guides/facturer\", { \"group\": \"Avancé\", \"expanded\": false, \"pages\": [\"guides/webhooks\"] }]\n      }\n    ]\n  }\n}\n```\n\nUne page s’écrit sans extension ni `/` au début : `guides/facturer` pour `guides/facturer.mdx`. Une page citée mais absente fait échouer le build, avec la liste de ce qui manque.\n\n## Onglets\n\nAu-delà d’une vingtaine de pages, sépare les grandes parties en onglets : guides, référence, explications. Les onglets s’affichent en haut de la barre latérale ; chacun a ses propres groupes.\n\n```json\n{\n  \"navigation\": {\n    \"tabs\": [\n      { \"tab\": \"Guides\", \"groups\": [{ \"group\": \"Démarrer\", \"pages\": [\"index\"] }] },\n      { \"tab\": \"Référence\", \"groups\": [{ \"group\": \"API\", \"pages\": [\"reference/api\"] }] }\n    ]\n  }\n}\n```\n\n> **Astuce**\n>\n> Cette doc suit le découpage Diataxis : des guides pour faire, une référence pour vérifier, des explications pour comprendre.\n\n## Versions\n\nQuand ton produit garde plusieurs versions en service, chacune peut avoir sa doc. Le visiteur passe de l’une à l’autre avec un menu en haut de la barre latérale.\n\n```json\n{\n  \"navigation\": {\n    \"versions\": [\n      { \"version\": \"v2\", \"default\": true, \"groups\": [{ \"group\": \"Démarrer\", \"pages\": [\"index\"] }] },\n      { \"version\": \"v1\", \"groups\": [{ \"group\": \"Démarrer\", \"pages\": [\"v1/index\"] }] }\n    ]\n  }\n}\n```\n\nLa version par défaut est celle que lisent l’assistant en priorité et l’index `llms.txt`. Les autres y figurent dans une section « Optional ».\n\n## Précédent et suivant\n\nEn bas de chaque page, les liens Précédent et Suivant suivent l’ordre de la navigation, sans sortir de l’onglet ouvert."},{"path":"/guides/publier/","title":"Publier avec Host","description":"Mettre la doc en ligne avec Host, activer Docs en un clic et brancher l'assistant.","version":null,"markdown":"Host construit ton site à chaque push et le sert depuis son serveur. La console `docs.hgdc.ch` relit ensuite le site publié pour indexer l’assistant.\n\n## Mettre la doc en ligne\n\n1. **Importer le dépôt**\n\n   Dans Host, crée un projet à partir de ton dépôt GitHub. Host reconnaît une doc Docs (un `docs.json` et le paquet `@hgdc/docs` dans `package.json`) : il la construit avec `hgdc-docs build` et publie le dossier `dist/`. Aucun fichier de configuration à ajouter.\n\n2. **Fusionner la pull request de Host**\n\n   Host propose une pull request qui ajoute son workflow de déploiement. Fusionne-la : la doc part en production.\n\n3. **Pousser**\n\n   Chaque push sur la branche principale publie le site en production. Les autres branches ont leur préversion.\n\n## Activer Docs\n\n1. **Cliquer sur « Activer Docs »**\n\n   Sur la vue d’ensemble du projet dans Host, la carte **Assistant et recherche avec Docs** propose **Activer Docs**. Host crée le projet dans la console, dans la même organisation. Il faut être admin de l’organisation, et la doc doit déjà être en production.\n\n2. **Publier une fois de plus**\n\n   Pousse une modification. Ce build reçoit l’identifiant du projet de la console : le site le porte sans que tu le recopies dans `docs.json`.\n\n3. **Laisser faire**\n\n   À chaque mise en production, Host prévient la console, qui relit `/_hgdc/corpus.json` et indexe les pages en quelques secondes. La carte de Host affiche **Docs est activé** et mène à la console. En plus, la console relit le site tous les quarts d’heure : un appel perdu se rattrape seul.\n\n> **Note**\n>\n> Le projet apparaît dans la console dès que tu t’y connectes avec ton compte HGDC. Ses réglages (domaines, assistant) s’y changent comme pour n’importe quel projet.\n\n## Ton domaine\n\nLe domaine se branche dans Host, comme pour n’importe quel site : Host annonce la nouvelle adresse à la console à la mise en production suivante. Si la doc répond sur plusieurs adresses (`docs.acme.ch` et `aide.acme.ch`), ajoute les autres dans **Réglages › Domaines** : l’assistant ne répond qu’aux pages servies par ces adresses.\n\n## Relier un projet existant\n\nLe dossier `dist/` est un site statique, il se dépose chez n’importe quel hébergeur. Hors de Host, ou pour un projet créé directement dans la console, relie la doc à la main.\n\n1. **Créer le projet dans la console**\n\n   Sur `docs.hgdc.ch`, ouvre ton organisation, puis **Nouveau projet**. Donne l’adresse de production du site, par exemple `https://docs.acme.ch`.\n\n2. **Copier l'identifiant dans docs.json**\n\n   La console affiche une ligne à copier. Ajoute-la dans `docs.json`, puis publie :\n\n   ```json\n   { \"project\": \"k57a8m2x9q4n1b3c5d7e9f0g2h4j6k8m\" }\n   ```\n\n   Sans cet identifiant, le site fonctionne mais l’assistant reste caché, et la console refuse d’indexer un site qui ne porte pas le sien.\n\n3. **Synchroniser**\n\n   Clique sur **Synchroniser** dans l’aperçu du projet. La console lit `/_hgdc/corpus.json` sur ton site et indexe chaque page, puis relit le site tous les quarts d’heure.\n\n> **Adresse publique seulement**\n>\n> La console n’accepte qu’une adresse `https://` avec un nom de domaine public. Elle ne suit pas les redirections : donne l’adresse finale du site."},{"path":"/guides/theme/","title":"Thème et logo","description":"Poser ta couleur, ton logo et ton favicon dans docs.json.","version":null,"markdown":"Le site suit la DA de HGDC par défaut : gris neutres, coins arrondis, Inter pour le texte. Tu changes trois choses : la couleur, le logo et le favicon.\n\n## Couleur\n\n```json\n{ \"colors\": { \"primary\": \"#0f766e\" } }\n```\n\nLa couleur sert aux liens, à l’onglet actif et aux renvois de l’assistant. Sa teinte est gardée ; sa luminosité est ajustée pour que les liens restent lisibles (contraste de 4,5:1 au moins), en clair comme en sombre.\n\nPour une couleur différente en mode sombre, ajoute `\"dark\": \"#5eead4\"`.\n\n> **Note**\n>\n> Dans la console, **Réglages › Thème** montre l’effet d’une couleur en clair et en sombre, son contraste sur un fond blanc, et prépare la ligne à copier dans `docs.json`.\n\n## Logo\n\n```json\n{ \"logo\": { \"light\": \"/images/logo-clair.svg\", \"dark\": \"/images/logo-sombre.svg\" } }\n```\n\nLe chemin part de la racine du dossier de la doc. Un SVG carré ou large, de 32 pixels de haut environ, rend le mieux. Une seule image : `\"logo\": \"/images/logo.svg\"`.\n\n## Favicon\n\n```json\n{ \"favicon\": \"/images/favicon.svg\" }\n```\n\nSans favicon, le site n’en annonce pas d’autre que `/favicon.svg` s’il existe."},{"path":"/","title":"Bienvenue dans Docs","description":"Ta documentation en MDX, publiée par Host, avec recherche, llms.txt et un assistant IA qui cite ses sources.","version":null,"markdown":"Docs transforme un dossier de pages MDX en site de documentation. Tu écris dans ton dépôt Git, Host publie le site à chaque push, et la console `docs.hgdc.ch` branche un assistant qui répond à tes visiteurs à partir de ta doc, et de rien d’autre.\n\n[Ta première doc](/demarrer/premiere-doc/)\n\n[Un dossier, un fichier `docs.json` et une page : ton site tourne en local en cinq minutes.](/demarrer/premiere-doc/)\n\n[Publier avec Host](/guides/publier/)\n\n[Relie le dépôt à Host : chaque push met le site à jour.](/guides/publier/)\n\n[L'assistant IA](/guides/assistant/)\n\n[Il répond aux questions de tes visiteurs et cite les pages qu’il a utilisées.](/guides/assistant/)\n\n[Pour les agents](/guides/agents/)\n\n[`llms.txt`, une version Markdown de chaque page et un serveur MCP en lecture.](/guides/agents/)\n\n## Ce que tu obtiens\n\n- **Un site rapide et lisible** : navigation par onglets et groupes, versions, mode clair et sombre, mise en page pensée pour le téléphone.\n- **La recherche** : `Ctrl K` sur chaque page, sans service externe. L’index est construit avec le site.\n- **Tes couleurs** : une couleur dans `docs.json` suffit. Le contraste des liens est ajusté pour rester lisible.\n- **Un assistant sourcé** : il cherche dans tes pages, répond en quelques phrases et renvoie vers les sections exactes. S’il ne trouve rien, il le dit.\n- **Une doc lisible par les IA** : `llms.txt`, `llms-full.txt`, un bouton « Copier pour un LLM » et un serveur MCP.\n\n## Compatible avec Mintlify\n\nLe fichier `docs.json` reprend celui de Mintlify : nom, couleurs, logo, navigation en onglets, groupes et versions. Les composants les plus courants (`<Note>`, `<Steps>`, `<Card>`, `<Tabs>`…) fonctionnent sans import. Une doc Mintlify se reprend en général sans réécrire les pages.\n\n> **Tout reste en Suisse quand c'est possible**\n>\n> Le site est servi par Host. Les questions des visiteurs sont gardées 90 jours au plus. Voir [Données et confidentialité](/explications/donnees/)."},{"path":"/reference/api-assistant/","title":"API de l'assistant","description":"La requête que le widget envoie, la réponse et les codes d'erreur.","version":null,"markdown":"Le widget du site appelle une seule route. Tu peux l’appeler toi-même pour intégrer l’assistant dans ton application, depuis une page servie par une adresse déclarée dans la console.\n\n## Requête\n\n```http\nPOST https://docs.hgdc.ch/api/v1/ask\nContent-Type: application/json\nOrigin: https://docs.acme.ch\n```\n\n```json\n{\n  \"project\": \"k57a8m2x9q4n1b3c5d7e9f0g2h4j6k8m\",\n  \"question\": \"Comment publier ma doc ?\",\n  \"page\": \"/guides/publier/\",\n  \"previous\": [\"j97f2k8m1q4n6b3c5d7e9f0g2h4j6k8m\"]\n}\n```\n\n| Champ      | Rôle                                                                                                                                            |\n| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `project`  | Identifiant du projet.                                                                                                                          |\n| `question` | 2 à 1 000 caractères.                                                                                                                           |\n| `page`     | Chemin de la page ouverte. Ses passages sont légèrement favorisés.                                                                              |\n| `previous` | Les `id` des réponses précédentes de la conversation, 3 au plus. L’assistant relit lui-même ce qu’il a répondu, dans les deux dernières heures. |\n\nL’en-tête `Origin` doit être l’adresse du site ou un des domaines déclarés dans **Réglages › Domaines**. Chaque visiteur a droit à 6 questions par minute et 40 par jour.\n\n## Réponse\n\n```json\n{\n  \"id\": \"j97f…\",\n  \"status\": \"answered\",\n  \"answer\": \"Importe le dépôt dans Host[^1], puis synchronise le projet dans la console[^2].\",\n  \"sources\": [\n    { \"n\": 1, \"title\": \"Publier avec Host\", \"section\": \"Avec Host\", \"url\": \"https://docs.acme.ch/guides/publier/#avec-host\" },\n    { \"n\": 2, \"title\": \"Publier avec Host\", \"section\": \"Relier la console\", \"url\": \"https://docs.acme.ch/guides/publier/#relier-la-console\" }\n  ]\n}\n```\n\n`answer` est du Markdown simple ; `[^n]` renvoie à la source `n`. `status` vaut `no_answer` quand la doc ne répond pas : `sources` est alors vide.\n\n## Erreurs\n\n| Code HTTP | `error.code`         | Quand                                               |\n| --------- | -------------------- | --------------------------------------------------- |\n| 400       | `invalid_request`    | Corps illisible ou question trop courte.            |\n| 403       | `origin_not_allowed` | La page n’est pas servie par une adresse du projet. |\n| 403       | `assistant_disabled` | L’assistant est coupé dans la console.              |\n| 404       | `project_not_found`  | Identifiant inconnu.                                |\n| 409       | `not_indexed`        | Le site n’a pas encore été synchronisé.             |\n| 429       | `rate_limited`       | Trop de questions en une minute.                    |\n| 429       | `quota_exceeded`     | Le quota mensuel de l’organisation est atteint.     |\n| 503       | `unavailable`        | Le modèle ne répond pas. Réessayer plus tard.       |\n\nChaque erreur porte aussi `error.message`, une phrase en français à montrer telle quelle."},{"path":"/reference/cli/","title":"La commande hgdc-docs","description":"Les commandes dev, build et preview, et les variables d'environnement du build.","version":null,"markdown":"`hgdc-docs` est installée avec le paquet `@hgdc/docs`. Elle se lance depuis le dossier de la doc, ou avec le chemin du dossier en argument.\n\n## Commandes\n\n| Commande            | Effet                                                                                                      |\n| ------------------- | ---------------------------------------------------------------------------------------------------------- |\n| `hgdc-docs dev`     | Site local sur `http://localhost:4321`, rechargé à chaque modification.                                    |\n| `hgdc-docs build`   | Site statique dans `dist/`, avec la recherche, `llms.txt`, les pages Markdown et le corpus de l’assistant. |\n| `hgdc-docs preview` | Sert le dernier build, pour vérifier avant de pousser.                                                     |\n\nOptions : `--port 4000` change le port de `dev` et `preview`, `--help` affiche l’aide.\n\n## Variables d’environnement\n\n| Variable         | Rôle                                                                                                                                                                |\n| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `HGDC_DOCS_SITE` | Adresse publique du site (`https://docs.acme.ch`). Rend les liens de `llms.txt` absolus et produit le sitemap. Sur Host, l’adresse de production est reprise seule. |\n| `HGDC_DOCS_OUT`  | Dossier de sortie, `dist/` par défaut.                                                                                                                              |\n| `HGDC_DOCS_API`  | API de l’assistant, `https://docs.hgdc.ch` par défaut.                                                                                                              |\n\n## Ce que contient dist/\n\n| Fichier                                             | Contenu                                                        |\n| --------------------------------------------------- | -------------------------------------------------------------- |\n| `index.html`, `<page>/index.html`                   | Les pages du site.                                             |\n| `<page>.md`                                         | Chaque page en Markdown.                                       |\n| `llms.txt`, `llms-full.txt`, `.well-known/llms.txt` | L’index et la doc complète pour les agents.                    |\n| `pagefind/`                                         | L’index de la recherche.                                       |\n| `_hgdc/corpus.json`                                 | Le contenu publié, lu par la console pour indexer l’assistant. |"},{"path":"/reference/docs-json/","title":"docs.json","description":"Tous les champs du fichier de configuration d'un site Docs.","version":null,"markdown":"`docs.json` vit à la racine du dossier de la doc. Il reprend le format de Mintlify : les champs que Docs ne gère pas sont acceptés et ignorés. Pour l’autocomplétion dans ton éditeur, ajoute `\"$schema\": \"https://docs.hgdc.ch/docs.schema.json\"`.\n\n## Champs\n\n| Champ                | Type                                          | Obligatoire | Rôle                                                                                                                                                                                                                                                                                                                                              |\n| -------------------- | --------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `name`               | texte                                         | oui         | Nom de la doc, en tête du site et dans `llms.txt`. 80 caractères au plus.                                                                                                                                                                                                                                                                         |\n| `description`        | texte                                         | non         | Une phrase de présentation.                                                                                                                                                                                                                                                                                                                       |\n| `navigation`         | objet                                         | oui         | Pages, groupes, onglets ou versions. Voir [Navigation](/guides/navigation/).                                                                                                                                                                                                                                                                      |\n| `project`            | texte                                         | non         | Identifiant du projet dans la console. Active l’assistant et l’indexation.                                                                                                                                                                                                                                                                        |\n| `language`           | `fr`, `en`, `de`, `it`                        | non         | Langue de l’interface du site. `fr` par défaut.                                                                                                                                                                                                                                                                                                   |\n| `base`               | texte                                         | non         | Sous-chemin où la doc est servie, par exemple `/docs` quand ton application la publie derrière un proxy (`https://app.acme.ch/docs`). Liens, images, recherche, `llms.txt` et pages `.md` le portent ; le site est écrit dans `dist/docs/`. Écris tes liens depuis la racine de la doc (`/guides/publier/`) : le sous-chemin est ajouté au build. |\n| `colors.primary`     | couleur `#rrggbb`                             | non         | Couleur des liens et des éléments actifs.                                                                                                                                                                                                                                                                                                         |\n| `colors.dark`        | couleur `#rrggbb`                             | non         | La même, en mode sombre.                                                                                                                                                                                                                                                                                                                          |\n| `logo`               | chemin, ou `{ light, dark }`                  | non         | Logo affiché en tête.                                                                                                                                                                                                                                                                                                                             |\n| `favicon`            | chemin                                        | non         | Icône de l’onglet du navigateur.                                                                                                                                                                                                                                                                                                                  |\n| `navbar.links`       | liste de `{ label, href }`                    | non         | Jusqu’à 5 liens dans la barre du haut (adresses complètes).                                                                                                                                                                                                                                                                                       |\n| `navbar.primary`     | `{ label, href }`                             | non         | Bouton mis en avant à droite de la barre du haut.                                                                                                                                                                                                                                                                                                 |\n| `footer.socials`     | objet                                         | non         | Liens vers tes réseaux : `linkedin`, `github`, `gitlab`, `x`, `youtube`, `instagram`, `facebook`, `discord`, `mastodon`, `bluesky`, `website`.                                                                                                                                                                                                    |\n| `redirects`          | liste de `{ source, destination, permanent }` | non         | Anciennes adresses qui mènent aux nouvelles. `source` est un chemin du site (`/guides/ancien`), `destination` un chemin ou une adresse `https://`. `permanent: false` pour une redirection temporaire. 500 au plus.                                                                                                                               |\n| `assistant.enabled`  | oui / non                                     | non         | `false` cache l’assistant du site.                                                                                                                                                                                                                                                                                                                |\n| `assistant.endpoint` | adresse                                       | non         | API de l’assistant, à ne changer que pour un environnement de test.                                                                                                                                                                                                                                                                               |\n\n## Navigation\n\nQuatre formes, une seule à la fois :\n\n| Forme      | Exemple                                                   |\n| ---------- | --------------------------------------------------------- |\n| `pages`    | `[\"index\", \"installation\"]`                               |\n| `groups`   | `[{ \"group\": \"Démarrer\", \"pages\": [\"index\"] }]`           |\n| `tabs`     | `[{ \"tab\": \"Guides\", \"groups\": [...] }]`                  |\n| `versions` | `[{ \"version\": \"v2\", \"default\": true, \"groups\": [...] }]` |\n\nUn groupe accepte `expanded: false` pour être replié par défaut, et peut contenir des groupes.\n\n## Erreurs\n\nUn `docs.json` invalide fait échouer le build avec la liste des problèmes, par exemple :\n\n```text\ndocs.json invalide :\n- colors.primary : couleur attendue au format #rrggbb\n- navigation : utiliser une seule forme parmi versions, tabs, groups ou pages\n```"},{"path":"/reference/mcp/","title":"Serveur MCP","description":"Transport, méthodes et outils du serveur MCP en lecture d'un projet.","version":null,"markdown":"Le serveur suit le [Model Context Protocol](https://modelcontextprotocol.io), transport Streamable HTTP, sans session : chaque requête est indépendante.\n\n```text\nPOST https://docs.hgdc.ch/mcp/<identifiant du projet>\nContent-Type: application/json\nAccept: application/json, text/event-stream\n```\n\nIl répond en JSON (`application/json`), jamais en flux. `GET` et `DELETE` répondent 405. Versions du protocole acceptées : `2025-11-25`, `2025-06-18`, `2025-03-26`.\n\n## Méthodes\n\n| Méthode      | Réponse                                                   |\n| ------------ | --------------------------------------------------------- |\n| `initialize` | Nom du serveur, capacités (`tools`) et consignes d’usage. |\n| `ping`       | Objet vide.                                               |\n| `tools/list` | Les trois outils ci-dessous.                              |\n| `tools/call` | Le résultat de l’outil, en texte.                         |\n\nUne notification (message sans `id`) reçoit un 202 sans corps.\n\n## Outils\n\n### search_docs\n\n| Paramètre | Type           | Rôle                              |\n| --------- | -------------- | --------------------------------- |\n| `query`   | texte          | Question ou mots-clés.            |\n| `limit`   | entier, 1 à 10 | Nombre de passages, 5 par défaut. |\n\nRend les passages trouvés, chacun avec son titre, sa section, son adresse et son texte.\n\n### get_page\n\n| Paramètre | Type  | Rôle                                                             |\n| --------- | ----- | ---------------------------------------------------------------- |\n| `path`    | texte | Chemin de la page (`/guides/publier/`), ou son adresse complète. |\n\nRend la page en Markdown, précédée de son adresse.\n\n### list_pages\n\nSans paramètre. Rend la liste des pages publiées.\n\n## Limites\n\nLe serveur est public et en lecture seule : il ne donne accès qu’à ce que le site publie déjà. Chaque projet accepte 300 requêtes par minute, chaque visiteur 60. Au-delà, la réponse est un 429."}]}