De fichiers morts à JSON : l'extraction d'informations dans Azure

Reçus scannés que personne ne transcrit, appels de support archivés sans être écoutés, photos d'une salle que quelqu'un regarde à l'œil pour compter les gens : des données utiles bloquées dans des formats qu'aucun système ne peut consommer. « Introduction to information extraction with artificial intelligence in Azure » sur Microsoft Learn présente comment convertir ces fichiers en champs structurés avec Azure Content Understanding dans Foundry Tools, et ce post suit ce chemin complet : ce que couvre le service, à quoi ressemble son flux, pourquoi un schéma bat l'OCR (reconnaissance optique de caractères), ce qu'est un analyseur, ce qu'il extrait de l'audio et de la vidéo, et comment le programmer avec son SDK (kit de développement logiciel) asynchrone. Le principe qui tient tout le post est simple : si vous savez décrire les champs, le service les renvoie.

Données bloquées

L'extraction d'informations par IA convertit du contenu non structuré (documents, images, audio, vidéo) en données lisibles par machine qui peuvent être cherchées et analysées, en éliminant le travail manuel de traiter factures, formulaires ou enregistrements.

Les scénarios qui font le point sont du quotidien. Dans les notes de frais, extraire descriptions et montants de reçus scannés. Dans le service client, analyser des appels de support enregistrés pour identifier problèmes et solutions. Dans la planification de la capacité, estimer les volumes de visiteurs à partir de photographies et d'enregistrements vidéo. Les trois illustrent le même principe : il y a de l'information précieuse piégée dans des formats non structurés, et l'IA la convertit en quelque chose d'processable.

Ce que couvre Content Understanding

Azure Content Understanding est un service dans Foundry Tools qui utilise l'IA pour extraire des informations structurées du contenu non structuré, en identifiant entités, champs, relations et sens. La portée est large : documents et images (PDF, formulaires, factures, reçus, contrats), audio (enregistrements ou appels) et vidéo (réunions ou autres fichiers multimédias).

Un détail qui ordonne les attentes : le service ne fait pas que transcrire ou reconnaître. La promesse est de comprendre ce qu'il y a dans le fichier et de le renvoyer avec des noms de champs qu'un système peut lire.

Les trois formats (documents, audio et vidéo) entrent par des portes différentes et sortent par la même : une app peut traiter une facture, un appel et une réunion avec le même code de sortie.

Le flux : ingestion, analyse, sortie

Le flux de travail est uniforme pour tout le contenu. D'abord, l'ingestion : le contenu est envoyé au service. Ensuite, l'analyse par IA, qui combine reconnaissance optique de caractères (OCR), reconnaissance de parole, compréhension du langage naturel et modèles d'IA bidirectionnels. Et enfin, la sortie structurée : le service renvoie des résultats (normalement JSON, le format structuré que les programmes consomment) qui correspondent au modèle, prêts à stocker, chercher ou intégrer dans des systèmes en aval.

flowchart LR
    I[Ingestion<br/>le contenu est envoyé] --> A[Analyse par IA<br/>OCR, reconnaissance de parole, langage et modèles bidirectionnels]
    A --> S[Sortie structurée<br/>JSON qui correspond au modèle]

Quatre pièces d'IA différentes (OCR, reconnaissance de parole, langage et modèles bidirectionnels) travaillent en silence derrière une seule requête JSON.

Que le même flux s'applique à un PDF, à un enregistrement et à une vidéo est ce qui le rend attractif : une seule façon de travailler, quelle que soit la provenance du données. Et la sortie garde la forme que vous avez définie : pas de texte libre à interpréter, mais des champs nommés sur lesquels programmer. C'est le contrat entier du service.

De l'OCR aux schémas

La question de fond est pourquoi cela bat l'OCR de toujours. L'OCR basique « lit » du texte dans des images et le rend numérique et cherchable, mais il se concentre sur l'extraction et ne comprend ni sens, ni contexte, ni relations entre mots : il renvoie des caractères, pas des champs. La différence est de catégorie : l'OCR lit ; le schéma structure. La question utile cesse d'être « puis-je extraire le texte ? » et devient « quels champs dois-je renvoyer ? »

L'approche contrôlée par schéma va plus loin. Un schéma déclare quelle information extraire et comment la structurer (champs, collections et champs imbriqués), et il s'applique sémantiquement : le champ est extrait même si son étiquette diffère ou manque. L'exemple classique le dit tout : « Invoice No. », « Invoice # » ou un nombre sans étiquette peuvent tous être assignés à InvoiceNumber si l'analyseur conclut qu'ils représentent le même concept.

Un schéma de facture réel le démontre. Ses champs : nom du fournisseur, numéro de facture, date, nom du client, adresse, et une collection d'articles avec description, prix unitaire, quantité et total de ligne, plus sous-total, taxes, expédition et total. Le service identifie les champs même s'ils sont étiquetés autrement ou sans étiquette, et renvoie des valeurs imbriquées avec leur structure. Ni le format de la facture ni l'orthographe de ses en-têtes n'ont d'être exacts ; ce qui doit être clair, c'est quel champ on cherche.

Analyseurs : l'unité de travail

L'analyseur est l'unité de Content Understanding qui prend l'entrée, applique l'analyse par IA et génère des résultats structurés. Il applique la même logique d'extraction de façon cohérente à tout le contenu et produit du JSON prévisible : une fois configuré, il réutilise le schéma à chaque requête d'analyse.

