Multimodal inbound mailbot : OCR/VLM + audio (STT) à l’échelle

Le mail est un colis. La pièce jointe, c’est ce qu’il y a dedans.

Je vais être un peu brutal : un mailbot “texte-only” n’existe pas longtemps.

Au début, vous faites un POC sur des e-mails bien propres :

• une question simple,
• pas trop de thread,
• pas de PJ,
• un vocabulaire standard.

Puis vous branchez une boîte partagée.

Et là, bienvenue dans la vraie vie :

• un PDF de 43 pages (scanné, donc image),
• une photo de facture prise de travers,
• une capture d’écran d’erreur (avec du texte… dans l’image),
• un formulaire à moitié rempli,
• et le tout envoyé depuis un iPhone avec une signature qui prend la moitié du message.

Votre mailbot ne traite pas “des e-mails”. Il traite des preuves.

Multimodal inbound : la définition qui tient en prod

Un pipeline multimodal inbound, côté mailbot, c’est :

1. Ingestion : parsing MIME, reconstitution du thread, extraction des fichiers.
2. Sécurité : antivirus, sandbox, décompression contrôlée, limites de taille, type sniffing.
3. Détection : PDF natif vs scan, image, audio, office, zip…
4. Extraction : parsing (si possible), OCR (si scan), VLM (si image complexe), STT (si audio).
5. Structuration : champs, tableaux, entités, “preuves” (citations page/zone).
6. Confiance : score OCR/STT, incohérences, missing fields, flags de risque.
7. Décision : N1 standard, N2 contextualisé + actions backoffice, ou HITL.

Ça ressemble à une chaîne industrielle. Et c’est une bonne nouvelle : les chaînes industrielles se scalent.

Les 4 types de pièces jointes (et leur traitement “par défaut”)

1) PDF natif (texte sélectionnable)

Le meilleur cas. Le “PDF natif” contient du texte.

Votre stratégie :

• extraire le texte (par page),
• garder la structure (titres, sections, tableaux),
• et produire des citations : page X, paragraphe Y.

2) PDF scanné (image dans un PDF)

Le cas le plus courant dans les secteurs “papier”.

Votre stratégie :

• OCR (page par page),
• score de confiance,
• extraction de champs si besoin (montants, dates, références),
• et escalade si l’OCR est trop incertain (ou si le document est illisible).

Côté modèles, vous avez des OCR modernes côté fournisseurs (ex. Mistral OCR 3) ou des services cloud spécialisés (AWS Textract, Google Document AI, Azure Document Intelligence).⁴⁹¹⁰¹¹

3) Images (photos, captures d’écran)

Ici, l’OCR pur marche parfois… et parfois non.

Sur une capture d’écran d’erreur :

• OCR + LLM peut suffire.

Sur une photo de facture froissée, lumière jaune, cadrage de travers :

• un VLM (vision-language model) peut mieux comprendre la scène.

4) Audio (note vocale, voicemail exporté)

Ça arrive plus souvent que vous ne le pensez :

• note vocale envoyée comme PJ,
• client qui dicte un numéro de contrat,
• équipe terrain qui envoie une description audio + une photo.

Votre stratégie :

• STT (speech-to-text),
• éventuellement segmentation (s’il y a plusieurs locuteurs),
• puis extraction de champs comme sur un e-mail.

Les options 2026 côté STT : OpenAI propose par exemple des modèles “transcribe” dédiés,¹ Mistral documente Voxtral côté transcription,⁵ et vous avez aussi des options open source (Whisper).⁶

OCR + LLM vs VLM : pourquoi le “plus intelligent” n’est pas toujours le meilleur

Je vous donne un insight qui évite des mois de débats : VLM direct ≠ solution universelle.

Oui, un VLM peut “voir” un document.

Mais quand votre document fait 60 pages, vous payez :

• en tokens,
• en latence,
• en difficulté d’audit (quel passage exact a été utilisé ?),
• et en fragilité (un mauvais cadrage, un tableau dense, des pages répétitives).

Sur du document long et répétitif, le duo “boring” gagne souvent :

1. OCR (ou parsing PDF natif),
2. LLM pour structurer/expliquer,
3. citations page/section,
4. HITL sur les zones à faible confiance.

Tableau de décision (simple, mais utile)

