Documents on-brand avec Claude Design : comment les créer une fois et les partager partout

C'est déjà arrivé à vous aussi : la marque est revue, vous recevez de magnifiques PDF, les logos SVG et les guidelines d'utilisation de la marque. Excellent matériel. Ensuite c'est à vous de transformer tout ça en templates utiles pour votre entreprise et de les rendre accessibles à votre équipe.

Parce que l'identité ne vit pas dans le manuel de marque — elle vit dans le devis que vous envoyez au client et dans le contrat que vous lui faites signer.

La génération de nos documents avait déjà évolué, passant des templates classiques Word et Google Docs vers un petit script custom que nous avons créé — IA pour organiser les notes en Markdown, les convertir en HTML, et Playwright pour créer le PDF — résultat : un lien téléchargeable pratique à utiliser n'importe où, en local ou par un agent dans le cloud.

Ça fonctionne. On l'utilise encore aujourd'hui pour les notes de réunion et les suivis.

La limitation principale est qu'il n'est pas flexible dans sa forme : on ne peut le mettre à jour qu'en modifiant le code source. Pour les devis et contrats, ce n'était plus suffisant — ils nécessitent souvent des ajustements, modifications, personnalisations qui demandent la flexibilité d'un document Word combinée à un design reproductible.

L'étape suivante était de tout refaire de zéro : du code vers un plugin IA. J'ai appris la marque à Claude une seule fois, j'en ai fait un outil et je l'ai transmis à mon équipe.

Trois éléments : un design system dans Claude Design, une skill qui génère les documents, un plugin pour distribuer le tout. Dans l'ordre.

Ce qu'est Claude Design

Claude Design est l'outil de design de Claude, encore en bêta. On y accède depuis le web sur claude.ai/design ou depuis la barre latérale de l'application desktop. Sur l'écran d'accueil, vous choisissez ce que vous voulez créer : Slides, Product prototype, Product wireframe, Document, Animation — ou vous partez d'un fichier existant.

Posons une limite d'emblée : ce n'est pas Lovable, Bolt ou v0, ces outils qui génèrent une application fonctionnelle en une fois. Claude Design fait du design — esthétique, mise en page, identité visuelle — pas du code. Si vous avez besoin d'un vrai logiciel, il passe la main à Claude Code. Pour mes documents, je n'avais pas besoin d'une application. J'avais besoin qu'ils soient justes.

Étape 1 — Le design system : là où tout se joue

Par où commencer ?

Ce qui compte, c'est le design system — le langage visuel de la marque : couleurs, typographies, espacements, composants, logos. C'est ce qui distingue un document qui vous ressemble d'une production générique sortie d'une IA. Une fois qu'il existe, tout ce que vous générez naît déjà à l'intérieur de votre identité.

Dans Claude Design, vous le créez via "Add a design system". Trois chemins possibles, selon ce que vous avez sous la main :

• Create here — connectez Figma ou GitHub, ou importez des slides et des assets.
• Create using Claude Code — fidélité maximale si la marque existe déjà sous forme de composants React sur votre machine.
• Add fonts, logos and assets — glissez-déposez polices, logos et documents décrivant la marque.

Claude Design offre plusieurs options pour démarrer : l'URL de votre site déjà mis à jour, un fichier .fig Figma, un repo GitHub avec la marque. J'avais les PDF et les logos de l'agence, donc j'ai utilisé "Add fonts, logos and assets" et j'ai tout fourni — plus l'adresse de mon site, que j'avais déjà refait avec la nouvelle marque, offrant à Claude des polices et des couleurs "en production" dont il pouvait s'inspirer.

Ensuite vous le laissez travailler — et là il faut vraiment de la patience. Une bonne demi-heure, voire plus. Ce n'est pas instantané parce qu'il construit le système sérieusement : palette, échelles typographiques, espacements, composants.

À la fin, il est prêt et sélectionnable en haut de chaque projet — dans mon cas l'Arkad Design System. À partir de là, chaque design part déjà dans la bonne marque.

Étape 2 — Les modèles de documents

Le design system est prêt. Qu'est-ce que je génère maintenant ?

Les modèles que j'utilise vraiment : devis, contrat et les autres documents formels qui se retrouvent entre les mains du client. Pas un catalogue théorique — ceux qu'on ouvre chaque semaine.

Ils sortent cohérents entre eux parce qu'ils naissent du même langage. Les documents rapides et les suivis, je les ai laissés sur l'ancien générateur : là, le flux Markdown→PDF est très bien. Le soin du détail compte là où le client signe.

Quand j'ai été satisfait, j'ai exporté le tout en .zip : modèles et design system ensemble. Ce fichier est la brique de tout le reste.

Étape 3 — Du package à la skill : testez d'abord sur du vrai

C'est maintenant le moment de donner à Claude le fichier .zip pour créer la Skill — les instructions plus les templates qui lui indiquent comment produire un document Arkad. Pour ça, Claude Code comme Cowork fonctionnent. J'ai commencé par Cowork parce que je voulais le tester immédiatement sur un vrai fichier, avec des données réelles, pas sur un exemple bidon.

Le premier passage était bon. Pas parfait : deux ou trois détails à corriger, deux ou trois règles à écrire noir sur blanc plutôt que de les supposer acquises. Je tiens au texte justifié et aux lignes bien alignées dans les documents — ce genre de chose, une IA ne le devine pas, il faut le lui imposer par écrit.

J'ai corrigé la skill, refait le test, itéré jusqu'à ce que le résultat soit ce que j'enverrais vraiment à un client. Seulement alors je l'ai figée.

Tester sur un cas réel avant de bloquer la skill permet de corriger les imprécisions avant de l'utiliser sérieusement.

