Callbot open source 2026 : blueprint SIP + STT/TTS + LLM (self-hosted)

Open source, open-weight… et la nuance qui évite les conversations religieuses

Avant de parler architecture, clarifions un point :

• open source : code ouvert (et parfois modèles ouverts),
• open-weight : poids de modèles disponibles, mais pas forcément le dataset/pipeline complet.

Dans un callbot, la question pratique est :

Pouvez-vous héberger, gouverner, observer, et mettre à jour sans surprise ?

Si oui, vous avez “du contrôle”. Qu’on appelle ça open source ou open-weight, c’est secondaire.

Et si non, vous avez une démo auto‑hébergée. C’est une espèce rare, mais elle existe.

Le panorama “stack callbot 2026” (LLM/STT/TTS/S2S, open source vs cloud) est ici : Stack callbot 2026.

Blueprint : les 7 briques d’un callbot self-hosted

Un callbot “open source” solide ressemble à une chaîne :

1. Téléphonie (SIP/RTP)
2. Passerelle média (audio in/out, WebRTC si besoin)
3. Traitement audio (AEC/denoise/AGC)
4. STT streaming (transcription)
5. Orchestration (états + règles + outils)
6. LLM (décision)
7. TTS streaming (synthèse)

Et autour :

• observabilité,
• sécurité,
• conformité,
• et déploiement (scaling).

Si vous voulez la partie téléphonie détaillée : SIP/RTP/WebRTC pour callbot.

Téléphonie : SIP et RTP (les fondations)

SIP est normalisé dans l’IETF RFC 3261.¹

RTP (transport média) dans l’IETF RFC 3550.²

Vous n’avez pas besoin de lire ces RFCs pour écrire un callbot.

Mais c’est utile pour comprendre :

• ce qui est “signalisation” vs “média”,
• pourquoi certaines erreurs sont des timeouts,
• et pourquoi “ça marchait en labo” casse avec un trunk réel.

Asterisk (open source)

La documentation Asterisk décrit sa stack téléphonie et ses modules (PBX, dialplan, etc.).³

Un pattern courant :

• Asterisk gère la signalisation et le call control,
• votre application callbot gère la conversation,
• et vous reliez les deux via une passerelle média.

FreeSWITCH (open source)

FreeSWITCH fournit une autre stack téléphonie open source, largement utilisée comme softswitch.⁴

Choix Asterisk vs FreeSWITCH ?

Ce n’est pas une question “de goûts”. C’est :

• vos compétences internes,
• votre besoin de média/routing,
• et votre stratégie d’exploitation.

Passerelle média : là où l’audio devient “un produit”

Entre la téléphonie et votre IA, il y a un endroit où l’audio doit être :

• décodé,
• routé,
• parfois mixé,
• et instrumenté.

C’est votre passerelle média.

En inbound SIP/RTP, vous avez souvent un flux RTP.

Votre application callbot, elle, veut :

• un stream audio stable,
• un signal de référence pour l’AEC,
• et parfois un contrôle fin de la lecture (barge-in).

Donc vous finissez avec une architecture de type :

• PBX/softswitch (Asterisk/FreeSWITCH),
• media gateway (bridge RTP ↔ votre app),
• et votre engine STT/LLM/TTS.

Ce n’est pas glamour, mais c’est le point où :

• la latence se gagne,
• la qualité se gagne,
• et la prod se sauve.

Si vous voulez revoir la plomberie (SIP, RTP, WebRTC) avec des mots simples : SIP/RTP/WebRTC pour callbot.

Audio : AEC, denoise, AGC (la brique qui sauve vos KPI)

Dans un callbot, si l’audio est mauvais :

• le STT est mauvais,
• donc les décisions sont mauvaises,
• donc l’appel est long.

Avant de parler modèles, lisez : Audio callbot : AEC/denoise/AGC.

STT open source / open-weight : Whisper, Voxtral…

Whisper (open source)

Whisper est publié en open source (repo officiel).⁵

Avantages :

• contrôle (self-host),
• audit de pipeline,
• et options d’optimisation.

Inconvénients :

• exploitation GPU,
• latence/streaming selon votre implémentation,
• et maintenance.

Voxtral (open-weights Apache 2.0)

Mistral publie une model card Voxtral, et mentionne des open weights sous licence Apache 2.0 (selon variantes), ce qui en fait une option intéressante côté STT open-weight en 2026.⁶

Intérêt :

• self-host possible,
• options “realtime”,
• et une voie “souveraine” selon votre infra.

LLM open-weight : contrôle, coûts, gouvernance

Un callbot n’a pas besoin du modèle “le plus poète”.

Il a besoin d’un modèle qui :

• suit des règles,
• appelle des outils proprement,
• et reste stable (latence, versions).

