Texte en données : opinions, entités et résultats déterministes

Commentaires de clients, histoires cliniques, relevés bancaires, dossiers juridiques : le texte qu'une entreprise accumule n'est pas pensé pour qu'un programme le traite. « Introduction to text analysis in Azure » sur Microsoft Learn montre comment convertir ce matériau en données qu'une app peut utiliser (opinions, phrases clés, entités, thèmes) et pose la décision qui traverse tout le chapitre : le demander à un modèle d'IA ou appeler un analyseur déterministe. Ce post parcourt les deux voies dans Microsoft Foundry, les tâches que chacune couvre, comment choisir selon la sortie nécessaire et à quoi ressemble le pont quand celui qui demande est un agent. Le fil conducteur est un seul : la sortie. Tout le reste (modèle, outil ou serveur) s'en déduit : le modèle quand la réponse peut varier, l'outil quand elle ne peut pas, et le serveur MCP quand celui qui demande est un agent.

Texte non structuré, information actionnable

L'analyse de texte examine automatiquement le texte écrit pour en extraire des informations utiles comme opinions, phrases clés, entités ou thèmes, en convertissant du texte non structuré en information significative. Elle s'appuie sur le traitement du langage naturel (NLP), qui permet aux machines de comprendre, interpréter et répondre au langage humain dans le but d'analyser et d'extraire le sens ou la structure du texte existant. La machine n'est pas là pour comprendre le langage comme une personne : elle est là pour extraire d'un texte ce qu'un système peut stocker, comparer et router.

Les applications se reconnaissent au toucher : commentaires de clients à lire en volume, santé avec des notes que personne n'a le temps de relire, finance avec des rapports, documents juridiques qui demandent de localiser des clauses. Dans tous, la promesse est la même : du tas de texte brut à quelque chose qu'on peut compter, trier ou router.

Deux voies dans Foundry

Foundry offre deux chemins et la différence est flexibilité face à prévisibilité.

Du côté flexible, les modèles d'IA d'usage général : entraînés sur de grands volumes de texte, ils suivent des instructions en langage naturel pour extraire des phrases clés, reconnaître des entités, analyser l'opinion, résumer, traduire, classer et répondre à des questions, sans configuration ni entraînement préalable de l'utilisateur. Comme la sortie dépend de la façon de formuler la demande, plus elle est précise, plus la réponse est structurée et détaillée.

Du côté prévisible, Azure Language dans Foundry Tools : un service de NLP avec des analyseurs créés pour des tâches spécifiques qui utilisent des techniques statistiques pour renvoyer des résultats structurés et déterministes, adaptés aux pipelines automatisés qui exigent la cohérence. Le modèle couvre beaucoup de tâches avec sortie variable ; l'outil répond de façon prévisible pour une tâche concrète.

flowchart LR
    P[De quelle sortie avez-vous besoin ?] -->|Variable ou conversationnelle| A[API de responses<br/>modèle d'usage général]
    P -->|Toujours le même format| B[SDK Azure Language<br/>analyseurs déterministes]
    P -->|C'est un agent qui demande| C[Serveur MCP Azure Language<br/>invoqué par l'agent]

Même texte, même réponse : c'est le contrat qu'un pipeline automatisé a besoin de brancher sans surprises.

Ce qu'il peut faire

Avec un modèle d'usage général, le catalogue de tâches est large. L'extraction de phrases clés renvoie les concepts principaux, utiles pour indexer et chercher. La reconnaissance d'entités nommées localise personnes, lieux, dates et organisations avec type, sous-type et valeur. L'analyse de sentiment classe le texte en positif, négatif ou neutre, par document ou par phrase, et va de pair avec l'exploitation des opinions. Résumé, traduction, classification par catégories et réponse sur un passage sont aussi là. Tout étant contrôlé en langage naturel, les tâches se combinent dans la même conversation : une même demande peut résumer et repérer des entités sans changer de service. Vous demandez de résumer un contrat et d'en signaler les dates et les parties, et le même échange renvoie les deux ; c'est ça qui enlève le travail d'orchestrer trois appels distincts pour une seule question.

Les exemples rendent tangible ce qu'ils renvoient. Du texte « On 2 de mayo de 2017, John Smith visitó Nueva York para asistir a una conferencia hospedada por Microsoft… más de 25% de los 40 asistentes viajaron más de 10 millas » sortent Personne (John Smith), Localisation (New York), Organisation (Microsoft), DateTime (date, heure et durée) et Quantité (pourcentage, nombre et dimension). Et « ¡Hola! Me llamo Josefina y vivo en Madrid, España » renvoie Spanish, code ISO 639-1 es et confiance 1.00, tandis qu'un texte avec téléphone et adresse (« Maria Garcia llamó desde 020 7946 0958 y pidió enviar documentos a 42 Market Road, Londres… ») renvoie la détection de PII de Personne, Numéro de téléphone et Adresse.

Ce que les trois exemples partagent, c'est que la réponse est structurable : chaque entité arrive avec type et valeur, chaque langue avec son code et sa confiance. C'est le point où le texte cesse d'être texte et devient programmable.

Azure Language : quand le résultat doit toujours être le même

