Stack multimodale 2026 : VLM, OCR, STT, TTS, S2S (agents)

Un agent multimodal, c’est un opérateur. Pas un gadget.

Vous avez déjà vu la démo :

“Regarde, il voit l’image, il lit le PDF, il répond à la voix.”

C’est impressionnant. Et c’est exactement là que la plupart des projets se plantent : ils confondent capacité et système.

Un agent multimodal, ce n’est pas un modèle “magique”. C’est un opérateur qui doit :

• recevoir des signaux (images, PDFs, audio),
• comprendre ce qu’il doit en faire,
• appeler des outils,
• garder un état,
• et produire une sortie fiable.

Donc la question n’est pas “quel VLM ?”. La question est : quelle chaîne, et à quel niveau vous voulez l’audit.

LLM/VLM 2026 : le paysage utile (sans religion)

En 2026, la plupart des “grands” modèles sont multi-capacités :

• texte (LLM),
• parfois image (VLM),
• parfois audio,
• et souvent tool calling.

Le point clé : ce ne sont pas les mêmes compromis.

Texte (LLM) : la décision et l’orchestration

Pour l’orchestration, vous regardez surtout :

• tool calling stable,
• robustesse sur votre langue,
• coût + latence,
• gouvernance (versions, logs).

Les fournisseurs publient des listes de modèles (ex. OpenAI “Models”, Anthropic “Models list”, Google “Gemini models”, Mistral “Models overview”).¹²³⁴

Shortlist 2026 (texte) : 3 profils de modèles, 3 usages

Je vous propose une façon pragmatique de raisonner : pas “le meilleur modèle”, mais “le bon profil”.

Profil 1 — le modèle “généraliste premium” (qualité + robustesse)
Utile quand vous avez des conversations complexes, des décisions nuancées, et une exigence de ton stable.

Vous retrouvez ce type de positionnement chez les modèles phares listés par les fournisseurs (OpenAI, Anthropic, Google, Mistral).¹²³⁴

Profil 2 — le modèle “fast/cheap” (latence + coût)
Utile pour router, reformater, extraire, résumer, ou pré-traiter.

En agentic, ces modèles sont souvent le secret de la rentabilité : vous ne payez un “gros” raisonnement que quand c’est nécessaire.

Profil 3 — l’open-weight (contrôle + isolation)
Utile quand vous devez héberger, isoler, ou optimiser le coût à grande échelle.

La model card de Llama 4 décrit un modèle open-weight, nativement multimodal (texte + image), ce qui le rend intéressant pour des stacks “on-prem / souveraineté”.⁶

La morale : en prod, vous choisirez rarement un seul modèle. Vous choisirez une équipe.

Image (VLM) : la perception (et parfois le piège)

Un VLM est utile quand :

• l’information est visuelle (photo, screenshot, schéma),
• la mise en page porte du sens (tableaux, formulaires, UI),
• vous devez comprendre une scène.

OpenAI documente des capacités “Vision” dans ses guides (images + compréhension).⁵

Et côté open-weight, la model card de Llama 4 décrit le modèle comme “nativement multimodal” (texte + image).⁶

VLM en prod : 3 tests qui évitent les mauvaises surprises

Avant de “valider” un VLM, testez-le sur trois catégories :

1. Screenshots d’UI : boutons, erreurs, états, menus.
   (C’est souvent votre futur agent “ops”, celui qui lit un écran ou un back-office.)
2. Tableaux et formulaires : extraction de champs, détection de cases cochées.
   Ici, un OCR structuré peut gagner.
3. Schémas / images ambiguës : un diagramme, un croquis, un scan dégradé.
   C’est l’endroit où la qualité “vision” se voit vraiment.

Et posez-vous la question de l’audit : comment prouver ce que le modèle a “vu” ?

Documents : OCR vs VLM vs hybride (le cas du PDF de 120 pages)

C’est ici qu’on gagne (ou qu’on perd) la confiance.

Parce que la plupart des entreprises ne manipulent pas “des images”. Elles manipulent des documents :

• contrats,
• avenants,
• justificatifs,
• formulaires,
• tableaux sur 40 pages.

Et là, votre agent doit être bon… à l’échelle.

Option A : VLM direct sur le document

Avantages :

• simplicité conceptuelle (“je lui donne le PDF, il comprend”),
• bonne compréhension de la mise en page,
• moins de composants à intégrer.

Limites fréquentes :