Les familles open-weight (ex. Meta Llama 4, model card officielle) sont une option fréquente pour du self‑host quand on veut du contrôle.⁷

Et Mistral documente également son catalogue de modèles.⁸

Le plus important : isoler le modèle derrière une interface stable (contrat), pour pouvoir changer de modèle sans réécrire tout le callbot.

TTS open source : Piper, Coqui TTS

Piper est un projet open source utilisé pour de la TTS locale/edge (repo officiel).⁹

Coqui TTS est une boîte à outils open source pour la synthèse vocale (repo officiel).¹⁰

Dans un callbot, la TTS n’est pas un concours de voix.

C’est une interface :

• chiffres,
• pauses,
• barge-in,
• et latence.

Le meilleur conseil : choisissez une voix “assez bonne”, puis optimisez la conversation et l’architecture.

Scaling : le blueprint qui marche à 100 appels casse à 10 000 (si vous ne le préparez pas)

Self-host, c’est une promesse : “on contrôle”.

Mais le scale, lui, s’en fiche de la promesse.

À l’échelle, vous allez découvrir des réalités :

• la latence p95 n’est pas la latence “moyenne”,
• le GPU n’est pas un puits sans fond,
• et les retries coûtent du temps et de l’argent.

Quelques patterns de scale (pragmatiques) :

1) Découpler les maillons

Ne faites pas “un monolithe” qui :

• reçoit l’audio,
• transcrit,
• décide,
• synthétise,
• et transfère,

dans un seul process.

Découpler STT/LLM/TTS vous permet :

• d’absorber des pics,
• de mettre des files,
• et de remplacer une brique sans tout casser.

2) Cacher ce qui se répète

Beaucoup d’intents sont répétitifs (“horaires”, “suivi”).

Vous pouvez cacher :

• des réponses courtes,
• des résultats retrieval (RAG),
• et des prompts “squelettes”.

Le but est de réduire la charge, pas de faire “moins intelligent”.

3) Prévoir le fallback (et le tester)

Fallback STT (autre modèle), fallback TTS, escalade humaine.

Le plan B non testé est un plan imaginaire.

4) Mesurer (sinon, vous pilotez à l’oreille)

Vous devez instrumenter :

• latence p95 par maillon,
• taux d’erreur,
• et coût par appel.

L’article dédié : Observabilité callbot.

Orchestration : state machine + outils + guardrails

Le cœur du callbot, ce n’est pas le modèle.

C’est l’orchestration :

• états (où on en est),
• validations (champs critiques),
• actions (outils),
• et escalade (humain).

Le modèle peut aider, mais la structure doit être déterministe.

Pour la méthode “zone de confiance” : Guardrails callbot.

Observabilité : si vous ne pouvez pas expliquer, vous ne pouvez pas opérer

Self‑host = plus de contrôle.

Mais self‑host = aussi plus de responsabilité.

Donc, instrumentez dès le début :

• traces,
• métriques,
• logs structurés.

L’article dédié : Observabilité callbot.

Déploiement et mises à jour : versionner tout (sinon vous ne comprendrez rien)

Un callbot self-hosted a plus de contrôle… donc plus de variables :

• versions de modèles,
• versions de prompts,
• règles de routing,
• et politiques de guardrails.

Donc, versionnez :

• vos configurations,
• vos modèles,
• vos schémas d’événements,
• et vos déploiements.

La prod aime les changements contrôlés. Le big bang aime les post‑mortems.

Conformité : le self-host ne vous donne pas la conformité “gratuite”

On entend parfois :

“On self-host, donc c’est bon.”

Non.

Le self-host vous donne du contrôle sur la donnée.

Il ne vous donne pas automatiquement :

• les scripts de consentement,
• les politiques de rétention,
• les process d’effacement,
• et la documentation.

Pour la partie RGPD/voix : RGPD & callbots.

Sécurité : isolation, secrets, et “ne pas exposer le cerveau sur Internet”

Self‑host vous donne une liberté : vous contrôlez vos composants.

Mais ça signifie aussi : vous pouvez vous tromper vous‑même.

Quelques basiques de sécurité en callbot self-hosted :

• isoler les composants (STT/LLM/TTS) derrière des réseaux privés,
• gérer les secrets (rotation, vault),
• limiter les accès aux logs et aux transcriptions,
• et garder une zone de confiance (ce que le bot peut faire).

Un callbot est une surface de social engineering : quelqu’un peut essayer d’obtenir des infos, de forcer une action, ou de contourner une policy. Les principes et menaces sont détaillés ici : Sécurité callbot.

Et pour le côté “guardrails” (tool permissions, escalade) : Guardrails callbot.

RAG dans une stack open source : la base de connaissance doit être gouvernée

