MarkItDown est souvent classé à tort dans la case des scrapers web. En réalité, ce n’est pas du tout le bon tiroir. Il n’a ni crawler, ni moteur JavaScript, ni mécanisme pour aller chercher une URL puis nettoyer le contenu inutile. Son rôle est tout autre : il prend des fichiers que vous avez déjà — PDF, document Word, feuille de calcul, présentation — et les transforme en Markdown lisible par un modèle de langage.
J’ai passé quelques semaines à soumettre MarkItDown de Microsoft à une série de documents réels sur un seul Mac, en consignant chaque tableau à partir d’un manifeste rédigé avant les tests et en chronométrant chaque conversion. Le résumé est simple : sur des entrées propres, l’outil est rapide et fidèle ; son empaquetage cache toutefois un runtime d’apprentissage automatique de 73 Mo que vous n’avez pas forcément demandé ; et ses tableaux se dégradent d’une manière qui peut faire passer un test du type « le texte est-il intact ? » tout en échouant à « les données sont-elles dans la bonne colonne ? ». Voici l’analyse complète, chiffres à l’appui.
Ce qu’est réellement MarkItDown
MarkItDown est un utilitaire Python de Microsoft qui convertit des fichiers et des documents Office en Markdown optimisé pour les LLM. Donnez-lui un PDF, un .docx, un .xlsx, un .pptx, une image, un fichier HTML ou quelques autres formats, et il renvoie du Markdown. Il peut être utilisé de trois façons : en ligne de commande (markitdown file.pdf -o out.md, ou via stdin), via une API Python (MarkItDown().convert(...)), ou avec un serveur MCP optionnel pour les workflows d’agents.
L’essentiel, c’est surtout ce qu’il ne fait pas — et ce point est crucial, car le README ne le promet pas, et mes tests l’ont confirmé : pas de crawling, pas de rendu JS, pas de suivi de liens, pas de pagination, pas d’extraction du contenu principal à la manière de Readability. C’est un convertisseur de documents complet. Vous apportez les octets ; il les standardise. Cette seule distinction détermine si l’outil mérite sa place dans votre stack ou non, donc j’y reviendrai plusieurs fois.
Le dépôt affiche des chiffres très flatteurs sur GitHub — 165 282 étoiles et 11 790 forks à la mi-juillet 2026, sous licence MIT, avec une dernière version (v0.1.6) publiée le 2026-05-26. Mais ce volume d’étoiles reflète surtout l’enthousiasme général autour des outils pour LLM, pas forcément la maturité du cœur de conversion. Il y a aussi 833 tickets ouverts, et certains méritent votre attention avant l’installation (j’y reviens plus bas).
HTML vers Markdown : rapide, complet… avec le bruit de fond du site
Comme le reste de ma série d’évaluations de scrapers repose sur les mêmes quatre pages web, j’ai fourni à MarkItDown les mêmes fichiers HTML locaux — non pas pour l’évaluer comme scraper, mais pour juger la qualité de sa conversion HTML vers Markdown. Sur des pages bien structurées, le résultat est franchement bon.
Les quatre pages ont été converties avec l’installation de base, sans aucun complément, et tous les points de vérification du contenu principal ont survécu. L’article Wikipedia « Web scraping » (226 Ko) a conservé son arbre de titres — un h1, sept h2, douze h3, en phase avec la structure réelle de l’article — et 418 liens ont été préservés sous la forme correcte [texte](url). Le tableau de statistiques de hockey en 25×9 sur 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 incluses. La vitesse n’était pas un sujet ici : médiane de 48 ms pour la petite page de citations, jusqu’à 352 ms pour la page Wikipedia de 226 Ko.
Le point de vigilance, en revanche, est un choix de conception plutôt qu’un bug. MarkItDown ne supprime pas le boilerplate. Il convertit tout le <body>, donc l’interface du site remonte avec le reste — et cette pollution augmente avec la quantité de chrome présente dans la page.
| Page | 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 dépourvue de chrome, 0,6 % des lignes en sortie sont du chrome. Sur Wikipedia, on monte à 12,4 % : 42 des 338 lignes non vides correspondent à « jump to content », « toggle the table of contents », « 22 languages », « retrieved from », ou encore aux pieds de page de cookies et de licence. Ces bandeaux de maintenance Wikipedia (« This article needs additional citations ») sont même rendus fidèlement sous forme de tableaux Markdown à deux colonnes, ce qui explique neuf lignes de tableau sur une page qui ne contient aucun véritable tableau de données.
Cela ne veut pas dire que MarkItDown fait quelque chose de mal. C’est un convertisseur de document complet, pas un extracteur de contenu lisible : convertir fidèlement un HTML en Markdown n’est pas la même tâche qu’extraire proprement un article. Trafilatura et les outils de type Firecrawl visent le contenu principal uniquement ; 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 aucune heuristique de contenu principal dans la chaîne. Si vous ne voulez que l’article, ce n’est pas la bonne couche.
Son terrain naturel : PDF, DOCX, XLSX, PPTX
Les documents sont le terrain pour lequel MarkItDown a été conçu. Je l’ai testé sur de vrais fichiers publics — un article arXiv avec couche texte, le whitepaper Bitcoin, un PDF scanné en image uniquement que j’ai rendu sans aucun texte, et les fichiers DOCX/XLSX/PPTX issus de la suite de tests de MarkItDown lui-même (avec des UUID pour détecter toute perte de contenu silencieuse).
| Document | Entrée | Caractères en sortie | Vérifications | Temps médian | Notes |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF avec couche texte) | 2.2 MB | 40,174 | 7/7 | 3.7 s (chaud) | titre, "Transformer", "BLEU", "References" tous présents |
| Bitcoin whitepaper (9 pages PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" présents |
| PDF scanné (sans couche texte) | 89 KB | 0 | 0/4 | 15 ms | sortie vide, aucune erreur, pas d’OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | titres + tableau GFM ; les UUID intégrés survivent |
| DOCX avec équations | 15 KB | 240 | — | 101 ms | Office Math conservé en LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | chaque feuille → ## NomDeFeuille + tableau GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | marqueurs de numéro de slide, tableaux, graphique → tableau |
La restitution textuelle sur les PDF avec couche texte était excellente — 7/7 vérifications préenregistrées 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. Autrement dit, pas de perte silencieuse de contenu sur les jeux de régression des mainteneurs. Point fort plus discret mais bien réel : le chemin DOCX (via mammoth) préserve les équations Office Math sous forme de LaTeX, en convertissant equations.docx en vraies mathématiques $$...$$. Si vous alimentez un LLM avec des documents Word riches en formules, c’est un atout concret, même s’il est très spécifique.
Deux constats sur ce terrain méritent une attention particulière, car ce sont eux qui risquent le plus de vous poser problème.
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, parce qu’il n’y a tout simplement rien à extraire. Le chemin PDF de MarkItDown repose uniquement sur l’extraction de texte (pdfminer et pdfplumber en coulisses) et n’intègre aucun OCR, ni dans l’installation de base ni dans les extras pip.
En traitement par lots, cela compte énormément. Un développeur qui traite un dossier de PDF contenant aussi des scans obtiendra silencieusement des résultats vides pour ces fichiers, sans aucun signal indiquant qu’ils ont été ignorés. J’ai vérifié que le fichier de test n’était pas corrompu en lançant extract_text de pdfminer dessus directement : zéro caractère extrait, pas de couche texte, confirmation faite. La sortie vide est donc bien le comportement réel de MarkItDown sur un vrai scan. Cela reproduit une absence persistante de fallback OCR (#1268) signalée depuis un moment en amont. La voie documentée consiste à utiliser le backend optionnel Azure Document Intelligence ou un plugin ; aucun des deux n’est inclus par défaut.
Les PDF sortent en texte plat, pas en structure
Sur les deux PDF avec couche texte, MarkItDown n’a produit aucun marqueur Markdown de titre. Un PDF ne contient pas de balises sémantiques de heading, et MarkItDown n’essaie pas d’inférer la hiérarchie à partir de la taille de police ; tout arrive donc au niveau du corps de texte. La récupération du texte est élevée, mais la structure est aplatie.
Ce n’est pas seulement mon observation. Des benchmarks publics tiers attribuent à MarkItDown un score d’environ 0,0 pour la hiérarchie des titres PDF et d’environ 0,27 pour la fidélité des tableaux, bien en dessous des 0,88 de Docling adossé à TableFormer (voir la comparaison MarkItDown vs Docling vs Marker et le benchmark READoc). Mes jeux de test reproduisent ces résultats, ce qui renforce la crédibilité des données : mes chiffres concordent avec une source externe. Le compromis mis en avant par ces mêmes benchmarks, c’est que MarkItDown est environ 100 fois plus rapide que Docling, ce qui colle avec mes temps en secondes plutôt qu’en minutes, là où un outil basé sur un modèle de mise en page travaille pendant plusieurs minutes. La conclusion : 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 modèle de mise en page comme Docling ou Marker est le bon niveau.
Tableaux : le contenu survit toujours, la structure pas forcément
Les tableaux sont précisément l’endroit où « le texte est-il intact ? » et « les données restent-elles exploitables ? » se séparent. J’ai donc construit une matrice de 13 cas — un <table> par cas, chacun évalué face à un manifeste rédigé avant l’exécution — afin de voir exactement quelles formes tiennent et lesquelles se cassent.
Le constat principal : MarkItDown n’a jamais perdu le contenu des tableaux. Dans les 13 cas, 100 % des jetons préenregistrés ont été conservés. En revanche, la fidélité structurelle s’est répartie 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 à 24 colonnes, sans en-tête, avec cellules vides, avec bloc dans cellule, et en arabe de droite à gauche). Quatre se sont dégradés, parce que Markdown ne connaît pas les cellules fusionnées : les rowspan, colspan et sources mal formées produisent donc des lignes raccourcies. Et deux cas étaient franchement cassés.
Ces deux échecs méritent d’être nommés. Un tableau imbriqué (<table> à l’intérieur d’un <td>) est aplati en ligne, ce qui injecte ses propres barres verticales et sa ligne de séparation dans la cellule parent et produit une ligne de « 14 colonnes » inutilisable. Et un caractère littéral | dans une cellule n’est pas échappé — le texte a | b devient deux colonnes, x || y devient trois — de sorte qu’un tableau à deux colonnes produit des lignes de deux, trois et quatre colonnes, que tout parseur Markdown en aval interprète alors avec de mauvaises limites. Curieusement, les astérisques et les backticks dans une cellule sont, eux, bien échappés ; pas les barres verticales. La cause racine est que le chemin HTML de MarkItDown s’appuie sur le traitement par défaut des tableaux de markdownify, et que sa sous-classe personnalisée surcharge les liens, les images et les titres, mais pas les cellules de tableau. La même classe de bogue liée à l’échappement des | apparaît d’ailleurs comme ticket ouvert pour le convertisseur CSV (#2019), même si ce correctif ne touche pas le chemin HTML que j’ai testé.
Le point le plus subtil — celui qu’un data engineer devrait absolument voir — concerne rowspan. Le cas t03 ne se contente pas de se dégrader ; il aligne les données de travers sans le dire. Une étiquette avec rowspan=2 (« Fruit ») n’est émise qu’une seule fois, et la ligne située en dessous devient une ligne courte à deux colonnes (| Banana | 8 |), si bien que « Banana » se retrouve sous la colonne Groupe au lieu de Item. Tous les jetons sont bien là. Mais un consommateur naïf qui lirait la deuxième colonne récupérera la mauvaise valeur. C’est exactement le genre de bug qui passe un test de survie du texte tout en corrompant silencieusement un jeu de données.
La limitation des spans elle-même est une contrainte de conception connue et suivie (#1211, #1248) : une grille GFM plate ne peut pas représenter les fusions de cellules ni l’imbrication, donc le convertisseur échange de la structure contre une complétude du contenu. Il existe aussi des comportements corrects dans le lot : les tableaux sans en-tête reçoivent une ligne d’en-tête vide synthétique (aucune donnée n’est ainsi promue silencieusement en en-tête), les cellules vides sont conservées, et <caption> survit sous forme de ligne de texte au-dessus du tableau.
Installation et démarrage : la taxe dont un « utilitaire léger » ne vous prévient pas
Rien ne m’a davantage surpris que ce point, et c’est aussi là que l’image de « petit utilitaire Python léger » devient un peu trompeuse.
D’abord, n’exécutez pas pip install 'markitdown[all]'. Sous Python 3.14, cette commande rétrograde silencieusement vers markitdown 0.0.2, une version vieille de deux ans — ce que j’ai reproduit en direct dans un nouvel environnement virtuel. Si l’on épingle la version, on voit pourquoi : pip install 'markitdown[all]==0.1.6' échoue, car l’extra [all] contraint 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 versions compatibles 3.14 sortent de cette contrainte. Le résolveur recule donc jusqu’à la dernière version dont les dépendances sont satisfaisables. Cela correspond à un ticket ouvert en amont (#2179). La solution est simple : épingler la version et installer 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 [all] contient la contrainte problématique. (Piège dépendant de la version de Python : sous Python 3.13 ou avant, ce verrou peut ne pas se déclencher, donc [all] peut se résoudre différemment.)
Ensuite, le poids. L’installation de base occupe 161 Mo (un venv vide de 13 Mo + 148 Mo de paquets). Parmi cela, onnxruntime (73 Mo) et numpy (34 Mo) représentent à eux deux 107 Mo — soit 66 % de l’empreinte totale de base — et ils sont tous deux amenés par une seule dépendance obligatoire : magika, le détecteur de type de fichier basé sur ML de Google. Autrement dit, un convertisseur de texte embarque un runtime d’inférence ONNX de 73 Mo dès l’installation de base, avant même d’ajouter les extras pour les documents. Une fois ces extras ajoutés, le venv atteint 310 Mo. C’est bien plus léger qu’une pile de navigateur sans tête, mais si vous imaginiez un micro-outil « pip install et c’est fini », sachez qu’un runtime ONNX vous accompagne.
Troisièmement — et c’est, parmi tout mon dossier, le résultat qui passe tous les filtres de nouveauté que j’ai testés — même après une installation propre, import markitdown coûte environ 3,35 secondes sur cette machine. Le coût se concentre presque entièrement à l’import : markitdown._markitdown charge d’emblée tout le registre des convertisseurs (2,56 s cumulées, soit 76 % du total), ce qui entraîne pandas (1,21 s, 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 à vie, ce coût est amorti et sans importance. Pour un appel CLI ou un cold start serverless, c’est une vraie taxe par processus que l’étiquette « utilitaire léger » ne laisse pas présager. (Précision utile : il s’agit ici d’un seul profilage, traité comme une observation unique, pas d’une distribution sur plusieurs exécutions.)
Passage à l’échelle : ça ne plante pas, mais prévoyez du CPU pour les PDF et de la RAM pour les tableurs
J’ai fait passer quatre gros sujets dans l’outil, chacun dans son propre processus pour éviter que la mémoire de pointe soit contaminée par une exécution précédente. Rien n’a planté. Mais le profil de coût est très déséquilibré.
| Sujet | Entrée | Caractères en sortie | Temps médian | Δ RSS de pointe |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF 492 pages) | 6.07 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50 000 lignes × 8 colonnes | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (PDF ~15 pages) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 lignes × 64 colonnes | 46 KB | 120,129 | 2.9 s | +22 MB |
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 lance une détection de mise en forme par position des mots sur chaque page. La RSS de pointe n’a augmenté que de 40 Mo, donc la limite est 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 sur le même fichier en exécution « chaude » dans ma suite de documents. Cet écart correspond au coût d’un processus froid, et il confirme que le travail par page est le facteur déterminant, pas la taille brute du fichier. Si vous ne deviez retenir qu’un seul chiffre pour ce PDF, prenez les 12,6 s en exécution isolée.
Le chemin tableur inverse le goulot d’étranglement. Un XLSX de 2,1 Mo et 50 000 lignes a bondi à +374 Mo de RSS de pointe (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. Le conseil pratique est donc très simple : pour les gros PDF, prévoyez des minutes de CPU ; pour les gros tableurs, prévoyez des centaines de Mo de RAM. Ce sont des mesures faites sur une machine unique sous macOS arm64 et Python 3.14, et les constantes par page et par ligne dépendent de la plateforme — mais la forme générale (PDF lent et CPU-bound, XLSX gourmand en mémoire, aucun crash) est ce qui se transpose.
Où Thunderbit s’insère — et où il ne s’insère pas
Essayez Thunderbit pour l’extraction de données web
C’est la comparaison qu’il serait facile d’exagérer, donc je vais poser la frontière clairement. MarkItDown et Thunderbit résolvent des problèmes proches, mais pas identiques.
MarkItDown convertit des fichiers que vous possédez déjà. Thunderbit récupère d’abord la page. Son endpoint /distill transforme une page web en Markdown propre, prêt pour un LLM, en gérant le rendu JavaScript, l’anti-bot et le contenu dynamique que MarkItDown ne sait pas traiter. Son endpoint /extract renvoie, lui, du JSON structuré conforme à un schéma, pas seulement du Markdown brut. Côté développeur, tout cela est accessible via une API (POST /distill / POST /extract), un serveur MCP et une CLI (npx @thunderbit/thunderbit-cli), le tout propulsé par le même moteur IA que celui derrière l’extension utilisée par plus de 100 000 personnes.
Ils n’ont donc qu’un seul point de recoupement : 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 sur le web public, alors que MarkItDown prend un fichier local. Ce ne sont pas des équivalents interchangeables, et je ne vais pas faire semblant du contraire. Une pile réaliste utilise les deux : récupérer et explorer le web avec Thunderbit (ou un service de type Firecrawl), puis normaliser les documents locaux mixtes que vous avez aussi — les PDF, présentations et 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 contenu principal sur HTML propre (4/4 pages), avec titres et liens fidèlement conservés
- Excellente restitution du texte PDF/DOCX (arXiv 7/7, Bitcoin 6/6) et aucune perte silencieuse sur les jeux Office des mainteneurs
- Les équations Office Math sont préservées en LaTeX — un vrai point fort de niche
- Aucun plantage, même sur des sujets volumineux : PDF de 492 pages et XLSX de 50 000 lignes
- Utilisation très simple : CLI,
convert(), pipeline via stdin et serveur MCP optionnel - Licence MIT, maintenance active chez Microsoft, suivi des tickets réactif
Points faibles
- Conserve le boilerplate — jusqu’à 12,4 % de lignes de chrome sur Wikipedia ; ce n’est pas un extracteur d’articles
- Les tableaux cassent avec les spans, l’imbrication et les
|dans les cellules (2/13 cassés, 4/13 dégradés), etrowspanpeut décaler silencieusement les données - Les PDF scannés / image seule renvoient une sortie vide, sans OCR et sans erreur
- La sortie PDF n’a aucune structure de titres (ce que confirment les benchmarks publics)
- Installation de base de 161 Mo avec un runtime ONNX de 73 Mo ; ~3,35 s d’import à froid
- L’extra
[all]rétrograde silencieusement vers une vieille version 0.0.2 sous Python 3.14
Qui devrait l’utiliser, et qui devrait passer son chemin
Choisissez MarkItDown si vous standardisez un lot de documents locaux mixtes — Word, Excel, PowerPoint, PDF avec couche texte — vers du Markdown pour un pipeline LLM, et si vous accordez plus d’importance à la complétude du texte qu’à la conservation de la structure. Comme convertisseur de dernière étape dans un traitement par lots, pour nourrir un modèle avec du texte propre, il est rapide, fidèle et gratuit.
Évitez-le, ou combinez-le avec autre chose, si votre besoin relève de l’un de ces cas : vous voulez seulement l’article principal d’une page web (utilisez un outil de type readability ou Firecrawl) ; vous devez préserver intactes les structures d’un PDF, titres et tableaux compris (Docling ou Marker sont plus adaptés) ; ou vos entrées incluent des documents scannés nécessitant de l’OCR (il vous faudra le backend Azure ou un autre outil). Et si vous pensiez acheter un scraper — quelque chose qui récupère et explore le web — ce n’est pas du tout cela.
Le score provisoire que j’obtiens, sur une grille pensée pour un scraper, est de 60/100, et ce total modeste vient du fait de noter un convertisseur avec un test de crawler. Sur son propre terrain, ses scores de fidélité textuelle sont élevés ; ses faiblesses concernent surtout la structure (tableaux, titres PDF) et l’emballage (empreinte, import, piège [all]), pas la qualité du texte. Jugé pour ce qu’il est — un convertisseur de fichiers en Markdown — c’est un outil solide, bien maintenu, avec quelques angles saillants qu’il vaut mieux connaître avant de le mettre 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 des fichiers et documents que vous possédez déjà — PDF, DOCX, XLSX, PPTX, images, HTML — en Markdown. Si vous devez récupérer et explorer des pages web en direct, il vous faut un outil de scraping comme Thunderbit ou Firecrawl ; MarkItDown intervient après, pour transformer des 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 aux 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 séparément : pip install 'markitdown==0.1.6', puis ajouter 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. C’est suivi dans le ticket #2179.
MarkItDown fait-il de l’OCR sur les PDF scannés ?
Pas dans l’installation par défaut. Son chemin PDF ne fait que l’extraction de texte, donc un PDF composé d’images sans couche texte renvoie 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 (ticket #1268).
Comment MarkItDown gère-t-il les tableaux ?
Très bien sur le plan du contenu : dans mon test à 13 cas, 100 % du contenu des tableaux a été conservé dans tous les cas. Sur le plan structurel, cela dépend de la forme : les tableaux simples, larges, sans en-tête et avec cellules vides sortent en grilles GFM propres ; en revanche, les rowspan et colspan se dégradent (et rowspan peut décaler silencieusement les données dans la mauvaise colonne), les tableaux imbriqués sont aplatis en lignes inutilisables, et les barres verticales littérales dans les cellules ne sont pas échappées. Le format plat du tableau Markdown ne permet tout simplement pas de représenter les spans ni 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 ~0,39 s/page) parce qu’il effectue une détection de structure 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 consommé +374 Mo de RAM, car elle construit une grande chaîne Markdown en mémoire. Pour les gros PDF, prévoyez des minutes de CPU ; pour les gros tableurs, prévoyez des centaines de Mo de RAM.
Essayez Thunderbit pour l’extraction de données web Get Started Free
