Préparer des documents pour un LLM : la chaîne complète

Un grand modèle de langage (LLM) qui répond à partir de vos documents ne vaut que ce que vaut le texte qu'on lui donne. Avant tout réglage de modèle ou d'index, il faut une chaîne de préparation : inventorier, convertir en texte structuré, reconnaître le texte des scans, isoler tableaux et images, poser des métadonnées, retirer doublons et versions périmées, puis garder l'ensemble à jour. Ce site détaille chaque étape, avec les outils et les API documentés au 15/11/2026.

Les sept étapes, dans l'ordre

Le découpage en morceaux et le calcul des vecteurs viennent après : ils sont traités sur le site consacré au RAG (génération augmentée par récupération) et sur celui consacré aux embeddings.

Pourquoi passer par du Markdown

Un PDF décrit une mise en page, pas une structure. Un fichier Word ou PowerPoint contient de la structure, mais dans un format que toutes les API ne lisent pas. La documentation de l'interface de programmation (API) d'Anthropic le dit clairement : pour les fichiers que le bloc document ne prend pas en charge, « par exemple .docx et .xlsx », il faut les convertir en texte brut (Files API). Côté Google, la documentation Gemini précise que les documents autres que PDF, comme le TXT, le Markdown ou le HTML, sont traités comme du texte brut, sans le contexte visuel.

Le Markdown règle les deux problèmes : il reste du texte, et il garde les titres (#, ##), les listes et les tableaux. Des outils libres le produisent directement : Docling (licence MIT) exporte en Markdown, HTML ou JSON, et MarkItDown de Microsoft (licence MIT) convertit PDF, Word, Excel et PowerPoint.

Ce qui casse le plus souvent

• Les scans : aucun texte, seulement une image. Sans OCR, la recherche dans l'index ne trouve rien, même si un modèle qui lit les images peut parfois s'en sortir page par page.
• Les tableaux : mal extraits, les cellules deviennent une suite de mots sans lien. Ce sont souvent eux qui portent les prix, les délais et les références.
• Les versions : trois versions du même contrat dans l'index, et la réponse cite la mauvaise.
• Les suppressions : un document retiré du partage reste dans l'index si la synchronisation ne traite pas les éléments supprimés. La requête delta de Microsoft Graph, par exemple, signale ces éléments par une propriété deleted qu'il faut traiter.

Un contrôle qui vaut toutes les métriques

Après conversion, ouvrez dix fichiers Markdown au hasard et comparez-les à l'original : ordre de lecture, tableaux, accents, en-têtes répétés. C'est le contrôle le plus rapide de la chaîne, et il évite d'accuser le modèle d'erreurs qui viennent de l'extraction.

Construire sa chaîne ou s'appuyer sur une plateforme

Monter cette chaîne soi-même se justifie quand les documents sont nombreux, sensibles ou très mis en page. Pour un premier assistant, une plateforme qui s'en charge peut suffire : ALMA, la plateforme d'IArche qui édite ce site, annonce par exemple l'import de fichiers « PDF, DOCX, TXT, CSV », « automatiquement découpés, vectorisés et indexés ». Dans les deux cas, la qualité des documents d'entrée reste à votre charge : c'est l'objet des pages de ce site.

Exemple illustratif

Prenons un bureau d'études de quinze personnes : des notes de calcul en PDF natif, des plans annotés scannés, des tableaux de prix sous Excel et un SharePoint où chacun dépose ses fichiers. Sa chaîne aurait quatre branches d'entrée (PDF natif vers Docling, scans vers OCR, Excel vers MarkItDown, SharePoint par requête delta), une seule fiche de métadonnées par document, et un contrôle des doublons avant chaque indexation.