Chaque dépôt accumule des données structurées dont quelqu’un aura finalement besoin sous forme de document : les changements d’une version, les contributeurs de l’année, un inventaire d’API, une liste de risques ouverts. Les données sont déjà en JSON ; l’étape manquante est un fichier PDF ou Word formaté que le client, l’auditeur ou le manager ouvrira réellement. Avec GroupDocs.Assembly.Mcp fonctionnant localement à côté de Claude Code (claude mcp add avec dnx GroupDocs.Assembly.Mcp --yes), l’agent remplit un modèle Word conservé dans le dépôt à partir d’un fichier JSON du dépôt, et écrit le PDF, sans que personne ne formate un tableau :

Générer le PDF des notes de version 4.2.0 à partir de data/release-4.2.0.json avec templates/release-notes.docx, et un certificat de contribution pour chaque contributeur dans data/contributors-2026.json.

La version pas à pas avec configuration et dépannage se trouve dans la documentation : Comment générer un rapport PDF ou Word à partir de données JSON dans un dépôt avec Claude Code.

Pourquoi ne pas laisser l’agent de codage écrire le document ?

Les agents de codage sont très bons pour produire des données et assez mauvais pour produire des documents. Demandez‑lui « notes de version en PDF » et il écrira un fichier Markdown, puis un script qui le convertit, puis déboguera les polices du script. La version suivante, il le refait légèrement différemment. Le résultat ressemble à ce que la bibliothèque de conversion utilise par défaut, pas aux documents que votre entreprise envoie.

Un modèle fixe l’apparence et la place sous contrôle de version. templates/release-notes.docx est un fichier Word normal avec le logo, les styles de titres et un tableau, plus quelques balises <<…>>. Celui qui possède la mise en page l’édite dans Word ; l’agent ne le touche jamais. Le JSON est produit par votre outil de versionnage, ou par l’agent à partir de git log, et c’est la partie que l’agent de codage fait bien.

Cela rend également le travail révisable. Une pull request qui modifie data/release-4.2.0.json montre exactement quels changements apparaîtront dans les notes de version, ligne par ligne, dans un diff qu’un relecteur peut parcourir en une minute. Une pull request qui modifie un PDF généré ne montre rien du tout. Garder les données et la mise en page comme fichiers séparés et versionnés, et traiter le document comme quelque chose que vous rendez à partir d’eux, c’est la même idée que de séparer le code source et la sortie de construction, et cela s’applique aux documents pour les mêmes raisons.

À quoi ressemble le dépôt

repo/
  data/
    release-4.2.0.json       {"release":{...}, "changes":[...4 items]}
    contributors-2026.json   {"contributors":[...3 items]}
  templates/
    release-notes.docx       <<[release.Version]>>, <<foreach [c in
                             changes]>> table row, counts
    certificate.docx         <<[contributor.Name]>> ...
  out/                       GROUPDOCS_MCP_OUTPUT_PATH, in .gitignore
        |
        |  Claude Code -> GroupDocs.Assembly MCP server (local, stdio)
        v
  release-notes-4.2.0.pdf    pnair.pdf  tvarga.pdf  mrossi.pdf

Les appels

Premièrement, l’agent vérifie ce que le modèle attend, afin de pouvoir vous dire si le JSON manque quelque chose :

-> get_template_fields {"template":{"filePath":
     "repo/templates/release-notes.docx"}}
<- { "dataSourceNames": [ "release", "changes" ],
     "fields": [ "release.Product", "release.Version", "release.Date",
                 "changes[].Type", "changes[].Title",
                 "changes[].PullRequest", "changes[].Author" ] }

Ensuite, un appel le rend :

-> assemble_document {"template":{"filePath":
     "repo/templates/release-notes.docx"},
     "data":{"filePath":"repo/data/release-4.2.0.json"},
     "format":"pdf","outputName":"release-notes-4.2.0.pdf"}
<- Assembled 'release-notes.docx' with 'release-4.2.0.json' (JSON
   object) as PDF
   Saved to: .../release-notes-4.2.0.pdf

