Connecteurs de publication

NFZ Docs distingue volontairement deux usages : récupérer un projet VitePress source et publier un site statique déjà buildé.

Priorité produit

Le connecteur prioritaire reste Projet VitePress source.

Il fournit une structure autonome :

.
├─ docs
│  ├─ .vitepress
│  │  └─ config.js
│  ├─ api-examples.md
│  ├─ markdown-examples.md
│  └─ index.md
└─ package.json

Cette approche est la plus saine pour une offre commerciale, car elle permet au client de versionner, auditer et publier la documentation dans son propre dépôt.

Connecteurs prévus

Connecteur	Statut	Usage
Projet VitePress source	Prêt	Export autonome et réversible
Site statique buildé	Prêt	Livraison rapide du dossier dist
GitHub Pages	Prochain	Publication Git automatisée avec Actions
RustFS / S3	Prochain	Publication statique vers un bucket S3-compatible
Webhook CI/CD	Planifié	Déclenchement d'une pipeline externe

Sécurité attendue

Avant tout connecteur réel :

• garder les tokens Git/S3/webhook côté serveur uniquement ;
• imposer une allowlist des destinations ;
• appliquer les entitlements par plan ;
• journaliser chaque run de publication ;
• refuser les images inline base64 dans les pages Markdown ;
• isoler les chemins par tenantId et docsSpaceId avant le multi-tenant réel.

Prochaine brique recommandée

Créer un service Feathers docs-publishing-runs avec un mode dry-run puis un mode publish contrôlé.

Le premier connecteur réel à brancher devrait être GitHub Pages, car le workflow Node 24 est déjà généré dans l'export Projet VitePress source.