Générer des documents Word à partir de données Excel en C#

Générer des documents Word à partir de données Excel signifie utiliser les lignes d'un tableur comme source pour un ou plusieurs fichiers Word structurés, généralement en suivant un modèle ou un flux de travail de génération de documents. Traditionnellement, cette tâche est gérée par le publipostage Word : vous mappez les colonnes Excel vers des champs dans un modèle .docx et laissez Word générer un document par ligne. La même tâche peut être automatisée en C# avec un SDK de document, ou poussée plus loin avec un agent documentaire IA qui traite la demande comme une instruction en langage naturel. Cet article compare les approches, montre où le publipostage atteint ses limites et présente un exemple C# fonctionnel basé sur Spire.Agent.Office, un SDK d'agent IA pour les documents Office.

Navigation rapide

• Que signifie générer des documents Word à partir d'Excel ?
• Le publipostage d'Excel vers Word
• Trois méthodes d'automatisation de la génération Word depuis Excel en .NET
• Générer des documents Word personnalisés depuis Excel en C#
• FAQ

1. Que signifie générer des documents Word à partir de données Excel ?

L'expression ressemble à « convertir Excel en Word », mais l'intention est différente. Convertir un fichier .xlsx en .docx modifie le format du fichier tout en conservant son contenu globalement identique. Générer des documents Word à partir de données Excel consiste à créer de nouveaux documents dont le contenu est dérivé de cellules d'un tableur : une fiche de commande par client, un rapport mensuel par région, un lot de lettres ou d'étiquettes à partir d'une liste d'adresses, ou un ensemble de factures à partir d'une feuille de commandes.

La structure récurrente du besoin est presque toujours la même :

Exprimé en langage courant, cela donne : « J'ai une liste de clients et leurs commandes dans Excel ; j'ai besoin d'un document Word pour chacun d'eux avec leurs informations, leurs articles et un total. » Le mot important est dérivé : le contenu du document provient des données, il s'agit donc d'une génération de données vers document, et non d'un simple changement de format.

C'est la demande que cet article traite. Tout ce qui suit concerne les différentes manières d'y répondre et le moment où vous devriez cesser de configurer les champs manuellement.

2. La méthode traditionnelle : le publipostage d'Excel vers Word

Au niveau de l'interface utilisateur, la réponse par défaut à « transformer cette liste Excel en plusieurs documents Word » est le publipostage Word. C'est la fonctionnalité à laquelle la plupart des gens pensent lorsqu'ils recherchent cette tâche, et Microsoft propose un guide étape par étape. Le mécanisme est simple et bien connu :

Vous placez un champ comme «NomClient» dans un modèle de lettre, vous le liez à la colonne Client de la source Excel, vous lancez la fusion, et Word écrit un document par ligne avec la valeur substituée. Comme le nombre de lignes peut se compter par milliers, cela transforme une tâche de « ouvrir un fichier, copier le texte, changer le nom » en une opération par lots sans aucun code.

Le publipostage est efficace pour un seul type de travail : insérer cette colonne dans ce champ, à plusieurs reprises. Les lettres, enveloppes, étiquettes et avis avec une mise en page fixe sont son domaine de prédilection. Il s'exécute dans Office, ne nécessite aucune programmation, et pour ces documents stables et basés uniquement sur des champs, c'est réellement l'outil approprié.

3. Les limites du publipostage

La limite est atteinte dès que le document cesse d'être un formulaire fixe avec des espaces vides pour devenir quelque chose qui doit dépendre des données. Le publipostage substitue des valeurs ; il ne décide pas de la structure, ne raisonne pas sur le contenu et ne compose rien de nouveau.

Comparez deux demandes. La première est ce que le publipostage gère :

« Mettez le nom du client à l'endroit prévu, l'adresse à l'endroit prévu, et la commande dans les détails de la commande. »

La seconde est la demande correspondant à la plupart des rapports réels :

« Lisez ce classeur Excel, analysez les données de chaque client, créez un rapport personnalisé avec leurs articles et totaux, ajoutez un résumé de leur comportement d'achat, et enregistrez chaque résultat sous forme de document Word distinct. »

La seconde demande échoue sur les trois hypothèses du publipostage :

