Stack Mailbot 2026 : LLM, OCR, VLM, HITL, backoffice

Avant de parler modèles : votre mailbot est une usine, pas un email “bien écrit”

Je vais volontairement être un peu désagréable (avec le respect).

Quand une équipe me dit : “on veut un mailbot”, très souvent elle veut dire : “on veut que l’IA écrive des e-mails”.

Ce n’est pas ça, le problème.

Le vrai problème, c’est que l’e-mail est un format paresseux : tout est dedans, rien n’est structuré, et pourtant vous devez prendre une décision fiable.

Un mailbot sérieux est donc une usine de transformation :

• entrée : texte + thread + pièces jointes,
• sortie : intention + priorité + champs + décision + action + trace.

Et le “texte de réponse” n’est qu’un sous-produit.

La chaîne de valeur (vraie) d’un mailbot

Si je devais résumer la stack, voilà un pipeline “production-grade” (sans exotisme inutile) :

Pourquoi ce pipeline marche (et pourquoi votre démo ne suffit pas)

En démo, vous avez 3 e-mails propres.

En prod, vous avez :

• des threads qui ressemblent à des archives,
• des clients qui écrivent “URGENT” pour une question de mot de passe,
• des pièces jointes qui ne s’ouvrent pas,
• et des cas juridiques glissés entre deux “merci”.

Donc vous devez :

1. réduire l’incertitude étape par étape,
2. tracer les décisions,
3. escalader quand ça devient risqué.

N1 vs N2 : ce que ça change techniquement (spoiler : presque tout)

Le mailbot Niveau 1 (N1) peut vivre avec :

• une bonne classification,
• une extraction minimale,
• et des réponses standard.

Le mailbot Niveau 2 (N2) exige :

• identity resolution (matching client/contrat/dossier),
• accès contrôlé au CRM,
• et actions backoffice (outil calling) sécurisées.

Sorties structurées : le mailbot doit parler JSON avant de parler français

Le piège classique : demander au modèle “réponds au client”.

En prod, vous voulez d’abord une sortie structurée :

• intention,
• priorité,
• champs extraits,
• action proposée,
• escalade ou non,
• et justification.

Exemple (schéma) :

{
  "intent": "sinistre_auto",
  "priority": "high",
  "risk": "medium",
  "customer_match": { "confidence": 0.82, "customer_id": "C-1842" },
  "extractions": {
    "contract_id": "87421",
    "incident_date": "2026-03-03",
    "attachments": ["constat.jpg", "facture.pdf"]
  },
  "proposed_actions": [
    { "tool": "create_ticket", "idempotency_key": "msg-<id>" }
  ],
  "send_mode": "draft",
  "escalation_reason": "attachments_ocr_low_confidence"
}

Ensuite seulement vous rédigez l’e-mail de réponse… en vous appuyant sur les champs et les règles.

Les modèles en 2026 : qui fait quoi (LLM / VLM / OCR / STT / TTS / S2S)

1) LLM (texte) : compréhension + rédaction + extraction

Les familles “mainstream” côté API évoluent vite. Si vous voulez les noms exacts (et les IDs qui vont bien), gardez ces pages officielles sous la main :

• OpenAI liste ses modèles (texte + audio + realtime + open-weights gpt-oss).¹
• Anthropic documente ses modèles Claude (ex. Opus).²
• Google publie les identifiants modèles Gemini côté API (incluant Gemini 3).³
• Mistral publie ses modèles (Mistral Large 3, etc.).⁴
• Meta publie la famille Llama 4 (open weights).⁵

Exemples concrets de modèles 2026 (à copier-coller… mais avec discernement)

Je vous donne des exemples d’IDs/noms tels qu’ils apparaissent dans les docs — et je vous recommande de les considérer comme un “cheat sheet”, pas comme une vérité éternelle (les versions et deprecations bougent).

