Un formulaire Word avec des zones de texte, une liste déroulante de département et une case à cocher de code de conduite, ainsi qu’une feuille de calcul contenant trente nouvelles recrues : c’est une matinée de copier‑coller, ou une seule invite. Avec le serveur GroupDocs.Editor MCP exécuté localement, Claude, Cursor ou Copilot demandent d’abord au formulaire quels champs il possède, puis remplissent une copie par ligne et enregistrent chaque fichier sous le nom de la personne. La mise en page du formulaire reste intacte, et toute valeur qui n’a pas de champ correspondant est signalée au lieu d’être simplement ignorée :

Lire new-employee-form.docx, puis remplir une copie par ligne de new‑hires.csv et nommer chaque fichier d’après l’employé.

La version pas à pas se trouve dans la documentation : How to fill Word form fields from data with an AI agent.

Qui lit la feuille de calcul ?

L’agent le fait, et il faut le dire clairement. Le serveur Editor travaille sur le formulaire Word ; il ne lit pas votre CSV ou votre classeur. L’agent lit les lignes avec ses propres outils de fichiers, ou vous les collez, puis effectue un appel fill_form_fields par ligne avec un outputName par personne. Cette séparation est une fonctionnalité : les données n’ont jamais besoin d’être dans un format compris par le serveur, et l’agent peut les nettoyer en cours de route (séparer un nom complet, normaliser une date) avant qu’elles n’entrent dans le formulaire.

Interroger d’abord le formulaire

Les noms de champs dans les formulaires Word ne correspondent rarement à l’étiquette affichée sur la page. L’étiquette indique « Full name : », alors que le champ peut s’appeler FullName, Text1 ou Name_Employee. Deviner, c’est comment les formulaires reviennent à moitié vides. get_form_fields renvoie les vrais noms, les types et les valeurs actuelles. Capturé depuis GroupDocs.Editor.Mcp 26.10.0 sur un formulaire d’intégration synthétique (sortie raccourcie) :

-> get_form_fields {"file":{"filePath":"new-employee-form.docx"}}
<- { "count": 6, "fields": [
     { "name": "FullName",   "type": "Text",     "value": "" },
     { "name": "Email",      "type": "Text",     "value": "" },
     { "name": "StartDate",  "type": "Text",     "value": "" },
     { "name": "Department", "type": "DropDown",
       "value": { "options": [ "Engineering", "Finance", "Sales",
                               "Operations" ], "selected": "Engineering" } },
     { "name": "Agree",      "type": "CheckBox", "value": false },
     { "name": "Newsletter", "type": "CheckBox", "value": false } ] }

La liste déroulante vient avec ses options, de sorte que l’agent peut faire correspondre « finance » dans la feuille de calcul à l’entrée exacte « Finance » au lieu d’inventer un sixième département.

Puis remplir une ligne

-> fill_form_fields {"file":{"filePath":"new-employee-form.docx"},
     "values":{"FullName":"Amara Okafor",
               "Email":"amara.okafor@northwind.example",
               "StartDate":"2026-12-01","Department":"Finance",
               "Agree":"true","Phone":"+31 10 555 0100"}}
<- Updated 5 field(s) in 'new-employee-form.docx': FullName, Email,
   StartDate, Department, Agree.
   Not found: Phone. Call get_form_fields for the exact names.
   Saved to: …/new-employee-form_edited.docx

La feuille de calcul contenait une colonne téléphone pour laquelle le formulaire n’a aucun champ. Le serveur a rempli les cinq champs existants et a indiqué celui qui manque. Lire la copie remplie avec get_form_fields montre les valeurs en place, "selected": "Finance" et "Agree": true inclus, et Newsletter reste décoché parce que la ligne ne le spécifiait pas autrement.

Le lot complet

new-hires.csv (agent reads it)          new-employee-form.docx
  Amara Okafor, Finance, ...  ---+
  Tomas Varga, Sales, ...     ---+      get_form_fields (once)
  ...                            |        -> FullName, Email, StartDate,
                                 |           Department, Agree, ...
                                 v
  fill_form_fields {"values":{...row...},
                    "outputName":"form-amara-okafor.docx"}   x one per row
     -> "Updated 5 field(s) ... Not found: Phone"
     -> form-amara-okafor.docx, form-tomas-varga.docx, ...

