unstructured : partitionner des PDF et des DOCX pour alimenter un pipeline LLM

Le problème : des formats fermés, une sortie unique

Un pipeline de RAG commence rarement par un fichier propre. Il commence par un PDF de contrat scanné, un DOCX avec des tableaux imbriqués, une page HTML dont la mise en page porte du sens. Ces formats ne partagent ni structure ni sémantique, et les traiter séparément conduit à réécrire la même logique d'extraction pour chacun. La bibliothèque unstructured vise à remplacer cette dispersion par une seule sortie : une liste d'éléments typés, où chaque fragment du document porte une étiquette comme Title, NarrativeText, Table ou ListItem, accompagnée de métadonnées de provenance. Le public visé est l'ingénieur qui construit une chaîne d'ingestion en Python et qui veut brancher un seul appel sur des dizaines de formats. Le README annonce plus de 60 types de fichiers pris en charge, ce qui donne la mesure de l'ambition : le partitionnement est le produit, pas un utilitaire annexe.

Comment le partitionnement produit des éléments typés

Le mécanisme central est une fonction de partitionnement qui prend un chemin de fichier et renvoie une liste d'objets. Le README décrit l'ensemble comme des fonctions modulaires et des connecteurs formant un système cohérent d'ingestion et de pré-traitement. Concrètement, le partitionnement lit le document, en extrait le texte et les tableaux, puis attribue à chaque bloc une catégorie. C'est cette catégorie qui rend la sortie exploitable en aval : un pipeline peut décider de ne conserver que les NarrativeText, ou de traiter les Table séparément avant de les sérialiser. Le README mentionne également des étapes d'enrichissement, de découpage (chunking) et d'embedding, mais rattachées à la plateforme commerciale et au serveur MCP Transform, pas au paquet open source. Cette distinction est le point le plus important à retenir de la documentation : la bibliothèque fournit la matière première structurée, pas la chaîne complète jusqu'au vecteur.

Installation et premiers appels

Le paquet est publié sur PyPI sous le nom unstructured, avec des extras pour les dépendances lourdes. Le README ne détaille pas la commande d'installation dans l'extrait fourni, mais la page PyPI liée par les badges est la référence à consulter pour la version courante. Les releases récentes listées dans le dépôt sont 0.27.0, 0.27.1 et 0.27.5, cette dernière datée du 28 août 2026, ce qui donne un ordre de grandeur de la cadence de publication. Le point d'entrée habituel est la fonction partition, appelée avec un chemin de fichier et un paramètre de stratégie ; le README ne cite pas d'exemple de code complet, donc vérifiez la signature exacte dans la documentation de partitionnement liée depuis le README avant d'écrire votre première ligne. Côté agent, le README décrit une autre voie : ajouter le serveur MCP Transform à la configuration MCP de votre client (via la commande mcp add ou le fichier de configuration selon l'outil), s'authentifier une fois, puis pointer l'agent vers un fichier local ou une URL. Cette seconde voie passe par le service commercial, pas par la bibliothèque installée localement.

Ce que la documentation ne dit pas

L'extrait du README est presque entièrement consacré au produit MCP et à la plateforme. Il ne contient ni exemple de code, ni tableau de formats avec le niveau de support réel, ni indication sur le coût mémoire d'un gros PDF. La phrase sur les 60 formats vient du texte marketing, pas d'une matrice de compatibilité vérifiable dans le matériel fourni. Autre angle mort : les performances. Aucun chiffre n'est donné, et je n'en inventerai pas. Si votre charge de travail repose sur des milliers de PDF scannés, la question de l'OCR et de son coût par page reste ouverte à la lecture de ces seuls éléments. La mention de langages de programmation indique HTML comme langage principal du dépôt, ce qui reflète probablement la part de documentation et de pages statiques, pas la nature du code Python de la bibliothèque. Ne tirez pas de conclusion sur la qualité du code à partir de ce champ.

Les cas où unstructured est le mauvais outil

Si tous vos documents sont du texte brut ou du Markdown, la couche de partitionnement n'apporte rien : vous payez une dépendance, un temps d'import et une surface d'API pour retrouver le texte que vous aviez déjà. Même logique pour un flux de courriels courts ou de tickets structurés en JSON : le typage des éléments n'a de valeur que quand la mise en page porte de l'information. Autre cas défavorable, la latence stricte. Le partitionnement d'un PDF passe par une extraction de texte, parfois par de l'OCR, et cette étape est intrinsèquement plus lente qu'une lecture de fichier. Un service qui doit répondre en quelques dizaines de millisecondes à une requête utilisateur n'a pas sa place ici, sauf à pré-calculer les éléments en amont et à les stocker. Enfin, la sortie typée n'est pas une garantie de qualité : un tableau mal détecté dans un PDF complexe produira un élément Table dont le contenu est faux, et rien dans la bibliothèque ne vous alertera. Le contrôle qualité reste à votre charge.

Face à Docling et aux parseurs spécialisés

L'alternative la plus directe dans l'écosystème open source est Docling, d'IBM, qui vise aussi la conversion de documents en structures exploitables pour l'IA. La différence d'approche tient au point de départ : unstructured construit sa sortie autour d'une liste plate d'éléments typés, ce qui simplifie le filtrage et le découpage en morceaux, tandis que Docling met l'accent sur une représentation du document plus proche de sa mise en page d'origine. Pour un pipeline qui doit découper puis indexer, la liste d'éléments est souvent plus commode à manipuler. Pour une conversion fidèle vers un format balisé, l'autre approche peut mieux convenir. Il existe aussi des parseurs spécialisés par format, par exemple les bibliothèques dédiées au PDF, qui offrent un contrôle plus fin sur une seule famille de fichiers mais vous laissent assembler vous-même la couche multi-format. Le choix se résume donc à ceci : unstructured mutualise la diversité des formats au prix d'un contrôle plus grossier sur chacun d'eux.

Maintenance, licence et coût de mise à jour

Le dépôt n'est pas archivé et la dernière poussée listée est datée du 8 septembre 2026, soit peu après la release 0.27.5. La cadence observée sur les releases récentes est de plusieurs versions par mois, ce qui implique de suivre les changements de comportement du partitionnement au fil des mises à jour. La licence est Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence. Rien dans le matériel fourni n'indique de clause supplémentaire, mais les conditions exactes figurent dans le fichier LICENSE.md du dépôt, à lire avant toute redistribution. Le coût réel d'adoption se situe moins dans la licence que dans les dépendances : les extras liés à l'OCR et au traitement d'images pèsent lourd dans une image de conteneur, et chaque montée de version peut modifier la façon dont un format est découpé, ce qui casse silencieusement un index construit sur une version antérieure.

Conclusion éditoriale

Adoptez unstructured si vous devez ingérer des formats variés (PDF, DOCX, HTML, images) dans un pipeline Python et que vous acceptez de gérer vous-même OCR, découpage et indexation. Passez votre chemin si vos documents sont tous du texte brut ou du Markdown : la couche de partitionnement n'apporte alors rien. Avant de vous engager, vérifiez deux points précis dans votre environnement : le comportement de la fonction partition sur un échantillon représentatif de vos fichiers, et la taille de l'installation avec les extras dont vous avez besoin, notamment ceux liés à l'OCR.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Unstructured-IO/unstructured on GitHub