Azure Language travaille sur des résultats structurés et déterministes, et ses capacités pratiques commencent par deux. La détection de langue renvoie la langue principale avec un score de confiance et le code ISO 639-1 (le es de l'exemple), et sert à router des documents dans des flux multilingues. La détection d'informations d'identification personnelle (PII) identifie les données personnelles et de santé (noms, téléphones, adresses, informations de santé), renvoie le texte censuré avec les entités trouvées avec leur catégorie et confiance, et peut les censurer : la voie naturelle pour respecter les normes de confidentialité avant de stocker ou partager du texte.

Les deux analyseurs partagent un contrat : à la réponse accompagne la confiance avec laquelle elle est donnée, sur une échelle de 0 à 1. Ainsi un pipeline ne reçoit pas seulement la valeur, il reçoit aussi la foi à lui accorder.

Dans le code, la bibliothèque est azure-ai-textanalytics (pip install azure-ai-textanalytics). Un TextAnalyticsClient créé avec point de terminaison et AzureKeyCredential expose detect_language (qui renvoie la langue, son code ISO 639-1 et un score de confiance entre 0 et 1) et recognize_pii_entities (qui renvoie le texte censuré et les entités avec catégorie et confiance). C'est l'option quand l'application a besoin de valeurs cohérentes et structurées, comme un code de langue ou un score de confiance.

Choisir : API de responses vs. SDK

La règle de choix est simple et dépend de la variabilité possible de la réponse. La question qui l'ordonne est une seule : acceptez-vous que deux appels identiques renvoient des textes différents ? Si la réponse est oui, le modèle d'usage général est le chemin ; si non, l'analyur déterministe. Si l'application accepte du texte qui peut varier entre appels (analyse conversationnelle), l'API de responses convient : la bibliothèque OpenAI de Python (pip install openai) abstrait les requêtes HTTP, les variables de point de terminaison, clé et nom de déploiement vivent dans un fichier .env que dotenv charge, et le client authentifié permet d'appeler responses.create. Le squelette est court : enregistrer les variables dans .env, les charger avec load_dotenv() et les lire avec os.getenv() (en veillant à ce que les noms correspondent exactement à ceux du code), créer le client OpenAI(base_url=endpoint, api_key=api_key) et appeler client.responses.create(model=deployment_name, input=...).

Si en revanche l'application a besoin de valeurs cohérentes et structurées (un code de langue, un score de confiance, du texte censuré), le chemin est le SDK (kit de développement logiciel) d'Azure Language. La justification est la nature du modèle : les résultats du modèle peuvent varier entre appels parce qu'il génère du texte de façon probabiliste, et deux appels avec la même instruction peuvent renvoyer des textes différents, tandis que les analyseurs spécialisés renvoient des résultats déterministes. C'est la même distinction que tout le post vue depuis le code : une voie pour quand le texte peut se permettre de varier, une autre pour quand il ne peut pas.

Connecter un agent par MCP

Quand celui qui demande l'analyse est un agent, apparaît la pièce du Model Context Protocol (MCP) : un standard ouvert qui définit comment les agents d'IA se connectent à des outils externes et des sources de données, comme un adaptateur universel qui évite d'écrire une intégration sur mesure pour chaque service. Il utilise une architecture client-serveur : le client MCP est l'agent, qui envoie des requêtes et reçoit des réponses, et le serveur expose des outils, des données ou des actions, en répondant avec des données (scores, phrases clés, entités) ou avec des actions, comme traiter un lot de documents.

Le serveur MCP d'Azure Language est un service administré qui expose les capacités d'Azure Language (reconnaissance d'entités, analyse de sentiment, détection de langue, PII) via ce standard, de sorte que l'agent les invoque avec le même protocol qu'il utilise avec n'importe quel autre serveur MCP, sans appeler directement l'API REST ni administrer de tokens dans son code. Là se joint le meilleur des deux voies : le raisonnement du modèle avec des résultats déterministes, par exemple pour router des incidents par langue détectée ou pour identifier et censurer des PII. Et comme tous parlent le même protocole, l'agent peut changer de serveur sans réécrire de logique.

flowchart LR
    A[Agent<br/>client MCP] <--> S[Serveur MCP Azure Language<br/>outils exposés]
    S <--> L[Capacités Azure Language<br/>entités, sentiment, langue, PII]

Le circuit complet en une ligne : l'agent parle MCP et le serveur traduit cette conversation en capacités d'Azure Language.

Et pas besoin de créer une ressource de langage à part (une ressource Foundry inclut déjà l'accès aux outils de langage) ; la connexion se configure avec le nom de la ressource Foundry dans le playground de l'agent.

De la lecture à l'exécution

La pratique du portail (tâches NLP et exploration d'Azure Language) est restée en lecture : sa description a été relue, mais pas exécutée. Ce que ce parcours rend clair, c'est quand demander de la flexibilité à un modèle et quand exiger de la prévisibilité d'un analyseur, et comment brancher les deux sur un agent ; ce qui manque à tester sur un abonnement à soi, c'est le flux complet du portail jusqu'au serveur MCP connecté, parce que c'est là qu'on voit les vraies valeurs de confiance, le censurage et les réponses de l'agent en direct. L'ordre pour reprendre est déjà donné : d'abord le portail avec des tâches NLP, ensuite quelques appels au SDK avec un texte à soi, et seulement ensuite le serveur MCP connecté à l'agent ; chaque étape élimine une couche d'incertitude.

---

*Source : le module « Introduction to text analysis in Azure » de Microsoft Learn.*