Open source ne veut pas dire “on peut indexer tout et n’importe quoi”.

Le RAG reste un système de vérité :

• quelles sources font autorité ?
• comment on versionne ?
• comment on purge ?

Dans une stack self-hosted, vous avez un avantage : vous pouvez garder le retrieval on‑prem.

Mais vous avez aussi un devoir : vous devez l’opérer.

Le pattern robuste :

• corpus “procédures” séparé des données client,
• retrieval instrumenté (retrieval vide, contradictions),
• et escalade quand l’info manque.

Pour une méthode complète RAG “voice-ready” : RAG pour callbot.

Open source vs cloud : un comparatif honnête

Hybride : self-host + cloud fallback (la stratégie réaliste)

Beaucoup d’équipes “open source” finissent… hybrides. Et c’est sain.

Exemples :

• self-host STT pour des raisons de données, mais fallback cloud si GPU saturé,
• self-host LLM pour le contrôle, mais cloud pour certains intents non sensibles,
• self-host TTS, mais voice vendor pour une langue rare au début.

L’hybride vous donne deux choses :

• un chemin de migration (vous n’êtes pas bloqué),
• et un plan B (les pannes arrivent).

La condition de succès : une interface stable entre briques (contrat), et une observabilité qui vous permet de voir quand vous basculez (et pourquoi).

Et surtout : testez vos bascules.

Une stratégie fallback non testée est une stratégie imaginaire. Faites des exercices simples :

• couper volontairement le STT principal,
• saturer un worker,
• simuler une latence réseau,
• et vérifier que le callbot escalade proprement au lieu de rester silencieux.

La prod ne vous jugera pas sur “l’élégance” du fallback. Elle vous jugera sur l’absence de panique.

Encore une fois : le self-host qui impressionne en démo n’a aucune valeur s’il s’écroule à 9h12. La stabilité est la feature la plus sous-cotée.

C’est ça, un callbot qui résout vite et tient bien la charge.

Le bon choix n’est pas “open source partout”.

Le bon choix est : “où est-ce que je veux du contrôle, et où est-ce que je veux du temps ?”

Construire un MVP open-source : méthode en 10 étapes

1

Définir un cas d’usage mesurable

Routage + un parcours niveau 1. Pas “tout le service client”.

2

Choisir la brique téléphonie (Asterisk ou FreeSWITCH)

Selon vos compétences internes et votre trunk.

3

Mettre une passerelle média

Audio in/out stable, et tests en 8 kHz téléphonie.

4

Ajouter audio processing (AEC/NS/AGC)

Sinon vous allez débugger du bruit pendant 3 mois.

5

Brancher un STT (Whisper ou Voxtral)

Streaming + endpointing, mesuré p95.

6

Brancher un LLM open-weight derrière une API interne

Interface stable, tool calling contrôlé.

7

Brancher une TTS (Piper/Coqui)

Court, clair, barge-in friendly.

8

Écrire l’orchestration (états + validations)

Confirmation chiffres/dates, escalade en doute.

9

Instrumenter (observabilité)

Logs/traces/métriques dès le début.

10

Go-live en rampe + rollback

La prod aime les paliers. Le big bang aime les post-mortems.

FAQ

Questions frequentes

Open source = moins cher ?+

Pas automatiquement. Vous économisez parfois sur le prix API, mais vous payez en infra GPU, en exploitation, en monitoring et en maintenance. À l’échelle, ça peut être excellent. À petite équipe, ça peut être coûteux.

Whisper suffit-il pour un callbot temps réel ?+

Ça dépend de votre implémentation (streaming, endpointing) et de vos contraintes de latence. Le point clé : tester sur audio téléphonie réel.

Voxtral est-il open source ?+

Voxtral est présenté comme open-weights (licence mentionnée dans la model card). Ce n’est pas toujours la même chose qu’open source, mais ça ouvre le self-host et le contrôle.⁶

Le plus gros piège du self-host callbot ?+

Sous-estimer l’exploitation : latence p95, pannes, scaling, et logs. La prod n’a pas de patience pour les systèmes fragiles.

Sources et references

1. [1]IETF, “RFC 3261 — SIP: Session Initiation Protocol”.
2. [2]IETF, “RFC 3550 — RTP: A Transport Protocol for Real-Time Applications”.
3. [3]Asterisk Documentation (index).
4. [4]FreeSWITCH Documentation (index).
5. [5]OpenAI, “Whisper” (repository).
6. [6]Mistral, “Voxtral model card” (open-weights, licence).
7. [7]Meta, “Llama 4 Model Card”.
8. [8]Mistral AI, “Models overview”.
9. [9]Piper (Rhasspy), repository GitHub.
10. [10]Coqui TTS, repository GitHub.