Audio inbound : STT, puis “support normal” (et pourquoi TTS/S2S est souvent hors-sujet)

Un mailbot n’est pas un callbot. Il n’a pas besoin de parler.

La majorité du temps, le bon pipeline audio inbound est :

• audio → texte (STT),
• texte → classification / extraction / réponse,
• et éventuellement : “merci, voici le résumé et la prochaine étape”.

Alors pourquoi parler de TTS ou S2S ?

Parce qu’en organisation, les canaux se mélangent.

Vous pouvez vouloir :

• lire une réponse en audio à un conseiller (agent assist),
• générer un message vocal sortant (rare, mais possible),
• ou déclencher un callbot sur une escalade.

OpenAI documente par exemple des modèles TTS dédiés et des modèles “realtime” côté audio conversationnel.²¹² Google documente aussi un modèle Gemini Live en “native audio output”.³

Mais gardez la règle du terrain :

Sécurité des pièces jointes : le multimodal commence par “ne pas se faire attaquer”

Un pipeline PJ, c’est aussi un pipeline d’attaque.

Vous ingérez :

• des fichiers inconnus,
• des formats exotiques,
• des payloads compressés,
• des documents qui peuvent contenir du code (macro),
• et parfois des “PDF bomb”.

Ce n’est pas une paranoïa. C’est le coût d’entrée.

OWASP a une checklist claire sur les uploads (validation, restrictions, scanning, stockage).¹³

Le minimum syndical (mais non négociable)

• type sniffing (ne pas faire confiance à l’extension),
• limites de taille + timeouts,
• décompression contrôlée (zip/tar),
• AV / sandbox si vous exécutez des parsers,
• stockage isolé (bucket séparé, permissions),
• redaction PII si vous indexez (RAG),
• et TTL : les PJ ne sont pas une archive éternelle.

Architecture : du MIME au JSON, puis du JSON à la décision

Je vous propose une façon de penser simple : tout finit en JSON.

Le but du multimodal, ce n’est pas “traiter des formats”.
C’est produire des sorties structurées exploitables :

• intent
• priority
• risk_flags
• entities (contrat, référence, montant)
• attachments[] (type, pages, confiance)
• extractions[] (champs, tableaux, citations)

1

Normaliser l’e-mail

HTML → texte, thread reconstruction, langue, suppression des signatures/citations parasites.

2

Sécuriser et typer les fichiers

Sniffing, limites, scan, extraction des métadonnées (pages, durée audio, résolution).

3

Choisir la voie d’extraction

PDF natif → parsing. PDF scanné → OCR. Images complexes → VLM. Audio → STT.

4

Structurer + citer

Champs extraits + zones + page. La citation n’est pas cosmétique : c’est votre preuve.

5

Scorer la confiance et décider

Seuils (par doc/type). HITL si doute. Sinon N1/N2 + actions backoffice.

Extraction structurée : quand un PDF doit devenir une “fiche” (et pas un roman)

Un mailbot multimodal ne lit pas pour le plaisir. Il lit pour agir.

Et “agir” veut dire : produire des champs exploitables.

Exemples d’extraction qui changent la vie :

• assurance : numéro de contrat, date du sinistre, montant, adresse, immatriculation ;
• facturation : référence facture, IBAN, montant, TVA ;
• support produit : code d’erreur, version, OS, capture d’écran ;
• RH : identité, dates, pièces justificatives.

Le piège classique : croire qu’un LLM va “extraire” un tableau juste en lisant un PDF.

Parfois oui. Souvent non.

Pourquoi ? Parce que les tableaux sont une forme de mise en page, pas seulement du texte. Et la mise en page, c’est un sport.

Deux stratégies qui marchent (selon votre contexte)

1. Layout d’abord, LLM ensuite

   • vous détectez les blocs (titres, paragraphes, cellules),
   • vous reconstituez le tableau,
   • puis vous demandez au LLM de produire un JSON propre.

2. Service spécialisé documents
   Si vous avez beaucoup de formulaires standardisés, les services de type “Document AI / Textract / Document Intelligence” peuvent sortir des key-value et des tables directement.⁹¹⁰¹¹

Micro-heuristiques (celles que les équipes aiment, parce qu’elles sont simples)