Trois instructions rendent le lot fiable : appeler get_form_fields une fois et mapper les colonnes aux noms de champs avant le premier remplissage ; donner à chaque ligne son propre outputName, sinon les copies s’accumulent sous les noms new-employee-form_edited.docx, new-employee-form_edited (1).docx, etc., sans le nom de personne ; et rassembler les lignes « Not found » dans un seul rapport à la fin plutôt que d’arrêter au premier problème.

Une invite qui fonctionne sur la première ligne

La plupart des échecs de lot surviennent sur la première ligne puis se répètent trente fois. Demandez d’abord un essai à blanc :

Lire les champs de new-employee-form.docx et l’en‑tête de new‑hires.csv. Montrer quelle colonne correspond à quel champ, et quelles colonnes n’ont aucun champ. Puis remplir uniquement la première ligne et s’arrêter.

L’agent répond avec un petit tableau de correspondance, Name -> FullName, Dept -> Department, Phone -> (no field), et un formulaire rempli que vous pouvez ouvrir. Si l’orthographe du département ou le format de la date est incorrect, vous le voyez une fois, corrigez l’instruction, puis demandez le reste. Cette étape de révision coûte une minute et fait la différence entre trente formulaires corrects et trente formulaires à vérifier manuellement.

Cela résout également les questions auxquelles la feuille de calcul ne peut pas répondre d’elle-même. Une cellule « Agree » vide doit‑elle signifier décoché, ou la ligne doit‑elle être ignorée ? « 2026-12-01 » doit‑il être inséré tel quel dans le champ date, ou sous la forme « 1 December 2026 » ? L’agent suivra tout ce que vous indiquez, mais il faut le lui dire.

Ce que les outils de formulaire gèrent en plus

Les champs texte, nombre et date sont remplis avec des chaînes ; les cases à cocher acceptent "true" ou "false" ; les listes déroulantes acceptent l’une de leurs options. format enregistre la copie remplie en DOC, RTF ou ODT au lieu de DOCX ; un formulaire rempli reste toujours un document Word, donc un PDF pour le nouvel employé constitue une conversion séparée ultérieurement. Un formulaire protégé par mot de passe s’ouvre avec password et reste protégé. La copie remplie est écrite par le moteur de champs de formulaire plutôt que via HTML, de sorte que les en‑têtes, pieds de page et numéros de page sont conservés tels quels. Les outils lisent les formulaires DOCX, DOC, DOCM, DOT, DOTX, RTF et ODT.

Limites honnêtes

  • Formulaires Word uniquement, et champs de formulaire hérités uniquement : les champs texte, case à cocher et liste déroulante que Word insère depuis Developer → Legacy Tools. Les contrôles de contenu ne sont ni listés ni remplis. Les formulaires PDF (AcroForms) ne sont pas pris en charge par ce serveur.
  • Le serveur ne lit pas la feuille de calcul ; l’agent fournit les valeurs, il faut donc vérifier le mapping des colonnes sur la première ligne avant de le laisser parcourir tout le fichier.
  • Un appel remplit un formulaire. Un lot de trente nécessite trente appels.
  • Le mode d’évaluation ajoute une ligne de bannière en haut de chaque copie remplie, de sorte que la sortie non licenciée est un brouillon, pas quelque chose à envoyer aux nouveaux employés.

FAQ

Comment l’agent connaît‑il les noms de champs ?
Il interroge : get_form_fields renvoie le nom, le type et la valeur actuelle de chaque champ, ainsi que les options de chaque liste déroulante.

Que se passe‑t‑il lorsqu’une valeur n’a aucun champ correspondant dans le formulaire ?
Elle est ignorée et mentionnée dans la réponse (« Not found: Phone »), afin que l’agent puisse la signaler.

Mon formulaire d’origine est‑il modifié ?
Non. Chaque remplissage crée un nouveau fichier ; le modèle reste vierge pour la ligne suivante.

Approfondir