Construire des solutions vocales pour les marchés émergents a rapidement mis en lumière une réalité concrète : la qualité en production dépend de bien plus que du modèle ou du prompt.

Le chemin d'appel compte. Tout comme la latence de la boucle audio, l'adéquation de la voix, le contexte dont dispose l'agent, les outils qu'il peut invoquer en pleine conversation, et les contrôles dont les équipes ont besoin pour vérifier, sécuriser et déboguer le système après chaque interaction.

Chez AethexAI, nous concevons pour l'ensemble de cette surface. Nous hébergeons, entraînons et orchestrons la stack vocale en interne, afin que les équipes puissent déployer des agents vocaux rapides, conscients du contexte, adaptés localement et prêts pour la production dès le premier jour.

Aethex est le plan de contrôle (control plane) des agents vocaux pour les workflows des marchés émergents. Voici la surface que nous exposons aux développeurs :

1. Kora, notre famille de modèles de parole pour la reconnaissance vocale (speech-to-text) et la synthèse vocale (text-to-speech) en streaming.

2. L'API et le SDK Aethex, qui exposent les agents, les appels, les outils, les transcriptions, les bases de connaissances et l'usage sous forme de primitives programmables.

3. Le serveur MCP Aethex, qui rend cette même infrastructure accessible aux assistants IA via le Model Context Protocol.

Cet article parcourt cette stack et tout ce dont vous avez besoin en tant que développeur : comment la couche vocale se connecte au runtime de l'agent, comment un agent devient ancré dans le contexte et capable d'agir, comment les appels deviennent des conversations observables, et comment le modèle de sécurité maintient sûr un système capable de passer des appels et d'invoquer des outils.

Modèles et capacités vocales

À la base d'Aethex se trouve Kora, notre famille de modèles de parole. Nous reviendrons plus en détail sur le pipeline d'entraînement des modèles dans un prochain article.

• Kora Read alimente la reconnaissance vocale (STT, speech-to-text)

• Kora Speak alimente la synthèse vocale (TTS, text-to-speech)

Ensemble, ils fournissent la couche vocale de nos agents, ainsi que pour les développeurs qui souhaitent utiliser la parole directement via l'API.

Les capacités vocales fonctionnent de manière autonome. Vous pouvez synthétiser de l'audio à partir de texte, diffuser en streaming de l'audio généré pour une lecture en temps réel, transcrire de l'audio uploadé, prévisualiser des voix, consulter le catalogue et inspecter les modèles disponibles pour votre compte. Un workflow conversationnel utilise cette même couche vocale au sein d'un agent qui gère l'appel de bout en bout. Les mêmes primitives servent ces trois cas d'usage.

Les voix sont exposées comme des ressources dotées de métadonnées, afin de s'intégrer dans de véritables flux produit plutôt que d'être codées en dur. Filtrez le catalogue par langue, par prise en charge de style dialectal, par tag et par pays, et utilisez les tags de voix pour trouver des styles de diction et des personas métier tels que chaleureux, calme, professionnel, technique, orienté service ou digne de confiance.

Le modèle de raisonnement constitue l'étape configurable du flux d'appel. Un agent peut utiliser le modèle par défaut d'Aethex, colocalisé avec Kora Read et Kora Speak, ou bien fixer son comportement sur un modèle tiers d'un fournisseur tel qu'OpenAI, Anthropic ou Google. Dans tous les cas, la couche vocale, le comportement de l'agent, les outils, les connaissances et le cycle de vie de l'appel restent au sein d'une seule plateforme.

Les agents comme runtime déployable

L'objet principal dans Aethex est l'agent.

Un agent contient la configuration d'un workflow vocal en direct : nom, prompt système, premier message, voix, langue, style dialectal, modèle LLM, température, limites de durée, gestion des silences, comportement face aux interruptions, garde-fous, respect du script, paramètres d'enregistrement et de transcription, comportement face à la messagerie vocale, variables dynamiques, comportement de transfert, métadonnées, documents de base de connaissances, outils, et une URL de webhook.

from aethexai import AethexAI

client = AethexAI(api_key="ae_live_...")

agent = client.create_agent(

name="Collections agent",

system_prompt="Vérifiez l'identité de l'emprunteur avant de discuter du compte.",

first_message="Bonjour, ceci est un appel de courtoisie de la part de votre prêteur.",

voice_id="Aya",

language="french",

)

Une fois l'agent créé, il devient l'unité sur laquelle les équipes itèrent. Mettez à jour le prompt, changez la voix, modifiez le modèle LLM, attachez un document, enregistrez un outil, dupliquez l'agent pour un nouveau workflow, déclenchez un appel de test, inspectez la transcription, et faites passer la configuration en production derrière la bonne clé à portée restreinte (scoped key).

