OpenDocs — Publier du Markdown sous forme d'URLs partageables et de PDF/DOCX

OpenDocs transforme n'importe quel fichier Markdown en une URL propre et lisible — et, dans le même flux, en un fichier PDF ou Word personnalisé si l'utilisateur souhaite un fichier partageable hors ligne. Vous interagissez avec via le CLI opendocs.

Référence rapide

opendocs login --email [email protected]       # Connexion ou inscription : envoie un code à 6 chiffres par email
opendocs login --email [email protected] --code 123456   # Finalisation : sauvegarde une clé API pour vous
opendocs login --browser                     # Connexion via navigateur, plus humaine
opendocs login --key od_live_xxxxx           # Utilisation d'une clé API existante
opendocs publish doc.md                      # Publie un fichier Markdown → obtient une URL
opendocs publish doc.md                      # ...à nouveau : met à jour le même document (pas de doublon)
opendocs publish doc.md --anonymous          # Sans compte : un lien que n'importe qui peut ouvrir pendant 24h + URL de réclamation
opendocs clone                               # Télécharge l'espace de travail dans ./<espace> pour édition
opendocs status                              # Affiche ce qui a changé localement/en ligne depuis la dernière synchro
opendocs history <doc>                       # Chaque version publiée
opendocs rollback <doc> <version>            # Restaure une version (sous forme de nouvelle version)
opendocs move <doc> --project "Archives"    # Déplace entre projets
opendocs share <doc> [email protected] @acme.com  # Donne accès à des personnes extérieures à l'espace de travail
opendocs team invite [email protected]           # Invite un collaborateur (il accepte par email)
opendocs team join                           # Accepte une invitation qui vous a été envoyée
opendocs theme                               # Couleur de marque, police, logo et pied de page utilisés dans les exportations PDF/DOCX
opendocs theme set --preset editorial --yes  # Change le thème d'exportation (demandez à votre humain d'abord)
opendocs integrations                        # Google Drive / DocuSeal : ce qui est connecté, dossiers Drive nommés
opendocs save <doc> --folder "Procès-verbaux du conseil" # Sauvegarde un PDF (ou --format docx|md) dans un dossier Drive nommé
opendocs sign request <doc> --signer "Employé=Jean Dupont <[email protected]>"  # Crée une demande de signature (n'envoie rien)
opendocs sign send <id> --yes                # Envoie le brouillon, seulement après que l'utilisateur a confirmé chaque signataire
opendocs sign status <id>                    # Qui a signé ; liste des signatures / téléchargement / sauvegarde / annulation aussi
opendocs workspace create "Recherche Acme"  # Nouvel espace de travail
opendocs project link "Lancement Acme"      # Les documents publiés depuis ce dossier vont vers ce projet
opendocs config set organize auto            # Laisse les agents trier les documents dans les projets sans demander
opendocs claim                               # Garde les documents anonymes publiés depuis ce dossier
opendocs publish *.md                        # Publie plusieurs fichiers (par lots automatiques, jusqu'à 500)
opendocs publish ./vault --tags obsidian     # Publie un dossier/vault de manière récursive
opendocs publish *.md --export pdf           # Publie ET exporte — les PDF atterrissent à côté de chaque source
opendocs update doc.md --post-id <id|slug>   # Met à jour un article existant (nouvelle version)
opendocs list                                # Liste les docs dans l'espace de travail actif (alias : `opendocs ls`)
opendocs list --all                          # Liste dans tous les espaces de travail auxquels vous appartenez
opendocs project create <nom> --use          # Crée/bascule vers un projet pour un lot de documents connexes
opendocs project use <slug>                  # Bascule le projet actif
opendocs list --tag <tag>                    # Filtre par tag (idéal pour trouver un lot)
opendocs search <mots>                       # Trouve des documents par titre ou résumé dans tous les projets
opendocs get <id|slug>                       # Affiche les détails d'un article
opendocs pull <id|slug>                      # Télécharge le Markdown brut
opendocs pull --project                      # Télécharge tous les documents du projet actif
opendocs pull --workspace                    # Télécharge tous les documents de l'espace de travail actif
opendocs export <id|slug> --format pdf       # Exporte un article publié au format PDF (ou docx)
opendocs export a b c --format pdf           # Exporte par lots jusqu'à 10 articles à la fois (UUID ou slugs)
opendocs unpublish <id|slug>                 # Rend un article hors ligne (contenu et historique conservés ; pas de republication)
opendocs visibility <id|slug> <niveau>       # Change la visibilité sans re-télécharger le Markdown
opendocs delete <id|slug> --yes              # Supprime définitivement un article (libère son slug + son quota)
opendocs whoami                              # Affiche l'utilisateur/espace de travail/projet actuel
opendocs workspace list                      # Liste tous les espaces de travail auxquels vous appartenez (alias : `workspace ls`)
opendocs workspace use <slug>                # Bascule l'espace de travail actif (alias : `workspace switch`)
opendocs agent                               # Affiche des instructions concises pour un agent IA
opendocs agent --full                        # Affiche le SKILL.md complet intégré
opendocs agent --install                     # Installe cette compétence pour chaque agent sur cette machine
opendocs mcp add                             # Enregistre le serveur MCP OpenDocs dans vos outils de codage
opendocs mcp connect claude                  # Ajoute OpenDocs à l'application Claude (ou : chatgpt)
opendocs logout                              # Efface les identifiants stockés