• si le document fait beaucoup de pages, on privilégie parsing/OCR + extraction structurée plutôt que VLM direct ;
• si le texte OCR contient trop de “????” ou de caractères incohérents → escalade (ou re-demande) ;
• si un champ “clé” ne passe pas une validation (format IBAN, date, référence) → HITL.

Ce n’est pas de la poésie. C’est du contrôle qualité.

HITL sur pièces jointes : l’UI qui transforme le multimodal en produit

Un système multimodal sans HITL finit souvent en deux états :

• soit il automatise trop peu (“on escalade tout, c’est plus sûr”) ;
• soit il automatise trop (“on laisse passer, on verra bien”).

Le HITL bien conçu, c’est un troisième état : on automatise beaucoup, mais on vérifie intelligemment.

Le pattern que j’aime :

• le mailbot propose une extraction structurée (JSON),
• il surligne les zones “preuves” (page/zone),
• il met un score par champ,
• et il pose une question claire au reviewer : “valider / corriger / escalader”.

Ce qui évite l’épuisement :

• ne pas envoyer l’intégralité du PDF à relire,
• envoyer les 3 zones qui supportent les 3 champs critiques,
• et capturer les corrections comme données (active learning).

Coûts et observabilité : ce qu’on oublie toujours en démo

Deux pièges classiques :

1. Vous payez à la page, et personne ne sait combien de pages arrivent.
2. Vous payez au retry, et personne ne sait pourquoi ça retry.

Donc vous instrumentez :

• pages OCR/jour,
• temps par étape (parse/OCR/VLM/STT),
• taux de confiance moyen,
• taux d’escalade HITL,
• erreurs par type de fichier,
• et coût par ticket (pas seulement coût par requête).

Le multimodal devient rentable quand vous arrêtez de le mesurer “en tokens” et que vous le mesurez “en résolution”.

Conclusion : le multimodal, c’est de la plomberie… et c’est très bien

Le marketing aime dire “vision”, “audio”, “multimodal”.

En production, c’est plus simple :

• sécuriser,
• extraire,
• structurer,
• citer,
• scorer,
• escalader.

Et si vous faites ça, votre mailbot devient un vrai opérateur : il traite des preuves, pas des phrases.

Checklist “multimodal ready”

• Parsing MIME + thread reconstruction
• File upload security (sniffing, size limits, scan, sandbox)
• Détection PDF natif vs scan
• OCR + score + HITL sur faible confiance
• VLM pour images complexes (pas par défaut)
• STT pour audio (note vocale) + confiance
• Sorties structurées (JSON) + citations page/zone
• Observabilité : pages, latence, erreurs, coût/ticket

FAQ

Questions frequentes

Faut-il un VLM pour traiter des PDF scannés ?+

Pas forcément. Sur du document long, OCR + extraction structurée est souvent moins cher et plus auditable. Le VLM est utile sur les images “réelles” (photos, captures, documents très visuels).

Que faire quand l’OCR est mauvais ?+

Ne pas “forcer”. Vous scorez la confiance, vous isolez les zones douteuses, et vous escaladez HITL. Parfois, la meilleure automatisation est de demander une photo plus nette (ou un PDF natif).

Pourquoi parler de TTS/S2S dans un article mailbot ?+

Parce que les organisations mélangent les canaux : un mail peut déclencher un callbot, un conseiller peut vouloir un résumé audio, et l’outbound peut utiliser la voix. Mais dans 90% des cas, le mailbot fait surtout STT → texte → support.

Sources et references

1. [1]OpenAI — Modèle STT (gpt-4o-mini-transcribe) :
2. [2]OpenAI — Modèle TTS (gpt-4o-mini-tts) :
3. [3]Google — Gemini API changelog (Gemini Live, native audio output) :
4. [4]Mistral AI — Mistral OCR 3 (mistral-ocr-2512) :
5. [5]Mistral AI — Voxtral Mini Transcribe Realtime (STT) :
6. [6]OpenAI — Whisper (open source) :
7. [7]Tesseract OCR (open source) :
8. [8]Piper TTS (open source) :
9. [9]AWS — Amazon Textract :
10. [10]Google Cloud — Document AI :
11. [11]Microsoft — Azure AI Document Intelligence :
12. [12]OpenAI — Modèle audio “realtime” :
13. [13]OWASP — File Upload Cheat Sheet :