• La structure varie. Un client avec trois articles a besoin d'un corps de document différent de celui d'un client avec trente articles. Les champs de fusion supposent une mise en page fixe avec des espaces vides fixes ; ils ne peuvent pas agrandir un tableau en fonction du nombre de lignes de données.
• Le contenu doit être calculé, pas copié. « Résumer le comportement d'achat » et « signaler les clients à forte valeur » produisent du texte et des décisions qu'aucune colonne ne contient. Il n'y a pas de champ source auquel les lier.
• La sortie est un lot de fichiers réels. Chaque enregistrement doit être son propre document Word avec son propre nom, et le flux de travail doit s'exécuter sans surveillance dans une application, et non depuis un assistant Office.

C'est la position honnête du publipostage, énoncée clairement : il est excellent pour le mappage de champs, mais devient moins adapté lorsque la structure du document, le contenu ou la logique de sortie doivent varier en fonction des données. Le besoin plus profond — transformer des données en documents — est un problème de génération, et c'est là que les méthodes d'automatisation ci-dessous entrent en jeu.

4. Transformer le besoin en instruction : l'approche par agent

L'alternative qui correspond à la vraie version du problème est un agent documentaire IA : une couche de langage naturel au-dessus d'un moteur de document déterministe. Au lieu d'énumérer des champs de modèle et du code par champ, vous décrivez la sortie, et l'agent peut gérer des exigences difficiles à exprimer avec un publipostage traditionnel — lire les données, façonner la structure, rédiger l'analyse — tandis que le moteur de document garantit qu'un fichier .docx (ou PDF) réel et bien formé est produit.

La valeur est plus facile à visualiser sous forme de chaîne :

Les étapes difficiles à exprimer avec un publipostage traditionnel — surtout les trois étapes intermédiaires — sont précisément là où un agent peut faire ses preuves. Il peut interpréter ce qu'une colonne signifie (« Montant total », « Ventes » et « Net » peuvent désigner le même concept sous trois en-têtes différents), adapter la structure du document à chaque enregistrement et composer les paragraphes de résumé. Ce que vous fournissez est une phrase, pas un mappage de champs.

Le message à retenir pour le reste de cet article : le publipostage mappe des colonnes Excel vers des champs Word ; un agent IA génère des documents à partir d'une exigence. Le premier est une étape de substitution de valeur, le second est ce que la demande était réellement.

5. Trois méthodes d'automatisation de la génération Word depuis Excel en .NET

Choisir la bonne approche compte plus que le code, car chaque approche a une courbe de coût différente. Pour une application .NET nécessitant ce flux de travail, les choix réalistes sont :

Un raccourci pour décider dans la plupart des cas :

• La forme ne change jamais, un champ par colonne, lettres en masse — le publipostage est difficile à battre.
• La forme ne change jamais mais vous avez besoin de code, déterministe et testable — utilisez une boucle de liaison de champs par SDK.
• Le document doit varier selon les données, inclure une analyse ou changer souvent — c'est là qu'un agent IA est rentable, car le coût d'un changement peut souvent être réduit à la mise à jour de l'instruction plutôt qu'à la modification de la logique de mappage et de mise en page dans le code.

6. Générer des documents Word personnalisés depuis Excel en C#

Une version concrète et fonctionnelle du besoin « un document Word par enregistrement » est un résumé de commande client. Les entrées sont un classeur de commandes clients et un modèle Word léger ; la sortie est un document personnalisé par client. La configuration complète — jeton, package et câblage du projet — est documentée dans le tutoriel Démarrage ; ici, nous nous concentrons sur l'appel de génération lui-même.

using Spire.Doc;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;

AIOptions options = new AIOptions
{
    SpireToken = spireToken,
    WorkDir = @"C:\order-ops\output",   // dossier où les documents générés sont écrits
    TimeoutMs = 300000
};

using (Document doc = new Document())
{
    // Le modèle fournit des ancres par enregistrement ; le classeur est la source de données.
    doc.LoadFromFile(@"C:\order-ops\templates\order-summary-template.docx");

    // savePath = null : une instruction produit un document par enregistrement,
    // écrit dans le dossier de sortie WorkDir. Pas de boucle C# sur les lignes.
    AIResult result = doc.AI(options).ExecuteInstruction(
        doc,
        "Lisez les données de commande client dans Q3-orders.xlsx. Générez un résumé " +
        "de commande Word indépendant par client, ligne par ligne. Incluez leurs informations " +
        "de contact, chaque article avec quantité et montant, les totaux de commande, " +
        "et un résumé d'un paragraphe sur leur comportement d'achat. Signalez les clients " +
        "dont le total dépasse 50 000 comme étant à haute valeur. Enregistrez chaque document " +
        "sous forme de fichier nommé output_ suivi du nom du client (par exemple " +
        "output_acme-order-summary.docx).",
        null,
        new[] { @"C:\order-ops\input\Q3-orders.xlsx" });

    if (result == null || !result.Success)
        throw new InvalidOperationException($"La génération a échoué : {result?.ErrorMessage}");
}