• OpenAI (texte + open weights + audio) : gpt-5.2, gpt-5-mini, gpt-5-nano, gpt-oss-120b, gpt-oss-20b, gpt-realtime-1.5, gpt-4o-mini-transcribe, gpt-4o-mini-tts.¹
• Anthropic : claude-opus-4-6 et claude-sonnet-4-6 (noms API cités dans les annonces 2026).²¹⁶
• Google : gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-2.5-pro, gemini-2.5-flash (et variantes preview/latest selon besoin).³¹⁷
• Mistral : Mistral Large 3 (open-weight), OCR 3 Premier, Voxtral (audio/transcription).⁴
• Meta (open weights) : Llama 4 Scout et Llama 4 Maverick (nativement multimodaux).⁵

2) VLM (vision-language) : images et mises en page “impossibles”

Le VLM est utile quand :

• vous avez des photos (dommages, produits),
• des captures d’écran,
• des formulaires tordus,
• ou des documents où l’OCR perd le contexte.

Mais attention : sur des PDF longs, l’OCR + LLM est souvent plus robuste et plus contrôlable (pages → texte → extraction). C’est une question de “contrôle industriel” : vous voulez des checkpoints.

3) OCR / Document Understanding : rendre le texte fiable

Vous avez 3 options réalistes :

1. Cloud OCR / doc AI : Textract, Document AI, Azure Document Intelligence.⁶⁷⁸
2. OCR orienté IA (ex. OCR 3 chez Mistral).⁴
3. Open source : Tesseract, PaddleOCR.⁹¹⁰

Choix guidé par :

• variabilité des documents,
• exigences de conformité/souveraineté,
• et coût total (API vs infra + ops).

4) STT : utile même pour un mailbot (notes vocales, omnicanal)

Si vous avez des fichiers audio entrants (ça arrive), ou si votre support devient omnicanal :

• Deepgram documente Nova-3 (STT) et ses évolutions.¹¹
• Whisper est une option open source populaire côté STT.¹²

5) TTS / S2S : surtout si vous unifiez mailbot + callbot

Un mailbot “pur” n’a pas besoin de TTS.

Mais les entreprises sérieuses finissent souvent par unifier :

• e-mail,
• chat,
• téléphone.

Dans ce cas :

• ElevenLabs documente ses modèles TTS (utile côté callbot/voice).¹³
• OpenAI documente la Realtime API pour des échanges audio low-latency (S2S / audio).¹⁴
• Google documente aussi la génération vocale/TTS via Gemini (selon modèles/disponibilités).¹⁵

RAG pour mailbots : votre antidote aux “réponses convaincantes… fausses”

Un mailbot sans RAG, c’est comme un agent support sans accès à la base de connaissances : il improvise.

Et les LLM improvisent très bien. C’est justement le problème.

Le Retrieval-Augmented Generation (RAG), dans un mailbot, sert à trois choses très concrètes :

1. Ancrer la réponse sur des sources (KB, procédures, politiques internes).
2. Limiter l’hallucination (“je vous confirme que…”) quand personne n’a confirmé.
3. Rendre auditables les décisions (“voici la règle / le paragraphe / la page”).

Checklist RAG (pratique, pas philosophique) :

• Versionnez vos sources (procédures qui changent, CGV qui évoluent).
• Stockez la “preuve” : quel document a été utilisé, quelle section, quel timestamp.
• Prévoyez le cas “KB vide” : si aucune source fiable n’est trouvée, le mailbot doit refuser, demander une clarification, ou escalader.
• Distinguez “information” vs “policy” : une KB répond, une policy décide (ex. “ne jamais promettre un remboursement sans validation”).

Router multi-modèle : la stratégie d’adulte (et le secret des stacks qui durent)

Vous n’avez pas besoin d’un seul modèle. Vous avez besoin d’une politique.

Dans une stack mailbot, un “router” est une brique qui choisit :

• quel modèle utiliser (gros / petit, commercial / open weights),
• quel mode (extraction structurée vs rédaction),
• et quand passer en HITL.

Exemples de routage utile :

• intent simple, faible risque → modèle rapide + template,
• extraction sur PDF scanné → OCR + modèle orienté extraction,
• email juridique → escalade + modèle plus conservateur + policy stricte,
• email “unknown intent” → draft + demande de clarification.

