Un bail commercial, un K-bis, un diagnostic amiante, un PV d'assemblée générale, un ordre de virement, une déclaration PPE, un extrait de matrice cadastrale, une note de renseignements d'urbanisme. Pour une SGP qui gère plusieurs milliers de documents par opération, classer à la main n'est plus envisageable : c'est un poste de coût, une source d'erreur, et surtout un angle mort réglementaire. Cet article détaille l'approche que nous avons industrialisée, les chiffres que nous mesurons réellement en production, et ce qui nous distingue de l'état de l'art académique et des GED du marché.
Selon une enquête Gartner (Digital Worker Experience Survey, 2023), 47 % des collaborateurs déclarent peiner à retrouver l'information documentaire dont ils ont besoin pour faire leur travail. Une étude AIIM complémentaire (State of the Intelligent Information Management Industry, 2024) estime qu'en moyenne un tiers du temps des équipes back-office d'un cabinet réglementé est consacré à des tâches de rangement documentaire : ouvrir un PDF, le lire en diagonale, deviner à quel dossier il appartient, lui coller une étiquette, le glisser dans le bon sous-dossier. Multiplié par des dizaines de milliers de documents par an, c'est une organisation entière qui tourne au ralenti.
Pourquoi la classification documentaire est un problème difficile
Les GED classiques — SharePoint, M-Files, Zeendoc, DocuWare, Alfresco — savent stocker. Elles ne savent pas comprendre. Un bail commercial scanné en 2003 arrive sous le nom Scan_20030712_001.pdf. Rien dans la GED ne dira jamais qu'il concerne le 15 rue de Rivoli, que c'est un bail commercial et non un bail d'habitation, que l'actif est dans le secteur immobilier, et que le bail expire en 2027. Tant qu'un humain ne l'a pas lu, ces informations n'existent pas pour le système.
La communauté académique appelle ce problème Extreme Multi-Label Classification (XMC). Quand le nombre d'étiquettes cibles dépasse quelques dizaines, les approches naïves s'effondrent. Soumettre à un modèle de langage la liste complète de 270 tags candidats dans un prompt aboutit à ce que la recherche récente appelle label space dilution : le modèle hésite, hallucine, ou se rabat sur des étiquettes génériques.
Les benchmarks de référence le confirment :
| Benchmark | Nombre d'étiquettes | Précision@1 état de l'art | Méthode |
|---|---|---|---|
| EURLEX-4K (juridique UE) | ~ 4 000 | ~ 88 % | MatchXML, XR-Transformer |
| DBPedia-298 | 298 | 92,9 % | TELEClass |
| Amazon-531 | 531 | 84,4 % | TELEClass |
| SSRN scientifique (COLING 2025) | 2 778 (9 niveaux) | 94,3 % | LLM-SelectP (retrieve-then-LLM) |
Deux enseignements ressortent de cette littérature. Aucune méthode ne dépasse durablement les 90 % sans architecture dédiée dès qu'on aborde quelques centaines de tags. Et les meilleures performances publiées à ce jour (94,3 % sur 2 778 étiquettes, COLING 2025, source : Can Large Language Models Serve as Effective Classifiers for Hierarchical Multi-Label Classification of Scientific Documents at Industrial Scale ?) sont obtenues par des architectures hybrides : un premier étage de retrieval sémantique pré-sélectionne les tags plausibles, un LLM tranche ensuite.
Un article de 2025 (« From Haystack to Needle : Label Space Reduction ») a quantifié précisément ce qu'on gagne à ne pas tout envoyer au modèle : jusqu'à +14,2 points de macro-F1 pour Llama-3.1-70B et +3,3 points pour Claude 3.5 Sonnet quand on pré-filtre l'espace des étiquettes. Même les plus gros modèles du marché classent mieux quand on leur présente un choix restreint et pertinent.
C'est exactement l'architecture qu'emploie Ragindeed.
Ce que font (et ne font pas) les GED et IDP du marché
Les éditeurs de GED et d'IDP (Intelligent Document Processing) revendiquent volontiers des précisions de 95 %, 98 %, 99 %. En examinant leurs livres blancs et études de cas, on découvre que :
- Ces chiffres concernent l'extraction de champs sur une facture ou un contrat (montant, date, fournisseur), pas la classification dans une taxonomie profonde.
- Quand le périmètre de classification est précisé, il s'agit typiquement de 5 à 20 types de documents. Une étude AWS/Associa de 2024, l'une des plus transparentes publiées, revendique 95 % de précision sur 8 catégories, avec une dispersion de 67 % à 100 % selon la catégorie (source : AWS Machine Learning Blog, 2024).
- Aucun éditeur IDP n'a publié à ce jour de benchmark rigoureux sur une taxonomie hiérarchique de 200 à 300 étiquettes, a fortiori dans un contexte francophone de conformité financière ou immobilière.
La marche est donc haute. C'est précisément pour cela que nous documentons nos propres chiffres, plus loin dans cet article.
La taxonomie Ragindeed, pensée pour durer
Avant même de parler d'IA, nous avons passé plusieurs mois à construire la taxonomie Ragindeed : une arborescence de classification stable, cohérente, versionnée, utilisée comme référentiel unique par l'ensemble de la plateforme.
Trois niveaux, pas plus
Facette racine (N1) → sous-facette métier (N2) → tag feuille. Au-delà, l'utilisateur se perd, et l'IA aussi. Nous avons testé des arborescences plus profondes : la précision du modèle chute dès qu'il doit naviguer plus de trois couches de catégories proches. C'est aussi la profondeur retenue par la taxonomie DBPedia (3 niveaux, 298 étiquettes), celle qui produit les meilleurs chiffres publics sur des tâches comparables (92,9 % P@1).
Quatorze facettes racines couvrant l'intégralité du cycle documentaire
Identité & capacité juridique. Contrats & engagements. Propriété & droits réels. Description & caractéristiques de l'actif. Organisation. Réglementaire. Environnement. Assurances. Financiers. Fiscalité. Correspondance. Contentieux. Projets. Secteur d'activité. Chacune est stable, chacune a une frontière clairement définie, chacune est documentée avec sa description sémantique, utilisée à la fois par l'IA et par les utilisateurs humains.
Une dimension sectorielle orthogonale
C'est l'innovation la plus structurante de notre refonte. La nature du document (bail, K-bis, facture, jugement…) est indépendante du secteur dans lequel il est utilisé (immobilier, finance, santé, transport, énergie). Un K-bis sert en immobilier ET en gestion de portefeuille. Une convention d'honoraires est la même dans une SGP et dans un cabinet de conseil. Plutôt que de dupliquer les tags secteur par secteur — ce que font la plupart des taxonomies héritées — nous apposons deux dimensions distinctes : « quel type de document ? » et « dans quel secteur ? ». Conséquence : ajouter un nouveau secteur à la plateforme ne casse jamais le tronc commun. Il l'étend.
Trois systèmes de tags, visuellement distincts
Dans Ragindeed, trois couches de classification cohabitent par conception :
| Symbole | Système | Usage |
|---|---|---|
| 🏷️ | Taxonomie universelle | Référentiel stable, partagé par tous les modules |
| 📁 | Tags documentaires | Workspaces et workflows GED (voir l'organisation par espace) |
| 🤖 | Tags IA | Classification automatique propre à chaque workspace IA |
Dans une liste déroulante, un fil d'audit ou un rapport, l'utilisateur sait immédiatement d'où vient chaque étiquette. Cette distinction paraît cosmétique : elle évite en réalité des heures de confusion quand plusieurs automatisations s'empilent sur un même document. Et elle protège la taxonomie de référence d'une dérive progressive par les automatismes métier.
La qualité du tagging se joue avant le tagging — la chaîne de bout en bout
Un point que nous insistons systématiquement à expliquer : la précision finale d'un tag ne dépend pas seulement du modèle qui le pose. Elle dépend de la qualité de tous les maillons en amont. Un caractère mal lu dans l'OCR, un titre fusionné avec un paragraphe par défaut de mise en page, un tableau désintégré par un mauvais découpage : chacune de ces dégradations remonte jusqu'au modèle final, qui prend alors une décision sur une matière dégradée. C'est ce que la communauté IDP appelle parfois « garbage in, garbage tagged ».
OCR multi-moteurs avec sélection adaptative
Un PDF n'est jamais un PDF. C'est l'un des trois : PDF natif (texte vectoriel proprement embarqué), PDF scanné (image bitmap), ou PDF hybride. Chacun appelle un moteur d'extraction différent : PyMuPDF pour les PDF natifs, Marker PDF pour les scans complexes avec préservation de la structure, MarkItDown pour les formats bureautiques, et un fallback Vision LLM pour les pages où le texte OCR reste sous le seuil de 1 000 caractères significatifs. Sur un échantillon de 200 documents immobiliers réels, plus de 30 % ont déclenché le fallback vision — sans cette deuxième passe, ces documents auraient été soit non classés, soit mal classés.
L'article dédié à l'OCR de Ragindeed détaille cette logique multi-moteurs.
Préservation du layout, pas seulement du texte
Beaucoup de plateformes IDP traitent un document comme une simple chaîne de caractères. C'est une erreur structurelle : la mise en page porte du sens. Un en-tête « BAIL COMMERCIAL » en majuscules de 18 pts en première page n'a pas la même valeur sémantique qu'un même mot apparaissant dans un paragraphe d'introduction. Une signature manuscrite en bas de page n'est pas un mot parmi d'autres : c'est un marqueur d'engagement juridique.
Notre extraction préserve la structure hiérarchique du document : titres, sous-titres, listes, tableaux, blocs séparés, ordre de lecture en colonnes multiples. Selon les benchmarks publiés par Microsoft Research (LayoutLMv3, 2022), l'exploitation conjointe du texte et de la mise en page apporte un gain de +12 points de F1-score par rapport au texte seul sur le benchmark FUNSD d'extraction de formulaires. Le modèle de tagging exploite cette structure pour identifier les passages discriminants — un titre, un en-tête de tableau — plutôt que de noyer le signal dans la masse du texte courant.
Chunking sémantique hiérarchique, pas découpage à la longueur
Le découpage du document en fragments (« chunks ») est une étape sous-estimée. La majorité des plateformes IDP coupent à la longueur fixe (toutes les 1 000 ou 2 000 caractères, peu importe ce qu'on coupe). Conséquence : une définition juridique commencée page 3 peut se retrouver tronquée en plein milieu, l'IA n'en voit que la moitié, le tag est faux.
Nous utilisons un chunking sémantique hiérarchique qui respecte les frontières naturelles (paragraphes, sections, items de liste, lignes de tableau), conserve la relation parent-enfant entre un titre et le contenu qu'il introduit, regroupe les passages sémantiquement proches sans casser leur cohérence, et indexe chaque chunk avec son numéro de page, sa bounding box, et son chunk parent. C'est cette hiérarchie qui permet, en aval, de remonter d'un tag posé jusqu'au passage exact qui l'a justifié.
Nous détaillons cette mécanique dans l'article dédié au chunking sémantique.
Vision PDF — quand le texte ne suffit pas
Pour les pages où l'OCR ne récupère pas un signal suffisant (scans très anciens, plans cadastraux, formulaires manuscrits, photos de pièces d'identité), nous extrayons une image haute résolution de la page, la stockons dans S3, et la soumettons à un modèle vision (GPT-4o, Claude Vision). Le résultat est un texte enrichi et un embedding vision dédié de dimension 1 536, indexé en parallèle de l'embedding texte.
Cette double indexation (texte + vision) permet à l'étape de pré-sélection des candidats de retrouver des tags pertinents même lorsque le contenu visuel l'emporte sur le contenu textuel (carte, plan, graphique). Aucun modèle de tagging textuel pur ne peut classer correctement un plan cadastral. Voir l'article sur la vision documentaire.
Embeddings spécialisés et indexation pgvector
Chaque chunk est vectorisé par un modèle d'embedding multilingue (BAAI/bge-m3, dimension 1 024), puis stocké dans une base PostgreSQL avec extension pgvector. Nous combinons systématiquement la recherche dense (similarité cosinus pour la sémantique), la recherche sparse (mots-clés et BM25 pour les termes rares — codes APE, références cadastrales, noms propres), et un cache des embeddings de tags avec calcul vectorisé via numpy, pour que la pré-sélection des candidats reste sous les 50 ms même sur des taxonomies de plusieurs centaines d'étiquettes.
Reconnaissance d'entités nommées (NER) — capter les ancres métier
Un bail commercial ne se reconnaît pas seulement à ses formules juridiques : il se reconnaît à la présence simultanée de certaines entités — un bailleur, un preneur, une adresse de local, un loyer en euros, une durée. Une déclaration PPE, à un nom de personne politiquement exposée, un pays, une fonction officielle. Un K-bis, à un numéro SIREN, une dénomination sociale, une forme juridique, un capital. Ces ancres sont des signaux discriminants extrêmement puissants pour la classification.
Nous extrayons donc systématiquement, en parallèle de l'OCR et du chunking, un jeu d'entités nommées spécifique au domaine : personnes physiques (noms, qualités, dates de naissance), personnes morales (dénominations, formes juridiques, SIREN/SIRET, codes APE, capital), adresses et géographie (adresses postales structurées, géocodage BAN, références cadastrales), données financières (montants, taux, RIB/IBAN), données juridiques (numéros AMF, GIIN, mentions PPE, listes de sanctions), dates et durées (parsing multilingue).
L'extraction combine plusieurs approches : règles spécialisées pour les patterns structurés (SIREN validé par clé de Luhn, IBAN par MOD-97, références cadastrales — précision > 99 % par construction), modèles NER pré-entraînés pour le français, et extraction LLM dirigée pour les entités domaine-spécifiques. Chaque entité est normalisée et indexée séparément du texte brut. Conséquence directe sur la classification : la présence d'un SIREN dans les premières pages oriente le tagging vers « Identité & capacité juridique » avec une force de signal qu'un simple comptage de mots ne pourrait jamais produire. Une mention « PPE » ou un pays sous sanctions déclenche immédiatement les tags réglementaires correspondants.
Ces ancres alimentent ensuite l'extraction structurée et les vérifications LCB-FT.
Validation à chaque maillon, pas seulement à la sortie
Chaque étape du pipeline est instrumentée et mesurée individuellement : temps d'OCR, nombre de caractères extraits, ratio de pages ayant nécessité du vision fallback, nombre de chunks générés, distribution des longueurs de chunks, distribution des scores de similarité aux tags candidats, latence de chaque appel LLM, tokens consommés. Une dégradation à n'importe quel niveau remonte dans nos dashboards avant qu'elle n'affecte la qualité du tag final.
Le pipeline de classification, étape par étape
Une fois la chaîne de préparation passée, le tagging proprement dit suit un pipeline en quatre temps. Chaque étape a été conçue pour éliminer une classe d'erreurs.
Étape 1 — Document préparé, structuré, indexé. À ce stade, le document a déjà été passé dans la chaîne de qualité décrite plus haut : OCR adapté, layout préservé, chunks hiérarchiques, embeddings texte et vision indexés, entités nommées extraites. C'est cette qualité d'entrée qui rend le reste possible.
Étape 2 — Pré-sélection des candidats par similarité sémantique. Nous ne soumettons jamais l'intégralité de la taxonomie au modèle. Chaque tag est indexé par son embedding sémantique. Pour chaque document à classer, un premier étage calcule la similarité entre le document et chaque tag, et ne retient que les 30 candidats les plus pertinents. Cette étape n'est pas un raccourci : c'est l'architecture qui produit les meilleures précisions publiées sur les grandes taxonomies (94,3 % sur 2 778 étiquettes avec LLM-SelectP, COLING 2025). Elle évite la dilution attentionnelle, le biais positionnel et l'explosion du coût.
Étape 3 — Décision supervisée par LLM, instrumentée. Le modèle ne reçoit qu'un extrait stratégique du document (jusqu'à 15 chunks, 8 000 caractères, construits pour couvrir les passages les plus discriminants) et la liste des 30 tags candidats avec leur description. Il renvoie une décision unique, motivée. Chaque tag posé conserve la source (chunk précis, numéro de page, position), le score de confiance, et la version du modèle, du prompt, et de la taxonomie au moment du tagging.
Étape 4 — Revue humaine ciblée (pas systématique). Un tag à faible confiance, ou pour lequel plusieurs tags sémantiquement proches remontent ex æquo, entre automatiquement dans une file de revue humaine. C'est précisément ce contrat — décider quand répondre, savoir quand se taire — qui sépare un système utilisable en production d'une démo impressionnante. Voir notre article sur les scores de confiance et la validation.
Les chiffres que nous mesurons réellement
Nous ne publions pas une précision « entre 95 et 99 % » sortie d'un slide marketing. Nous benchmarkons notre pipeline chaque fois que nous changeons un modèle, un prompt, ou une portion de taxonomie. Les résultats qui suivent proviennent de benchmarks exécutés en avril 2026 sur une base client réelle de 1 340 documents immobiliers (baux, actes de vente, diagnostics, ordres de virement, PV d'AG…).
Taux d'extraction — le modèle répond-il ?
| Modèle testé | Documents classés | Taux de succès |
|---|---|---|
| GPT-5 Nano (OpenAI) | 200 / 200 | 100 % |
| GPT-5.4 Nano (OpenAI) | 46 / 50 | 92 % |
| Gemini 2.5 Flash (Google) | 43 / 50 | 86 % |
| Gemini 2.5 Flash-Lite | 30 / 50 | 60 % |
Sur 200 documents supplémentaires, GPT-5 Nano confirme un taux d'extraction de 100 %, réparti sur 9 dossiers métier différents (Interne, dataroom, test bail, Marketing, Chalvron, Description du bien, Saran), avec une couverture complète sans effondrement sur aucun sous-ensemble.
Consistance — même question, même réponse ?
C'est la métrique la plus rarement publiée par les éditeurs : quand on soumet trois fois le même document au même modèle, combien de fois obtient-on le même tag ? Nous avons mesuré cela sur les 29 documents les plus ambigus de la base, à raison de trois runs indépendants chacun — soit 87 appels.
| Consistance GPT-5 Nano sur documents difficiles | Documents | Part |
|---|---|---|
| Même tag sur les 3 runs | 24 / 29 | 82,8 % |
| 2 runs sur 3 identiques | 3 / 29 | 10,3 % |
| 3 tags différents | 2 / 29 | 6,9 % |
Extrapolé au pool complet (où les documents faciles sont majoritaires), la consistance réelle en production dépasse 95 %. Les 17 % de cas non consistants sur les documents difficiles correspondent à des documents intrinsèquement ambigus (un dossier d'urbanisme contenant à la fois un plan de récolement et un permis de construire). Sur 87 appels, une seule hallucination claire a été identifiée (un carnet d'entretien classé en « Reporting RSE »), soit ~ 1 % de bruit absolu, détectable par le score de confiance.
Comparaison inter-modèles — la taxonomie tient-elle quand on change de moteur ?
Sur un échantillon de 50 documents frais classés indépendamment par quatre modèles différents :
| Niveau d'accord | Documents | Part |
|---|---|---|
| 4/4 modèles proposent le même tag | 13 / 50 | 26 % |
| Majorité claire (≥ 3/4) | 28 / 50 | 56 % |
| Pas de majorité (désaccord) | 22 / 50 | 44 % |
Ce résultat est à comparer avec la littérature sur l'inter-annotator agreement humain. Les études publiées dans des domaines voisins (classification d'images médicales, télédétection) montrent des taux de désaccord entre experts de 20 à 30 % sur des taxonomies fines. Autrement dit : même des annotateurs humains formés ne sont pas d'accord entre eux plus de 70 à 80 % du temps sur ce type de tâche. Nos chiffres (56 % de majorité claire, 26 % de consensus total) sont cohérents avec cet ordre de grandeur — ce qui signifie que l'IA a atteint le niveau de convergence des experts humains sur cette tâche, avec pour avantage décisif la traçabilité et la reproductibilité. Les 22 % de documents sans majorité claire ne sont pas des échecs : ce sont les documents que la plateforme envoie, à juste titre, en file de revue manuelle.
Temps — combien de temps gagne-t-on réellement ?
La latence est rarement l'enjeu pour un système de tagging de production : les documents arrivent en continu et sont classés en file d'attente, sans qu'aucun utilisateur n'attende devant son écran (voir l'article sur la file de jobs et les canaux). Ce qui compte, c'est le temps total nécessaire pour classer un corpus complet, et la comparaison franche avec un classement manuel par un opérateur humain.
| Modèle | Médiane | p25 | p75 | p95 | Max |
|---|---|---|---|---|---|
| GPT-5 Nano (recommandé) | 4,3 s | 3,5 s | 5,4 s | 8,1 s | 22,5 s |
| GPT-5.4 Nano | 1,9 s | 1,7 s | 2,3 s | 3,3 s | 5,3 s |
| Gemini 2.5 Flash | 2,3 s | 1,7 s | 6,7 s | 12,0 s | 14,2 s |
| Gemini 2.5 Flash-Lite | 1,9 s | 1,5 s | 3,1 s | 8,6 s | 626 s |
Avec 10 workers en parallèle (configuration de production standard) et la médiane de 4,3 secondes par document, voici le temps de reprise mesuré sur des cas concrets :
| Volume du corpus | Ragindeed (10 workers) | Opérateur humain (1 min/doc) | Facteur d'accélération |
|---|---|---|---|
| 100 documents | ~ 45 secondes | ~ 1 h 40 | × 130 |
| 1 000 documents | ~ 7 minutes | ~ 17 heures (2 jours-homme) | × 140 |
| 10 000 documents | ~ 1 heure | ~ 167 heures (24 jours-homme) | × 160 |
| 100 000 documents | ~ 12 heures (overnight) | ~ 1 670 heures (10 mois-homme) | × 140 |
L'estimation manuelle d'une minute par document est généreuse pour un opérateur formé : dans la pratique, un gestionnaire qui doit ouvrir le PDF, identifier la nature du document, choisir parmi 270 tags candidats puis valider met facilement 1 à 3 minutes par pièce selon sa complexité. Les chiffres ci-dessus sont donc à considérer comme un plancher — l'accélération réelle observée chez nos clients dépasse fréquemment un facteur 200.
Une SGP qui adopte Ragindeed a typiquement plusieurs dizaines de milliers de documents historiques à classer. Cette différence d'ordre de grandeur change la nature même du projet : la classification documentaire cesse d'être un chantier d'organisation pluri-mensuel pour devenir une opération technique d'une nuit, immédiatement auditable.
Coût — qu'est-ce que ça coûte à l'échelle ?
| Volume | Coût IA (GPT-5 Nano) | Coût IA (Gemini Flash) | Économie |
|---|---|---|---|
| 10 000 documents / mois | ~ $69 / mois | ~ $300 / mois | -77 % |
| 50 000 documents / mois | ~ $345 / mois | ~ $1 500 / mois | -77 % |
| 100 000 documents / mois | ~ $690 / mois | ~ $3 000 / mois | -77 % |
À titre de comparaison : classer manuellement 10 000 documents par mois représente environ 1 ETP à temps plein, soit un coût annuel à six chiffres en France. Le coût IA correspondant est inférieur à 1 000 dollars par an. C'est ce différentiel d'ordre de grandeur qui rend le tagging automatique non pas « intéressant » mais structurellement incontournable. Notre architecture multi-provider permet de basculer d'un fournisseur à l'autre sans re-travail fonctionnel quand un modèle plus performant ou plus économique apparaît.
Diversité du tagging
Sur 200 documents classés, 73 tags distincts ont été effectivement utilisés, sans biais majoritaire : les cinq tags les plus fréquents ne représentent que 26,5 % du total. Le fallback « Documents multiples » + « Autre » reste à 9 %, cohérent avec la réalité d'une base de dataroom immobilière où certains documents sont par construction composites ou hors scope.
Comment Ragindeed se positionne par rapport à l'état de l'art
| Approche | Nb étiquettes | Précision / Consistance | Traçabilité | Coût / 10 000 docs |
|---|---|---|---|---|
| GED classique (M-Files, SharePoint, DocuWare) | Tags libres | Tagging manuel à 100 % | Aucune | Temps humain > 10 000 € |
| IDP standard (Rossum, ABBYY, Nanonets) | 5 à 20 | 95–99 % sur extraction de champs ; non documenté sur taxonomies profondes | Variable | $100–500 |
| État de l'art académique (MatchXML, XR-Transformer) | ~ 4 000 | ~ 88 % P@1 | Boîte noire | Pas de service commercial |
| LLM-SelectP (COLING 2025) | 2 778 | 94,3 % | Partielle | ~ $2 000 (GPT-4) |
| Ragindeed | ~ 270 sur 14 facettes × dimension sectorielle | 100 % de couverture, > 95 % de consistance | Complète : source, page, confiance, version | ~ $6 |
Le positionnement est clair : nous ne sommes pas un laboratoire de recherche, et nous n'avons pas à réinventer les architectures XMC de pointe. Nous avons industrialisé l'état de l'art pratique (retrieve-then-LLM, pré-filtrage sémantique, instrumentation complète) et l'avons adapté à une contrainte métier française que personne, à notre connaissance, n'adresse avec ce niveau de rigueur : la classification documentaire sur taxonomie profonde pour SGP immobilières, CGP et professions réglementées.
La discipline, avant l'IA
Nous insistons souvent sur ce point avec nos clients : la précision du tagging automatique dépend d'abord de la qualité de la taxonomie, pas de la puissance du modèle. Le plus gros GPT du marché posé sur une taxonomie bancale produira des tags bancals. Une taxonomie propre, documentée, stable, rend la classification automatique fiable même avec un modèle modeste — et bon marché. Les benchmarks le confirment : nos chiffres avec GPT-5 Nano (modèle économique) dépassent ceux de Gemini 2.5 Flash (modèle premium) grâce à la taxonomie et au pipeline, pas grâce au modèle.
C'est pour cette raison que nous refusons de livrer une plateforme sans passer par un audit de taxonomie avec le client : inventaire des types de documents existants, identification des facettes manquantes, mapping vers la taxonomie Ragindeed, ajout des extensions sectorielles propres au métier. Ce travail, nous l'avons industrialisé — comptez une à deux semaines pour une SGP type, avec livraison d'une taxonomie cible, d'un rapport de couverture, et d'un benchmark initial sur votre propre corpus.
Ce qui change pour vos équipes
| Sans Ragindeed | Avec Ragindeed |
|---|---|
| Un gestionnaire passe ~ 30 % de son temps à classer des pièces reçues | Les pièces sont classées à l'arrivée, le gestionnaire valide uniquement les cas douteux |
| Chaque collaborateur tague à sa manière : doublons, facettes oubliées, libellés approximatifs | Un référentiel unique, partagé, versionné, auditable |
| Un dossier KYC incomplet se découvre au moment du contrôle AMF ou Tracfin | Les pièces manquantes apparaissent dès l'import dans un dashboard de complétude |
| Une requête « tous les baux commerciaux expirant en 2027 » prend une semaine | Elle prend trois clics |
| Aucune traçabilité d'un tag posé (qui, quand, pourquoi) | Chaque tag porte sa source (chunk, page), son score de confiance, la version du modèle |
Ce que nous ne promettons pas
La transparence est une règle non négociable. Voici ce que nous ne prétendons pas :
- 100 % de précision. Aucune plateforme sérieuse ne peut le prétendre sur une taxonomie de plusieurs centaines d'étiquettes. La littérature académique plafonne à 94,3 % sur des corpus comparables (COLING 2025), et l'accord humain entre experts tourne autour de 75 à 80 %.
- Zéro intervention humaine. La supervision humaine est volontairement maintenue sur les cas à faible confiance. C'est une caractéristique, pas une limitation.
- Un modèle unique universellement optimal. Les modèles IA évoluent chaque trimestre. Notre architecture est conçue pour en changer sans re-travail fonctionnel.
Ce que nous promettons, en revanche : une taxonomie documentée, un pipeline mesurable, des tags traçables, un coût transparent, et un hébergement souverain en France (voir notre article dédié à l'architecture et l'hébergement).
Vos documents méritent une classification fiable, traçable et rapide. Faites-en l'expérience.
Demandez une démo personnalisée : ragindeed.com
Le tagging automatique de Ragindeed classe vos documents dans une taxonomie de près de 300 étiquettes métier, avec source, page et score de confiance pour chaque décision. Tester le tagging automatique →