Chaque commande accepte --json pour une sortie lisible par machine et --api-url <url> pour remplacer le point de terminaison API. Lors de l'exécution programmatique, passez toujours --json — stdout devient un objet JSON analysable unique, les erreurs vont vers stderr et les spinners lisibles par l'humain sont supprimés.

Chaque commande qui prend un <postId> accepte aussi un slug. Le slug est le segment de chemin lisible par l'humain dans l'URL et est unique dans le projet actif. Préférez les slugs d'articles lorsque l'utilisateur nomme un document en langage naturel : opendocs get mon-rapport est plus convivial que de copier l'UUID depuis opendocs list --json. En interne, l'API résout slug → postId via une recherche indexée limitée à l'espace de travail/projet actif, puis effectue la même vérification de propriété que le chemin UUID.

Le slug d'espace de travail et le nom d'utilisateur sont des choses différentes. L'URL est construite à partir du slug de l'espace de travail, pas du nom d'utilisateur. Les documents du projet par défaut utilisent opendocs.cc/<espace_de_travail>/<article>. Les documents de projet non par défaut utilisent opendocs.cc/<espace_de_travail>/projects/<projet>/<article>. Le nom d'utilisateur existe toujours pour l'attribution dans l'interface utilisateur, mais il n'apparaît pas dans les URLs publiées.

OpenDocs via MCP

OpenDocs exécute également un serveur MCP distant à l'adresse https://mcp.opendocs.cc/mcp (guide : https://opendocs.cc/mcp). Chaque application connecte l'utilisateur à OpenDocs avec OAuth la première fois qu'elle l'utilise ; aucune clé API n'est impliquée.

Applications de chat (Claude, ChatGPT) : ajoutez-le comme connecteur personnalisé avec cette URL. opendocs mcp connect claude ouvre la boîte de dialogue "Ajouter un connecteur personnalisé" de Claude avec OpenDocs.cc prérempli ; opendocs mcp connect chatgpt ouvre la page des plugins de ChatGPT (puis "+" → "Ajouter un serveur MCP personnalisé"). Les deux copient l'URL dans le presse-papiers.
Outils de codage : opendocs mcp add l'enregistre dans chaque outil qu'il trouve (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini, opencode, Kiro) et imprime une instruction d'une ligne pour les autres. --agent <id...> sélectionne les outils, --dry-run montre ce qui changerait, opendocs mcp remove le retire, et opendocs agent --install --mcp installe cette compétence et le serveur ensemble.
Outils MCP ou CLI ? Si les outils MCP OpenDocs sont disponibles et que vous ne pouvez pas exécuter de commandes shell, utilisez-les à la place du CLI ; ils prennent le texte Markdown directement. Si vous avez un shell, préférez le CLI pour les fichiers locaux, dossiers et images : il télécharge les images locales, publie des dossiers entiers par lots et se souvient de ce que chaque dossier a publié.

