Docling est souvent rangé à tort dans la catégorie des ai web scraper, alors que ce n’en est pas un. Il s’agit d’une boîte à outils de conversion de documents signée IBM Research — désormais projet de la LF AI & Data Foundation — qui prend des fichiers que vous possédez déjà (PDF, DOCX, PPTX, XLSX, HTML, images) pour les transformer en Markdown ou en JSON. Sa promesse tient en une phrase : « Préparez vos documents pour l’IA générative. »
Ce test pratique porte donc sur un convertisseur, pas sur un crawler. Tous les résultats ci-dessous ont été mesurés sur une seule machine CPU uniquement (macOS arm64, Python 3.14.2, Docling 2.111.0), avec un relevé des échecs quand il y en avait. Le dépôt est immense et évolue en continu — 63 069 étoiles, 4 449 forks, et un push le jour même où j’ai récupéré les métadonnées — donc prenez chaque chiffre de version ou de volume comme une photographie à l’instant T, pas comme une constante.
Ce qu’est vraiment Docling — et ce qu’il n’est pas
L’unité centrale de Docling est le DoclingDocument : on analyse un fichier dans cette structure, puis on l’exporte en Markdown, HTML, DocTags ou JSON sans perte. Le code est sous licence MIT (les licences des modèles peuvent varier), le projet est né chez IBM Research Zurich, et au moment où j’écris ces lignes, la dernière version est la v2.112.0, publiée deux jours avant mon test.
La fonctionnalité phare concerne les PDF et les images. Et ici, on ne parle pas de simple parsing de chaîne : Docling s’appuie sur une pile de modèles de machine learning — un modèle de mise en page RT-DETR, le modèle de structure de tableaux TableFormer, un modèle vision-langage facultatif, et RapidOCR pour les scans. Ces modèles reconstituent la mise en page, l’ordre de lecture et la structure des tableaux. C’est cette partie qui mérite d’être évaluée, et c’est précisément ce qu’un test limité au HTML ne peut pas voir.
Une distinction évite une semaine de confusion. Docling ne va chercher aucun contenu. Il ne rend pas JavaScript, ne contourne pas les protections anti-bot, et ne parcourt pas le web. Vous apportez le fichier ; il en comprend la structure. Le crawling relève d’un autre outil, ce qui devient important quand on se demande si Docling remplace Firecrawl (ce n’est pas le cas — ils se complètent, et j’explique pourquoi plus loin).
Le premier lancement que personne ne vous annonce
pip install docling s’installe proprement sur Python 3.14.2. Puis on regarde l’environnement virtuel, et il pèse 1,3 Go. Docling embarque toute la pile ML comme dépendances obligatoires, même si vous ne convertissez au final qu’un simple fichier HTML :
| Dépendance | Taille 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) | 72.1 |
| docling_parse | 30 |
Et cela, avant même de convertir le moindre PDF. Le vrai frottement apparaît à la première conversion de PDF, au moment où 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 en cache ; on ne paie la taxe qu’une seule fois.
Un chiffre à ignorer : le script de démarrage à froid affiche un model_download_mb de 1060.2. Ne citez pas cette valeur comme empreinte réelle. Elle vient d’un os.walk qui suit les liens symboliques, alors que le cache HuggingFace stocke chaque fichier de modèle une seule fois sous blobs/ puis le réexpose via un lien symbolique dans snapshots/ — l’analyse compte donc 14 fichiers de modèle deux fois. La valeur corrigée, équivalente à du et sans double comptage des symlinks, est d’environ 506 MiB (505,4 MiB pour les blobs seuls). Le point à retenir pour toute comparaison de Docling : distinguer les octets téléchargés des octets réellement stockés sur disque, car ce n’est pas la même chose.
Il y a un second piège qui touche quiconque construit un conteneur Docling. Les poids se répartissent en deux emplacements et selon deux mécanismes différents. Les modèles de mise en page et TableFormer respectent HF_HOME et se téléchargent à la première conversion de PDF. Les modèles de RapidOCR, eux, ne le font pas : ils atterrissent dans …/site-packages/rapidocr/models/, en dehors de votre configuration de cache. Si vous préparez une image à l’avance ou travaillez en environnement isolé, il faut gérer les deux caches, et aucun paramétrage de HF_HOME n’attrapera le second.
Il faut néanmoins être juste. Depuis les versions antérieures de Docling, le projet a publié docling-slim — un cœur d’environ 50 Mo qui permet pip install docling-slim[format-html] pour HTML sans embarquer torch. Les 1,3 Go sont donc bien réels pour le méta-paquet docling par défaut, mais ce n’est plus une fatalité. J’ai testé le paquet standard parce que c’est encore ce que donne pip install docling, mais ce poids n’est pas un défaut non traité : la solution modulaire existe, suivie dans le ticket #2393.
Au moment de l’installation, j’ai aussi relevé un petit accroc à signaler : import docling; docling.__version__ déclenche 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’un détail d’expérience développeur, ouvert en amont depuis juillet 2026 dans le ticket #3733.
Fidélité des tableaux : là où TableFormer justifie son existence
Les tableaux sont la raison pour laquelle on choisit Docling plutôt qu’un simple dump PDF vers texte, alors j’ai généré sept PDF de tableaux avec une vérité terrain exploitable par machine et j’ai noté le résultat cellule par cellule. Deux métriques comptent, et elles ne mesurent pas la même chose : le cell recall est la proportion de valeurs de vérité terrain présentes quelque part dans le tableau détecté ; le taux in-row est la proportion de valeurs placées dans la bonne ligne. Mélanger les deux avantage l’outil, donc les voici séparées :
| Tableau (cas stress) | Détecté | Cell recall | Taux in-row | Remarque |
|---|---|---|---|---|
| T1 grille bordée simple (8 lignes × 5 colonnes), seule sur la page | Non | 0.0 | — | classé comme <!-- image -->, toutes les cellules perdues |
| T2 sans bordures (seulement une règle d’en-tête) | Oui | 1.00 | 1.00 | parfait, grille exacte |
| T3 en-tête fusionné sur 2 niveaux avec colspan | Oui | 1.00 | 0.97 | toutes les valeurs sont là ; une valeur d’en-tête décale d’une ligne |
| T4 étiquette de ligne fusionnée sur plusieurs lignes, seule sur la page | Non | 0.0 | — | classé comme <!-- image --> |
| T5 en-tête avec colspan + sans bordures | Oui | 1.00 | 0.97 | toutes les valeurs sont là ; même décalage de ligne qu’en T3 |
| T6 tableau financier, colonne vide, aligné à droite | Oui | 1.00 | 1.00 | colonne vide conservée, pas de décalage |
| T7 grille large à 12 colonnes | Oui | 1.00 | 1.00 | aucun décalage de colonne sur un grand tableau |
Sur les cinq tableaux détectés par Docling, toutes les valeurs de vérité terrain ont été retrouvées — cell recall 1.00 partout. Sur trois de ces cinq, chaque valeur tombe aussi dans la bonne ligne. Sur les deux cas à en-têtes multiniveaux (T3 et T5), une valeur d’en-tête glisse d’une ligne, ce qui fait descendre le score in-row à 0.97 — toutes les données sont présentes, c’est simplement l’affectation à la ligne qui vacille d’un cran sur un en-tête empilé.
Les cas structurels les plus difficiles s’en sortent mieux que prévu. L’en-tête colspan à deux niveaux a été aplati correctement en Markdown GitHub-flavored (le libellé « Q1 2026 » est répété sur ses deux colonnes, ce qui est la bonne manière d’aplatir un colspan en GFM). La grille sans bordures, avec uniquement une règle d’en-tête (T2), a été restituée exactement. Le tableau large à 12 colonnes (T7) n’a subi aucun décalage. Et une colonne financière entièrement vide (T6) a été conservée sous forme de cellules vides, au lieu d’être supprimée ou fusionnée. Cela correspond aux scores officiels TEDS de TableFormer — 95,4 pour les tableaux simples, 90,1 pour les complexes, 93,6 au global — 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 un ticket ouvert dit presque l’inverse. Le ticket #3698 indique que V1 et V2 gèrent mal les lignes et colonnes fusionnées. Dans mes jeux de test, les simples colspan (T3/T5) et les rowspan ont été aplatis correctement, avec uniquement le décalage de ligne sur les en-têtes multiniveaux mentionné plus haut. Mais les cas qui échouent dans #3698 sont des fusions irrégulières multi-lignes/multi-colonnes et des tableaux multi-pages — le bord pathologique. Les miens appartiennent à la catégorie simple. La formulation exacte est donc é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 ouvert documenté. 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
Revenez au tableau : T1 et T4 n’ont pas été détectés du tout. Docling a émis <!-- image --> et supprimé toutes les cellules, sans erreur. T1 est une grille parfaitement ordinaire, bordée, de 8 lignes par 5 colonnes. C’est suffisamment inquiétant pour que j’aie refusé d’y voir d’emblée une faiblesse du parsing des tableaux ; j’ai donc construit un test A/B scripté pour identifier le vrai déclencheur.
D’abord, j’ai écarté les explications évidentes. La couche texte est intacte : pypdfium2 lit 327 caractères sur T1 et 221 sur T4, donc ce sont bien des PDF numériques et non des images scannées. Désactiver l’OCR (do_ocr=False) n’y change rien ; les tableaux disparaissent quand même. Et en inspectant directement DoclingDocument, on obtient len(doc.tables) == 0 alors que len(doc.pictures) == 1 : le modèle de mise en page a classé toute la zone du tableau comme une Picture.
Puis est venu le test décisif. J’ai re-rendu exactement les mêmes tableaux T1 et T4, cette fois entourés de quelques paragraphes ordinaires, puis j’ai reconverti. Les deux sont passés parfaitement : len(doc.tables) == 1, sortie d’un tableau GFM correcte, et l’étiquette rowspan « North » de T4b a bien été répétée sur ses trois lignes. Même tableau. La seule variable modifiée était sa position : seul sur une page presque vide, ou intégré à du texte.
La vraie réserve n’est donc pas que TableFormer serait fragile ; c’est que le modèle de mise en page RT-DETR de Docling utilise le contexte de page, et qu’un petit tableau isolé sur une page presque vide a de fortes chances d’être vu comme une Picture puis supprimé silencieusement. C’est facile à rencontrer en pratique, parce que cela ressemble exactement à des factures, des fiches techniques et des exports recadrés : un tableau par page, sans prose autour. La correction est simple et efficace : fournir davantage de contexte au modèle de mise en page, ou vérifier après conversion doc.tables et signaler les pages où le nombre est nul. Ce cas est proche du ticket #3495 (un tableau détecté à la fois comme Table et Picture), mais le déclencheur spécifique lié à la sparsité de la page — même tableau, supprimé lorsqu’il est isolé, converti lorsqu’il est intégré — je n’ai trouvé cela nulle part dans la documentation publiée. Mesuré, pas documenté auparavant ; pas un bug que personne ne connaissait.
OCR sur de vrais scans : RapidOCR, pas EasyOCR
Les PDF scannés sont souvent l’endroit où beaucoup de convertisseurs échouent discrètement, alors j’ai soumis Docling à deux vrais scans avec une couche texte mesurée à 0 caractère — pypdfium2 renvoyant zéro caractère récupérable, ce qui confirme que toute sortie provient bien de l’OCR et non d’un texte caché sous-jacent.
Le fichier mono-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 », reconstitué mot pour mot. Le document de quatre pages nemotron_multipage.pdf a lancé l’OCR sur les quatre pages pour un total de 70,1 secondes (17,5 s/page), en répétant la phrase de test sur chaque page. L’OCR par défaut s’est déclenché automatiquement — sans option, sans configuration.
Voici le détail que beaucoup d’articles se trompent à raconter : le moteur OCR par défaut est RapidOCR, et non EasyOCR. Je l’ai confirmé en observant le téléchargement initial des poids .pth PP-OCRv4 au premier lancement. Beaucoup de blogs existants, ainsi que d’anciens textes FAQ de Docling, affirment encore qu’EasyOCR est le moteur par défaut ; c’est dépassé. EasyOCR est désormais une option que l’on active explicitement. La réserve, elle, reste vraie : l’OCR devient le chemin lent à grande échelle, et ici tout est limité à du CPU — un GPU réduirait nettement ces durées.
PDFs réels, ordre de lecture et temps par page
Les jeux de test synthétiques prouvent des comportements ciblés ; les vrais PDF prouvent que l’outil fonctionne réellement. J’ai donc traité 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 deux colonnes avec tableaux et formules.
Sur l’article de 15 pages Attention, les cinq marqueurs de section — Abstract, Introduction, Background, Conclusion, References — apparaissent dans le bon ordre documentaire dans le Markdown linéarisé, malgré la mise en page en deux colonnes. Chaque mot-clé de vérification (Transformer, encoder, BLEU, multi-head) est bien présent, et les célèbres tableaux de résultats en multi-colonnes sont reconnus comme quatre tableaux détectés. C’est une vraie récupération de l’ordre de lecture et de la fusion des colonnes, qui constitue la valeur centrale pour le découpage RAG : on ne peut pas découper proprement un document si la linéarisation transforme une page en deux colonnes en chaos entremêlé.
Le temps de traitement apporte une leçon contre-intuitive. Le temps par page dépend de la densité structurelle de chaque page, pas du nombre de pages. Le rapport de 9 pages, plus dense, a tourné à 14,95 secondes par page — 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 par page — 3 tableaux sur 9 pages contre 4 sur 15 — et que chacun déclenche davantage d’inférences de mise en page et de TableFormer. La différence est étroite, et en valeur absolue le document le plus dense contient moins de tableaux, pas plus. Donc « secondes par page » sur CPU est une fonction de la densité structurelle, pas de la longueur. Il s’agit d’une exécution CPU unique ; c’est un plafond, pas une mesure de production.
Multi-format et promesse de JSON sans perte
Docling annonce 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 points de contrôle apparaissent-ils dans le Markdown, et survivent-ils à l’aller-retour JSON via export_to_dict() ?
| Fichier | Conversion s | Points de contrôle trouvés en MD | Tableaux dans MD | Points de contrôle 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 points de contrôle ont bien été retrouvé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 point de contrôle a également survécu au JSON export_to_dict() — ce qui constitue la preuve pertinente pour la promesse de DoclingDocument sans perte, du moins sur des fichiers propres. Ces formats passent par des backends natifs au format plutôt que par les modèles ML, d’où un traitement en quelques dizaines de millisecondes et un fonctionnement entièrement hors ligne. Le périmètre est honnête : un fichier propre par format démontre l’étendue, pas un test de résistance sur des fichiers Office pathologiques.
HTML : fidèle, mais pas nettoyé
C’est la réserve qui décidera si Docling a sa place dans votre pipeline RAG, donc lisez bien. Docling convertit l’intégralité du document HTML. Il ne fait pas d’extraction du contenu principal façon readability. J’ai quantifié la part d’habillage de site qui subsiste en comptant, dans la sortie de Docling, les lignes de navigation, table des matières, cookies et pied de page.
| 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 habillage comme Wikipedia, environ 13 % des lignes Markdown correspondent à de la navigation, de la table des matières ou du pied de page, et le vrai article ne commence qu’à la ligne 28 — la sortie s’ouvre par « move to sidebar / Contents / Toggle the table of contents » et se termine par « CS1 maint… / Search Wikipedia ». Sur des pages au contenu propre (books, quotes), on est à environ 0 %, donc il s’agit d’un problème d’habillage du template, pas d’une taxe systématique par page. Docling vous fournit un Markdown fidèle du document entier, pas une extraction nettoyée de l’article principal. L’upstream suit ce problème de mobilier HTML dans le ticket #1865 (fermé) et le #1930 (ouvert).
Deux points gardent l’évaluation équitable. D’abord, pour le HTML, Docling n’utilise aucun modèle ML — il repose sur BeautifulSoup dans un pipeline simple. L’histoire des « modèles de vision qui lisent votre page » ne concerne que les PDF et les images ; fournissez du HTML à Docling et toute la mécanique de mise en page ou de TableFormer ne s’active pas. Ensuite, le chemin PDF tente bien une classification des en-têtes et pieds de page, donc dire « aucune suppression de boilerplate » serait excessif — c’est le backend HTML, spécifiquement, qui renvoie l’habillage.
Comparaison avec le reste — et où Thunderbit s’insère
Essayez Thunderbit pour l’extraction de données web
L’outil de référence auquel on compare Docling est Firecrawl, donc voici un tableau de positionnement. Petite réserve d’emblée, car elle compte : il s’agit d’une comparaison documentaire, pas d’un benchmark sur la même machine. Je n’ai pas exécuté Firecrawl sur ces jeux de test. 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 | Explorer + extraire le web en direct → Markdown | Convertir un document que vous possédez déjà → Markdown/JSON |
| Fetch / rendu JS / anti-bot | Oui (navigateur hébergé) | Non — vous fournissez le fichier |
| Extraction du contenu principal | Oui | Non — document entier fidèle (~13 % de boilerplate 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 (un scan à couche texte nulle a été reconstruit) |
| Largeur de formats | pages web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/images |
| Déploiement | API hébergée (+ auto-hébergement) | bibliothèque locale pip, hors ligne, sans clé API |
| Poids d’installation | 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 |
La version courte : Firecrawl est l’outil à choisir quand vos données sont sur le web en direct et qu’il faut crawler, rendre du JavaScript et nettoyer le contenu principal. Docling est l’outil à choisir quand vous avez déjà le document — en particulier les PDF, les scans et les fichiers Office riches en tableaux — et que vous voulez une conversion fidèle, hors ligne, conservant la structure, avec une vraie compréhension des tableaux et de l’OCR. Les deux outils se complètent. Un pipeline réaliste utilise l’un pour crawler et l’autre pour convertir les documents.
C’est aussi l’endroit où je vais être transparent à propos de Thunderbit, puisque j’y travaille et que vous auriez raison de vous méfier si je faisais semblant du contraire. Thunderbit et Docling ne font pas la même chose, et je ne vais pas forcer une équivalence. Pour les développeurs, Thunderbit est à la fois une API de scraping par IA, un serveur MCP et un 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 touche pas), et POST /extract renvoie un JSON structuré conforme à un schéma JSON que vous définissez. C’est la partie « fetch and clean » d’un pipeline RAG. Docling correspond à la partie « document local » — le PDF, le scan, la feuille de calcul déjà sur votre disque. Si votre corpus est constitué de pages web, utilisez l’API Thunderbit, ses outils MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ou le CLI (npx @thunderbit/thunderbit-cli). S’il s’agit de PDF et de scans, utilisez Docling. Si vous avez les deux — ce qui est le cas de la plupart des pipelines réels — associez-les, et aucun des deux n’essaie de remplacer l’autre.
Verdict : provisoire, avec encore des devoirs à faire
Je ne vais pas vous donner une note unique de 0 à 100, car un total pondéré mélangerait des pénalités pour des choses que Docling n’a jamais prétendu faire (comme le crawling) et ferait comme si elles étaient comparables. Par dimension, sur les fixtures que j’ai testées :
- Installation / premier lancement : lourd — venv de 1,3 Go, ~506 MiB de modèles, ~224 s pour le premier PDF, ~0,55 s ensuite — mais
docling-slimpermet d’éviter 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 phase avec l’histoire officielle TEDS sur ces fixtures.
- Robustesse de détection des tableaux : le piège des pages sparse — un tableau isolé peut être classé comme Picture et disparaître. Vérifiez
doc.tablesaprès conversion. - Scans / OCR : fonctionne, RapidOCR par défaut ; lent à grande échelle.
- Multi-format : solide, avec un aller-retour JSON intact.
- HTML : fidèle, mais non nettoyé — pas d’extraction du contenu principal.
- Expérience développeur : API propre en 3 lignes et un
DoclingDocumentclair, à l’exception de__version__absent.
Pour qui c’est utile : les équipes qui construisent des pipelines RAG ou data autour de PDF, scans et fichiers Office, et qui veulent une conversion hors ligne, conservant la structure, avec une vraie compréhension des tableaux et de l’OCR. Pour qui ce n’est pas adapté : toute personne ayant besoin de crawler le web en direct ou d’extraire un article HTML propre — c’est un autre outil.
Et comme il s’agit d’un test, pas d’un communiqué de presse, les limites restent explicites. Ceci est une exploration ciblée — 7 tableaux synthétiques et 2 PDF réels sur une machine CPU unique — pas un benchmark TEDS à grande échelle. Plusieurs points n’ont pas été testés et méritent de l’être 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 multi-pages, la fidélité des formules vers LaTeX, et — le point le plus susceptible de vous surprendre en production — le triptyque de robustesse composé de la croissance mémoire en lot, du passage à l’échelle via threads/GIL, et du cycle de vie des objets sur des milliers de conversions. Docling est très fort sur ce qu’il promet, mesuré plutôt que marketé, et il a de vraies limites qu’il vaut mieux cartographier avant de lui confier un corpus. Connaissez le piège des pages sparse, budgétez le téléchargement du premier lancement, et vérifiez vous-même le 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 des documents que vous possédez 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 crawling du web en direct est un autre métier, assuré par des outils comme Firecrawl ou l’API web de Thunderbit ; Docling part du fichier que tu lui fournis.
Quelle est la taille de l’installation Docling et du téléchargement initial ?
Le méta-paquet par défaut docling crée un environnement virtuel d’environ 1,3 Go, car il embarque toute la pile ML comme dépendances obligatoires (torch à lui seul pèse 536 MiB). La première conversion PDF télécharge environ 506 MiB de modèles de mise en page et TableFormer sur disque, plus environ 40 Mo de poids RapidOCR, et prend environ 224 secondes — presque entièrement à cause du téléchargement. La deuxième conversion prend environ 0,55 seconde. Si vous n’avez besoin que de formats légers, docling-slim (cœur d’environ 50 Mo) évite le chemin lourd.
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 restitué le texte proprement lors de mon test. Le moteur par défaut est RapidOCR, et non EasyOCR — une confusion fréquente dans les articles plus anciens. EasyOCR est maintenant une option à activer explicitement. L’OCR reste 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 page sparse. Le modèle de mise en page RT-DETR de Docling utilise le contexte de page, et un petit tableau isolé sur une page presque vide peut être classé comme Picture puis supprimé sans erreur. Le même tableau entouré de texte se convertit correctement. La solution consiste à fournir davantage de contexte au modèle de mise en page, ou à vérifier doc.tables après conversion et à signaler toute page où le nombre est nul.
Docling vs Firecrawl — lequel utiliser ? Ce ne sont pas les mêmes tâches, donc la réponse est rarement binaire. Firecrawl parcourt le web en direct, rend JavaScript et extrait le contenu principal. Docling convertit des documents déjà en votre possession, avec une vraie structure de tableaux PDF et de l’OCR, entièrement hors ligne. Si votre source est une page web, utilisez un outil web (Firecrawl ou l’API/MCP/CLI de Thunderbit). S’il s’agit de PDF, de scans ou de fichiers Office, utilisez Docling. Dans la plupart des pipelines réels, on utilise les deux.
