Docling est souvent classé à tort dans la même catégorie que les web scrapers, alors que ce n’en est pas un. C’est une boîte à outils de conversion de documents signée IBM Research — aujourd’hui projet de la LF AI & Data Foundation — qui prend les fichiers que tu as déjà (PDF, DOCX, PPTX, XLSX, HTML, images) et les transforme en Markdown ou en JSON. Son slogan est d’ailleurs littéral : « Get your documents ready for gen AI. »
Ce test est donc une évaluation pratique d’un convertisseur, pas d’un crawler. Tout ce qui suit a été mesuré sur une machine uniquement CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), avec des scores issus de scripts et des échecs comptés comme des échecs. Le dépôt est énorme et évolue sans arrêt — 63 069 étoiles, 4 449 forks, et un push le jour même où j’ai récupéré les métadonnées — donc il faut voir ici les chiffres de version ou de bugs comme un instantané, pas comme une constante.
Ce qu’est vraiment Docling, et ce qu’il n’est pas
Le cœur de Docling, c’est DoclingDocument : on analyse un fichier pour le convertir dans cette structure, puis on exporte en Markdown, HTML, DocTags ou en JSON sans perte. Le code est sous licence MIT (les licences des modèles varient selon les composants), le projet est né chez IBM Research Zurich, et au moment où j’écris la dernière version publiée est la v2.112.0, sortie deux jours avant ce test.
Son gros point fort, c’est le traitement des PDF et des images. Et on ne parle pas ici d’un simple parsing de texte brut : toute la pile repose sur des modèles d’apprentissage automatique — un modèle de mise en page RT-DETR, le modèle de structure de tableau TableFormer, un modèle vision-langage optionnel et RapidOCR pour les scans. Ces modèles reconstruisent la mise en page, l’ordre de lecture et la structure des tableaux. C’est précisément cette partie qu’il faut évaluer — et c’est aussi celle qu’un test limité au HTML ne verra jamais.
Une distinction évite une semaine de confusion : Docling ne va rien chercher. Il ne rend pas le JavaScript, ne contourne pas les protections anti-bot et ne fait pas de crawl. Tu fournis le fichier, il en extrait le sens. Le crawl relève d’un autre outil, ce qui devient important quand on se demande si Docling remplace Firecrawl (non — ils se complètent, et j’explique pourquoi plus loin).
Le premier lancement que personne ne t’annonce
pip install docling s’installe sans problème sur Python 3.14.2. Puis on regarde l’environnement virtuel, et il affiche 1,3 Go. Docling embarque toute la pile ML comme dépendances obligatoires, même si tu ne convertis qu’un fichier HTML :
| Dépendance | Taille sur disque (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ modèles intégrés) | 75.6 |
| docling_parse | 30 |
Et ça, c’est avant même de convertir un seul PDF. La première conversion d’un PDF, c’est là que la vraie friction apparaît, parce que c’est à ce moment-là que les modèles se téléchargent. Sur un cache HuggingFace vierge et isolé, la première conversion PDF a pris environ 224 secondes — et presque tout ce temps correspond au téléchargement, pas au calcul. Les modèles de mise en page et TableFormer occupent environ 506 MiB sur disque (342 MiB pour TableFormer + 164 MiB pour la mise en page, vérifiés avec du), et RapidOCR récupère environ 40 Mo de poids PP-OCRv4 dans site-packages. La deuxième conversion du même fichier ? 0,55 seconde. Les modèles sont mis en cache ; on paie le péage une seule fois.
Un chiffre à ignorer : le script de démarrage à froid affiche model_download_mb à 1060.2. Ne le cite pas comme empreinte réelle. Il vient d’un os.walk qui suit les liens symboliques, alors que le cache HuggingFace stocke chaque fichier de modèle une seule fois dans blobs/ puis le réexpose via des liens symboliques dans snapshots/ — le parcours compte donc les 14 fichiers modèle deux fois. La valeur cohérente avec du, en dédupliquant les symlinks, est d’environ 506 MiB (505,4 MiB pour les blobs seuls). Conclusion utile pour toute personne qui benchmarke Docling : il faut séparer les octets téléchargés et les octets réellement présents sur disque, parce que ce sont deux choses différentes.
Il y a un second piège qui touche ceux qui veulent mettre Docling en conteneur. Les poids se répartissent sur deux emplacements et deux rythmes. Les modèles de mise en page et TableFormer respectent HF_HOME et se téléchargent à la première conversion PDF. Les modèles de RapidOCR, eux, non : ils atterrissent dans …/site-packages/rapidocr/models/, en contournant complètement ta configuration de cache. Si tu prépares une image Docker à l’avance ou si tu travailles en environnement isolé, il faut gérer les deux caches ; aucun réglage de HF_HOME ne couvrira le second.
Cela dit, soyons justes. Depuis les premières versions, le projet propose docling-slim — un cœur d’environ 50 Mo qui permet d’installer pip install docling-slim[format-html] pour le HTML sans embarquer torch. Les 1,3 Go du package par défaut docling sont donc réels, mais ils ne sont plus imposés dans tous les cas. J’ai testé le package standard parce que c’est encore ce que renvoie pip install docling, mais le poids n’est pas un défaut ignoré : la solution modulaire existe, et elle est suivie dans l’issue #2393.
Lors de l’installation, j’ai aussi relevé un petit accroc à signaler : import docling; docling.__version__ lève AttributeError: module 'docling' has no attribute '__version__'. Le module n’expose tout simplement pas cette information. La méthode qui fonctionne est importlib.metadata.version("docling"), qui renvoie '2.111.0'. Ce n’est qu’une petite gêne DX, ouverte en amont depuis juillet 2026 sous l’issue #3733.
Fidélité des tableaux : là où TableFormer mérite sa place
Les tableaux sont précisément la raison pour laquelle on choisit Docling plutôt qu’un simple dump PDF-vers-texte. J’ai donc généré sept PDF de tableaux avec une vérité terrain lisible par machine, puis j’ai noté le résultat cellule par cellule. Deux métriques comptent, et ce n’est pas la même chose : le cell recall est la proportion de valeurs de référence présentes quelque part dans le tableau détecté ; le taux in-row est la proportion de valeurs placées dans la bonne ligne. Les confondre embellit l’outil, alors voici les deux :
| Tableau (stress test) | Détecté | Cell recall | Taux in-row | Remarque |
|---|---|---|---|---|
| T1 grille bordée simple (5×8), seule sur la page | Non | 0.0 | — | classé comme <!-- image -->, toutes les cellules perdues |
| T2 sans bordure (seulement une règle d’en-tête) | Oui | 1.00 | 1.00 | parfait, grille exacte |
| T3 en-tête à 2 niveaux avec colspan fusionné | Oui | 1.00 | 0.97 | toutes les valeurs sont retrouvées ; une valeur d’en-tête décale d’une ligne |
| T4 étiquette de ligne rowspan fusionnée, seule sur la page | Non | 0.0 | — | classé comme <!-- image --> |
| T5 en-tête colspan + sans bordure | Oui | 1.00 | 0.97 | toutes les valeurs sont retrouvées ; même décalage de ligne d’en-tête que T3 |
| T6 données financières, colonne vide, alignée à droite | Oui | 1.00 | 1.00 | la colonne vide est conservée, non décalée |
| T7 grille large à 12 colonnes | Oui | 1.00 | 1.00 | aucun décalage de colonne sur un tableau large |
Sur les cinq tableaux détectés par Docling, toutes les valeurs de vérité terrain ont bien été retrouvées — cell recall de 1.00 partout. Sur trois de ces cinq tableaux, chaque valeur est aussi tombée dans la bonne ligne. Sur les deux cas à en-tête multiniveau (T3 et T5), une valeur d’en-tête glisse d’une ligne, ce qui fait descendre le taux in-row à 0.97 — les données sont bien là, mais l’affectation à la ligne vacille d’un cran sur un en-tête empilé.
Les cas structurellement difficiles ont mieux résisté que je ne l’aurais cru. L’en-tête colspan à deux niveaux s’est correctement aplati en Markdown compatible GitHub (l’étiquette « Q1 2026 » est répétée sur ses deux colonnes fusionnées, ce qui est la bonne manière de convertir un colspan en GFM). La grille sans bordure avec uniquement une ligne d’en-tête (T2) est ressortie exactement comme prévu. Le tableau large à 12 colonnes (T7) n’a pas dérivé. Et une colonne financière entièrement vide (T6) a été conservée comme cellules vides au lieu d’être supprimée ou fusionnée. Cela correspond aux scores officiels TableFormer TEDS — 95,4 pour les tableaux simples, 90,1 pour les complexes, 93,6 au total — que la fiche modèle place nettement au-dessus de Camelot (73,0) et EDD (88,3).
Un mot de prudence sur les cellules fusionnées, car une issue ouverte dit l’inverse. L’issue #3698 signale que V1 et V2 gèrent mal les lignes et colonnes fusionnées. Sur mes jeux de test, les simples colspan (T3/T5) et les valeurs rowspan ont été aplatis correctement, avec seulement le décalage de ligne mentionné plus haut sur les en-têtes multiniveaux. Mais les cas qui échouent dans #3698 sont des fusions irrégulières multi-lignes / multi-colonnes et des tableaux multipages — le cas pathologique, à l’extrême. Les miens appartiennent au cas simple. Donc la formulation correcte est étroite : les colspan et rowspan simples ont bien été récupérés ici (les en-têtes multiniveaux peuvent décaler d’une ligne) ; les fusions complexes et irrégulières restent un problème documenté et ouvert. Pas « les cellules fusionnées fonctionnent », pas « les cellules fusionnées sont cassées ».
Le piège : un tableau seul sur une page peut disparaître
Regarde à nouveau le tableau : T1 et T4 n’ont pas du tout été détectés. Docling a émis <!-- image --> et supprimé toutes les cellules, sans aucune erreur. T1 est une grille 5×8 ordinaire avec bordures. C’est assez inquiétant pour que je refuse d’y voir une simple faiblesse de parsing avant d’avoir isolé le vrai déclencheur, alors j’ai monté un A/B scripté.
J’ai d’abord éliminé les explications évidentes. La couche texte est bien présente — pypdfium2 lit 327 caractères pour T1 et 221 pour T4, ce sont donc de vrais PDF numériques, pas des images scannées. Désactiver l’OCR (do_ocr=False) ne change rien ; les tableaux disparaissent toujours. Et en inspectant DoclingDocument directement, len(doc.tables) == 0 alors que len(doc.pictures) == 1 — le modèle de mise en page avait classé toute la zone du tableau comme une Picture.
Puis le test décisif. J’ai re-rendu les tableaux T1 et T4 à l’identique, mais cette fois entourés de quelques paragraphes de texte classiques, puis j’ai reconverti. Les deux sont alors passés parfaitement : len(doc.tables) == 1, des tableaux GFM corrects sont générés, et l’étiquette de rowspan « North » dans T4b est bien répétée sur ses trois lignes. Même tableau. La seule variable modifiée était la présence ou non d’un contexte textuel autour du tableau sur une page peu dense.
La vraie réserve n’est donc pas que TableFormer est fragile : c’est que le modèle de mise en page RT-DETR de Docling utilise le contexte de la page, et qu’un petit tableau seul sur une page presque vide risque d’être lu comme une Picture puis d’être supprimé silencieusement. C’est facile à rencontrer dans la pratique, parce que c’est exactement à quoi ressemblent les factures, fiches techniques et exports recadrés : un tableau par page, sans prose autour. La correction est simple et efficace : donner du contexte à la mise en page, ou vérifier après conversion doc.tables et signaler les pages où le compteur est à zéro. Cela touche de près l’issue #3495 (un tableau détecté à la fois comme Table et comme Picture), mais le déclencheur précis lié à la sparsité de la page — même tableau, supprimé s’il est isolé, converti s’il est intégré au texte — je n’ai trouvé cela documenté nulle part. Mesuré, pas encore publié ; ce n’était pas un bug inconnu, mais ce cas précis ne l’était pas.
OCR sur de vrais scans : RapidOCR, pas EasyOCR
Les PDF scannés sont le terrain où beaucoup de convertisseurs échouent en silence. J’ai donc soumis à Docling deux vrais scans avec une couche texte mesurée à 0 caractère — pypdfium2 renvoie zéro caractère récupérable, ce qui confirme que toute sortie provient bien de l’OCR, et non d’un texte caché présent à côté.
Le fichier d’une page ocr_test.pdf est revenu proprement en 14,3 secondes sur CPU : « Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package, » a été récupéré mot pour mot. Le PDF de quatre pages nemotron_multipage.pdf a lancé l’OCR sur les quatre pages en 70,1 secondes au total (17,5 s/page), en reproduisant la phrase de test à chaque page. L’OCR par défaut s’est déclenché automatiquement — sans option, sans configuration.
Le détail que beaucoup d’articles se trompent encore à écrire : le moteur OCR par défaut est RapidOCR, pas EasyOCR. Je l’ai confirmé en voyant les poids .pth de PP-OCRv4 se télécharger au premier lancement. Beaucoup de blogs existants et d’anciennes FAQ de Docling affirment encore qu’EasyOCR est la valeur par défaut ; c’est obsolète. EasyOCR est désormais une extension optionnelle à activer. La réserve reste valable : l’OCR est le chemin lent à grande échelle, et ici tout est mesuré sur un plafond CPU uniquement — un GPU réduirait nettement ces temps.
Vrais PDF, ordre de lecture et temps par page
Les fixtures synthétiques prouvent des comportements précis ; les vrais PDF prouvent que l’outil fonctionne réellement. J’ai testé deux articles académiques natifs numériques — le rapport technique Docling de 9 pages et « Attention Is All You Need » de 15 pages, tous deux en double colonne avec tableaux et formules.
Sur l’article de 15 pages Attention, les cinq repères de section — Abstract, Introduction, Background, Conclusion, References — apparaissent dans l’ordre du document dans le Markdown linéarisé, malgré la mise en page en double colonne. Tous les points de contrôle de contenu (Transformer, encoder, BLEU, multi-head) sont présents, et les célèbres tableaux de résultats multi-colonnes sont bien détectés comme quatre tableaux. C’est une véritable récupération de l’ordre de lecture et de la fusion des colonnes, ce qui constitue la valeur centrale pour le découpage RAG — impossible de découper proprement un document si la linéarisation transforme une page à deux colonnes en chaos entremêlé.
Le timing apporte une leçon contre-intuitive : le temps par page dépend de la quantité de structure présente, pas du nombre de pages. Le rapport dense de 9 pages s’est exécuté à 14,95 secondes par page — donc plus lent par page que l’article de 15 pages à 5,99 secondes par page — parce qu’il contient davantage de tableaux et de figures, et que chacun déclenche plus d’inférences de mise en page et de TableFormer. Autrement dit, les « secondes par page » sur CPU dépendent de la densité structurelle, pas de la longueur. Il s’agit d’une exécution CPU unique ; c’est un plafond, pas un chiffre de production.
Multi-format et promesse de JSON sans perte
Docling revendique un parsing unifié multi-format, alors j’ai généré un DOCX, un XLSX et un PPTX avec du contenu connu et des points de contrôle de vérité terrain, puis j’ai vérifié deux choses : les repères apparaissent-ils dans le Markdown, et survivent-ils au aller-retour JSON via export_to_dict() ?
| Fichier | Conversion s | Repères trouvés dans MD | Tableaux dans MD | Repères conservés en JSON |
|---|---|---|---|---|
report.docx (titres + tableau fusionné « Total » + puces) | 0.137 | 7/7 | 1 | Oui |
workbook.xlsx (2 feuilles, colonne vide) | 0.016 | 6/6 | 2 | Oui |
deck.pptx (3 diapositives, puces + tableau) | 0.038 | 6/6 | 1 | Oui |
Tous les repères sont bien arrivés dans le Markdown, les tableaux ont été récupérés (y compris la ligne « Total » fusionnée du DOCX et les deux feuilles du XLSX), et chaque repère a aussi survécu au JSON de export_to_dict() — ce qui constitue la preuve utile pour l’affirmation de DoclingDocument sans perte, au moins sur des entrées propres. Ces formats passent par des backends natifs au format plutôt que par les modèles ML, ce qui explique qu’ils s’exécutent en quelques dizaines de millisecondes et fonctionnent totalement hors ligne. Le périmètre reste honnête : un fichier propre par format démontre la largeur de support, pas un stress test de fichiers Office pathologiques.
HTML : fidèle, mais pas nettoyé
C’est la réserve qui décide si Docling a sa place dans ton pipeline RAG, donc il faut la lire attentivement. Docling convertit le document HTML dans son intégralité. Il ne fait pas d’extraction du contenu principal façon readability. J’ai mesuré la quantité de chrome de site qui subsiste en comptant les lignes de navigation, sommaire, cookies et pied de page dans la sortie de Docling.
| Page | Lignes MD non vides | Lignes de boilerplate | % de boilerplate | Début de l’article à la ligne |
|---|---|---|---|---|
| Wikipedia « Web scraping » | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
Sur une page très chargée en éléments de navigation comme Wikipedia, environ 13 % des lignes Markdown correspondent au boilerplate de navigation/sommaire/pied de page, et le vrai article ne commence qu’à la ligne 28 — la sortie s’ouvre sur « move to sidebar / Contents / Toggle the table of contents » et se termine par « CS1 maint… / Search Wikipedia. » Sur les pages de contenu propres (books, quotes), on est proche de 0 %, donc il s’agit d’un problème de chrome de template, pas d’un coût constant par page. Docling fournit un Markdown fidèle du document entier, pas une extraction propre du contenu principal. En amont, le problème du mobilier HTML est suivi dans l’issue #1865 (fermée) et #1930 (ouverte).
Deux précisions permettent d’être juste. D’abord, sur le HTML, Docling n’exécute aucun modèle ML : il repose sur BeautifulSoup dans un pipeline simple. Le récit « les modèles vision lisent votre page » ne s’applique qu’aux PDF et aux images ; si tu donnes du HTML à Docling, ni la logique de mise en page ni TableFormer ne s’activent. Ensuite, le chemin PDF tente bien une classification du header et du footer, donc dire « aucun retrait du boilerplate » serait excessif : c’est le backend HTML, précisément, qui renvoie le chrome.
Comment il se compare — et où Thunderbit s’insère
Essayez Thunderbit pour l’extraction de données web
L’outil de référence avec lequel on compare Docling est Firecrawl, alors voici un tableau de positionnement. Une réserve importante d’emblée, car elle compte : il s’agit d’une comparaison au niveau documentation, pas d’un benchmark sur la même machine. Je n’ai pas exécuté Firecrawl sur ces fixtures. Seule la colonne Docling est mesurée ici ; la colonne Firecrawl provient de sa documentation publique.
| Axe | Firecrawl (selon sa documentation) | Docling (mesuré ici) |
|---|---|---|
| Mission principale | Crawler + extraction du web vivant → Markdown | Convertir un document que vous possédez déjà → Markdown/JSON |
| Récupération / rendu JS / anti-bot | Oui (navigateur hébergé) | Non — vous fournissez le fichier |
| Extraction du contenu principal | Oui | Non — document complet fidèle (~13 % de chrome sur Wikipedia) |
| Structure des tableaux PDF (ML) | limitée | Oui — TableFormer (TEDS officiel 93,6 ; cell recall 1.00, in-row 0.97–1.00 sur les fixtures détectées) |
| PDF scanné / OCR | limitée | Oui — RapidOCR par défaut (scan sans couche texte récupéré) |
| Ampleur des formats | pages web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/images |
| Déploiement | API hébergée (+ self-host) | bibliothèque pip locale, hors ligne, sans clé API |
| Poids de mise en route | clé API / client léger | installation par défaut de 1,3 Go + ~506 MiB de modèles (ou docling-slim) |
| Licence | commerciale / code source disponible | MIT |
En une phrase : Firecrawl est l’outil à utiliser quand tes données vivent sur le web et demandent crawl, rendu JavaScript et nettoyage du contenu principal. Docling est l’outil à utiliser quand tu as déjà le document — surtout les PDF, les scans et les fichiers Office riches en tableaux — et que tu veux une conversion fidèle, hors ligne, qui préserve la structure avec une vraie compréhension des tableaux et de l’OCR. Ils se complètent. Un pipeline réaliste explore le web avec l’un et convertit les documents avec l’autre.
C’est aussi l’occasion d’être clair sur Thunderbit, puisque je travaille ici et qu’il serait légitime d’être méfiant si je faisais semblant du contraire. Thunderbit et Docling ne font pas le même travail, et je ne vais pas forcer une équivalence. Pour les développeurs, Thunderbit est une API de scraping IA, plus un serveur MCP, plus une CLI ; son unité de travail est la page web vivante : POST /distill transforme une URL en Markdown propre, prêt pour les LLM (en gérant le rendu JS, l’anti-bot et les CAPTCHA que Docling ne traite pas), et POST /extract renvoie un JSON structuré correspondant à un schéma que tu définis. C’est l’étape de récupération et de nettoyage d’un pipeline RAG. Docling est la partie locale-document du pipeline — le PDF, le scan, la feuille de calcul déjà présente sur ton disque. Si ton corpus est composé de pages web, utilise l’API Thunderbit, ses outils MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ou la CLI (npx @thunderbit/thunderbit-cli). Si ce sont des PDF et des scans, utilise Docling. Si c’est les deux — ce qui est le cas de la plupart des pipelines réels — associe-les, parce qu’aucun des deux n’essaie d’être l’autre.
Verdict : provisoire, avec du travail restant
Je ne vais pas te donner une note unique sur 100, parce qu’un score pondéré intégrerait ici des pénalités pour des choses que Docling n’a jamais prétendu faire (comme le crawl) et ferait comme si tout était comparable. Par dimension, sur les fixtures testées :
- Mise en route / premier lancement : lourd — environnement virtuel de 1,3 Go, ~506 MiB de modèles, ~224 s au premier PDF, ~0,55 s ensuite — mais
docling-slimpermet de contourner ce poids. - Fidélité des tableaux : solide quand un tableau est détecté (cell recall 1.00 sur 5/5, in-row 0.97–1.00), en ligne avec l’histoire officielle TEDS sur ces fixtures.
- Robustesse de détection des tableaux : le piège des pages peu denses — un tableau isolé peut être classé comme Picture et disparaître. Vérifie
doc.tablesaprès coup. - Scans / OCR : fonctionne, RapidOCR par défaut ; lent à l’échelle.
- Multi-format : bon, avec un aller-retour JSON intact.
- HTML : fidèle, pas nettoyé — pas d’extraction du contenu principal.
- Expérience développeur : API claire en 3 lignes et
DoclingDocumentpropre, à l’exception du__version__manquant.
Pour qui c’est destiné : les équipes qui construisent des pipelines RAG ou data sur des PDF, des scans et des fichiers Office, et qui veulent une conversion hors ligne, structurée et fidèle, avec une vraie compréhension des tableaux et de l’OCR. Pour qui ce n’est pas destiné : toute personne qui a besoin de crawl du web vivant ou d’une extraction propre du contenu principal HTML — là, c’est un autre outil.
Et parce qu’il s’agit d’un test, pas d’un communiqué marketing, les limites restent clairement affichées. C’est une évaluation ciblée — 7 tableaux synthétiques plus 2 PDF réels sur une machine CPU uniquement — pas un benchmark d’exactitude à l’échelle TEDS. Plusieurs choses n’ont pas été testées et tu devrais les vérifier avant de miser un pipeline sur Docling : le chemin VLM optionnel (GraniteDocling), l’empreinte réelle de docling-slim, une exécution GPU, les cellules fusionnées complexes et irrégulières ainsi que les tableaux multipages, la fidélité des formules vers LaTeX, et — point le plus susceptible de te surprendre en production — la durabilité combinée de la mémoire en batch, de la montée en charge sous threads/GIL et du cycle de vie des objets sur des milliers de conversions. Docling est fort sur ce qu’il revendique, mesuré plutôt que marketé, et il a de vrais angles morts que tu voudras cartographier avant de lui confier un corpus. Connais la limite des pages peu denses, prévois le téléchargement initial, et vérifie toi-même son comportement à grande échelle.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Docling est-il un web scraper ou un crawler ? Non. Docling convertit les documents que tu possèdes déjà — PDF, DOCX, PPTX, XLSX, HTML, images — en Markdown ou JSON. Il ne récupère pas d’URL, ne rend pas JavaScript et ne gère pas l’anti-bot. Le crawl du web vivant est un travail séparé, assuré par des outils comme Firecrawl ou l’API web de Thunderbit ; Docling commence à partir du fichier que tu lui fournis.
Quelle est la taille de l’installation Docling et du premier téléchargement ?
Le package méta docling par défaut produit un environnement virtuel d’environ 1,3 Go, car il télécharge toute la pile ML comme dépendances obligatoires (torch à lui seul fait 536 MiB). La première conversion PDF télécharge environ 506 MiB de modèles de mise en page et de TableFormer sur disque, plus environ 40 Mo de poids RapidOCR, et prend environ 224 secondes — presque entièrement du temps de téléchargement. La deuxième conversion prend environ 0,55 seconde. Si tu n’as besoin que de formats légers, docling-slim (cœur d’environ 50 Mo) évite la partie lourde.
Docling fait-il de l’OCR, et avec quel moteur ? Oui. Sur un PDF scanné sans couche texte, l’OCR de Docling se déclenche automatiquement et a retrouvé le texte proprement dans mon test. Le moteur par défaut est RapidOCR, pas EasyOCR — une erreur fréquente dans les articles plus anciens. EasyOCR est désormais une extension facultative. L’OCR est le chemin lent à grande échelle, surtout sur CPU.
Pourquoi Docling a-t-il transformé mon tableau en image ou l’a-t-il supprimé ?
Très probablement à cause de l’effet des pages peu denses. Le modèle de mise en page RT-DETR de Docling utilise le contexte de la page, et un petit tableau seul sur une page presque vide peut être classé comme Picture puis supprimé sans erreur. Le même tableau entouré de texte est converti correctement. La solution consiste à donner du contexte à la mise en page ou à vérifier doc.tables après conversion et à signaler toute page où le compteur est à zéro.
Docling ou Firecrawl — lequel dois-je utiliser ? Ce sont des tâches différentes, donc ce n’est généralement pas un choix exclusif. Firecrawl explore le web vivant, rend JavaScript et extrait le contenu principal. Docling convertit les documents que tu possèdes déjà, avec une vraie structure de tableau PDF et de l’OCR, entièrement hors ligne. Si ta source est une page web, utilise un outil web (Firecrawl ou l’API / MCP / CLI de Thunderbit). Si ce sont des PDF, des scans ou des fichiers Office, utilise Docling. Dans la plupart des pipelines réels, on utilise les deux.
