Structurer des données non structurées avec l'IA

Le problème des données non structurées n'est pas de les faire entrer dans un fichier Excel. Le vrai problème, c'est d'obtenir les mêmes catégories, le même niveau de détail et les mêmes règles de décision sur des milliers de textes écrits par des personnes différentes.

Un CV parle de « pilotage de projet ». Une offre demande de la « coordination de programme ». Une fiche métier utilise « conduite de projets complexes ». Trois formulations, peut-être une seule compétence. Ou peut-être pas. Une extraction par LLM peut repérer les termes, mais elle ne suffit pas à construire un référentiel cohérent.

Sur le projet ModelRH, il a fallu enchaîner extraction PDF, sorties structurées, matching par embeddings, harmonisation et contrôle humain pour transformer des sources RH hétérogènes en référentiels exploitables. Voici l'architecture, ses limites, et ce qu'on réutiliserait sur d'autres projets documentaires.

Une donnée « non structurée » contient déjà une structure. Elle n'est juste pas explicite.

Un CV, une offre d'emploi, un rapport d'audit ou un email ne sont pas des blocs de texte aléatoires. On y trouve des personnes, des dates, des compétences, des organisations, des décisions et des relations entre ces éléments. Le lecteur humain les reconnaît sans y penser. Un système d'information, lui, a besoin de colonnes, de types et d'identifiants stables.

La structuration consiste donc à passer d'une information exprimée librement à un objet contrôlé. Par exemple :

L'extraction n'est que la première moitié du travail. Si le système crée à la fois « gestion de projet », « gestion des projets » et « pilotage projet », les champs sont remplis, mais la donnée reste inutilisable pour comparer, compter ou analyser.

Structurer, c'est extraire puis harmoniser.

Le pipeline en six étapes : du document brut au référentiel exploitable

1. Lire correctement la source avant d'appeler un LLM

Tout commence par une bifurcation simple : document natif ou document scanné. Sur un PDF natif, PyMuPDF récupère directement la couche texte. Sur un scan, il faut une reconnaissance optique de caractères. Dans le cas ModelRH, Mistral OCR intervient en secours lorsque l'extraction directe ne suffit pas.

Faire passer tous les documents par l'OCR coûte plus cher et peut introduire des erreurs qui n'existaient pas dans le texte natif. Faire l'inverse laisse des pages blanches dès qu'un PDF est une image. Le routeur doit être déterministe : tentative d'extraction native, contrôle du résultat, puis OCR seulement si nécessaire.

Le sujet est détaillé dans notre guide sur l'extraction de données PDF par IA.

2. Retirer ou isoler les données sensibles

Un pipeline RH manipule des noms, coordonnées, parfois des informations personnelles qui n'ont aucune utilité pour l'analyse des compétences. L'anonymisation doit intervenir avant l'envoi au modèle quand ces champs ne sont pas nécessaires.

Ce n'est pas un nettoyage décoratif. C'est une règle d'architecture : minimiser les données transmises, conserver la correspondance éventuelle dans un espace séparé et tracer les traitements. Dans ModelRH, l'anonymisation des informations personnelles des CV est intégrée en amont de la chaîne.

3. Contraindre l'extraction avec un schéma

Demander à un LLM « extrais les compétences de ce CV » donne une réponse lisible, pas forcément une donnée exploitable. Les intitulés de champs changent, certains niveaux disparaissent, une liste devient parfois un paragraphe.

Les structured outputs règlent une partie du problème. Un schéma Pydantic décrit les champs attendus, leurs types, les valeurs autorisées et les objets imbriqués. Gemini reçoit ce schéma comme contrainte de réponse. La sortie est ensuite validée côté application ; si elle ne passe pas, elle n'entre pas dans le référentiel.

4. Chercher les catégories candidates par similarité sémantique

Une fois les compétences extraites, il faut les rattacher à un référentiel commun. Comparer chaque libellé à toutes les catégories avec un LLM serait lent, coûteux et difficile à stabiliser.

Le pré-matching sémantique réduit le problème. Sentence-Transformers et le modèle all-MiniLM-L6-v2 transforment le libellé extrait et les libellés du référentiel en vecteurs. La similarité cosinus mesure leur proximité ; un top-K conserve les candidats les plus plausibles.

Sur ModelRH, cette étape réduit le catalogue présenté au LLM d'environ 200 entrées à un ensemble de 50 à 100 candidates. Le modèle ne cherche plus à l'aveugle dans tout le référentiel. Il arbitre dans un sous-ensemble sémantiquement proche, avec le contexte métier.