• coûts et latence (surtout sur des gros documents),
• difficulté à “pointer” une phrase exacte (audit),
• gestion multi-pages parfois délicate (context windows, pagination).

Option B : OCR dédié + LLM (le pattern qui tient)

Avantages :

• extraction structurée (texte, pages, positions),
• meilleure auditabilité (vous citez page/ligne),
• plus facile à chunker et à versionner,
• robustesse quand le document est énorme.

Exemples de briques OCR (2026) :

• Mistral documente OCR 3 dans sa liste de modèles.⁴
• Google Document AI propose des modèles OCR “Enterprise Document OCR”.⁷
• Amazon Textract extrait texte et structures depuis des documents.⁸
• Tesseract reste une référence open source pour l’OCR (self-host).⁹

OCR en prod : ce que vous devez tester (sinon vous vous mentez)

Un OCR, c’est un capteur. Et les capteurs mentent.

Testez :

• documents scannés vs natifs (vrai texte),
• langues et accents (FR, EN, mixtes),
• tableaux (colonnes qui sautent),
• “petite typo” (8pt, notes de bas de page),
• et le pire : des documents “moyennement” lisibles (photo de smartphone).

Et surtout : testez la stabilité. Un OCR qui change de comportement selon la qualité d’image peut casser vos règles métier.

Exemple de pipeline OCR + RAG (simple, mais solide)

1. OCR → texte + structure (pages, blocs, positions)
2. Chunking → segments versionnés (page 12, paragraphe 3)
3. Index → recherche (vector + keyword)
4. LLM → interprétation + décision, avec citations de chunks

Le bénéfice est moins “IA magique”. Il est plus prosaïque : vous pouvez expliquer et corriger.

Option C : Hybride (VLM pour comprendre, OCR pour prouver)

C’est souvent le meilleur des deux mondes.

Pattern typique :

1. OCR pour extraire un texte indexable (RAG / recherche / citations),
2. VLM pour comprendre un tableau tordu ou une capture illisible,
3. LLM pour prendre une décision et écrire un résultat.

Voix : STT + LLM + TTS vs Speech-to-Speech (S2S)

La voix, c’est la modalité où l’illusion de démo est la plus dangereuse.

Parce qu’une voix “wahou” sur 3 minutes ne dit rien de la prod.

Un bon callbot n’est pas celui qui impressionne. C’est celui qui :

• résout vite,
• transfère proprement,
• et survit à des millions d’appels sans devenir un incident.

Pipeline classique : STT → LLM → TTS

Avantages :

• audit (vous avez du texte),
• contrôle (vous pouvez filtrer, reformater),
• monitoring plus simple.

Exemples (2026) :

• OpenAI documente des familles “Transcribe” et “TTS”.¹⁰
• Mistral documente Voxtral Mini Transcribe et Voxtral Mini Transcribe Realtime (transcription).⁴
• Deepgram documente Nova-3 (changelog et docs).¹¹
• ElevenLabs documente ses modèles voix (TTS) et speech recognition (Scribe).¹²
• Google Cloud documente Speech-to-Text et un guide de sélection de modèles.¹³
• AWS documente la transcription streaming (Amazon Transcribe).¹⁴

STT/TTS en prod : 6 points qui font la différence

1. End-of-turn / endpointing : quand est-ce que l’utilisateur a fini ?
   C’est la source #1 de “callbot qui coupe la parole” ou “callbot qui attend trop”.
2. Barge-in : est-ce que la voix s’interrompt proprement ?
   La voix “wahou” qui ne sait pas s’arrêter est une voix inutile.
3. Qualité téléphonie : 8 kHz, bruit, chevauchements.
   Ce n’est pas YouTube. Ce n’est pas un studio.
4. Noms propres : clients, villes, références.
   Ici, le “context biasing” et les lexiques font gagner.
5. Chiffres et formats : dates, montants, IBAN, immatriculations.
   Si votre TTS lit “deux zéro deux six” au lieu de “vingt vingt-six”, vous perdez la confiance.
6. Observabilité : vous devez pouvoir écouter, transcrire, et rejouer.

Si la voix est un gros sujet chez vous, vous pouvez aussi croiser avec notre article callbot “terrain” : Stack callbot 2026.

Speech-to-Speech : la promesse (et le coût caché)

Le S2S, c’est séduisant : audio in → audio out.

OpenAI décrit une Realtime API pour des échanges audio à faible latence (WebRTC/WebSocket).¹⁵

Google documente aussi une Live API (Gemini) pour des expériences temps réel.¹⁶