La ligne du tableau du modèle se répète une fois par changement, et sa dernière ligne compte les changements et les auteurs distincts avec changes.Count() et changes.Select(c => c.Author).Distinct().Count(). Ces nombres proviennent des données au moment du rendu, pas de l’agent.

Les certificats sont un fan‑out : un PDF par élément du tableau contributors, nommé d’après le pseudo du contributeur :

-> assemble_per_record {"template":{"filePath":
     "repo/templates/certificate.docx"},
     "data":{"filePath":"repo/data/contributors-2026.json"},
     "recordsPath":"contributors","fileNameField":"Handle",
     "format":"pdf"}
<- Assembled 3 of 3 document(s) from 'certificate.docx' with
   'contributors-2026.json', one per record (each record as
   'contributor'), as PDF.
   Saved to:
   .../pnair.pdf
   .../tvarga.pdf
   .../mrossi.pdf

recordsPath indique au serveur où se trouve le tableau lorsque le fichier JSON est un objet, ce qui est la forme habituelle des fichiers de données réelles.

En faire une habitude, pas une invite

Les agents suivent les instructions du projet concernant le moment d’utiliser un outil. Quelques lignes dans CLAUDE.md ou AGENTS.md transforment cela en convention :

Documents for people (release notes, reports, certificates) are generated
with the groupdocs-assembly MCP server from templates/*.docx and data/*.json.
Call get_template_fields first; never edit a template. Generated files land
in out/, which is in .gitignore. Dates in JSON as yyyy-MM-ddTHH:mm:ss.

Gardez les sorties hors du git. Par défaut le serveur écrit à côté de son dossier de stockage ; définissez GROUPDOCS_MCP_OUTPUT_PATH dans l’enregistrement du serveur vers le dossier out/ du dépôt et ajoutez ce dossier à .gitignore. Le JSON et le modèle sont la source ; le PDF est un artefact de construction, régénéré en quelques secondes, et le commettre ne produit que des diff que personne ne peut examiner.

Limites honnêtes

  • Mode évaluation : chaque PDF commence par « Evaluation Only. Created with GroupDocs.Assembly 26.7… ». Correct pour les essais ; licencez le serveur avant que quoi que ce soit ne quitte l’équipe.
  • Les modèles sont des entrées de confiance. Les balises d’image et de document chargent les chemins et URL que leurs expressions renvoient, donc traitez un modèle provenant d’une pull request comme du code, et donnez au serveur un seul dossier de stockage.
  • Dates : écrivez‑les sous la forme 2026-11-03T00:00:00 et formatez‑les dans le modèle (<<[release.Date]:"d MMMM yyyy">>). Une chaîne contenant uniquement la date a été décalée d’un jour sur une machine UTC+2 lors de nos tests ; l’image Docker s’exécute en UTC.
  • La génération par enregistrement ne lit que le JSON, et maxDocuments (100 par défaut) empêche un tableau inattendu d’être trop grand avant que quoi que ce soit ne soit écrit.
  • get_template_fields est statique : les valeurs calculées à l’intérieur des projections Select ou GroupBy ne sont pas suivies.

FAQ

Claude Code peut‑il générer un PDF à partir de JSON dans mon dépôt sans service cloud ?
Oui. Le serveur MCP s’exécute localement comme processus enfant de Claude Code et lit le modèle ainsi que le JSON depuis le dossier que vous indiquez.

Cela peut‑il fonctionner en CI ?
Le serveur est un serveur MCP, il a donc besoin d’un client MCP : Claude Code en mode sans tête, ou tout exécuteur d’agent. L’image Docker (ghcr.io/groupdocs-assembly/assembly-net-mcp) est la forme pratique pour un pipeline.

Word ou PDF ?
Les deux. Omettez format et la sortie sera un DOCX comme le modèle ; "format":"pdf" produit un PDF. get_supported_formats répertorie chaque cible par modèle.

Approfondir