Configuration

Installation

Façons d'obtenir OpenDocs dans un agent :

# Node.js 20+ : le CLI complet (recommandé), puis cette compétence pour chaque agent qu'il trouve
npm install -g @opendocs.cc/cli
opendocs agent --install                 # SKILL.md + scripts/opendocs.sh, aucun réseau nécessaire

# Node.js 22+ : la même compétence via le CLI skills
npx skills add opendocs-cc/skills --skill opendocs -g -y

# Sans Node.js : installe cette compétence + scripts/opendocs.sh (curl + jq)
curl -fsSL https://opendocs.cc/install.sh | bash

opendocs agent --install installe dans le dossier global des compétences de chaque agent dont le dossier de configuration existe : ~/.claude/skills (Claude Code), le dossier partagé ~/.agents/skills (Codex, Cursor, GitHub Copilot, Gemini CLI, opencode, OpenClaw, Windsurf, Amp, Goose, Grok Build), ~/.cline/skills, ~/.hermes/skills et ~/.kiro/skills. opendocs agent --list montre le dossier de chaque agent et s'il a été trouvé ; --agent <id...> installe pour des agents spécifiques même s'ils n'ont pas été trouvés (--agent claude-code codex). Réexécutez-le après avoir mis à jour le CLI pour mettre à jour la compétence. Il imprime les dossiers qu'il a écrits ; avec --json, installed[] a agent, path et status.

Dans Claude Code, vous pouvez également l'installer comme plugin OpenDocs.cc, qui ajoute /opendocs-cc:publish et /opendocs-cc:export, connecte le serveur MCP et maintient la compétence à jour : /plugin marketplace add opendocs-cc/skills, puis /plugin install opendocs-cc@opendocs-cc. Dans Codex : codex plugin marketplace add opendocs-cc/skills, puis codex plugin add opendocs-cc@opendocs-cc.

npx skills add peut se terminer par ✗ opendocs → PromptScript: PromptScript does not support global skill installation. C'est un bogue connu de l'installateur qui n'affecte que PromptScript ; la compétence est installée, continuez donc.

Si la commande opendocs n'est pas disponible et que Node.js n'est pas installé, utilisez bash scripts/opendocs.sh (dans le dossier de cette compétence) à la place — voir "Sans Node.js" ci-dessous. Tout le reste de ce guide s'applique aux deux.

Vérifier si le CLI est installé et authentifié

opendocs --version    # imprime la version installée du CLI
opendocs whoami       # affiche le nom d'utilisateur + le nom de l'espace de travail (le slug d'URL se trouve dans la sortie JSON)

opendocs whoami --json est la commande de diagnostic la plus utile pour un agent — elle renvoie le slug de l'espace de travail actif du CLI (pour construire les URLs des articles) ainsi que le contexte du compte/espace de travail et le quota de documents en un seul appel :

{
  "userId": "...",
  "onboarding": { "username": "...", "workspace": { "id": "...", "name": "Documents Acme", "slug": "documents-acme" } },
  "quota": { "documents": { "plan": "gratuit", "limit": 50, "used": 3, "remaining": 47 } }
}

Pour les espaces de travail Pro/Team, quota.documents.limit et remaining sont null (signifiant illimité). Les points de terminaison de publication vérifient toujours le quota par rapport au workspaceId explicite dans le corps de la requête, donc une configuration locale périmée ne peut pas contourner l'application côté serveur.

Si le CLI est manquant :

npm install -g @opendocs.cc/cli

Si l'utilisateur n'est pas connecté, inscrivez-le (ou connectez-le) avant sa première publication, depuis le terminal avec un code envoyé par email : pas de navigateur, pas de copie de clés API. Un compte est gratuit jusqu'à 50 documents et c'est ce que l'utilisateur souhaite par défaut : les liens restent actifs, restent privés pour son espace de travail, peuvent être mis à jour sur place et exportés en PDF.