Trois détails comptent lorsque vous exécutez cela vous-même. Premièrement, l'instruction est l'endroit où réside la logique de génération : l'analyse (« résumé de leur comportement d'achat »), la logique conditionnelle (« signaler les clients au-dessus de 50 000 ») et la structure par enregistrement (« chaque article »). Deuxièmement, le classeur doit être propre : la première ligne est l'en-tête, un enregistrement par ligne, pas de lignes vides ou de cellules d'en-tête fusionnées — les mêmes règles que celles attendues par la source de données de Word. Troisièmement, le document de base ancre la mise en page de sortie ; un document légèrement structuré peut donner à l'agent un point de départ utile pour la structure de chaque enregistrement. Avec un document de base totalement vide, la même instruction produit un seul document composé.

Une règle de nommage est importante ici : les documents que l'agent écrit dans WorkDir doivent commencer par le préfixe output_, sinon le SDK ne les compte pas comme des fichiers générés. C'est pourquoi l'instruction ci-dessus demande des fichiers comme output_acme-order-summary.docx au lieu de simples noms de clients.

L'extension .docx sur votre cible d'enregistrement ou modèle de fichier choisit le format de sortie ; pointez la même instruction vers .pdf et l'agent exporte les documents identiques pour distribution, sans étape de rendu séparée.

Appels API clés

• Document.AI(options) — attache le processeur de document IA à un objet document Word
• ExecuteInstruction(doc, instruction, savePath, attachments) — exécute la génération ; un savePath à null signifie « écrire dans WorkDir », et le classeur est transmis dans attachmentPaths
• AIResult.Success / AIResult.ErrorMessage — vérifie l'exécution et fait remonter les erreurs

7. Ce que vous écririez sans agent

Par contraste, l'approche de liaison de champs par SDK pour le même travail fait tout explicitement. Ce qui suit est intentionnellement simplifié pour montrer la quantité de logique applicative impliquée ; une implémentation en production nécessiterait également de charger et de regrouper les données du classeur :

using Spire.Doc;
using Spire.Xls;

// Une forme fixe est correcte ; chaque variation demande plus de câblage.
foreach (DataRow row in customersTable.Rows)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(@"templates\order-summary-template.docx");

        // Rechercher-remplacer par ancre...
        doc.Replace("{{CustomerName}}", row["Customer"].ToString(), true, true);
        doc.Replace("{{TotalAmount}}", row["Amount"].ToString("C"), true, true);

        // Les articles vivent dans une seconde feuille : vous les joignez manuellement par client,
        // construisez un tableau et l'insérez à un signet...
        // La règle « signaler les clients à haute valeur » est un if/else que vous maintenez,
        // et le paragraphe de résumé par client est un modèle que vous écrivez à la main.
        doc.SaveToFile($@"out\{row["Customer"]}-order-summary.docx");
    }
    // ... et chaque nouvelle règle, colonne ou changement de mise en page signifie modifier ceci et recompiler.
}

L'agent ne supprime pas le besoin de code — il supprime le besoin de code de mappage et de mise en page. La différence réside dans l'endroit où se trouve la logique : dans un index de colonne et un rechercher-remplacer, ou dans une phrase que l'entreprise peut lire et modifier. Lorsque les règles métier ou les structures de documents changent fréquemment, l'approche en langage naturel peut réduire la quantité de code de mappage et de mise en page à maintenir. Le modèle « modèle + données » s'étend au-delà des résumés de commande : Génération de contrats par lots avec Spire.Agent.Office parcourt le même flux « une instruction, un document par enregistrement » appliqué aux contrats.

8. Où l'IA s'arrête et où commence la logique applicative

Une frontière utile n'est pas « ce que l'IA peut ou ne peut pas faire » mais ce que l'application doit continuer à posséder. Un agent de génération de documents repose sur du code déterministe ; il ne le remplace pas.

Votre application possède toujours les parties qui n'ont rien à voir avec la compréhension du tableur :

• Découverte et accès aux fichiers — trouver le classeur, vérifier les autorisations, préparer les entrées
• Planification du flux de travail — quand le travail s'exécute, sur quel déclencheur, dans quel ordre
• Contrôle de la source de données — quel classeur est une entrée autorisée et d'où il provient
• Gestion des erreurs et tentatives — ce qui se passe lorsqu'un fichier est manquant ou qu'une exécution échoue
• Approbation finale — un humain examine les documents générés avant leur envoi