Pour comprendre cette brique en détail, notre guide sur les embeddings et la recherche sémantique explique la représentation vectorielle, la similarité cosinus et les limites du tout-sémantique.

5. Harmoniser : garder, fusionner ou remplacer

Le candidat le plus proche n'est pas automatiquement le bon. Deux compétences peuvent être proches dans l'espace vectoriel tout en correspondant à deux niveaux de responsabilité différents. À l'inverse, une formulation rare peut être le synonyme exact d'une catégorie existante.

L'harmonisation doit pouvoir prendre trois décisions explicites :

• Garder une compétence distincte lorsqu'elle apporte une information absente du référentiel.
• Fusionner plusieurs formulations qui représentent la même capacité métier.
• Remplacer un libellé par la catégorie canonique du référentiel.

Cette décision peut combiner règles, score sémantique et LLM. Elle doit surtout rester traçable : libellé source, candidats proposés, décision finale et version du référentiel.

6. Envoyer uniquement les cas incertains à un expert

Le contrôle humain n'est pas un aveu d'échec. C'est ce qui permet d'automatiser le volume sans laisser les ambiguïtés contaminer la base.

Dans la chaîne ModelRH, un seuil de confiance configurable identifie les matchings à revoir. Une macro-compétence « idéale » peut être proposée, puis l'analyste choisit de garder, fusionner ou remplacer. Les cas évidents poursuivent leur chemin ; les cas proches ou mal documentés arrivent dans une file de revue.

Voilà le bon objectif : ne pas supprimer l'expertise humaine, mais concentrer son temps là où le système hésite réellement.

Matching sémantique, regroupement et clustering : trois mots qu'on mélange trop vite

« Regroupement sémantique » est une expression utile côté métier, mais elle peut recouvrir des techniques différentes. Soyons précis.

Le pipeline ModelRH décrit ici repose sur du matching par embeddings, du top-K et un arbitrage LLM avec contrôle humain. Il ne repose pas sur un clustering K-means ou HDBSCAN. Employer le mot « clustering » donnerait une impression de sophistication technique, mais décrirait mal le système réellement construit.

Le clustering peut être utile lorsqu'aucun référentiel n'existe et qu'on veut explorer le corpus. Mais il produit des groupes statistiques, pas automatiquement des catégories métier stables. Il reste ensuite à nommer les clusters, traiter les éléments frontières et vérifier que le découpage correspond aux usages.

Quand un référentiel existe déjà, comme le ROME, un catalogue produit, une nomenclature qualité ou une taxonomie documentaire, le matching est généralement le point de départ le plus direct.

Traiter un lot une fois est facile. Pouvoir reprendre au milieu l'est beaucoup moins.

Un notebook peut structurer cent documents pendant une démonstration. Une chaîne qui traite des volumes importants doit gérer les quotas API, les réponses invalides, les coupures réseau, les doublons, les changements de version et la reprise après erreur.

Sur ModelRH, l'orchestration s'appuie sur Prefect, avec 14 flows et une concurrence configurable. Les résultats intermédiaires, statuts et journaux sont suivis pendant l'exécution. Pour la génération prospective, le pipeline est découpé en cinq phases et orchestre des dizaines de milliers d'appels LLM avec parallélisation, retries et checkpoints sur S3.

Trois choix deviennent indispensables à cette échelle :

1. Rendre chaque étape rejouable. Une erreur d'export ne doit pas relancer l'OCR et tous les appels LLM.
2. Conserver les versions. Le modèle, le prompt, le schéma et le référentiel utilisés doivent être associés au résultat.
3. Séparer données intermédiaires et livrables. Les données validées peuvent alimenter DuckDB et Parquet, puis être exportées en Excel ou JSON selon l'utilisateur final.

Le modèle n'est qu'une brique. À grande échelle, le travail difficile se déplace vers l'orchestration, les contrôles et la capacité à expliquer d'où vient chaque ligne.

Ce que le cas ModelRH montre vraiment

Le besoin de départ était RH : transformer des CV, offres d'emploi, fiches métier et données externes en référentiels de compétences structurés et prospectifs. Mais l'architecture dépasse largement ce secteur.

La chaîne mise en place couvre :

