Demandez à un agent IA de « rédiger le contrat de service pour Contoso » et il le fera, avec ses propres mots, ses propres titres, et un total qu’il aura calculé dans sa tête. C’est la mauvaise répartition du travail. Avec GroupDocs.Assembly.Mcp exécuté localement (dnx GroupDocs.Assembly.Mcp --yes), Claude Desktop, Cursor ou Copilot demandent à votre modèle Word quels champs il faut, les remplissent à partir de vos notes, et le moteur rend le contrat, le tableau et les calculs inclus, sans que le modèle ne touche à la mise en page :

Rédigez le contrat de service pour cette commande en utilisant contract-template.docx et enregistrez-le au format PDF : Contoso Pharma, Keizersgracht 210 Amsterdam, contact Dr. Lena Brandt ; 12 mois d’hébergement géré à 4 800 EUR, 12 mois de support à 1 200 EUR, un atelier d’intégration à 3 500 EUR ; remise de 5 pour cent.

La version étape par étape avec configuration et dépannage se trouve dans la documentation : Comment générer des documents à partir de modèles avec des agents IA en utilisant MCP.

Pourquoi le modèle ne devrait-il pas rédiger le document ?

Parce qu’un document généré échoue de manières difficiles à détecter. La mise en page s’écarte de celle approuvée légalement. Une clause est paraphrasée en quelque chose qui se lit bien mais signifie autre chose. Un total provient de la prédiction du prochain token au lieu d’une multiplication. Et chaque exécution est légèrement différente, de sorte que la révision du mois dernier ne vous renseigne en rien sur le contrat de ce mois.

Un modèle renverse cela. Le service juridique possède contract-template.docx, avec ses titres, son bloc de signature et ses balises <<[customer.Name]>>. Le travail du modèle se réduit à ce qu’il fait bien : lire un e‑mail ou un ensemble de notes et les transformer en valeurs structurées. Le moteur fait le reste, de la même façon à chaque fois.

Comment l’agent sait‑il quoi remplir ?

Il interroge le modèle. get_template_fields lit les balises sans exécuter le moteur et renvoie les noms utilisés par le modèle, chaque champ qu’il lit, ainsi qu’un squelette JSON à remplir. Voici ce que le serveur a renvoyé pour notre modèle de contrat :

-> get_template_fields {"template":{"filePath":"contract-template.docx"}}
<- { "tagCount": 17,
     "dataSourceNames": [ "contract", "customer", "items" ],
     "dataSkeleton": {
       "contract": { "Number": "", "Date": "", "Discount": "" },
       "customer": { "Name": "", "Address": "", "Contact": "",
                     "Email": "" },
       "items": [ { "Title": "", "Quantity": 0, "UnitPrice": 0 } ] } }

Ce squelette est le contrat entre le modèle et le document. L’agent le remplit à partir du texte de la commande et le renvoie sous forme de dataJson.

Que se passe‑t‑il lorsque l’agent oublie un champ ?

Il est informé, précisément. Dans notre test, la première tentative de l’agent a omis l’adresse e‑mail du client. Le serveur a refusé et a indiqué le manque :

-> assemble_document {"template":{...},"dataJson":"{... no Email ...}"}
<- Document assembly failed for 'contract-template.docx': ...
   Can not get the value of member 'Email' on type ''. The template
   reads 'Email', which the data does not have. Check the spelling
   (names are case-sensitive) with get_template_fields and add it to
   the data. ... pass allowMissingMembers=true to output nothing for
   missing members and empty lists.

Un modèle rédigeant du texte libre aurait simplement omis la ligne. Ici, l’agent peut vous demander l’adresse, ou décider avec vous que le champ peut rester vide.

L’échange complet

user            agent                       Assembly MCP server
 | "Make the contract for this order: ..."                      |
 |-------------->|                                              |
 |               |-- get_template_fields {"template":          |
 |               |     "contract-template.docx"} ------------->|
 |               |<- dataSkeleton: contract, customer, items --|
 |               |   (fills the skeleton from the order text)  |
 |               |-- assemble_document {"dataJson":"{...}",    |
 |               |     "format":"pdf"} ----------------------->|
 |               |<- Saved to: .../contract-template_          |
 |               |   assembled.pdf ----------------------------|
 |<- "Contract ready: 3 items, total 75500 EUR, 5% discount."  |
   layout, table and arithmetic come from the template

Avec l’e‑mail ajouté, le deuxième appel a réussi :

-> assemble_document {"template":{"filePath":"contract-template.docx"},
     "dataJson":"{...}","format":"pdf"}
<- Assembled 'contract-template.docx' with inline JSON (JSON object)
   as PDF
   Saved to: .../contract-template_assembled.pdf

Le document contient un tableau de frais à trois lignes construit par un <<foreach>> dans la ligne du tableau, des montants calculés par le modèle (<<[item.Quantity * item.UnitPrice]>>), un total de 75 500 EUR provenant de items.Sum(...), et la ligne « Une remise de 5 pour cent s’applique. », qui n’existe que parce qu’une balise <<if>> a trouvé une remise dans les données. Le modèle n’a calculé aucune de ces valeurs.

Est‑ce meilleur qu’un service de modèles hébergé ?

C’est un compromis différent. Les services de modèles hébergés récupèrent votre modèle et vos données via HTTPS, les rendent dans leur cloud et facturent par document ou par crédit. Ici, le modèle, les données et le résultat restent dans un dossier sur votre machine ; le moteur est GroupDocs.Assembly s’exécutant en‑processus, et rien n’écoute sur un port. Ce qui est envoyé à votre fournisseur de modèle, c’est le texte de la commande que vous collez et le squelette que l’agent remplit, pas le contrat rendu. L’architecture est décrite dans le billet de la famille sur traitement de documents IA sur site.

Limites honnêtes

  • Mode d’évaluation : chaque document généré commence par la ligne « Evaluation Only. Created with GroupDocs.Assembly 26.7… », les classeurs enregistrés gagnent une feuille de calcul supplémentaire, et les modèles d’e‑mail ne conservent que leur corps en texte brut. Un fichier de licence ou des clés à consommation suppriment les trois.
  • La syntaxe du modèle est <<[name]>>. Les espaces réservés {{name}} sont laissés en texte ; get_template_fields l’indique.
  • Les modèles sont des entrées de confiance : les balises image et document chargent tout chemin ou URL que renvoie leur expression. Montez un dossier pour le serveur.
  • Dates : écrivez‑les sous la forme 2026-11-12T00:00:00 et formatez‑les dans le modèle (<<[contract.Date]:"d MMMM yyyy">>). Une date uniquement "2026-11-12" s’affiche comme 11 novembre sur une machine UTC+2 dans notre test.
  • L’agent est la source de données. Demandez‑lui de lister les valeurs qu’il a extraites avant de rendre le document, et examinez‑les.

FAQ

Un agent IA peut‑il remplir mon modèle Word sans le télécharger ?
Oui. Le serveur s’exécute localement via stdio et lit le modèle depuis le dossier que vous configurez ; le résultat est écrit à côté.

Quels formats le modèle peut‑il prendre ?
Word, Excel, PowerPoint, Markdown, HTML, texte et modèles d’e‑mail ; chacun peut être enregistré dans son propre format ou en PDF et autres. get_supported_formats les répertorie par modèle.

Que se passe‑t‑il si le modèle est maintenu par quelqu’un d’autre ?
C’est le but. Qui que soit le propriétaire du modèle modifie les clauses et la mise en page ; l’agent continue de remplir le même squelette, et get_template_fields lui montre tout nouveau champ la prochaine fois qu’il interroge.

Approfondir