Un agent de recouvrement pourrait démarrer avec un script strict et un outil de vérification d'identité, puis ajouter une base de connaissances pour les plans de paiement. Un agent de support pourrait utiliser une voix plus chaleureuse, de la documentation produit, une recherche de commande et un chemin de transfert. Un agent d'enquête pourrait utiliser des réponses plus courtes, un respect du script plus rigoureux et des métadonnées structurées. Chaque workflow obtient sa propre configuration de runtime sans forcer les équipes à reconstruire la stack autour de lui.

Bases de connaissances pour des conversations ancrées dans le contexte

Les agents d'entreprise ont besoin des supports auxquels l'organisation fait déjà confiance : politiques produit, règles d'éligibilité, scripts de paiement, guides d'onboarding, consignes de clinique, mentions légales, playbooks de support et procédures d'escalade. Les bases de connaissances Aethex vous permettent d'attacher ce contexte directement à un agent.

L'API de base de connaissances prend en charge l'upload de fichiers et de documents texte, les uploads échelonnés (staged uploads), le traitement de documents, la consultation, le retraitement, la suppression, la récupération du texte intégral extrait, et les requêtes de récupération (retrieval) à des fins de débogage. Ce dernier point compte : avant qu'un agent passe en production, vous pouvez tester ce que la base de connaissances renvoie pour une question donnée et inspecter les fragments (chunks) dont l'agent disposerait pendant une conversation.

La voix change les attentes en matière de récupération. Dans une interface texte, une réponse lente peut être acceptable. Lors d'un appel, l'étape de récupération s'inscrit dans un tour de parole en direct, aux côtés du raisonnement et de la génération vocale ; l'agent doit donc trouver le contexte pertinent, produire une réponse et faire avancer la conversation sans laisser l'appelant dans le silence. Traiter les connaissances comme une partie du runtime de l'agent les rend également améliorables : mettez à jour le contenu source, retraitez un document, interrogez la base de connaissances, examinez les transcriptions, et décidez si l'agent a besoin d'un meilleur contexte, d'instructions plus précises ou d'un nouvel outil, sans reconstruire le prompt à partir de zéro.

Outils pour des actions en direct

Les outils connectent un agent à des systèmes externes pendant une conversation. Chaque outil possède un nom, une description, un schéma de paramètres et un endpoint. La description aide l'agent à déterminer quand l'outil est pertinent. Le schéma définit les informations requises pour l'appeler. L'endpoint relie la conversation au système du client.

client.add_agent_tool(

agent["id"],

name="verify_account",

description="Vérifier le compte d'un client par son identifiant avant de discuter des soldes.",

parameters={

"type": "object",

"properties": {"account_id": {"type": "string"}},

"required": ["account_id"],

},

endpoint_url="https://api.votrebanque.com/aethex/verify",

)

Un outil peut vérifier un compte, rechercher une commande, contrôler l'éligibilité, créer un ticket, mettre à jour un CRM, enregistrer une promesse de paiement, déclencher une notification ou planifier un rappel. L'agent maintient la conversation en mouvement pendant que le workflow interagit avec les systèmes où vit réellement le processus métier.

La validation autour des outils fait partie intégrante du produit. Les noms, schémas et URL des outils sont vérifiés au moment de leur création ou de leur mise à jour, et les endpoints doivent utiliser le HTTPS public ; les destinations privées, en boucle locale (loopback), avec identifiants embarqués ou non résolues sont rejetées. Cela maintient l'appel d'outils sur une surface d'intégration de niveau production, plutôt que sur une fonctionnalité de prompt non contrôlée.

L'exécution d'outils en direct ne tolère que peu de défaillances, et le runtime est conçu pour cela. Un endpoint lent devient une pause que l'appelant entend, un paramètre manquant devient une question de suivi, et une requête échouée devient une nouvelle tentative, une explication ou un transfert. L'appel n'est pas interrompu parce qu'un service externe a échoué. C'est cette couche qui transforme une interface conversationnelle en un système opérationnel.

Appels, conversations et enregistrements

Une fois un agent configuré, vous passez des appels via l'API. Nous prenons en charge les intégrations avec le trunking SIP en mode BYO, WebRTC, Twilio, avec d'autres intégrations à venir.

call = client.trigger_call(

    agent_id=agent["id"],

    to_number="+225...",

    from_number="+225...",

)

L'appel réunit toute la stack : modèles de parole, sélection de la voix, instructions de l'agent, paramètres du LLM, récupération des connaissances, exécution des outils, comportement d'appel, enregistrement, transcription, métadonnées, usage et permissions.

À la fin de l'appel, la plateforme conserve les artefacts dont les équipes ont besoin pour fonctionner. Inspectez le statut des appels, récupérez les conversations, accédez aux enregistrements, examinez les transcriptions, recherchez dans l'historique et comptabilisez l'usage. Une équipe QA construit des files de revue. Une équipe opérations recherche les abandons, les transferts, les appels d'outils échoués et les objections récurrentes. Un workflow de conformité conserve les enregistrements et transcriptions pour une revue ultérieure.