Le router vous donne aussi un superpouvoir opérationnel : le fallback.

Quand un fournisseur a un incident, vous ne “subissez” pas : vous basculez.

Coût et latence : comment éviter l’IA “qui marche”… mais qui ruine votre marge

Sur l’e-mail, la latence n’est pas aussi dramatique qu’au téléphone. Mais le coût, lui, peut l’être.

Les leviers simples (qui marchent vraiment) :

• Résumé de thread : ne repassez pas 12 messages dans le LLM à chaque fois.
• Déduplication : même contenu, même décision.
• Extraction d’abord, rédaction ensuite : JSON → réponse, pas l’inverse.
• Chunking pièces jointes : travail par pages/sections, avec early exit si info trouvée.
• Caching : FAQ et procédures stables ne doivent pas coûter des tokens à chaque mail.

Actions backoffice : patterns d’exécution (et pourquoi l’idempotency est non négociable)

Une action backoffice, ce n’est pas un texte. C’est un effet réel.

Donc vous avez besoin de garanties :

• idempotency key (même e-mail → même action),
• retries contrôlés (pas de doublons),
• audit logs (qui a fait quoi, quand, pourquoi),
• approvals sur actions sensibles (HITL ciblé, pas généralisé).

Le pattern que j’aime en mailbot :

1. le LLM propose (action + arguments),
2. le système valide (schéma + règles),
3. l’action s’exécute (ou se met en file de validation),
4. le mailbot répond avec un statut clair (“j’ai créé le ticket #…”, “je transmets à…”, “j’ai besoin de…”).

Évaluation : si vous ne testez pas, vous “espérez”

Le mailbot n’est pas un jeu. C’est un système qui touche au client.

Minimum viable evaluation :

• un set d’e-mails réels anonymisés (et représentatifs),
• des tests d’extraction (champs clés),
• des tests de routage (bon service, bon niveau N1/N2/HITL),
• et des tests de conformité (pas de promesses interdites, pas de PII en clair).

Et surtout : surveillez la dérive. Les intents changent. Les saisons changent. Le mailbot doit apprendre sans réécrire l’univers.

Open source vs commercial : comment décider sans se raconter d’histoires

Je vous propose un cadre simple : vous ne choisissez pas une techno, vous choisissez une contrainte dominante.

Si votre contrainte dominante est “time-to-value”

Le cloud gagne souvent :

• intégration rapide,
• qualité générale,
• maintenance déléguée.

Risques :

• dépendance fournisseur,
• coûts variables,
• parfois moins de contrôle fin.

Si votre contrainte dominante est “maîtrise” (coût/souveraineté/contrôle)

L’open source (ou l’on-prem) devient attractif :

• coûts prévisibles (si vous maîtrisez l’ops),
• contrôle des données,
• possibilité de tuning.

Risques :

• MLOps plus lourd,
• performance variable,
• besoin de vrais tests et monitoring.

Production : ce que vous devez ajouter au “schéma”

Si vous ne gardez qu’une idée : la stack n’est pas finie quand “ça répond”.

Elle est finie quand :

• elle tient la charge,
• elle se surveille,
• elle se dégrade proprement,
• et elle apprend.

1) Politique de risque (gating)

Définissez des classes :

• auto-send (faible risque),
• draft (validation),
• escalade (haut risque / incertitude).

2) Observabilité (sinon vous êtes aveugles)

Tracez, au minimum :

• latence par étape (OCR, LLM, outils),
• taux d’erreur,
• taux d’escalade,
• et dérive des intents (apparition de “nouveaux sujets”).

3) Gestion des clés API et anti-abus

La prod, c’est aussi l’opérationnel :

• rate limiting,
• budgets,
• rotation de clés,
• séparation des environnements.

Si je devais vous donner une recommandation (très pratique)

1. Commencez par un N1 robuste (classification + extraction + templates).
2. Ajoutez la brique pièces jointes (OCR, qualité, fallback).
3. Ensuite seulement : N2 (identité + backoffice), avec HITL strict.
4. Mesurez. Itérez. Ne fantasmez pas “l’autonomie”. Visez “la résolution”.