Ce que ça peut améliorer :

• latence perçue,
• tours de parole plus naturels,
• moins de “silences morts”.

Ce que ça complique :

• audit (pas toujours de texte intermédiaire clair),
• garde-fous (où filtrez-vous ?),
• conformité (où logguez-vous ?),
• debugging (“pourquoi il a dit ça ?”).

Quand le S2S est une mauvaise idée (au début)

Si vous démarrez, évitez souvent le S2S quand :

• vous devez archiver un texte “verbatim” pour audit,
• vous avez des contraintes fortes de conformité (filtrage, redaction),
• vous voulez itérer vite sur des règles (dates, montants, consentements),
• ou vous n’avez pas encore une observabilité solide.

Le S2S peut être une optimisation. Mais optimiser un système pas encore maîtrisé, c’est accélérer vers le mur.

Commencez par un pipeline auditable, puis optimisez quand vous mesurez réellement.

Open source vs cloud : une matrice utile (par modalité)

Je vous propose une matrice très simple. Pas parfaite. Mais actionnable.

Les modèles et services évoluent vite : gardez ce tableau comme une grille, pas comme une vérité gravée.

Open source vs open-weight : un mot qui change la discussion

Dans le monde LLM, beaucoup de modèles sont “open-weight” : les poids sont publiés, mais pas forcément tout le pipeline (données, recette, etc.).

Ce que ça change en entreprise :

• vous pouvez héberger (contrôle),
• vous pouvez isoler (données),
• mais vous devez assumer l’exploitation (GPU, scaling, patching).

Donc la question n’est pas “open source ou pas”. La question est : qui porte l’astreinte ?

Checklist : choisir votre stack multimodale sans vous mentir

1

Définissez la preuve attendue

Besoin d’audit ? Alors vous devez pouvoir citer une page, une phrase, un log d’outil. Ça influence OCR vs VLM, et STT→texte vs S2S.

2

Mesurez la latence perçue (pas la latence moyenne)

En voix, le P95/P99 compte plus que la moyenne. Si vous ne mesurez pas, vous faites de l’art, pas un service.

3

Séparez extraction et décision

OCR/STT extraient. Le LLM décide. Mélanger les deux peut marcher… jusqu’à ce que vous deviez expliquer.

4

Préparez une stratégie d’échec

Documents illisibles, audio bruité, API down : votre agent doit savoir escalader et tracer.

5

Bench sur vos données, pas sur Internet

Vos PDF, vos accents, vos formulaires. Sinon vous optimisez pour un dataset imaginaire.

FAQ

Questions frequentes

Pourquoi ne pas faire VLM partout ?+

Parce que la prod n’est pas une démo. VLM partout peut coûter cher, ralentir, et compliquer l’audit. Sur du document long, OCR + LLM est souvent plus gouvernable.

S2S est-il obligatoire pour un callbot moderne ?+

Non. Beaucoup de callbots solides restent en STT→LLM→TTS pour garder l’audit et le contrôle. Le S2S devient intéressant quand la latence est critique et que vous avez les garde-fous.

Open source pour la voix : bonne idée ?+

Oui si vous assumez l’exploitation (GPU, scaling, monitoring). Whisper, Vosk, Piper et Coqui existent. L’arbitrage se fait sur vos contraintes de données et de coût.

Sources et references

1. [1]OpenAI, “Models”.
2. [2]Anthropic, “Models list”.
3. [3]Google, “Gemini models”.
4. [4]Mistral AI, “Models overview” (incl. multimodal, OCR, Voxtral).
5. [5]OpenAI, “Vision” (guide).
6. [6]Meta, “Llama 4 Model Card” (multimodal).
7. [7]Google Cloud, “Document AI - Enterprise Document OCR”.
8. [8]AWS, “Amazon Textract”.
9. [9]Tesseract OCR (GitHub).
10. [10]OpenAI, “Audio / Transcribe / TTS / Realtime models” (changelog).
11. [11]Deepgram, “Nova-3” (changelog).
12. [12]ElevenLabs, “Models” (TTS + Scribe).
13. [13]Google Cloud, “Speech-to-Text - Model selection”.
14. [14]AWS, “Amazon Transcribe - Streaming”.
15. [15]OpenAI, “Realtime API”.
16. [16]Google, “Live API” (Gemini).
17. [17]OpenAI, “Whisper” (open source).
18. [18]Vosk (STT open source).
19. [19]Piper TTS (open source).
20. [20]Coqui TTS (open source).