Pour relire les enregistrements dans une interface destinée au client, générez une URL signée à courte durée de vie, limitée à une seule conversation, et transmettez-la au navigateur ; elle expire rapidement, ne porte aucune autre autorité, et garde le chemin audio sous contrôle même lorsqu'il quitte votre serveur. Un appel de test isolé peut être jugé à l'oreille ; un déploiement en production nécessite des enregistrements structurés, et les appels deviennent des conversations que vous pouvez rechercher, auditer et relier à des systèmes internes.

Les workflows vocaux se poursuivent souvent après la fin de l'appel. Aethex envoie des webhooks sortants signés pour des événements tels que call.ended et recording.ready, de sorte que les équipes reçoivent les métadonnées d'appel, les transcriptions finales et les URL d'enregistrement sans avoir à interroger l'API en boucle (polling). Un appel de recouvrement terminé met à jour un tableau de bord interne. Une conversation de support entre dans une file QA. Un enregistrement est transféré vers le stockage dès l'arrivée de recording.ready. Une transcription déclenche des analyses, une notation (scoring) ou un suivi.

Comme ces événements touchent aux workflows des clients, ils sont signés en HMAC-SHA256 avec un secret de tenant que vous pouvez faire pivoter, afin que le système récepteur puisse vérifier qu'un rappel provient bien d'Aethex avant d'en accepter le contenu.

MCP pour un développement piloté par assistant

Le serveur MCP Aethex amène la même plateforme au sein des assistants IA via le Model Context Protocol, ce qui vous permet de travailler avec Aethex depuis Claude Code, Claude Desktop, Cursor, Codex, Windsurf et d'autres clients compatibles MCP.

claude mcp add aethex \

  --env AETHEX_API_KEY=votre-clé-api \

  -- uvx aethexai-mcp

Via MCP, un assistant peut consulter les voix, synthétiser de la parole, transcrire de l'audio, construire des agents, passer des appels et lire l'usage à travers l'API publique. Le serveur est distribué sous forme du paquet aethexai-mcp, s'exécute localement, se lance avec uvx et utilise la clé API fournie dans son environnement : il n'y a donc rien à héberger.

Le modèle de sécurité reste identique. Le serveur MCP hérite des portées (scopes) de la clé qu'il reçoit. Donnez-lui une clé en lecture seule et il pourra inspecter. Donnez-lui une clé de test et il pourra aider à construire. Gardez les appels de production derrière une clé distincte et l'assistant restera dans cette limite. Il recherche les véritables identifiants avant d'agir et confirme les actions sensibles telles que les suppressions, les annulations et les appels sortants avant de les exécuter.

Cela change la boucle de développement. Demandez à un assistant de créer un agent de test, d'attacher un document, d'enregistrer un outil, de passer un appel, de récupérer la transcription et de résumer ce qui a changé. L'API demeure la source de vérité. MCP devient une interface supplémentaire vers la même plateforme.

Assembler la stack

Aethex est organisé autour du cycle de vie d'un agent vocal de production. Commencez par la parole : générez de l'audio, transcrivez des enregistrements, inspectez les voix et choisissez le comportement du modèle. Configurez un agent avec la bonne voix, la bonne langue, les bonnes instructions, les garde-fous, les paramètres d'appel et les métadonnées appropriés. Attachez une base de connaissances pour que l'agent puisse répondre à partir du contexte métier. Ajoutez des outils pour qu'il puisse agir pendant la conversation. Passez des appels, capturez les enregistrements et transcriptions, recevez des webhooks signés, inspectez l'usage et contrôlez les accès avec des clés à portée restreinte. Amenez ce même workflow dans un assistant IA via MCP lorsque c'est le moyen le plus rapide de construire ou de tester.

Pour les marchés que sert Aethex, c'est l'ensemble de la stack qui compte. La topologie réseau influe sur la latence des tours de parole. La qualité de la voix influe sur la confiance. L'exécution des outils détermine si l'agent peut mener le workflow à son terme. Les bases de connaissances déterminent si les réponses sont ancrées dans le contexte. L'usage influe sur l'économie unitaire. La sécurité détermine si le système peut être déployé en toute sûreté au sein d'une entreprise. La surface développeur reflète ces contraintes : modèles, voix, agents, outils, bases de connaissances, numéros de téléphone, appels par téléphone et par navigateur, conversations, enregistrements, transcription, usage, limites de débit (rate limits), clés API, webhooks, SDK et MCP, le tout dans une seule plateforme.

Pour commencer

• Démarrage rapide : developers.aethexai.com/fr/docs/quickstart

• SDK Python : developers.aethexai.com/fr/docs/sdk

• Serveur MCP : developers.aethexai.com/fr/docs/mcp

• Référence de l'API : developers.aethexai.com/fr/docs/api-reference

• GitHub : github.com/aethexai

Vous construisez un projet qui a besoin de la voix pour fonctionner dans le monde réel ? Retrouvez-nous sur Discord ou @aethexailabs sur X !