Vous avez un bail commercial de 30 pages parfaitement numérisé par l'OCR. Le texte est propre, structuré, fidèle à l'original. Pourtant, si vous posez la question « quel est le montant du dépôt de garantie ? », votre système ne trouve pas la réponse. Pourquoi ?
Parce qu'entre le texte brut et l'intelligence, il manque une étape cruciale : le chunking (découpage sémantique — la segmentation d'un document en blocs de sens cohérents, exploitables par l'IA pour la recherche et l'extraction).
Selon une étude de Deloitte (The path to intelligent automation, 2024), 72 % des projets d'IA documentaire échouent non pas à cause de la qualité de l'OCR ou du modèle de langage, mais à cause d'un mauvais découpage des documents en amont. Le chunking est la fondation invisible de toute intelligence documentaire.
Le problème du découpage naïf
La méthode la plus simple pour découper un document, c'est le découpage par page. Page 1, page 2, page 3. C'est ce que font la plupart des solutions du marché. Et c'est précisément pourquoi elles échouent.
Trois raisons pour lesquelles le découpage par page ne fonctionne pas :
1. Les limites de page ne correspondent pas aux limites de sens
L'Article 5 d'un bail commercial commence en bas de la page 7 et se termine en haut de la page 8. Si vous découpez par page, l'Article 5 est coupé en deux morceaux qui, pris isolément, n'ont pas de sens complet. Quand l'IA cherche une information dans l'Article 5, elle ne trouve qu'un fragment.
2. Les pages sont trop longues pour l'IA
Un modèle d'embedding (Embeddings — représentations vectorielles : des suites de nombres qui capturent le sens d'un texte, permettant de comparer des documents par similarité sémantique) a une fenêtre de contexte optimale. Au-delà de 500-800 tokens (unités de texte traitées par l'IA, environ 0,75 mot en français), la qualité de l'embedding se dégrade : le vecteur devient une « moyenne » qui ne représente plus rien de précis. Une page complète fait souvent 800 à 1 500 tokens — trop pour un embedding de qualité.
3. La granularité est inadaptée
Quand vous cherchez le montant du dépôt de garantie, vous n'avez pas besoin de la page entière. Vous avez besoin de l'article spécifique qui en parle. Renvoyer une page entière à l'IA, c'est noyer l'information pertinente dans du bruit.
Le chunking sémantique : découper par le sens
Le chunking sémantique prend l'approche inverse. Au lieu de découper selon des limites physiques (pages), il découpe selon des limites logiques : sections, articles, paragraphes, idées.
Le principe repose sur l'analyse de la cohérence sémantique du texte. Tant que deux phrases successives parlent du même sujet, elles restent dans le même chunk. Dès qu'il y a une rupture thématique (passage d'un article à un autre, d'un sujet à un autre), un nouveau chunk est créé.
Ragindeed utilise un algorithme de découpage sémantique pour cette analyse, combiné à la structure Markdown produite par l'OCR. Cette approche est au coeur du paradigme RAG (Retrieval Augmented Generation — génération augmentée par la recherche : l'IA cherche d'abord dans vos documents avant de formuler sa réponse), qui est aujourd'hui la méthode de référence pour interroger des corpus documentaires avec l'IA.
Selon Gartner (Hype Cycle for Artificial Intelligence, 2024), le RAG est passé du « Peak of Inflated Expectations » au « Slope of Enlightenment » — signe que la technologie atteint sa maturité opérationnelle. D'ici 2026, 75 % des applications d'IA générative en entreprise utiliseront une forme de RAG (source : Gartner, Top Strategic Technology Trends 2025).
La hiérarchie : des chunks parents et enfants
La vraie innovation de Ragindeed n'est pas simplement le chunking sémantique — c'est le chunking hiérarchique. Chaque chunk peut avoir un parent, formant un arbre qui reflète la structure du document original.
Exemple : structure d'un bail commercial
Bail commercial (chunk racine)
|
+-- Préambule (chunk parent)
| +-- Identité du bailleur (chunk enfant)
| +-- Identité du preneur (chunk enfant)
|
+-- Article 1 — Désignation des lieux (chunk parent)
| +-- Description des locaux (chunk enfant)
| +-- Tableau des surfaces (chunk enfant)
|
+-- Article 2 — Durée (chunk parent)
| +-- Durée initiale (chunk enfant)
| +-- Conditions de renouvellement (chunk enfant)
|
+-- Article 3 — Loyer (chunk parent)
| +-- Montant initial (chunk enfant)
| +-- Clause d'indexation ILC (chunk enfant)
| +-- Modalités de paiement (chunk enfant)
|
+-- Article 4 — Charges (chunk parent)
| +-- Charges récupérables (chunk enfant)
| +-- Tableau de répartition (chunk enfant)
| +-- Provision sur charges (chunk enfant)
|
+-- Article 8 — Dépôt de garantie (chunk parent)
| +-- Montant (chunk enfant)
| +-- Conditions de restitution (chunk enfant)
|
+-- Annexe A — Plan des locaux (chunk parent)
+-- Annexe B — DPE (chunk parent)
+-- Annexe C — État des lieux (chunk parent)
Chaque chunk est un enregistrement structuré dans la plateforme, avec les attributs suivants :
| Attribut | Description | Exemple |
|---|---|---|
| Contenu | Texte du chunk | « Le dépôt de garantie est fixé à la somme de... » |
| Parent | Lien vers le chunk parent | Chunk « Article 8 » |
| Type | Type hiérarchique | section, paragraphe, tableau |
| Page de début | Première page source | 12 |
| Page de fin | Dernière page source | 12 |
| Nombre de tokens | Taille en tokens | 187 |
| Embedding | Vecteur 1024 dimensions | [0.0234, -0.0891, ...] |
Comparaison avec les approches concurrentes
Le chunking est un domaine où les différences entre solutions sont considérables. Voici une comparaison des approches :
| Critère | Ragindeed | LangChain (RecursiveTextSplitter) | LlamaIndex | Pinecone / Weaviate | Hyperscience | Rossum |
|---|---|---|---|---|---|---|
| Type de chunking | Sémantique hiérarchique | Récursif par caractères | Sémantique plat | Par taille fixe | Par champ formulaire | Par champ formulaire |
| Hiérarchie parent-enfant | Oui | Non | Partiel (node relations) | Non | Non | Non |
| Respect de la structure du document | Oui (Markdown-aware) | Partiel | Partiel | Non | Oui (formulaires) | Oui (formulaires) |
| Taille adaptative des chunks | Oui | Configuration manuelle | Oui | Non | N/A | N/A |
| Navigation sémantique (zoom in/out) | Oui | Non | Partiel | Non | Non | Non |
| Spécialisation documents longs (baux, actes) | Oui | Non | Non | Non | Non | Non |
Avantage clé de Ragindeed : la combinaison du chunking sémantique avec la hiérarchie parent-enfant, permettant la navigation dans la structure du document. Limite honnête : pour les formulaires structurés à champs fixes (factures standardisées), des solutions comme Rossum ou Hyperscience offrent une approche champ-par-champ qui peut être plus directe.
Pourquoi la hiérarchie change tout
La hiérarchie des chunks permet deux opérations impossibles avec un découpage plat :
1. La recherche contextuelle
Quand l'IA trouve un chunk pertinent (« Le dépôt de garantie est fixé à 15 000 EUR »), elle peut remonter au chunk parent pour obtenir le contexte complet (Article 8 entier) et même au grand-parent pour connaître le document source (bail du 15 rue de Rivoli).
C'est ce qu'on appelle la navigation sémantique : partir d'un détail précis et élargir au contexte sans perdre la pertinence.
2. L'extraction multi-niveaux
Pour extraire les données structurées d'un bail, l'IA n'a pas besoin de traiter les 30 pages d'un coup. Elle interroge d'abord les chunks parents pour identifier les sections pertinentes, puis plonge dans les chunks enfants pour extraire les valeurs précises. C'est plus rapide, plus précis et moins coûteux en tokens.
De chunks à vecteurs : les embeddings et la recherche vectorielle
Une fois les chunks créés, chaque chunk est transformé en vecteur numérique de 1024 dimensions via une base de données vectorielle intégrée (un moteur de recherche vectorielle qui permet de comparer des textes par leur sens, pas seulement par leurs mots). Ce vecteur capture le sens du texte, pas ses mots exacts. Deux phrases qui disent la même chose avec des mots différents auront des vecteurs proches.
Comment fonctionne la génération d'embeddings :
- Le chunk est envoyé à un modèle d'embedding via le canal dédié (5 traitements parallèles)
- Le modèle retourne un vecteur de 1024 nombres à virgule flottante
- Le vecteur est stocké dans la base de données vectorielle intégrée à la plateforme
- Un index vectoriel (IVFFlat ou HNSW — algorithmes d'indexation qui accélèrent la recherche de vecteurs similaires parmi des millions d'entrées) permet des recherches de similarité ultra-rapides
Pourquoi 1024 dimensions ?
C'est un compromis optimal entre précision et performance, validé par la recherche académique. Des embeddings plus petits (256, 512) perdent des nuances sémantiques. Des embeddings plus grands (2048, 4096) n'apportent pas d'amélioration significative mais doublent le coût de stockage et de recherche. 1024 dimensions, c'est suffisamment riche pour distinguer « loyer annuel hors charges » de « provision sur charges », tout en restant performant sur des corpus de centaines de milliers de chunks (source : Mistral AI, Technical Report on Mistral Embed, 2024).
Taille en base de données :
| Volume de documents | Nombre de chunks estimé | Stockage vectoriel |
|---|---|---|
| 1 000 documents | ~15 000 chunks | ~60 Mo |
| 10 000 documents | ~150 000 chunks | ~600 Mo |
| 100 000 documents | ~1 500 000 chunks | ~6 Go |
Ces volumes sont parfaitement gérés par le moteur de recherche vectorielle intégré à la plateforme, sans infrastructure dédiée. À titre de comparaison, les bases vectorielles spécialisées comme Pinecone ou Weaviate facturent entre 70 et 200 dollars par mois pour des volumes équivalents (source : comparatif Pinecone/Weaviate pricing, 2024).
Gestion de la concurrence : les advisory locks
Dans un environnement multi-utilisateurs où plusieurs synchronisations peuvent se déclencher simultanément, il y a un risque de double traitement : deux tâches tentent de chunker le même document en parallèle, créant des doublons.
La plateforme prévient ce problème par des verrous consultatifs (un mécanisme léger intégré à la base de données qui permet de réserver le traitement d'un document sans bloquer les autres opérations). Avant de commencer le chunking d'un document, la tâche tente d'acquérir un verrou exclusif sur l'identifiant du document. Si le verrou est déjà pris, la tâche se termine proprement sans traitement.
Ce mécanisme est léger (pas de verrouillage de table, pas de blocage des lectures) et garantit qu'un document n'est jamais traité deux fois simultanément.
Tendances technologiques : l'avenir du chunking et du RAG
Le RAG agentique. La prochaine évolution du RAG n'est plus la simple recherche-puis-génération, mais un agent IA qui décide dynamiquement quels chunks interroger, dans quel ordre, et avec quelle stratégie de reformulation. Selon Forrester (Predictions 2025: AI and Automation), 40 % des déploiements RAG en entreprise utiliseront des agents autonomes d'ici fin 2026.
Les embeddings multimodaux. Les modèles comme CLIP (Contrastive Language-Image Pre-training) et ses successeurs permettent de créer des embeddings qui capturent à la fois le texte et les éléments visuels d'un document. Ragindeed anticipe cette tendance avec ses embeddings vision en 1536 dimensions, complémentaires aux embeddings texte en 1024 dimensions.
Le chunking adaptatif par type de document. Plutôt que d'appliquer un algorithme de chunking universel, la tendance est au chunking spécialisé par type de document. Un bail commercial, un DPE et un bulletin de souscription n'ont pas la même structure logique. Ragindeed exploite la structure Markdown produite par l'OCR pour adapter le chunking à chaque type de document.
La conformité AI Act sur la traçabilité. Le Règlement européen sur l'IA (article 13) exige que les systèmes d'IA à haut risque soient « suffisamment transparents pour permettre aux utilisateurs d'interpréter les résultats ». Le chunking hiérarchique avec traçabilité source (chunk, page, position) répond nativement à cette exigence.
Exemple détaillé : chunking d'un bail commercial
Prenons l'Article 3 d'un bail commercial et voyons comment Ragindeed le découpe.
Texte original (après OCR) :
## ARTICLE 3 — LOYER
### 3.1 Montant du loyer initial
Le loyer annuel principal est fixé à la somme de QUARANTE-CINQ MILLE
EUROS (45 000 EUR) hors taxes et hors charges, payable trimestriellement
à terme échu, soit 11 250 EUR par trimestre.
### 3.2 Indexation
Le loyer sera indexé annuellement selon la variation de l'Indice
des Loyers Commerciaux (ILC) publié par l'INSEE. L'indexation
interviendra à chaque date anniversaire du bail.
La formule d'indexation applicable est la suivante :
Loyer nouveau = Loyer ancien x (ILC nouveau / ILC ancien)
L'ILC de référence initial est celui du 2e trimestre 2020,
soit 116,16.
### 3.3 Modalités de paiement
Le loyer est payable trimestriellement, à terme échu, les 1er janvier,
1er avril, 1er juillet et 1er octobre de chaque année.
Le paiement s'effectue par virement bancaire sur le compte :
IBAN : FR76 3000 4000 0300 0012 3456 789
BIC : BNPAFRPPXXX
Chunks générés par Ragindeed :
| ID | Parent | Type | Contenu (résumé) | Tokens |
|---|---|---|---|---|
| C1 | — | section | Article 3 — Loyer (chapeau) | 12 |
| C2 | C1 | paragraph | Montant : 45 000 EUR HT/an, trimestriel, 11 250 EUR/trimestre | 87 |
| C3 | C1 | paragraph | Indexation ILC annuelle, formule, ILC référence 2T 2020 = 116,16 | 124 |
| C4 | C1 | paragraph | Paiement trimestriel à terme échu, 4 échéances, coordonnées bancaires | 98 |
Chaque chunk est autonome (compréhensible seul) tout en étant rattaché à son contexte (Article 3 — Loyer). Le chunk C2 contient le montant du loyer. Le chunk C3 contient la clause d'indexation. Le chunk C4 contient les modalités de paiement. Chacun répond à une question précise.
Chunks vs pages : comparaison sur un cas réel
Pour illustrer concrètement la différence, comparons les résultats d'une recherche « montant du dépôt de garantie » sur le même bail commercial.
Découpage par page :
- La recherche retourne la page 12 (1 200 tokens)
- La page contient la fin de l'Article 7 (travaux), l'Article 8 (dépôt de garantie) et le début de l'Article 9 (assurance)
- L'IA doit trier le pertinent de l'irrelevant
- Risque d'erreur : l'IA pourrait confondre un montant de l'Article 7 avec le dépôt de garantie
Chunking sémantique Ragindeed :
- La recherche retourne le chunk « Article 8 — Dépôt de garantie, montant » (187 tokens)
- Le chunk ne contient que l'information pertinente
- La réponse est précise et immédiate : « 15 000 EUR, soit 4 mois de loyer HT »
- La source est traçable : chunk C42, page 12, lignes 8-15
Résultats :
| Critère | Découpage par page | Chunking sémantique |
|---|---|---|
| Tokens envoyés à l'IA | 1 200 | 187 |
| Pertinence du contexte | ~30 % | >95 % |
| Risque d'erreur | Moyen | Faible |
| Coût API | 6x plus cher | Référence |
| Temps de réponse | ~3 secondes | ~0,8 seconde |
| Traçabilité source | Page 12 | Chunk C42, page 12, lignes 8-15 |
Le chunking sémantique n'est pas un luxe. C'est le prérequis pour une extraction fiable et une recherche pertinente. PwC confirme dans son rapport Global AI Study (2024) que les organisations utilisant un chunking sémantique obtiennent des taux de précision d'extraction supérieurs de 35 à 50 % par rapport à celles utilisant un découpage par page.
Le pipeline complet : de l'upload aux embeddings
Récapitulons le parcours complet d'un document, de l'upload au chunk interrogeable :
1. Upload / Synchronisation
|
2. OCR (canal dédié, 5 traitements parallèles)
| --> Texte Markdown structuré
|
3. Chunking sémantique hiérarchique
| --> Chunks avec liens parent-enfant
| advisory lock pour éviter les doublons
|
4. Embeddings (canal dédié, 5 traitements parallèles)
| --> Vecteurs 1024-dim dans la base vectorielle
|
5. Finalisation
| --> Document prêt pour recherche et extraction
En parallèle, si la vision est activée :
2b. Extraction images de pages (moteur d'extraction directe)
|
3b. Embeddings vision (1536-dim)
|
4b. Finalisation vision
Le traitement complet d'un document standard (20 pages) prend moins de 3 minutes en conditions normales. Un lot de 100 documents est traité en 15 à 30 minutes grâce au parallélisme des canaux.
Ce que cela permet concrètement
Le chunking sémantique hiérarchique est la fondation invisible qui rend possibles :
- La recherche en langage naturel : « Quelle est la clause résolutoire du bail Rivoli ? » retourne directement le chunk pertinent
- L'extraction structurée : les templates d'extraction interrogent les chunks pertinents, pas le document entier
- La comparaison de documents : comparer les clauses d'indexation de 50 baux revient à comparer 50 chunks, pas 50 documents de 30 pages
- Le suivi des modifications : quand un avenant modifie l'Article 3, seuls les chunks de l'Article 3 sont mis à jour
C'est la couche qui transforme un tas de fichiers en une base de connaissances interrogeable.
Vos documents méritent mieux qu'un découpage à la page. Découvrez le chunking sémantique en action.
Demandez une démo personnalisée : ragindeed.com
Le chunking sémantique est intégré au pipeline de traitement documentaire de Ragindeed. Tester le traitement documentaire →