Il y a deux façons d'en obtenir un. Des analyseurs précompilés prêts à l'emploi (prebuilt-invoice pour les factures, prebuilt-imageSearch sur les images, prebuilt-audioSearch sur l'audio et prebuilt-videoSearch sur la vidéo) ou des analyseurs personnalisés quand le schéma est propre au métier. Le flux de travail est le même dans les deux cas : choisir ou créer l'analyseur, envoyer le contenu, recevoir le résultat JSON qui correspond au schéma. Un analyseur est, ainsi, un contrat exécutable : schéma d'un côté, JSON de l'autre.

Avant de toucher au code, le portail de Foundry permet de tester l'analyseur et de valider sa sortie ; le code est l'étape d'après, quand le schéma a déjà donné ce que vous espériez dans le portail.

L'audio et la vidéo extraient aussi des champs

Là où le service s'écarte le plus de l'OCR traditionnel, c'est en audio et vidéo. D'un fichier audio il renvoie des transcriptions, des résumés et les champs définis dans le schéma (appelant, résumé des messages, actions demandées, numéro de rappel, contact alternatif). D'une vidéo il extrait la présence, l'emplacement, qui a parlé et ce qu'il a dit, un résumé de la discussion et les tâches assignées, même avec des comptages par intervalle de temps.

L'exemple du message vocal le rend concret : un schéma avec appelant, résumé des messages, actions demandées, numéro de rappel et coordonnées de contact alternatif, appliqué à un message vocal Contoso renvoie « Ava de Contoso », le résumé de l'appel, l'action de rappeler ou d'envoyer un courriel, le 555-12345 et Ava@contoso.com. Tout cela sort en JSON, sans que personne n'écoute l'enregistrement.

L'exemple de réunion en vidéo ferme l'idée : un schéma avec emplacement, participants sur place, participants distants et total des participants renvoie « Salle de conférence » avec 1 participant sur place, 3 distants et 4 au total. Et au même schéma on peut ajouter des comptages par intervalle de temps, qui a parlé et ce qu'il a dit, un résumé de la discussion et la liste des tâches assignées.

Le programmer : le SDK asynchrone

L'analyse avec Content Understanding est une opération de longue durée asynchrone : le travail est envoyé et le résultat arrive plus tard, donc il faut sonder l'URL d'Operation-Location jusqu'à la fin. C'est ce sondage que le SDK Python encapsule (python -m pip install azure-ai-contentunderstanding) : on crée un ContentUnderstandingClient avec le point de terminaison de la ressource Foundry et une clé ou un identifiant Microsoft Entra, on appelle begin_analyze(analyzer_id, inputs) avec l'URL du contenu et on attend avec poller.result().

flowchart LR
    B[begin_analyze<br/>démarre l'opération] --> P["poller.result()<br/>attend et sonde"]
    P --> R[Résultat<br/>markdown et fields avec confiance]

Le SDK fait le travail ennuyeux : au lieu d'écrire le sondage à la main contre l'URL d'Operation-Location, on demande le résultat et le poller s'occupe de demander jusqu'à la fin du travail.

Le code d'une analyse de facture est court : analyzer_id = "prebuilt-invoice", inputs = [{"url": ...}], poller = client.begin_analyze(...), result = poller.result() et une boucle sur result.contents imprimant markdown et fields. La sortie JSON inclut status, analyzerId et apiVersion, et par contenu le markdown à côté de champs comme CustomerName avec confiance 0.95 et InvoiceDate avec confiance 0.994. Chaque champ arrive avec sa valeur et son score de confiance, prêt à stocker ou intégrer. La forme brute ressemble à ceci (valeurs abrégées) :

{
  "status": "…",
  "analyzerId": "prebuilt-invoice",
  "apiVersion": "…",
  "contents": [
    {
      "markdown": "…",
      "fields": {
        "CustomerName": { "value": "…", "confidence": 0.95 },
        "InvoiceDate": { "value": "…", "confidence": 0.994 }
      }
    }
  ]
}

En clair : l'URL d'un PDF entre, et le même JSON avec champs nommés et confiance pour chacun sort.

Par où commencer

Si le format de vos documents est fixe (factures, formulaires, tickets), commencez par un analyseur précompilé et regardez quels champs il renvoie avant de concevoir quoi que ce soit de votre côté. Si le schéma est le vôtre, déclarez-le complet dès le départ : collections et champs imbriqués, pour qu'ajouter un champ plus tard n'oblige pas à refaire le flux. Et si le volume est dans les appels ou les réunions, l'audio et la vidéo ne sont pas un extra du service : c'est la moitié de la valeur.

Avec n'importe quel chemin choisi, la fin du flux est la même : JSON avec champs et confiances, prêt à être versé dans une base de données ou à alimenter un système en aval.

De la lecture à l'exécution

La pratique d'analyser des documents dans Foundry Tools est restée en lecture : sa description a été relue, mais pas exécutée. Ce que ce parcours rend clair, c'est la carte (ce qui entre, ce qu'on demande au schéma, ce qu'il renvoie et comment le sondage fonctionne) ; ce qui manque à tester sur un abonnement à soi, c'est le flux avec de vrais fichiers, parce que c'est là qu'apparaissent les vrais doutes : combien de confiance est une confiance suffisante, comment échoue un schéma mal déclaré, et combien de temps prend vraiment le travail. L'ordre d'attaque qui laisse le moins de doutes ouverts : d'abord un analyseur précompilé avec un fichier d'exemple, ensuite votre propre schéma contre ce même fichier, et seulement ensuite l'automatisation dans le code.

---

*Source : le module « Introduction to information extraction with artificial intelligence in Azure » de Microsoft Learn.*