Demandez à l'utilisateur son adresse email.
Exécutez opendocs login --email <email> --json. Il envoie un code à 6 chiffres par email et se termine immédiatement avec {"status": "code_sent", ...}.
Dites à l'utilisateur : "Vérifiez votre boîte de réception pour un code de connexion d'OpenDocs et collez-le ici."
Exécutez opendocs login --email <email> --code <code> --json.

Si l'email est nouveau, cela crée le compte, un nom d'utilisateur, un espace de travail (opendocs.cc/<nom_utilisateur>) et un projet par défaut, puis sauvegarde une nouvelle clé API nommée d'après votre agent (par exemple claude-code) dans la configuration du CLI. Les comptes existants reçoivent simplement une nouvelle clé. opendocs signup est un alias. Les codes expirent après 10 minutes et autorisent 5 tentatives ; en cas d'invalid_code, demandez l'email le plus récent, en cas de code_expired, répétez l'étape 2.

Seulement si l'utilisateur ne souhaite pas encore de compte, proposez une publication anonyme à la place :

opendocs publish notes.md --anonymous --json

Toute personne disposant de l'url renvoyée peut la lire pendant 24 heures, puis elle est supprimée. Partagez le claimUrl avec l'utilisateur exactement comme il est renvoyé, et proposez-lui de s'inscrire pour qu'il soit conservé : exécuter opendocs login --email ... plus tard depuis le même dossier le réclame automatiquement dans son nouvel espace de travail (ou exécutez opendocs claim). Ne publiez jamais anonymement à moins que l'utilisateur n'ait accepté qu'un lien que n'importe qui peut ouvrir soit acceptable.

Autres moyens de se connecter : les humains sur un terminal peuvent utiliser opendocs login --browser ; les scripts et CI peuvent utiliser une clé existante :

opendocs login --key od_live_xxxxx
# Ou passez-la via une variable d'environnement pour les scripts / CI :
export OPENDOCS_API_KEY=od_live_xxxxx && opendocs login

N'exécutez jamais opendocs login nu depuis un agent. Sans --email, --key ou la variable d'environnement, il demande une clé API sur stdin et votre appel d'outil se bloquera. OPENDOCS_API_URL remplace le point de terminaison intégré https://api.opendocs.cc.

Travailler avec plusieurs espaces de travail

