Résumez cet article avec :
Qu’est-ce que la reconnaissance d’entités nommées (NER) ?
La reconnaissance d’entités nommées, ou Named Entity Recognition (NER), identifie les segments d’un texte qui désignent des entités du monde réel, puis attribue chaque segment à une catégorie.
Les modèles NER standards extraient généralement les catégories suivantes :
- Personne : noms de personnes ;
- Organisation : entreprises, institutions et organismes publics ;
- Lieu : pays, villes, adresses et zones géographiques ;
- Date : dates calendaires et périodes ;
- Montant monétaire : sommes d’argent et devises ;
- Pourcentage : ratios exprimés en pourcentage.
Par exemple :
« Microsoft a investi 15 millions d’euros à Paris en mars 2026. »
- Microsoft : ORGANISATION
- 15 millions d’euros : MONTANT MONÉTAIRE
- Paris : LIEU
- Mars 2026 : DATE
La reconnaissance d’entités nommées standard fonctionne particulièrement bien lorsque les champs recherchés correspondent à des catégories courantes et que les documents utilisent un langage familier. Elle est souvent suffisante pour l’analyse d’actualités, l’indexation de documents, le routage de tickets d’assistance, les contrôles de conformité et l’extraction d’informations de base.

La NER personnalisée ou spécialisée par domaine permet de traiter des catégories qu’un modèle généraliste ne connaît pas. Une équipe juridique peut, par exemple, extraire les parties contractantes, la date de résiliation et le droit applicable. Un produit de santé peut devoir identifier un médicament, une posologie et un symptôme. Une plateforme de recrutement peut chercher à reconnaître un intitulé de poste, une compétence technique ou un diplôme.
La NER personnalisée peut consister à entraîner un modèle à partir d’exemples annotés, à ajouter des dictionnaires et des règles, ou à définir les catégories au moment de l’inférence avec un modèle zero-shot ou un LLM.
La méthode adaptée dépend de la stabilité des catégories, des données d’entraînement disponibles, des contraintes de confidentialité, du volume attendu et de votre tolérance aux résultats incohérents.
Le choix principal se fait entre une API NER managée, un modèle open source auto-hébergé et une solution d’extraction basée sur un LLM.
Comment évaluer une API ou un modèle NER en 2026
F1, precision, and recall
Score F1, précision et rappel
Check the actual taxonomy, not the phrase “named entity recognition.” One API may identify people, organizations, locations, dates, money, and percentages. Another may only cover people, organizations, locations, and miscellaneous entities.
A fixed taxonomy creates a hard ceiling. It cannot extract fields such as contract clause, product SKU, adverse event, job skill, or insurance policy number unless the provider offers custom NER.
Question à poser au fournisseur : « Pouvez-vous fournir la précision, le rappel et le score F1 par type d’entité, sur des données similaires aux nôtres, plutôt qu’un seul score global ? »
Entity type coverage
Vérifiez la taxonomie réellement prise en charge, et pas uniquement la présence de l’expression « reconnaissance d’entités nommées ».
Une API peut identifier les personnes, les organisations, les lieux, les dates, les montants monétaires et les pourcentages. Une autre peut se limiter aux personnes, aux organisations, aux lieux et à une catégorie générique d’entités diverses.
Une taxonomie fixe impose une limite stricte aux informations que le modèle peut extraire. Elle ne pourra pas identifier des éléments comme une clause contractuelle, une référence produit, un événement indésirable, une compétence professionnelle ou un numéro de police d’assurance, sauf si le fournisseur propose une fonctionnalité de NER personnalisée.
Question à poser au fournisseur : « Quelles catégories d’entités sont prises en charge nativement, et que se passe-t-il lorsque nous avons besoin d’une catégorie absente de cette liste ? »
Prise en charge des langues
Une longue liste de langues disponibles ne garantit pas une qualité équivalente dans chacune d’elles. Les fournisseurs testent souvent davantage leurs modèles en anglais, tandis que les langues disposant de moins de ressources bénéficient de moins de données d’entraînement et d’évaluations moins approfondies.
Les performances peuvent également diminuer sur les documents multilingues, les variantes orthographiques régionales, les noms translittérés et les formats d’adresse locaux.
Testez chaque langue sur vos propres documents et mesurez les résultats séparément. Ne regroupez pas les performances en anglais et dans les autres langues dans un seul score moyen.
Question à poser au fournisseur : « Quels sont vos résultats de précision et de rappel pour chaque langue que nous prévoyons de traiter, sur quel jeu de données et pour quels types d’entités ? »
Latence et débit
Les cas d’usage en temps réel nécessitent des temps de réponse prévisibles, et pas seulement une moyenne faible. Examinez la latence aux percentiles p95 et p99, les limites de requêtes, la taille maximale des documents, le niveau de concurrence accepté et les éventuels démarrages à froid.
Pour le traitement de grandes archives, la vitesse de traitement par lots et la gestion des nouvelles tentatives après échec sont plus importantes que la latence d’une requête individuelle. Vérifiez également si le fournisseur facture ou applique ses limites en fonction du nombre de documents, de caractères, de tokens ou de requêtes.
Question à poser au fournisseur : « Quel débit et quelle latence p95 pouvez-vous garantir pour la taille de documents et le niveau de concurrence que nous prévoyons ? »
Entraînement d’entités personnalisées
La NER personnalisée peut nécessiter des documents annotés, un pipeline d’entraînement, un hébergement du modèle et de nouveaux entraînements réguliers lorsque votre taxonomie évolue.
Certains fournisseurs gèrent ces étapes directement dans leur plateforme. D’autres vous demandent de préparer les fichiers d’entraînement et de gérer vous-même l’évaluation du modèle.
Le principal coût n’est souvent pas la puissance de calcul, mais l’annotation, la validation et le maintien de règles d’étiquetage cohérentes.
Question à poser au fournisseur : « Combien d’exemples annotés exigez-vous par type d’entité, et combien coûtent l’annotation, l’entraînement, le déploiement et les nouveaux entraînements ? »
Résidence des données et RGPD
Vérifiez où l’API reçoit, traite, journalise et stocke les textes envoyés.
Un endpoint européen ne garantit pas toujours que chaque requête reste intégralement en Europe. Les données peuvent transiter par une autre région pour l’inférence, la supervision, la détection des abus ou l’assistance technique.
Contrôlez les durées de conservation par défaut, l’utilisation éventuelle des données pour l’entraînement, les sous-traitants, les délais de suppression et la possibilité de désactiver les journaux.
Question à poser au fournisseur : « Pouvez-vous confirmer contractuellement que nos textes restent dans la région sélectionnée, y compris pendant l’inférence et dans les journaux, les sauvegardes et les systèmes de vos sous-traitants ? »
Les 9 meilleures API NER en 2026
Amazon Comprehend
Amazon Comprehend est un choix pratique pour intégrer une reconnaissance d’entités nommées classique dans des applications basées sur AWS. Son modèle préentraîné couvre les entités standards, tandis que la reconnaissance d’entités personnalisées permet d’entraîner des catégories propres à votre domaine, comme des références produit, des numéros de police ou des catégories internes de documents.
Son service NER standard prend en charge 12 langues, soit légèrement plus que Google Cloud Natural Language, mais nettement moins que Microsoft Azure AI Language. Cette différence est importante pour les produits multilingues, même si les trois services sont généralement présentés comme multilingues.
Amazon coûte 1,00 $ par million de caractères sur Eden AI. Le tarif reste fixe et ne diminue pas avec les volumes, ce qui facilite les prévisions budgétaires, mais le rend moins compétitif que les services à tarification dégressive lorsque vous traitez plusieurs milliards de caractères.
Avantages
- Tarification claire basée sur le nombre de caractères
- Reconnaissance d’entités standard et personnalisées
- Traitement en temps réel et par lots
Inconvénients
- NER standard limité à 12 langues
- Les modèles personnalisés nécessitent des données annotées et un entraînement
Microsoft Azure AI Language
Microsoft Azure AI Language se distingue par sa couverture linguistique. Son service NER disponible de manière générale prend en charge 79 langues, et environ 94 langues sont proposées en préversion. Cela représente plus de six fois la couverture d’Amazon Comprehend, son concurrent managé le plus proche dans ce comparatif.
Azure propose également une fonctionnalité de NER personnalisée pour les catégories absentes de sa taxonomie standard. Elle convient aux produits qui doivent extraire des entités comme un type de contrat, une compétence technique, un dispositif médical ou un service interne.
La NER personnalisée repose sur un processus d’entraînement et non sur de simples instructions intégrées à une requête. Vous devez donc disposer d’exemples annotés, de données d’évaluation et d’un modèle déployé.
Microsoft coûte 1,00 $ par million de caractères sur Eden AI. Comme Amazon et Tenstorrent, il s’agit d’un tarif d’entrée fixe, sans engagement de volume ni changement de tranche tarifaire.
Avantages
- 79 langues disponibles pour la NER
- NER personnalisée pour les catégories propres à un domaine
- Facturation prévisible basée sur le nombre de caractères
Inconvénients
- La qualité peut varier selon les langues prises en charge
- La NER personnalisée nécessite une annotation des données et un entraînement du modèle
- Le tarif fixe ne diminue pas à mesure que le volume augmente
OpenAI GPT-4o
GPT-4o réalise la reconnaissance d’entités nommées sous la forme d’une extraction structurée guidée par des instructions, plutôt que comme un service NER reposant sur une taxonomie fixe. Vous pouvez définir des catégories telles que governing_law, candidate_skill ou adverse_event directement dans la requête, puis retourner les résultats au format JSON structuré.
Cette flexibilité est utile lorsque le schéma change fréquemment ou lorsque l’identification d’une entité dépend fortement du contexte. Elle évite également d’entraîner un modèle personnalisé distinct pour chaque nouvelle catégorie.
Cependant, OpenAI n’a pas publié de benchmark spécifique à la NER couvrant plusieurs langues. Les capacités multilingues générales de GPT-4o ne doivent donc pas être considérées comme une preuve d’une précision équivalente pour l’extraction d’entités dans toutes les langues.
GPT-4o coûte 10,00 $ par million de tokens sur Eden AI. Avec environ 3,8 caractères anglais par token, cela représente approximativement 2,63 $ par million de caractères. Pour le chinois et le japonais, un caractère peut correspondre à près d’un token, ce qui peut faire monter le coût normalisé jusqu’à 10,00 $ par million de caractères.
Avantages
- Prise en charge de schémas d’entités arbitraires à l’aide d’instructions
- Capacité à appliquer des règles d’extraction contextuelles
- Résultats JSON conformes à un schéma défini
Inconvénients
- Aucun benchmark multilingue spécifique à la NER n’a été publié
- Les coûts varient fortement selon la langue et le fonctionnement du tokenizer
Tenstorrent
Tenstorrent est disponible sur Eden AI au tarif de 1,00 $ par million de caractères, soit le même prix d’entrée vérifié qu’Amazon et Microsoft.
Le principal problème n’est pas son prix, mais le manque de transparence concernant le produit. Tenstorrent est avant tout connu pour ses processeurs dédiés à l’IA et ses infrastructures d’inférence.
Avantages
- Tarification fixe basée sur le nombre de caractères
- Accessible via la même intégration Eden AI
- Aucun déploiement auto-hébergé nécessaire
Google Cloud Natural Language
Google Cloud Natural Language prend en charge l’analyse d’entités dans 11 langues : allemand, anglais, chinois simplifié, chinois traditionnel, coréen, espagnol, français, italien, japonais, portugais et russe.
Le service retourne les types d’entités, leurs différentes mentions, leur importance dans le texte ainsi que des liens vers des bases de connaissances.
Google inclut 5 millions de caractères gratuits par mois. La tarification payante commence à environ 1,00 $ par million de caractères, puis diminue à 0,50 $ au-delà d’un milliard de caractères et à 0,25 $ au-delà de 5 milliards de caractères.
Avantages
- Signaux utiles pour la liaison d’entités et l’évaluation de leur importance
- Quota mensuel gratuit généreux
- Tarification compétitive pour les volumes très élevés
Inconvénients
- Seulement 11 langues prises en charge pour la NER
- Aucune NER personnalisée dans l’API standard d’analyse des entités
IBM Watson Natural Language Understanding
IBM Watson NLU combine l’extraction d’entités avec d’autres fonctionnalités, notamment l’analyse des sentiments, des relations, des concepts et des catégories.
Son offre gratuite comprend 30 000 unités par mois, tandis que le tarif d’entrée de l’offre payante est de 0,003 $ par unité.
En utilisant une unité de 10 000 caractères, une seule fonctionnalité d’enrichissement revient à environ 0,30 $ par million de caractères au tarif d’entrée, puis approximativement entre 0,10 $ et 0,02 $ à grande échelle.
Chaque fonctionnalité d’enrichissement supplémentaire consomme une nouvelle unité. Une analyse combinant les entités et les sentiments coûterait donc environ deux fois plus cher.
IBM semble prendre en charge six langues pour ses entités intégrées, avec davantage de langues accessibles par l’intermédiaire de modèles personnalisés.
Avantages
- Faible coût normalisé pour les charges de travail utilisant une seule fonctionnalité
- Association de la NER à d’autres fonctionnalités d’analyse de texte
- Prise en charge de modèles personnalisés
Inconvénients
- Les coûts augmentent lorsque plusieurs enrichissements sont demandés
- La facturation par unité est plus difficile à comparer
- La couverture linguistique officielle doit être vérifiée manuellement
Lettria
Lettria ne se limite plus à une API NER classique. La plateforme se positionne désormais sur l’intelligence documentaire, les graphes de connaissances et le GraphRAG, avec l’extraction d’entités et de relations intégrée dans une solution plus large.
Elle peut convenir aux projets qui nécessitent une ontologie métier et la création d’un graphe structuré à partir de documents. Elle est cependant moins comparable à une API simple retournant uniquement des personnes, des organisations et des lieux.
Lettria ne publie pas de tarification en libre-service. Il est donc nécessaire de contacter l’entreprise pour obtenir un prix.
Avantages
- Ontologies personnalisées et extraction de relations
- Conçue pour les workflows reposant sur des graphes de connaissances
Inconvénients
- Aucun tarif public
- Ne remplace pas directement une API NER légère
- Périmètre d’implémentation plus large qu’une simple extraction d’entités
NLP Cloud
NLP Cloud propose une API NER hébergée reposant sur plusieurs familles de modèles. La couverture linguistique et le comportement du service dépendent donc du modèle sélectionné.
La plateforme propose également des déploiements sur CPU ou GPU, ainsi que des environnements dédiés et privés.
La tarification à l’usage est d’environ 0,003 $ par requête CPU et 0,005 $ par requête GPU, avec 15 $ de crédits gratuits. Les offres prépayées vont de 29 à 229 $ pour les CPU et de 99 à 2 499 $ pour les GPU.
Avantages
- Choix entre plusieurs modèles open source et génératifs hébergés
- Options de déploiement privé
- Faible coût d’entrée pour les tests
Inconvénients
- Le prix par requête ne peut pas être normalisé sans connaître la taille des documents
- La qualité et la couverture linguistique varient selon le modèle
- La sélection du modèle nécessite un travail d’évaluation supplémentaire
TextRazor
TextRazor combine la reconnaissance d’entités nommées avec la liaison et la désambiguïsation d’entités, l’extraction de relations et de sujets, ainsi que des dictionnaires personnalisés.
La plateforme prend en charge la NER dans 19 langues, et non 142. Le nombre le plus élevé correspond à la détection de la langue, et non à l’extraction d’entités.
L’offre gratuite comprend 500 requêtes par jour. Les offres payantes sont proposées à 200, 600 et 1 200 $ par mois.
Comme la facturation repose sur le nombre de requêtes, le coût réel dépend de la quantité de texte envoyée dans chaque requête.
Avantages
- 19 langues prises en charge pour la NER
- Liaison d’entités détaillée et données issues de bases de connaissances
- Offre gratuite adaptée aux prototypes
Inconvénients
- Tarification par requête difficile à comparer
- Les dictionnaires personnalisés ne remplacent pas un modèle NER contextuel entraîné
- La couverture de détection des langues peut être confondue avec la couverture NER
Meilleurs modèles et bibliothèques NER open source en 2026
spaCy
spaCy reste la solution de référence en production lorsque vous recherchez une reconnaissance d’entités nommées rapide et prévisible, sans devoir construire une infrastructure complète de machine learning.
Ses pipelines de petite et moyenne taille fonctionnent efficacement sur CPU. Ils conviennent donc aux API synchrones, aux files de traitement de documents et aux applications disposant d’une infrastructure limitée. Les pipelines basés sur des transformers offrent généralement une meilleure précision, mais nécessitent souvent un GPU pour maintenir un débit acceptable.
Les pipelines préentraînés ne nécessitent aucune donnée d’entraînement annotée, mais leur taxonomie d’entités est fixe. Par exemple, les pipelines anglais reconnaissent généralement les personnes, les organisations, les lieux, les dates, les montants monétaires, les pourcentages, les produits, les événements et d’autres catégories issues d’OntoNotes.
Ils ne peuvent pas identifier immédiatement une catégorie métier comme contract_clause ou drug_dosage. Pour cela, vous devez utiliser des exemples annotés, des règles ou un pipeline personnalisé.
La bibliothèque spaCy est distribuée sous licence MIT, même si les packages de modèles individuels peuvent utiliser des licences différentes. spaCy propose des pipelines entraînés pour environ 25 langues, mais tous n’intègrent pas nécessairement une fonctionnalité NER.
Avantages
- Inférence rapide sur CPU
- Outils matures pour l’entraînement, le packaging et le déploiement
- Possibilité de combiner la NER statistique avec des dictionnaires et des règles
Inconvénients
- Les modèles préentraînés utilisent des taxonomies d’entités fixes
- La couverture linguistique et les types d’entités varient selon le pipeline
- Les pipelines transformers sont plus lourds que les modèles spaCy standards
GLiNER
GLiNER est l’un des meilleurs choix open source lorsque vos catégories d’entités changent fréquemment.
Vous fournissez au moment de l’inférence une liste comme ["medical device", "adverse event", "manufacturer"], puis le modèle extrait les segments correspondants sans nécessiter d’entraînement spécifique à la tâche.
Cette approche lui apporte une partie de la flexibilité des instructions données à un LLM, tout en conservant la rapidité et les possibilités de déploiement local d’un modèle encodeur.
Les évaluations publiées sur la détection des données personnelles placent le modèle de base autour de 81 % de score F1, et la version plus large à près de 83 %. Il s’agit toutefois de résultats obtenus sur des benchmarks liés aux données personnelles, et non de scores NER généraux.
Ces résultats ne permettent donc pas de déterminer les performances des mêmes modèles sur des clauses juridiques, des produits, des entités scientifiques ou une autre taxonomie personnalisée.
GLiNER utilise la licence Apache 2.0. Il peut fonctionner sur CPU, notamment avec ONNX ou des déploiements quantifiés. Un GPU reste toutefois préférable pour les modèles plus volumineux, les documents longs ou les volumes de requêtes élevés.
L’utilisation en zero-shot ne nécessite aucune donnée annotée. Un fine-tuning sur des exemples labellisés reste possible lorsque les performances zero-shot ne sont pas suffisantes.
Avantages
- Catégories d’entités arbitraires fournies au moment de l’inférence
- Aucune donnée annotée nécessaire pour l’extraction zero-shot
- Plus petit et plus rapide qu’un LLM génératif
Inconvénients
- Le choix des mots utilisés pour définir les catégories peut fortement modifier les résultats
- Les scores obtenus sur des benchmarks PII ne se transfèrent pas automatiquement à d’autres domaines
- Un modèle fine-tuné sur une taxonomie fixe peut rester plus performant pour une tâche stable et bien annotée
Flair
Flair convient particulièrement aux projets dans lesquels la précision est plus importante que la vitesse brute de traitement.
Ses modèles de séquence combinent des embeddings contextuels, le contexte au niveau du document et des modèles transformers. La bibliothèque permet également de combiner différents types d’embeddings ou d’entraîner un modèle de classification adapté à votre propre taxonomie d’entités.
Le modèle ner-english-large affiche un score F1 de 94,36 sur la version corrigée de CoNLL-03. Ce benchmark ne couvre toutefois que quatre catégories : personnes, lieux, organisations et entités diverses.
Il apporte donc peu d’informations sur les performances du modèle pour les dates, les montants monétaires, les pourcentages, les données personnelles ou les entités propres à un secteur.
Le modèle repose sur des embeddings XLM-R au niveau du document. Il est donc plus lourd qu’un pipeline spaCy conçu pour fonctionner efficacement sur CPU.
Flair utilise la licence MIT. Les modèles préentraînés ne nécessitent aucune donnée annotée. En revanche, l’entraînement d’une nouvelle taxonomie demande des exemples labellisés.
Les petits modèles peuvent fonctionner sur CPU, mais les versions contextuelles et transformers les plus performantes sont mieux adaptées à un GPU, en particulier pour le traitement par lots. Flair repose lui-même sur PyTorch.
Avantages
- Excellente précision sur les taxonomies prises en charge
- Large catalogue de modèles linguistiques et spécialisés par domaine
- Entraînement flexible de modèles de séquence personnalisés
Inconvénients
- Les grands modèles offrent une inférence plus lente
- L’utilisation d’un GPU est recommandée pour les modèles les plus performants
- Les benchmarks couvrent souvent des ensembles d’entités limités
Stanza
Stanza constitue l’un des meilleurs choix généralistes lorsque la couverture linguistique est prioritaire par rapport à la vitesse d’un pipeline anglais.
Développé par le Stanford NLP Group, Stanza rassemble dans un même pipeline neuronal la tokenisation, la lemmatisation, l’étiquetage morphosyntaxique, l’analyse des dépendances et la reconnaissance d’entités nommées.
Des modèles NER sont proposés pour plus de 30 langues, tandis que l’ensemble de la bibliothèque Stanza en couvre plus de 60. Cette solution est donc utile lorsque vous souhaitez appliquer des étapes de traitement similaires dans plusieurs langues, sans utiliser une bibliothèque différente pour chaque marché.
Il ne faut toutefois pas supposer que la qualité de la NER est identique dans toutes les langues. Les corpus d’entraînement, les conventions d’annotation, les catégories d’entités et la quantité de données disponibles varient selon les langues.
Stanza utilise la licence Apache 2.0. Ses packages NER préentraînés ne nécessitent pas de données annotées.
L’entraînement d’un nouveau modèle linguistique ou d’une nouvelle taxonomie exige en revanche des exemples annotés. L’inférence sur CPU est adaptée aux volumes modérés, mais le pipeline neuronal est plus lourd que les petits packages statistiques de spaCy.
Un GPU est préférable pour l’entraînement ou le traitement de grandes collections de documents.
Avantages
- Large couverture multilingue pour la NER
- Pipeline linguistique complet au sein d’une seule bibliothèque
- Modèles issus des travaux de recherche de Stanford
Inconvénients
- Plus lent que les pipelines légers conçus en priorité pour le CPU
- Les taxonomies d’entités varient selon les langues
- L’entraînement personnalisé nécessite de maîtriser le format de données et le pipeline de Stanza
ModernBERT et modèles transformers fine-tunés
Un modèle encodeur fine-tuné est généralement la meilleure approche lorsque vous disposez d’une taxonomie stable, de données annotées et que vous recherchez la meilleure précision possible sur vos propres documents.
ModernBERT constitue un point de départ récent pour les traitements en anglais. Il accepte des entrées allant jusqu’à 8 192 tokens et est proposé dans des versions de 149 millions et 395 millions de paramètres.
Le modèle de base n’est pas directement un système de reconnaissance d’entités nommées. Vous devez lui ajouter une tête de classification de tokens, puis le fine-tuner sur des segments annotés.
Le code et les poids de ModernBERT utilisent la licence Apache 2.0. L’entraînement nécessite généralement un GPU.
Après l’entraînement, la version de base peut fonctionner sur un CPU suffisamment puissant, mais une inférence sur GPU reste préférable pour les documents longs ou les débits élevés. Le modèle le plus volumineux nécessite davantage de mémoire et présente une latence plus importante.
D’autres encodeurs transformers, notamment BERT, RoBERTa, DeBERTa et leurs variantes spécialisées par langue, suivent le même principe. Leur licence dépend du checkpoint choisi.
Avantages
- Meilleure voie vers une précision élevée sur des données métier
- Contrôle total de la taxonomie et du déploiement
- Résultats stables et reproductibles après l’entraînement
Inconvénients
- Nécessite des données d’entraînement annotées au niveau des tokens
- L’entraînement et l’analyse des erreurs exigent des compétences en machine learning
- L’ajout d’une nouvelle catégorie nécessite généralement une nouvelle annotation et un nouvel entraînement
Modèles spécialisés pour l’extraction biomédicale et des données personnelles
Les modèles NER généralistes perdent souvent en précision lorsqu’ils sont appliqués à un domaine très différent de leurs données d’entraînement.
Les textes biomédicaux contiennent des symboles de gènes, des protéines, des substances chimiques, des maladies, des abréviations et des entités imbriquées que les modèles entraînés sur des articles d’actualité n’ont pas été conçus pour reconnaître.
La détection des données personnelles inclut également des éléments spécifiques comme les numéros de téléphone, les identifiants de compte, les adresses IP, les numéros de passeport et les formats d’adresse locaux.
Pour l’extraction biomédicale, scispaCy propose des pipelines scientifiques et biomédicaux, ainsi que des fonctionnalités de liaison d’entités vers des ressources comme UMLS.
La bibliothèque utilise la licence Apache 2.0 et peut fonctionner sur CPU, bien que les pipelines plus volumineux et les index de liaison d’entités nécessitent davantage de mémoire.
Ses packages préentraînés ne nécessitent aucune donnée annotée. Les catégories personnalisées demandent toutefois un entraînement ou l’utilisation de règles.
Pour la détection des données personnelles, Presidio combine des modèles NLP, des expressions régulières, des sommes de contrôle et des mécanismes de reconnaissance personnalisés.
Presidio utilise la licence MIT et fonctionne efficacement sur CPU pour de nombreux cas d’usage. Les mécanismes de reconnaissance préconfigurés ne nécessitent aucune donnée d’entraînement, tandis que les identifiants propres à une organisation doivent être définis à l’aide de règles ou d’exemples annotés.
Avantages
- Taxonomies et étapes de prétraitement adaptées au domaine ciblé
- Meilleur point de départ qu’un modèle NER généraliste entraîné sur des actualités
- Combinaison fréquente de modèles, de règles et de liaison d’entités
Inconvénients
- Les outils biomédicaux et les solutions de détection PII ne sont pas interchangeables
- Les performances peuvent diminuer avec un nouveau type de document ou dans une nouvelle juridiction
- Les erreurs propres à un domaine peuvent avoir des conséquences juridiques ou cliniques plus importantes
Utiliser des LLM pour la reconnaissance d’entités nommées
L’extraction à l’aide de LLM constitue une troisième approche, aux côtés des API NER managées et des modèles encodeurs auto-hébergés. Au lieu de sélectionner une taxonomie NER fixe ou d’entraîner un classificateur de tokens, vous décrivez les entités recherchées et demandez au modèle de renvoyer des données structurées.
Une requête peut se présenter ainsi :
Extract all entities from the document.
Entity types:
- contracting_party
- effective_date
- governing_law
- termination_notice_period
Return JSON matching this schema:
{
"entities": [
{
"text": "string",
"type": "string",
"start": 0,
"end": 0,
"evidence": "string"
}
]
}
Les API prenant en charge les sorties structurées peuvent contraindre la réponse à respecter un schéma JSON, ce qui élimine une grande partie du travail de parsing. Le respect du schéma garantit toutefois uniquement la structure de la réponse, et non l’exactitude de chaque segment extrait ou de chaque classification.
Le principal avantage réside dans la possibilité de reconnaître des types d’entités arbitraires, sans disposer d’un jeu de données d’entraînement annoté. Vous pouvez ajouter aujourd’hui une catégorie renewal_condition, puis demain une catégorie liability_cap, sans annoter des centaines d’exemples ni réentraîner un modèle.
Un LLM peut également appliquer des règles contextuelles. Il peut, par exemple, distinguer le droit applicable à un contrat d’un pays uniquement mentionné dans l’adresse d’un client.
Cette flexibilité entraîne des coûts mesurables. D’après la normalisation présentée dans la section 4, GPT-4o coûte environ 2,5 fois plus cher par caractère anglais que les API spécialisées facturées 1,00 $ par million de caractères.
Le coût en tokens varie également selon la langue. L’inférence avec un LLM présente généralement une latence plus élevée, car le modèle génère sa réponse token par token.
Les résultats sont aussi moins reproductibles. Deux appels peuvent identifier des limites d’entités différentes, omettre des entités distinctes ou interpréter une catégorie ambiguë de manière différente.
Une température faible, des versions de modèles fixes, des schémas stricts et des tests de régression permettent de limiter ces variations, mais ils ne transforment pas un modèle génératif en système d’étiquetage déterministe.
L’extraction avec un LLM est généralement préférable lorsque :
- Le volume de texte est faible ou modéré
- Les types d’entités sont inhabituels ou changent fréquemment
- Vous avez besoin d’un prototype fonctionnel avant de constituer un jeu de données annoté
- La classification dépend d’informations réparties dans une phrase ou dans l’ensemble d’un document
Elle est généralement moins adaptée lorsque :
- Vous traitez de grands volumes de texte réguliers
- La taxonomie est fixe et bien définie
- L’application impose des contraintes strictes de latence
- Des entrées identiques doivent produire exactement les mêmes segments à chaque appel
GPT-4o est disponible sur Eden AI au tarif de 10,00 $ par million de tokens, avant l’application des 5,5 % de frais de plateforme. Le modèle prend en charge les sorties structurées, mais vous devez tout de même disposer d’un jeu de données d’évaluation permettant de mesurer la précision des segments, les entités manquées et les erreurs propres à votre schéma.
Quel est le coût réel de la NER : caractères ou tokens ?
Les prix des solutions de reconnaissance d’entités nommées peuvent sembler comparables jusqu’à ce que l’on examine leur unité de facturation.
Amazon Comprehend, Microsoft Azure AI Language et Tenstorrent facturent au caractère. OpenAI GPT-4o facture au token.
Un prix par million de tokens n’est pas équivalent à un prix par million de caractères. Comparer directement les tarifs affichés conduit donc à une conclusion erronée.
Les fournisseurs facturés au caractère coûtent : 1,00 $ par million de caractères
GPT-4o coûte : 10,00 $ par million de tokens
Pour un texte en anglais, un token représente en moyenne environ quatre caractères. Cela donne :
1 million de tokens × 4 caractères par token = environ 4 millions de caractères
Le prix de GPT-4o peut alors être normalisé : 10,00 $ ÷ 4 millions de caractères = 2,50 $ par million de caractères
Selon cette hypothèse, GPT-4o coûte environ 2,5 fois plus cher par caractère anglais qu’Amazon, Microsoft ou Tenstorrent.
Cette conversion devient toutefois moins fiable en dehors de l’anglais. Les tokenizers ne découpent pas toutes les langues en unités textuelles au même rythme. Le chinois, le japonais et l’arabe consomment généralement davantage de tokens par caractère que l’anglais. Le coût effectif par million de caractères augmente donc.
La formule est la suivante : Coût normalisé par million de caractères = prix par token ÷ nombre de caractères par token
Une API NER managée facturée 1,00 $ par million de caractères conserve un coût fixe, quelle que soit la langue. Ce n’est pas le cas d’un modèle facturé au token.
GPT-4o, au tarif de 10,00 $ par million de tokens d’entrée, revient à environ 2,27 $ par million de caractères en anglais, car l’anglais représente en moyenne près de 4,4 caractères par token avec le tokenizer de GPT-4o.
Ce ratio se dégrade fortement pour les écritures non latines. Le chinois représente en moyenne environ 1,3 caractère par token. Les mêmes 10,00 $ ne permettent donc de traiter qu’environ 1,3 million de caractères, contre près de 4,4 millions en anglais.
Le coût normalisé atteint alors environ 7,73 $ par million de caractères, soit près de 7,7 fois le prix d’une solution facturée au caractère.
Le coût atteint environ :
- 7,38 $ par million de caractères en japonais
- 6,63 $ par million de caractères en coréen
- 3,48 $ par million de caractères en arabe
Deux conclusions en découlent.
Premièrement, l’extraction facturée au token est la plus coûteuse précisément sur les workloads multilingues pour lesquels les utilisateurs considèrent souvent les LLM comme les plus performants.
Deuxièmement, l’écart de coût augmente avec la densité d’entités. Un texte rédigé en prose simple est généralement tokenisé efficacement, tandis qu’un contenu rempli de noms, de dates, de numéros de compte et d’identifiants consomme davantage de tokens. Or, ce type de contenu correspond précisément à de nombreuses tâches réelles de NER.
Mesurez ce ratio sur votre propre corpus avant de choisir une solution. Il dépend des caractéristiques de vos documents, et pas uniquement de leur langue.
Commencez à utiliser la NER avec Eden AI
La création d’un compte Eden AI account gives you an API key, access to the unified API, and a dashboard for monitoring usage, costs, latency, and errors. The self-service plan is pay as you go, with no subscription or volume commitment.
vous donne accès à une clé API, à l’API unifiée ainsi qu’à un tableau de bord permettant de suivre l’utilisation, les coûts, la latence et les erreurs.
L’offre en libre-service fonctionne selon un modèle pay-as-you-go, sans abonnement ni engagement de volume.
Vous pouvez tester Amazon Comprehend, Microsoft Azure AI Language, Tenstorrent et OpenAI GPT-4o depuis le même endpoint NER.
Envoyez à chaque fournisseur un texte représentatif de vos propres données, puis comparez :
- la couverture des types d’entités ;
- les segments non détectés ;
- les faux positifs ;
- la latence ;
- le coût.
Vous pourrez ensuite sélectionner le fournisseur par défaut le plus adapté à votre cas d’usage. Pour changer de fournisseur, il suffit de modifier le nom du modèle dans la requête.
import os
import requests
url = "https://api.edenai.run/v3/universal-ai"
headers = {"Authorization": f"Bearer {os.environ['EDENAI_API_KEY']}"}
models = [
"text/named_entity_recognition/amazon",
"text/named_entity_recognition/microsoft",
"text/named_entity_recognition/openai/gpt-4o",
"text/named_entity_recognition/tenstorrent",
]
for model in models:
response = requests.post(
url,
headers=headers,
json={
"model": model,
"input": {
"text": "Microsoft invested $5 million in Paris in March 2026.",
"language": "en",
},
},
timeout=60,
)
response.raise_for_status()
print(f"\n=== {model} ===")
for entity in response.json()["output"]["items"]:
print(entity["entity"], ":", entity["category"])
Consultez la documentation de l’API NER pour retrouver l’endpoint, les noms des modèles, les champs d’entrée et le format de réponse.

.jpg)


