MarkItDown est souvent mis, à tort, dans la même case que les extracteurs Web, et ce classement est faux. Il n’a ni crawler, ni moteur JavaScript, ni fonction pour aller chercher une URL puis nettoyer le bruit autour du contenu. Son vrai rôle est ailleurs : prendre des fichiers que vous avez déjà — un PDF, un document Word, une feuille de calcul, une présentation — et les convertir en Markdown lisible par un modèle de langage.
J’ai passé deux semaines à faire tourner MarkItDown de Microsoft sur une série de vrais documents, sur un seul Mac, en comparant chaque tableau à un manifeste préparé avant le test et en chronométrant chaque conversion. Verdict rapide : sur des fichiers propres, l’outil est rapide et fidèle ; son packaging cache en revanche un runtime de machine learning de 73 Mo dont vous n’avez pas forcément besoin ; et ses tableaux se dégradent parfois d’une manière qui passe le test « le texte est-il bien là ? » tout en échouant au test « les données sont-elles dans la bonne colonne ? ». Voici l’analyse complète, chiffres à l’appui.
Ce qu’est vraiment MarkItDown
MarkItDown est un utilitaire Python de Microsoft qui convertit des fichiers et des documents Office en Markdown optimisé pour les LLM. Pointez-le vers un PDF, un .docx, un .xlsx, un .pptx, une image, un fichier HTML ou quelques autres formats, et il vous renvoie du Markdown. Il peut s’utiliser de trois façons : en ligne de commande (markitdown file.pdf -o out.md, ou via un flux stdin), via une API Python (MarkItDown().convert(...)) et, en option, via un serveur MCP pour des workflows d’agents.
Le point clé, c’est surtout ce qu’il ne fait pas, parce que le README ne le promet pas et que mes tests l’ont confirmé : pas de crawling, pas de rendu JS, pas de suivi de liens, pas de pagination, et pas d’extraction du contenu principal à la manière de Readability. C’est un convertisseur de documents complet. Vous apportez les octets ; il les normalise. À elle seule, cette différence décide si l’outil a sa place ou non dans votre stack — j’y reviendrai souvent.
Le dépôt affiche des chiffres très visibles côté GitHub : 165 282 étoiles et 11 790 forks à la mi-juillet 2026, sous licence MIT, avec la dernière version (v0.1.6) publiée le 2026-05-26. Mais ce volume d’étoiles reflète surtout l’intérêt général pour les outils LLM chez Microsoft, pas forcément la maturité du cœur de conversion. Il y a aussi 833 issues ouvertes, et certaines valent le détour avant installation (j’y reviens plus bas).
HTML vers Markdown : rapide, complet… avec le bruit de fond
Comme le reste de ma série d’évaluation d’extracteurs repose sur les mêmes quatre pages web de référence, j’ai soumis à MarkItDown les mêmes fichiers HTML locaux — non pas pour le juger comme scraper, mais pour évaluer sa conversion HTML vers Markdown. Sur des pages bien structurées, le résultat est franchement solide.
Les quatre pages ont été converties avec l’installation de base, sans module supplémentaire, et tous les points de contrôle sur le contenu ont été conservés. L’article Wikipédia sur le web scraping (226 Ko) a reproduit fidèlement son arbre de titres — un h1, sept h2 et douze h3, correspondant à la structure réelle — et 418 liens ont été gardés sous forme de [texte](url). Le tableau de statistiques hockey 26×9 de la page Scrape This Site forms est devenu un tableau GFM propre de 27 lignes (en-tête + séparateur + 26 lignes de données), cellules vides comprises. Côté vitesse, rien à redire : médiane de 48 ms pour la page courte de citations, jusqu’à 352 ms pour l’article Wikipédia de 226 Ko.
Mais voici le revers, et ce n’est pas un bug : c’est un choix de conception. MarkItDown ne supprime pas le contenu parasite. Il convertit l’intégralité du <body>, donc le chrome du site reste là avec — et la quantité de bruit dépend de la densité de ce chrome.
| Page | Nombre de caractères en sortie | Titres (h1/h2/h3) | Liens | Lignes de chrome du site |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0,6 % (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1,2 % (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6,7 % (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12,4 % (42/338) |
Sur la page Books, presque sans interface, 0,6 % des lignes en sortie relèvent du chrome. Sur Wikipédia, on monte à 12,4 % — 42 lignes non vides sur 338 sont des éléments comme « Aller au contenu », « masquer la table des matières », « 22 langues », « récupéré de », ou encore les pieds de page cookie et licence. Les bandeaux de maintenance Wikipédia (« cet article nécessite des sources supplémentaires ») sont même rendus fidèlement en tableaux Markdown à deux colonnes, ce qui explique neuf lignes de tableau sur une page qui ne contient aucun vrai tableau de données.
MarkItDown ne se trompe pas ici. C’est un convertisseur de documents complet, pas un extracteur de contenu principal : convertir fidèlement du HTML vers du Markdown n’est pas la même chose qu’extraire proprement un article. Des outils comme Trafilatura ou Firecrawl cherchent à ne renvoyer que le contenu principal ; MarkItDown renvoie la page entière. En interne, son _html_converter.py retire <script> et <style>, puis passe tout le <body> à la bibliothèque markdownify — sans heuristique de contenu principal dans la chaîne. Si vous voulez seulement l’article, vous n’êtes pas sur la bonne couche.
Son terrain de jeu : PDF, DOCX, XLSX, PPTX
Les documents sont la vraie raison d’être de MarkItDown. Je l’ai testé sur de vrais fichiers publics — un article arXiv avec couche texte, le whitepaper Bitcoin, un PDF scanné uniquement en image que j’ai rendu sans aucune couche texte, ainsi que les fichiers DOCX/XLSX/PPTX de la propre suite de tests de MarkItDown (avec des UUID injectés pour repérer toute perte silencieuse de contenu).
| Document | Entrée | Nombre de caractères en sortie | Contrôles | Temps médian | Remarques |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF avec couche texte) | 2,2 Mo | 40,174 | 7/7 | 3,7 s (à chaud) | titre, « Transformer », « BLEU », « References » tous présents |
| Whitepaper Bitcoin (PDF 9 pages) | 184 Ko | 22,485 | 6/6 | 1,4 s | « Satoshi Nakamoto », « proof-of-work », « Conclusion » présents |
| PDF scanné (sans couche texte) | 89 Ko | 0 | 0/4 | 15 ms | sortie vide, aucune erreur, pas d’OCR |
| DOCX (test.docx) | 136 Ko | 4,651 | — | 70 ms | titres + tableau GFM ; UUID embarqués conservés |
| DOCX avec équations | 15 Ko | 240 | — | 101 ms | Office Math conservé en LaTeX |
| XLSX (test.xlsx) | 12 Ko | 808 | — | 57 ms | chaque feuille → ## SheetName + tableau GFM |
| PPTX (test.pptx) | 278 Ko | 2,047 | — | 52 ms | marqueurs de numéro de slide, tableaux, graphique → tableau |
La restitution du texte sur les PDFs avec couche texte est excellente — 7/7 contrôles sur l’article arXiv « Attention Is All You Need », 6/6 sur le whitepaper Bitcoin — et aucun fichier Office n’a perdu le moindre UUID sentinelle, donc pas de perte silencieuse sur les jeux de régression des mainteneurs. Petit point fort très utile : le chemin DOCX (via mammoth) préserve les équations Office Math en LaTeX et transforme equations.docx en vrai math $$...$$. Si vous envoyez des documents Word riches en maths à un LLM, c’est un vrai atout, même s’il est très ciblé.
Deux constats sur ce terrain méritent une attention particulière, car ce sont les plus susceptibles de vous piéger.
Le PDF scanné qui disparaît
Si vous donnez à MarkItDown un PDF composé uniquement d’images, sans couche texte, il renvoie une chaîne vide. Zéro caractère, aucune exception, aucun avertissement — conversion en environ 15 ms, puisqu’il n’y a rien à extraire. Le chemin PDF de MarkItDown repose uniquement sur l’extraction de texte (pdfminer et pdfplumber en arrière-plan), et aucune OCR n’est incluse dans l’installation de base ni dans les extras pip.
En traitement par lots, c’est important. Un développeur qui traite un dossier de PDF contenant des scans obtiendra des résultats silencieusement vides pour ces fichiers, sans signal indiquant qu’ils ont été ignorés. J’ai vérifié que le fichier n’était pas corrompu en lançant directement extract_text de pdfminer dessus — zéro caractère nettoyé, pas de couche texte, confirmé — donc la sortie vide correspond bien au comportement réel de MarkItDown sur un vrai scan. Cela reproduit un vieux manque bien connu de fallback OCR (#1268), suivi en amont depuis un moment. Le chemin documenté passe par le backend optionnel Azure Document Intelligence ou par un plugin ; rien de tout cela n’est inclus par défaut.
Les PDF sortent en texte plat, pas en structure
Sur les deux PDFs avec couche texte, MarkItDown n’a produit aucun marqueur de titre Markdown. Un PDF ne contient pas de balises sémantiques de titre, et MarkItDown n’infère pas les niveaux à partir de la taille des polices ; chaque ligne finit donc au niveau du corps du texte. La restitution du texte est très bonne ; la structure, elle, est plate.
Ce n’est pas seulement mon constat. Des benchmarks publics tiers attribuent à MarkItDown une hiérarchie de titres PDF proche de 0,0 et une fidélité des tableaux autour de 0,27, bien en dessous des 0,88 de Docling, basé sur TableFormer (voir la comparaison MarkItDown vs Docling vs Marker et le benchmark READoc). Mes tests reproduisent ces résultats, ce qui renforce la preuve : mes chiffres convergent avec une source externe. Le compromis mis en avant par ces mêmes benchmarks, c’est que MarkItDown fonctionne environ 100 fois plus vite que Docling, ce qui colle avec mes temps en secondes, et non en minutes, là où un outil fondé sur un modèle de mise en page tourne pendant plusieurs minutes. En bref : MarkItDown vous donne un texte PDF propre et rapide ; il ne vous donne pas la structure du PDF. Si les titres et les tableaux doivent absolument survivre, un outil de type Docling ou Marker est la bonne couche.
Tableaux : le contenu passe toujours, la structure pas forcément
C’est dans les tableaux que l’écart entre « le texte est-il bien là ? » et « les données restent-elles exploitables ? » devient évident. J’ai donc construit une matrice de 13 cas — un <table> par cas, chacun comparé à un manifeste rédigé avant l’exécution — afin de voir précisément quelles formes tiennent et lesquelles cassent.
Le constat principal : MarkItDown ne perd jamais le contenu des tableaux. Les 13 cas ont conservé 100 % de leurs jetons préenregistrés. En revanche, la fidélité structurelle se répartit en trois catégories. Sept cas sur treize ont produit une grille GFM correcte (tableaux simples, avec en-tête et colspan, très larges de 24 colonnes, sans en-tête, avec cellules vides, avec contenu bloqué dans une cellule, et en arabe de droite à gauche). Quatre sont devenus irréguliers, parce que Markdown ne sait pas représenter une cellule fusionnée : les rowspan, colspan et sources mal formées génèrent des lignes raccourcies. Et deux cas sont franchement cassés.
Les deux erreurs méritent d’être nommées. Un tableau imbriqué (un <table> dans un <td>) est aplati en ligne, avec ses propres barres verticales et sa ligne de séparation injectées dans la cellule parente, ce qui donne une ligne de 14 « colonnes » complètement incohérente. Et un caractère | littéral à l’intérieur d’une cellule n’est pas échappé — le texte a | b devient deux colonnes, x || y en devient trois — si bien qu’un tableau à deux colonnes produit des lignes de deux, trois et quatre colonnes, et qu’un parseur Markdown en aval lit des limites incorrectes. Curieusement, les astérisques et les backticks dans les cellules, eux, sont échappés ; pas les barres verticales. La cause racine, c’est que le chemin HTML de MarkItDown s’appuie sur la gestion par défaut des tableaux de markdownify, et que sa sous-classe personnalisée redéfinit les liens, les images et les titres, mais pas les cellules de tableau. Le même bug d’échappement du pipe fait d’ailleurs l’objet d’une issue ouverte pour le convertisseur CSV (#2019), même si ce correctif ne touche pas le chemin HTML testé ici.
Le cas plus subtil — celui que j’aimerais le plus montrer à un ingénieur data — est le rowspan. Le cas t03 ne devient pas seulement irrégulier ; il désaligne silencieusement les données. Une étiquette rowspan=2 (« Fruit ») n’est émise qu’une fois, et la ligne située en dessous devient une ligne courte à deux colonnes (| Banana | 8 |), de sorte que « Banana » se retrouve sous la colonne Group au lieu de Item. Tous les jetons sont là. Un consommateur naïf qui lit la deuxième colonne récupère la mauvaise valeur. C’est le genre de bug qui passe un contrôle de présence du texte tout en corrompant discrètement un jeu de données.
La limite liée aux spans est elle-même un choix de conception connu et suivi (#1211, #1248) : une grille GFM plate ne peut vraiment pas représenter les cellules fusionnées ni l’imbrication, donc le convertisseur sacrifie la structure au profit de l’exhaustivité du contenu. Il existe aussi des comportements positifs : les tableaux sans en-tête reçoivent une ligne d’en-tête vide synthétique (ainsi, aucune donnée n’est promue silencieusement en titre), les cellules vides sont conservées, et <caption> est préservé comme ligne de texte au-dessus du tableau.
Installation et démarrage : l’impôt qu’un « utilitaire léger » ne vous annonce pas
Rien ne m’a plus surpris, et c’est là que le discours « utilitaire Python léger » devient un peu trop optimiste.
D’abord, n’exécutez pas pip install 'markitdown[all]'. Sur Python 3.14, cela rétrograde silencieusement vers MarkItDown 0.0.2, une version vieille de deux ans, ce que j’ai reproduit en direct dans un environnement virtuel propre. Le blocage apparaît clairement quand on épingle la version : pip install 'markitdown[all]==0.1.6' échoue parce que l’extra [all] impose youtube-transcript-api~=1.0.0, et sur PyPI, toutes les versions de cette plage sont limitées à Python <3.14, alors que les seules compatibles avec 3.14 se trouvent hors de cette contrainte. Le résolveur recule donc jusqu’à la dernière version dont les dépendances peuvent être satisfaites. Cela correspond à une issue ouverte en amont (#2179). La solution est simple : épinglez la version et installez les extras séparément — pip install 'markitdown==0.1.6', puis pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Chacun de ces paquets se résout correctement ; seul le bundle combiné [all] contient la dépendance piégée. (Ce piège dépend de la version de Python : en Python 3.13 ou antérieur, le blocage peut ne pas mordre, et [all] peut se résoudre autrement.)
Ensuite, le poids de l’installation. L’installation de base pèse 161 Mo (un venv vide de 13 Mo + 148 Mo). Dans cet ensemble, onnxruntime (73 Mo) et numpy (34 Mo) représentent à eux deux 107 Mo — soit 66 % de l’empreinte totale — et ils sont entraînés par une seule dépendance obligatoire : magika, le détecteur de type de fichier de Google basé sur le machine learning. Autrement dit, un convertisseur de texte embarque déjà un runtime d’inférence ONNX de 73 Mo avant même que vous n’ajoutiez un seul extra documentaire. Avec les extras documentaires, le venv monte à 310 Mo. C’est bien plus léger qu’une pile basée sur un navigateur sans interface, mais si vous vous attendiez à un micro-outil « pip install et c’est fini », sachez qu’un runtime ONNX est bel et bien là.
Troisième point — et c’est l’une des rares mesures de tout mon lot qui passe tous les contrôles de nouveauté que j’ai appliqués — même après une installation propre, import markitdown prend environ 3,35 secondes sur cette machine. La quasi-totalité de ce coût se produit à l’import : markitdown._markitdown importe d’emblée tout le registre des convertisseurs (2,56 s cumulées, soit 76 % du total), ce qui charge pandas (594 ms, via le convertisseur XLSX), python-pptx (427 ms), magika (354 ms) et requests (270 ms) — que vous convertissiez ou non ces formats. Pour un service long-running, ce coût s’amortit et devient presque négligeable. Pour une invocation CLI ou un démarrage à froid serverless, c’est une vraie taxe par processus, bien loin de l’image « utilitaire léger ». (Précision utile : il s’agit d’une seule exécution profilée, à considérer comme une observation unique, pas comme une distribution sur plusieurs mesures.)
Passage à l’échelle : pas de crash, mais prévoyez du CPU pour les PDFs et de la RAM pour les feuilles de calcul
J’ai envoyé quatre gros sujets dans le pipeline, chacun dans son propre processus pour que la mémoire maximale ne soit pas faussée par une exécution précédente. Rien n’a planté. En revanche, le profil de coût est très asymétrique.
| Sujet | Entrée | Nombre de caractères en sortie | Temps médian | Variation RSS max |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF 492 pages) | 5,9 Mo | 1,625,365 | 192,5 s | +40 Mo |
| XLSX 50 000 lignes × 8 colonnes | 2,1 Mo | 3,722,955 | 62,1 s | +374 Mo |
| arXiv 1706.03762 (~15 pages PDF) | 2,2 Mo | 40,174 | 12,6 s | +25 Mo |
| XLSX 200 lignes × 64 colonnes | 46 Ko | 120,129 | 2,9 s | +22 Mo |
Le PDF NIST de 492 pages a pris une médiane de 192,5 secondes — environ 3,2 minutes, soit 0,39 s/page — parce que pdfplumber exécute une détection de formulaire et de position des mots sur chaque page. La RSS maximale est restée à +40 Mo, donc la contrainte est surtout le CPU, pas la mémoire. Même le PDF arXiv de 15 pages a pris 12,6 secondes dans un processus isolé, soit environ 3,4 fois les 3,7 secondes observées à chaud dans ma suite documentaire pour le même fichier. Cet écart correspond au coût d’un processus à froid, et confirme que le travail par page, pas la taille brute du fichier, est le facteur principal. Si vous cherchez une seule valeur à retenir pour ce PDF, gardez les 12,6 s en exécution isolée.
Le chemin des feuilles de calcul inverse le goulot d’étranglement. Un fichier XLSX de 2,1 Mo et 50 000 lignes a monté à +374 Mo de RSS maximale (et 3,7 millions de caractères en sortie), parce que le convertisseur charge toute la feuille et construit une énorme chaîne Markdown en mémoire. En pratique, le conseil est simple : pour les gros PDFs, prévoyez des minutes de CPU ; pour les gros tableaux Excel, prévoyez des centaines de Mo de RAM. Ce sont des chiffres mesurés sur une seule machine, sous macOS arm64 et Python 3.14, donc les constantes par page et par ligne dépendent de la plateforme — mais la tendance générale, elle, reste la même : les PDFs sont lents et CPU-bound, les XLSX sont gourmands en mémoire, et rien ne plante.
Où Thunderbit s’insère — et où il ne s’insère pas
Essayez Thunderbit pour l’extraction de données Web
C’est le genre de comparaison où il serait facile d’en faire trop, donc je vais poser la limite clairement. MarkItDown et Thunderbit résolvent des problèmes voisins, mais pas identiques.
MarkItDown convertit des fichiers que vous possédez déjà. Thunderbit récupère d’abord la page. L’endpoint /distill de Thunderbit transforme une page web active en Markdown propre, prêt pour les LLM — en gérant le rendu JS, les anti-bot et le contenu dynamique, ce que MarkItDown ne sait pas faire — et son endpoint /extract renvoie du JSON structuré conforme à un schéma, pas seulement du Markdown brut. Côté développeur, cela s’utilise via une API (POST /distill / POST /extract), un serveur MCP et une CLI (npx @thunderbit/thunderbit-cli) basés sur un seul moteur IA, celui qui alimente aussi l’extension utilisée par plus de 100 000 utilisateurs.
Ils se recoupent donc sur un seul point — tous deux peuvent produire du « Markdown prêt pour LLM » — mais leur domaine d’entrée est différent : le distill de Thunderbit prend une URL publique, alors que MarkItDown prend un fichier local. Ce ne sont pas des équivalents interchangeables, et je ne prétendrai pas le contraire. Dans une architecture réaliste, on utilise les deux : on récupère et on parcourt le Web avec Thunderbit (ou un service de type Firecrawl), puis on normalise aussi les documents locaux mixtes — PDF, présentations, feuilles de calcul — avec MarkItDown. L’un gère le réseau ; l’autre, le classeur de fichiers.
Avantages et inconvénients
Points forts
- Récupération complète du corps sur du HTML propre (4/4 pages), avec arbres de titres et liens correctement conservés
- Très bonne restitution du texte PDF/DOCX (arXiv 7/7 contrôles, Bitcoin 6/6) et aucune perte silencieuse sur les fichiers Office de régression des mainteneurs
- Les équations Office Math sont conservées en LaTeX — un vrai atout de niche
- Aucun crash sur les cas testés, jusqu’à un PDF de 492 pages et un XLSX de 50k lignes
- Très simple à appeler : CLI,
convert(), pipeline stdin et serveur MCP optionnel - Sous licence MIT, activement maintenu par Microsoft, suivi d’issues réactif
Points faibles
- Conserve le contenu parasite — jusqu’à 12,4 % de lignes de chrome sur Wikipédia ; ce n’est pas un extracteur d’article
- Les tableaux se dégradent avec les spans, l’imbrication et les pipes dans les cellules (2/13 cassés, 4/13 irréguliers), et le rowspan peut désaligner silencieusement les données
- Les PDFs scannés / image-only renvoient une sortie vide, sans OCR ni erreur
- La sortie PDF ne contient aucune structure de titres (ce qui concorde avec les benchmarks publics)
- Installation de base de 161 Mo avec un runtime ONNX de 73 Mo ; import à froid d’environ 3,35 s
- L’extra
[all]rétrograde silencieusement vers la version 0.0.2 vieille de deux ans sur Python 3.14
Qui devrait l’utiliser, et qui ne devrait pas
Choisissez MarkItDown si vous voulez standardiser un ensemble de documents locaux hétérogènes — Word, Excel, PowerPoint, PDFs avec couche texte — en Markdown pour un pipeline LLM, et si vous privilégiez l’exhaustivité du texte à la préservation de la structure. Comme convertisseur de dernière étape dans un traitement par lots, pour alimenter un modèle avec du texte propre, il est rapide, fidèle et gratuit.
Évitez-le, ou associez-le à autre chose, si votre besoin est l’un de ceux-ci : extraire uniquement l’article principal d’une page web (utilisez un outil de type readability ou Firecrawl) ; conserver intactes les titres et les tableaux d’un PDF (c’est le terrain de Docling ou Marker) ; ou traiter des documents scannés nécessitant de l’OCR (il vous faudra le backend Azure ou un autre outil). Et si tu pensais acheter un scraper — un outil qui récupère et parcourt des pages — ce n’est tout simplement pas ça.
La note provisoire que j’ai obtenue, sur une grille pensée pour un scraper, est de 60/100, et ce score bas vient surtout du fait d’évaluer un convertisseur avec un test conçu pour un crawler. Sur son propre terrain, ses scores de fidélité textuelle sont élevés ; ses faiblesses concernent surtout la structure (tableaux, titres PDF) et le packaging (poids, import, piège [all]), pas la qualité du texte. Juge-le pour ce qu’il est — un convertisseur de fichiers vers Markdown — et tu obtiens un outil solide, bien maintenu, avec quelques arêtes vives qu’il vaut mieux connaître avant de l’intégrer en production.
Questions fréquentes
MarkItDown est-il un scraper Web ?
Non. Il n’a ni crawler, ni rendu JavaScript, ni suivi de liens, ni pagination. Il convertit les fichiers et documents que vous possédez déjà — PDF, DOCX, XLSX, PPTX, images, HTML — en Markdown. Si vous devez récupérer et parcourir des pages web en direct, il vous faut un outil de scraping comme Thunderbit ou Firecrawl ; MarkItDown intervient après, pour transformer les fichiers récupérés ou locaux en Markdown propre.
Pourquoi pip install markitdown[all] installe-t-il une ancienne version ?
Sous Python 3.14, l’extra [all] impose youtube-transcript-api~=1.0.0, et toutes les versions de cette plage sont limitées à des versions de Python inférieures à 3.14. Le résolveur ne peut pas satisfaire cette contrainte, donc il rétrograde silencieusement vers markitdown 0.0.2, une version vieille de deux ans. La solution consiste à épingler la version et à installer les extras individuellement : pip install 'markitdown==0.1.6', puis ajouter 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Le sujet est suivi dans l’issue #2179.
MarkItDown fait-il de l’OCR sur les PDFs scannés ?
Pas dans l’installation par défaut. Son chemin PDF ne fait que de l’extraction de texte ; un PDF composé uniquement d’images, sans couche texte, renvoie donc une chaîne vide — sans erreur, sans avertissement. L’OCR nécessite le backend optionnel Azure Document Intelligence ou un plugin, qui ne sont pas fournis par défaut. C’est une lacune suivie depuis longtemps (issue #1268).
Comment MarkItDown gère-t-il les tableaux ?
Sur le fond, très bien : dans mon test à 13 cas, il a conservé 100 % du contenu de chaque tableau. Sur la structure, cela dépend de la forme : les tableaux simples, larges, sans en-tête et avec cellules vides sortent sous forme de grilles GFM propres, mais les rowspan et colspan deviennent irréguliers (et le rowspan peut désaligner silencieusement les données dans la mauvaise colonne), les tableaux imbriqués sont aplatis en lignes incohérentes, et les pipes littéraux à l’intérieur des cellules ne sont pas échappés. Le format plat de Markdown ne permet tout simplement pas de représenter les spans ou l’imbrication.
MarkItDown est-il assez rapide pour de gros documents ?
Il ne plante pas sur les gros fichiers, mais il faut prévoir les ressources selon le type. Un PDF de 492 pages a pris environ 3,2 minutes (soit à peu près 0,39 s/page) parce qu’il effectue une détection de formulaire par page, et il est donc limité par le CPU. Une feuille de calcul de 50 000 lignes a terminé en environ une minute, mais a utilisé +374 Mo de RAM parce qu’elle construit une grande chaîne Markdown en mémoire. Pour de gros PDFs, comptez des minutes de CPU ; pour de gros tableaux Excel, comptez des centaines de Mo de RAM.
Essayez Thunderbit pour l’extraction de données Web Get Started Free