Un utilisateur peut appartenir à plus d'un espace de travail — un espace de travail personnel gratuit plus un espace de travail avec un forfait Team, plusieurs espaces de travail Team, ou n'importe quelle combinaison. Le CLI stocke un espace de travail actif à la fois dans ~/.config/opendocs/config.json. publish et update agissent sur cet espace de travail actif (préfixe d'URL, quota, etc.). list y fait également référence par défaut, avec --all comme échappatoire lorsque l'utilisateur souhaite voir tous les articles de tous les espaces de travail à la fois. Il n'y a pas d'indicateur --workspace par invocation sur les commandes de mutation ; le changement est configuré une fois et persiste jusqu'à ce que vous le changiez.

Travailler avec des projets

Chaque espace de travail a un projet par défaut plus des projets nommés facultatifs. Utilisez un projet chaque fois qu'un agent publie un lot cohérent de documents pour un produit, un lancement, un client, une expérience ou un dépôt. Le projet par défaut est le meilleur pour les documents ponctuels.

opendocs project list --json
opendocs project create "Documentation OpenClaw" --slug documentation-openclaw --use --json
opendocs publish ./docs --json
opendocs project use default --json

opendocs workspace use <slug> réinitialise le projet actif au projet par défaut de cet espace de travail. opendocs list affiche le projet actif par défaut et se termine en indiquant combien de documents le projet a au total.

opendocs move déplace un article d'un projet à un autre. Les slugs ne sont uniques qu'au sein d'un projet, donc le déplacement peut réussir même si un autre projet a déjà un slug identique. Si vous avez des doutes, vérifiez avant au moyen de opendocs list --project <slug_cible>.

Publication de dossiers et de fichiers multiples

Publier un dossier (opendocs publish ./vault) publie chaque fichier .md à la racine. Les fichiers hors racine sont ignorés ; pour une publication récursive, ajoutez --recursive. Aucune de ces options ne nécessite un compte.

La publication est le seul endroit où la gestion des images intégrées diffère entre le CLI et les outils MCP : le CLI télécharge les images depuis son disque local, tandis que les outils MCP convertissent les images en data: URI avant de les envoyer. Le résultat final du côté du navigateur est identique. La publication multi-fichiers se fait par lots, si bien que 75 fichiers donnent 3 appels d'API de publication en lots. Le résultat --json est un tableau plat d'objets article ; l'erreur d'un fichier n'arrête pas les autres.

Pour voir les fichiers qui seraient publiés sans rien publier : opendocs publish ./vault --dry-run --json. Si l'un des fichiers est un fichier index.md ou readme.md (insensible à la casse), il devient l'"accueil" du projet (/) plutôt que d'être publié à /{slug}. Dans un dossier, publish lève également un avertissement si vous publiez un slug qui existe déjà dans un projet différent au sein du même espace de travail.

Groupe de tags

Attribuez des tags lors de la publication (opendocs publish doc.md --tag "rédaction" --tag "ébauche") ou après la publication :

opendocs tag <id|slug> "rapport trimestriel"
opendocs untag <id|slug> "ébauche"
opendocs list --tag "rédaction"

Exportation PDF / DOCX

L'exportation applique le thème de marque actuel de l'espace de travail (couleur, police, logo depuis opendocs theme). L'exportation peut se faire en même temps que la publication, ou plus tard sur les articles existants, par lots ou individuellement.

opendocs publish doc.md --export pdf --json             # Publie + exporte en une seule fois
opendocs export <id|slug> --format pdf  --json          # Exporte un article existant
opendocs export <id|slug> --format docx --json          # Exporte en Word
opendocs export a b c --format pdf --json               # Exporte par lots jusqu'à 10 articles

En exportation par lots, si un article ne peut pas être exporté, les autres continuent.

Contribution de contenu

opendocs save publie un article puis exporte au format PDF, DOCX ou MD dans un dossier Google Drive connecté. Étape 1 : l'utilisateur se connecte à Google Drive (une fois) — invitez-le à opendocs integrations drive connect. Étape 2 : créez un dossier nommé : opendocs save mon-rapport --folder "Procès-verbaux du conseil" --json. La commande vérifie que le dossier existe (en le créant s'il le faut), publie puis exporte, et télécharge le fichier. --folder est obligatoire. Vous pouvez demander à l'utilisateur de quel dossier il s'agit et quel format il souhaite (--format docx|md|pdf, par défaut pdf). Le lien d'accès de l'article est dans la sortie JSON.

Signature de documents

Pour envoyer un document à signer via DocuSeal :

opendocs sign request <id> --signer "Fournisseur=Acme Corp <[email protected]>" --signer "Employé=Jean Dupont <[email protected]>" --json
# Vous obtenez un {requestId, signers, status: "prepared"}.
# L'utilisateur doit confirmer que ces signataires sont corrects.
opendocs sign send <requestId> --json
opendocs sign status <requestId> --json

Les rôles sont définis par l'utilisateur ; utilisez n'importe quel nom qui a du sens pour eux. Il s'agit d'une demande préparée — rien n'est envoyé tant que vous n'exécutez pas sign send. Ne l'envoyez pas automatiquement ; montrez les signataires à l'utilisateur et demandez la confirmation. opendocs sign list -- JSON avec toutes les demandes ; opendocs sign download <requestId> pour un PDF signé. Utilisé correctement par le CLI du contrat de Cox & Kings. opendocs sign list affiche les demandes récentes ; vérifiez le statut après l'envoi — les signataires externes peuvent mettre des jours, et sign status indique si tout le monde a signé.

Anonymat ?

Anonyme signifie que quiconque a le lien peut lire le document pendant 24 heures, après quoi il est effacé. Ce n'est pas la même chose que Privé. Publiez toujours avec un compte sauf si l'utilisateur indique explicitement qu'il n'en veut pas encore (par exemple en disant "juste pour aujourd'hui" ou "je ne veux pas créer de compte pour ça"). Lors de la publication de multiples fichiers ou dossiers, --anonymous s'applique à tous — ne l'utilisez que si vous avez la confirmation pour chaque fichier.