• l'extraction de texte depuis des PDF natifs, avec OCR en fallback ;
• l'anonymisation des données personnelles en amont ;
• les sorties structurées Gemini contraintes par des schémas Pydantic ;
• le pré-matching sémantique par Sentence-Transformers et similarité cosinus ;
• l'harmonisation vers un référentiel commun, notamment le ROME issu de l'open data de France Travail ;
• la revue humaine des correspondances peu confiantes ;
• le stockage et les traitements en DuckDB/Parquet, puis les exports Excel, JSON ou Parquet ;
• l'orchestration et la reprise sur erreur avec Prefect, asyncio et S3 Scaleway.

Le résultat n'est donc pas « trois agents IA qui travaillent seuls ». C'est un système hybride : des parseurs pour lire, des schémas pour contraindre, des embeddings pour présélectionner, un LLM pour interpréter, des règles pour contrôler et des experts pour trancher les cas ambigus.

Cette combinaison est réutilisable pour des catalogues fournisseurs, des nomenclatures qualité, des dossiers techniques, des contrats ou des bases de connaissances. Dès qu'une organisation possède beaucoup de textes hétérogènes à comparer à un référentiel, le même geste revient.

Le cas client ModelRH présente le contexte RH et la mise en production. Notre offre d'automatisation de processus métier couvre les projets où cette chaîne doit s'intégrer à un SI, un outil interne ou un flux documentaire existant.

Ce qui ne marche pas dans la durée

Envoyer tout le référentiel dans le prompt

Ça fonctionne sur une petite nomenclature. Puis le contexte grossit, le coût augmente et les décisions deviennent moins stables. La présélection par embeddings sert précisément à réduire le bruit avant l'arbitrage.

Faire confiance au premier voisin vectoriel

Le score le plus élevé indique une proximité, pas une identité métier. Les intitulés génériques ou très courts sont particulièrement trompeurs. Il faut conserver plusieurs candidats, ajouter du contexte et prévoir une issue « aucune correspondance ».

Demander au LLM de créer la taxonomie en continu

Sans gouvernance, chaque nouveau lot produit de nouvelles variantes. Le référentiel gonfle, les catégories se chevauchent et les analyses deviennent impossibles à comparer dans le temps. La création d'une nouvelle catégorie doit être une décision explicite et versionnée.

Relire un échantillon aléatoire et ignorer les cas difficiles

Un échantillon moyen rassure facilement. Les erreurs se cachent dans les libellés courts, les formulations rares et les catégories voisines. La revue doit cibler les scores faibles, les marges réduites entre les premiers candidats et les incohérences détectées par les règles.

Les métriques à suivre avant de parler d'automatisation

Une démo visuellement convaincante ne dit rien sur la qualité d'un lot complet. Il faut mesurer séparément chaque étape.

• Couverture d'extraction : part des champs attendus effectivement extraits.
• Validité du schéma : part des objets qui passent les validations de type et de valeurs.
• Recall du top-K : part des cas où la bonne catégorie apparaît parmi les candidats présélectionnés.
• Précision du matching final : part des correspondances validées par un expert métier.
• Taux de revue humaine : part du volume envoyé à l'analyste, par motif d'incertitude.
• Stabilité : part des décisions qui restent identiques après un changement de modèle, de prompt ou de référentiel.
• Coût par document et par donnée validée : appels LLM, OCR, calcul et temps humain inclus.

Le taux d'automatisation seul est trompeur. Un système peut automatiser 98 % du volume et injecter beaucoup d'erreurs. Le bon indicateur combine qualité finale, charge de revue et coût total.

Avant de lancer ce type de chantier, vérifiez également si vos sources sont réellement exploitables avec notre guide sur les données prêtes pour l'IA. Et si le cas requiert une architecture NLP plus spécifique, la page expert IA générative, LLM et NLP détaille les briques d'intégration.

FAQ

Pour aller plus loin

• ModelRH : structuration et prospective des compétences. Ce cas client est à l'origine de l'architecture présentée dans l'article.
• Extraction PDF par IA. Le guide aide à choisir entre texte natif, OCR et LLM.
• Embeddings et recherche sémantique. Il explique le matching vectoriel et la similarité cosinus.
• Données prêtes pour l'IA. Cet article permet d'évaluer la qualité et l'accessibilité des sources.
• Automatisations métier. Cette offre couvre l'intégration de l'extraction, de la validation et des exports dans les processus.
• Expert IA générative, LLM et NLP. Nous concevons une architecture adaptée au vocabulaire métier.