Étape 4 — De la skill au plugin : le pourquoi, brièvement

Skill validée, je suis passé à Claude Code pour en faire un plugin.

Pourquoi un plugin plutôt que de laisser une skill ?

La distribuabilité — c'est la raison numéro un.

Vous pouvez partager une skill : envoyez les fichiers à un membre de l'équipe, expliquez-lui où les mettre. Ça fonctionne. Un plugin est plus pratique : vous le publiez une fois et n'importe qui l'installe avec une commande, sur son propre ordinateur. Une fois installé, il est disponible dans chaque conversation — pas seulement quand vous avez ouvert le bon dossier.

Un plugin est un dossier autosuffisant avec une structure précise :

arkad-documents/
├── .claude-plugin/
│   └── plugin.json        # manifeste : nom, version, description
├── skills/
│   └── arkad-documents/
│       ├── SKILL.md        # quand s'activer + comment générer le document
│       └── assets/         # templates HTML + Arkad Design System
└── README.md

Le cœur, c'est plugin.json, et il peut être aussi minimal que ça :

{
  "name": "arkad-documents",
  "version": "0.1.0",
  "description": "Génère des documents Arkad (devis, contrat, audit, NDA) dans la charte officielle",
  "author": { "name": "Arkad Consulting" }
}

Étape 5 — Le marketplace

Un plugin installé sur mon ordinateur règle mon problème. Mais mon équipe génère des documents aussi, et si ce qui sort de leur machine est différent, on repart de zéro.

Pour distribuer le même plugin à toute l'équipe — avec des mises à jour centralisées — il faut un marketplace : un catalogue qui liste vos plugins et indique où les trouver. J'en ai créé un privé pour Arkad — en pratique un repo GitHub avec un fichier marketplace.json :

{
  "name": "arkad",
  "owner": { "name": "Arkad Consulting" },
  "plugins": [
    {
      "name": "arkad-documents",
      "source": "./plugins/arkad-documents",
      "description": "Documents Arkad dans la charte officielle"
    }
  ]
}

À partir de là, c'est simple. Dans Claude Code, ça tient en deux lignes — un membre de l'équipe enregistre le marketplace une fois :

/plugin marketplace add Arkad-Agency/arkad-marketplace

et installe le plugin :

/plugin install arkad-documents@arkad

Voilà. Maintenant chacun génère devis, contrats et autres documents formels identiques aux miens, dans la même charte, sans que j'aie à envoyer des fichiers ou à expliquer quelle est la bonne version. Quand j'améliore quelque chose — une couleur, une section, un nouveau type de document — je mets à jour le repo et au prochain refresh tout le monde l'a. Un repo privé suffit : c'est juste pour nous.

Un piège à connaître : Cowork et Claude Code sont des environnements séparés

Il y a un détail ici qui fait perdre du temps si on ne le sait pas. Un plugin installé dans Cowork n'est pas installé dans Claude Code, et inversement : les deux environnements ont leurs propres plugins et leurs propres marketplaces, gérés séparément. Il n'y a pas de synchronisation automatique.

Et ce ne sont pas seulement deux enregistrements distincts — chaque environnement s'installe à sa façon. Dans Cowork, tout passe par l'interface : ouvrez Customize → Plugins et cliquez sur +. De là, deux voies au choix — connecter un marketplace (en le pointant vers le même dépôt Arkad-Agency/arkad-marketplace) ou charger directement un fichier .plugin. Les deux marchent, mais je privilégie le marketplace : quand j'améliore le plugin, la mise à jour arrive à tout le monde au rafraîchissement suivant, alors qu'un fichier .plugin est un instantané figé qu'il faudrait redistribuer à la main.

Si vous prenez quand même la voie du fichier, ce .plugin n'a rien d'exotique : c'est un zip du dossier du plugin, avec une autre extension. Depuis le dossier, vous en empaquetez le contenu :

cd plugins/arkad-documents && zip -r -X ../../arkad-documents.plugin . -x "*.DS_Store"

Le fichier arkad-documents.plugin obtenu est ce que vous déposez dans Cowork. En passant par le marketplace — dans Cowork comme dans Claude Code — vous ne le construisez jamais : l'installation assemble le dossier directement depuis le dépôt.

Dans Claude Code, pas d'interface pour ça — ce sont les deux mêmes lignes que plus haut : /plugin marketplace add Arkad-Agency/arkad-marketplace puis /plugin install arkad-documents@arkad. Le même catalogue que celui de Cowork, piloté depuis le CLI. Dans tous les cas, ça se configure une fois par environnement : chaque membre de l'équipe l'enregistre là où il travaille vraiment — dans Cowork, dans Claude Code, ou dans les deux.

Ce qu'il faut retenir

Pour les documents rapides, l'ancien générateur reste en place, mis à jour à la nouvelle marque : changer les couleurs et l'en-tête suffisait. Le code était déjà là et fonctionnel — autant le garder.

Pour les devis, contrats et rapports — là où le soin compte et où le client signe — il y a maintenant le plugin. Je l'installe en une commande et le document sort dans la bonne charte, que ce soit moi ou n'importe qui dans l'équipe.

Le changement a été de transformer une skill en quelque chose qui s'installe, se versionne et se distribue comme n'importe quel logiciel interne normal.

À partir de là, la cohérence a cessé de dépendre de qui se souvient d'ouvrir le bon template.

Comment on l'utilise aujourd'hui : mon équipe et moi rédigeons le contenu — devis, contrat, rapport — en Markdown, dans Claude ou Hermes. Quand le contenu est validé, on le passe à la skill, qui applique la finition de marque Arkad. Quel que soit l'expéditeur, la structure qui sort est pratiquement identique.

Le rebranding n'a été que l'occasion de mettre tout cela en place.