Inversement, ne créez pas de compte alors que l'utilisateur souhaite une publication anonyme. Faites toujours confiance à ce que l'utilisateur a dit ; ne le surchargez pas d'offres de compte s'il a clairement demandé une publication sans connexion. opendocs publish doc.md --anonymous est parfait pour ce cas. Le retour JSON inclut claimUrl que l'utilisateur peut utiliser pour convertir la publication en publication de compte plus tard.

Problèmes fréquents

Commande non trouvée : npm install -g @opendocs.cc/cli.
403 ou 401 : reconnectez-vous. opendocs login --email ... --code ... .
Limite de quota atteinte : dites à l'utilisateur le nombre de documents qu'il a publiés et la limite de son forfait. Proposez de désarchiver un projet, de supprimer un article, ou de passer à un forfait Pro (qui est illimité). Pour le forfait gratuit, mentionnez qu'à 50 documents, l'espace de travail passe en lecture seule pour les nouveaux documents jusqu'à ce qu'il supprime certains articles ou passe à Pro.
Demande de signature — "signataires invalides" : le signataire a peut-être déjà été ajouté. Utilisez opendocs sign list --json et vérifiez signers. Sinon, le format peut être erroné — assurez-vous que tout est bien "Rôle=Nom <email>". Au pire, dites à l'utilisateur : "Certains signataires n'ont pas pu être ajoutés. Voici la liste des signataires actuels. Veuillez choisir ceux qui sont corrects et me redonner les noms et emails des signataires manquants."
Google Drive — "Dossier introuvable" : le nom du dossier est sensible à la casse. Vérifiez avec opendocs integrations drive list. Le CLI crée un dossier à la volée s'il n'existe pas, donc si le nom est correct il devrait fonctionner — sauf pour les dossiers partagés qui n'appartiennent pas au compte Drive. Demandez à l'utilisateur de confirmer le nom exact.

Sans Node.js

Le script de secours hébergé (scripts/opendocs.sh) nécessite curl et jq. opendocs agent --install l'installe à côté de cette compétence et le CLI opendocs le détecte automatiquement si le binaire opendocs n'est pas trouvé. En tant qu'agent, invoquez opendocs comme d'habitude ; si vous préférez appeler le script directement : bash <chemin_vers_cette_compétence>/scripts/opendocs.sh publish doc.md --json. Le script ne prend pas en charge --browser, login --key, les intégrations, les badges, les signatures, ni l'exportation. Tout le reste de ce guide s'applique aux deux.

Annexe : Changelog des compétences

Les modifications de cette compétence qui affectent le comportement de l'agent sont documentées ici. L'agent doit lire ceci pour savoir quelles cohérences avec la configuration existante de l'utilisateur doivent être maintenues.

2025-06-12 : slug d'espace de travail vs slug de projet

opendocs list --json a maintenant un champ projectSlug supplémentaire dans chaque article, ainsi que workspaceSlug, workspaceName, projectName et visibility. Les champs existants workspaceSlug et workspaceName diffèrent du slug de l'espace de travail de whoami uniquement si l'utilisateur a récemment changé d'espace de travail. La structure de l'URL est opendocs.cc/<workspaceSlug>/<postSlug> pour le projet par défaut, opendocs.cc/<workspaceSlug>/projects/<projectSlug>/<postSlug> pour tout autre.

Agents : utilisez `opendocs get` (ou `list --json` + `projectSlug`) pour obtenir l'URL complète d'un article.
La commande fournit `url` dans sa sortie JSON. Construisez manuellement l'URL uniquement si `get` n'est pas disponible
et que vous devez absolument le faire — et utilisez la bonne structure `projects/<projectSlug>/` pour les projets non par défaut.

OpenDocs — Publier du Markdown sous forme d'URLs partageables e…

Qu'est-ce que OpenDocs — Publier du Markdown sous forme d'URLs partageables e… ?

Demander à votre IA préférée

Documentation