L'agent gère les étapes sémantiques :

• Compréhension — lire ce que chaque colonne signifie à partir de différents classeurs
• Planification de la structure — déterminer combien de sections et de lignes le document nécessite
• Analyse — transformer les données de commande en un résumé et un indicateur de haute valeur
• Composition — assembler des documents Word personnalisés à partir de l'exigence

Gardez la plomberie déterministe dans le code, où elle est testable et auditable, et confiez la génération sémantique à l'agent. Chaque côté fait ce pour quoi il est doué. Revue de contrat IA en C# montre la même séparation de l'autre côté : l'agent gère l'étape sémantique de la revue du contenu d'un document tandis que l'application conserve la gestion déterministe des fichiers autour.

9. FAQ

Est-ce un remplacement pour le publipostage Word ?

Pas un remplacement direct ; c'est le même travail poussé plus loin. Le publipostage mappe des colonnes Excel dans des champs Word fixes, ce qui suffit pour une lettre avec une forme stable. Un agent IA peut faire cela aussi, et peut également lire le classeur par contenu, façonner la structure par enregistrement, ajouter une analyse et composer de la prose. Pour des sorties simples à forme fixe, le publipostage reste un excellent outil ; lorsque le document doit varier selon les données, l'agent prend en charge une plus grande partie du travail.

Comment générer plusieurs documents Word à partir de données Excel ?

Passez le classeur en pièce jointe, définissez le chemin d'enregistrement sur null et pointez AIOptions.WorkDir vers un dossier de sortie. Une seule ExecuteInstruction avec une instruction ligne par ligne permet à l'agent de produire un document indépendant par enregistrement, chacun enregistré dans ce dossier. Aucune boucle C# sur les lignes n'est nécessaire pour le lot par enregistrement.

Puis-je générer des documents Word à partir d'Excel sans utiliser le publipostage ?

Oui. En C# vous pouvez lier un modèle avec le SDK directement, ou confier le classeur à un agent IA qui le lit à partir d'une instruction en langage naturel, et recevoir un vrai .docx ou PDF en retour. Le publipostage est une voie, pas la seule, et c'est la moins flexible une fois que le document nécessite une analyse ou des sections conditionnelles.

Quelle est la différence entre le publipostage et la génération de documents par IA ?

Le publipostage lie des champs définis à des colonnes définies : colonne Excel entrante, champ Word sortant. La génération de documents par IA interprète la demande et les données ensemble, elle peut donc interpréter ce que chaque colonne signifie et façonner la structure du document en conséquence, produire du contenu conditionnel ou analytique, et assembler plusieurs documents à partir d'une seule instruction. Le premier est une étape de mappage ; le second est une tâche de génération.

Puis-je générer des documents Word personnalisés à partir d'un fichier Excel en C# ?

Oui. Chargez un modèle Word ou un document vide dans Spire.Doc, attachez le classeur Excel et appelez ExecuteInstruction avec une description de la sortie personnalisée. L'agent lit chaque enregistrement et compose un document adapté, enregistré par enregistrement ou sous forme de fichier combiné, le tout dans votre propre application .NET.

Un agent IA peut-il utiliser des données Excel pour générer des documents Word ?

Oui. Spire.Agent.Office associe un modèle de langage à une couche Word et Excel déterministe, de sorte que l'instruction est comprise et que le résultat reste un vrai fichier Word que votre équipe peut ouvrir, formater et distribuer. L'agent interprète le contenu du tableur plutôt que de s'appuyer sur un mappage de colonnes fixe, ce qui permet de travailler avec des entrées hétérogènes.

Prêt à automatiser votre génération Word ?

Si votre flux de travail est « les données Excel deviennent des documents Word personnalisés », le chemin le plus rapide est de décrire la sortie et de laisser l'agent gérer le reste. Suivez le tutoriel Démarrage pour exécuter votre premier flux de travail Word piloté par instruction en .NET.

Lectures complémentaires

• Générer divers modèles Word avec Spire.Agent.Office — le même modèle de génération appliqué à différents modèles Word
• Automatisation de l'analyse et du classement des scores des étudiants avec Spire.Agent.Office — un flux de travail côté Excel qui alimente les documents que cet article génère
• Présentation du produit Spire.Agent.Office — SDK d'agent IA pour tous les formats de document Office