Gemini 3.8 Live ou Extended Thinking dans Famulor ?

Le 15 septembre 2026, Google a introduit deux nouveaux modèles de synthèse vocale : Gemini 3.8 Live pour des dialogues fluides à faible latence et Gemini 3.8 Live Extended Thinking pour des tâches plus complexes et multi-étapes. Selon le journal des modifications de Famulor daté du 17 septembre 2026, les deux modèles font désormais partie de la sélection de modèles Realtime de Famulor.

La question pertinente n'est pas de savoir quel modèle est universellement « meilleur ». Il s'agit plutôt de déterminer : Quel type de délai et d'échec est le moins acceptable dans votre appel ? Un raisonnement supplémentaire peut inutilement ralentir un flux de qualification de rendez-vous court. À l'inverse, dans un processus de reprogrammation complexe impliquant des règles et des appels d'outils, un manque de raisonnement peut accroître les risques d'erreurs.

Points clés à retenir

• Gemini 3.8 Live est le point de départ idéal pour des échanges rapides et fréquents.
• Extended Thinking doit être réservé aux tests impliquant des tâches réellement multi-étapes, et non utilisé par défaut pour chaque appel.
• Famulor précise que la sélection manuelle du modèle est visible avec l'extension Fallbacks & Guardrails ; sinon, Famulor utilise sa sélection automatique recommandée.
• Prenez vos décisions sur la base de tests identiques via le canal téléphonique réel, et non uniquement sur les benchmarks des fournisseurs.

Quoi de neuf avec Gemini 3.8 Live ?

L'annonce de Google du 15 septembre 2026 décrit les deux modèles comme des solutions natives Live qui traitent la parole directement et peuvent exécuter des outils de manière asynchrone pendant la conversation. Google positionne le modèle standard pour la mise à l'échelle et la fluidité des dialogues, tandis qu'Extended Thinking ajoute un raisonnement en arrière-plan pour les tâches complexes.

Les pages techniques des modèles tracent une frontière plus claire :

• Gemini 3.8 Live est la recommandation par défaut de Google pour des expériences d'agent vocal à faible latence, sans délais induits par le raisonnement. Il prend en charge l'appel de fonctions asynchrone et le raisonnement entrelacé.
• Gemini 3.8 Live Extended Thinking cible les tâches complexes à étapes multiples nécessitant un raisonnement approfondi. Google note également que le traitement asynchrone peut se poursuivre au-delà de ce qui semble être la fin d'un tour de parole.

Il s'agit de descriptions de produits Google, et non de preuves de performance indépendantes pour votre cas d'usage téléphonique. Les résultats de benchmarks publiés par Google n'ont pas été mesurés avec votre numéro de téléphone, votre prompt, vos outils ou vos profils d'appelants. Ils peuvent orienter une hypothèse de test, mais ne doivent pas remplacer un test d'acceptation en production.

Comment les modèles sont-ils exposés dans Famulor ?

Famulor décrit Realtime comme un mode moteur dans lequel un modèle écoute et parle. Selon la documentation actuelle sur les Modèles & Voix, Famulor sélectionne les modèles utilisés par défaut. Un catalogue de modèles compatibles devient visible, et la sélection manuelle devient disponible, lorsque Fallbacks & Guardrails est inclus dans l'espace de travail actif.

L'entrée du journal des modifications de Gemini 3.8 souligne quatre points pratiques :

1. Les deux variantes 3.8 Live font partie de la sélection Realtime.
2. Sans l'extension, Famulor conserve sa sélection automatique recommandée.
3. Extended Thinking peut aider pour les questions exigeantes, mais peut sembler plus lent.
4. Les améliorations de Realtime couvrent également l'exécution des outils, les fins de mots complètes et les périodes de silence audio.

Vérifiez toujours la disponibilité réelle dans l'espace de travail actif sous Paramètres → Plan. Cet article ne garantit pas un droit d'accès spécifique ou une disponibilité permanente des modèles.

Quand Gemini 3.8 Live est-il le meilleur point de départ ?

Commencez par Gemini 3.8 Live lorsque l'appel consiste en des décisions courtes et répétitives où le rythme conversationnel est primordial. Les exemples typiques incluent :

• les horaires d'ouverture, les vérifications de statut et les FAQ simples ;
• la qualification de leads avec quelques critères clairs ;
• les demandes de rendez-vous avec un nombre limité de champs requis ;
• le routage par intention, langue ou localisation ;
• les appels d'outils courts dont les résultats peuvent être confirmés immédiatement.

« Rapide » ne doit pas être transformé en un seuil arbitraire en millisecondes. Ce qui compte, c'est que l'expérience semble naturelle aux appelants : l'assistant reconnaît-il la demande assez tôt, évite-t-il de couper la parole et reste-t-il clair après un appel d'outil ?

Le modèle standard est également judicieux lorsque les cas complexes sont transférés à un humain ou à un assistant spécialisé. Dans cette conception, chaque appel simple n'a pas à supporter le coût d'un raisonnement approfondi.

Quand devriez-vous tester Extended Thinking ?

Extended Thinking mérite un parcours de test distinct lorsque plusieurs étapes dépendent les unes des autres et qu'une décision intermédiaire prématurée serait coûteuse ou difficile à corriger. Les exemples incluent :

• la reprogrammation combinant disponibilité, règles tarifaires et contraintes client ;
• un cas de service avec questions diagnostiques, récupération de connaissances et création de ticket ;
• une offre de reconquête avec exclusions et règles d'approbation ;
• un flux de réservation avec plusieurs appels d'outils asynchrones ;
• un processus dans lequel l'assistant doit expliquer la progression pendant que le travail en arrière-plan se poursuit.

Davantage de raisonnement ne signifie pas une autonomie illimitée. Continuez à définir explicitement les outils autorisés, les confirmations obligatoires, les conditions d'arrêt et les transferts. Les paiements, les modifications de contrat, les informations médicales et autres actions conséquentes doivent conserver une confirmation appropriée ou une approbation humaine dans le flux de travail.

Matrice de décision : flux conversationnel ou profondeur de raisonnement ?

Cette matrice est un point de départ, pas un classement de fournisseur. Si votre scénario se situe dans les deux colonnes, divisez le flux : acheminez les demandes simples via le chemin rapide et les demandes complexes via un chemin délimité avec plus de raisonnement ou un transfert humain.

Comment effectuer un test A/B équitable dans Famulor

1. Maintenez la conception de la conversation constante

Utilisez le même prompt système, les mêmes outils, sources de connaissances, voix et intentions de test pour les deux variantes. Ne modifiez que la sélection du modèle. Sinon, vous ne pourrez pas attribuer de manière fiable une amélioration.

L'aperçu actuel du mode moteur de Famulor marque également une limite importante : Realtime expose moins de contrôles au niveau des composants qu'un pipeline composé de STT, LLM et TTS. Si vous avez besoin d'une marque spécifique ou d'une voix clonée, vérifiez d'abord que Realtime est l'architecture appropriée. Famulor dispose déjà d'un guide sur l'architecture Realtime versus pipeline ; cet article se concentre uniquement sur le choix entre les nouveaux modèles Gemini 3.8 Live.

2. Définissez une suite de tests restreinte et exigeante

Ne testez pas uniquement le chemin idéal. Une suite utile comprend au moins :

• une demande simple sans outil ;
• un appel d'outil réussi ;
• un appel d'outil lent ou ayant échoué ;
• une correction de l'appelant au milieu du processus ;
• un détail ambigu ;
• une demande en dehors des actions autorisées ;
• un transfert humain ;
• un appel répété avec une intention similaire mais non identique.

Évaluez séparément l'achèvement de la tâche, la précision des données capturées, la séquence des outils, le flux conversationnel, la gestion des interruptions et la qualité du transfert. Évitez de les fusionner en une seule moyenne trop tôt.

3. Testez via le canal téléphonique réel

Les démos sur navigateur et les enregistrements des fournisseurs ne montrent pas comment votre assistant se comporte sur différents numéros de téléphone, réseaux et appareils réels. Répétez les mêmes cas avec des téléphones portables typiques, du bruit de fond, des débits de parole et des accents variés. Enregistrez les échecs observables tels que « outil déclenché deux fois », « correction ignorée » ou « long silence avant confirmation ».

4. Fixez des règles d'arrêt et d'acceptation à l'avance

Un modèle ne devrait pas gagner parce qu'un appel impressionnant semble inhabituellement bon. Définissez les échecs P0 avant les tests, tels que des actions conséquentes non confirmées, des paramètres d'outils erronés, des données manquantes ou un transfert échoué. Un seul P0 ne devrait pas être compensé par une prosodie fluide.

Exemple pratique : reprogrammation de rendez-vous de service

Une entreprise de services souhaite automatiser les appels entrants de reprogrammation. L'assistant doit capturer le numéro de bon de travail, récupérer le rendez-vous existant, vérifier les créneaux disponibles, prendre en compte la couverture des techniciens et créer la nouvelle réservation uniquement après confirmation explicite.

Pour le cas simple — un numéro de commande valide, un créneau disponible et une confirmation immédiate — Gemini 3.8 Live est un point de départ plausible. La conversation doit rester courte et le résultat de l'outil doit être confirmé directement.

Pour le cas difficile — plusieurs commandes, une adresse ambiguë, deux recherches de calendrier et une règle tarifaire — l'équipe teste Extended Thinking. L'assistant peut annoncer les étapes intermédiaires, mais il doit résumer la date, l'heure et la commande avant d'effectuer un changement. Si une règle ne peut être résolue avec certitude, il transfère l'appel au lieu de deviner.

Ce test ne suppose pas qu'Extended Thinking complète automatiquement plus de reprogrammations correctement. Il vérifie si l'architecture de raisonnement ajoutée produit moins d'échecs de processus dans ce flux de travail défini sans ralentir la conversation au-delà d'un niveau acceptable.

Que signale la communauté des praticiens ?

Signal de la communauté, pas preuve produit : Dans un post Show HN daté du 10 septembre 2026, des développeurs d'IA vocale affirment que des appels de test manuels répétés et des cas de production inattendus les ont motivés à construire une plateforme de simulation. Le fil de discussion a eu un engagement limité lors de sa consultation. Cela ne prouve ni l'efficacité du projet ni la qualité d'un modèle, mais cela soutient une question de test utile : un bon appel de démonstration suffit-il, ou le flux de travail est-il stable à travers de nombreux scénarios reproductibles ?

La distinction est délibérée : Google et Famulor soutiennent des affirmations sur les fonctionnalités et la disponibilité des produits. Hacker News fournit un signal de praticien sur une préoccupation opérationnelle. Cela ne peut remplacer la documentation officielle ou votre propre évaluation.

Quelles limites devez-vous documenter avant le déploiement ?

• Pas de transfert de benchmark : Les scores de Google ne sont pas automatiquement vos résultats en production.
• Pas de garantie de disponibilité : Les plans, catalogues et la sélection automatique peuvent changer ; vérifiez l'espace de travail actif.
• Pas de conformité automatique : Le choix du modèle n'établit pas la permissibilité légale et ne remplace pas les examens de confidentialité, d'enregistrement et de consentement.
• Pas d'autonomie illimitée : Les autorisations d'outils, les confirmations et les transferts restent des décisions de conception.
• Pas de test unique : Les modifications apportées aux prompts, outils, connaissances ou modèles nécessitent des tests de régression.
• Pas de substitut à la sélection d'architecture : Si une voix TTS spécifique ou un contrôle au niveau des composants est obligatoire, le pipeline ou le half-cascade peut être plus approprié.

Conclusion : Choisissez selon le profil de la tâche, pas le nom du modèle

Gemini 3.8 Live est le point de départ logique pour des conversations en temps réel fluides et fréquentes. Extended Thinking est une option ciblée lorsque le raisonnement multi-étapes et les outils asynchrones peuvent apporter un réel avantage au processus. « Plus de réflexion » n'est pas une amélioration de qualité universelle ; elle doit être mise en balance avec le flux conversationnel, les modes d'échec et les besoins d'escalade.

La décision la plus claire provient d'une comparaison contrôlée avec le même prompt, les mêmes outils et des scénarios téléphoniques reproductibles. Seule une variante qui réussit vos portes de qualité prédéfinies dans votre propre flux de travail devrait atteindre le trafic de production.

Testez les deux variantes Realtime avec la même suite d'appels

Vérifiez d'abord si la sélection manuelle du modèle est disponible dans votre espace de travail Famulor. Ensuite, construisez un chemin simple et un chemin complexe et comparez les deux variantes via des appels de test réels. Commencez par la documentation Realtime de Famulor.

FAQ sur Gemini 3.8 Live dans Famulor

Chaque espace de travail Famulor peut-il sélectionner Gemini 3.8 Live manuellement ?

Non. Famulor indique que la sélection du modèle est visible lorsque Fallbacks & Guardrails est inclus dans l'espace de travail actif. Sans l'extension, Famulor utilise sa sélection automatique recommandée. Vérifiez le plan actuel dans votre espace de travail.

Extended Thinking est-il toujours plus précis ?

Cela ne peut être affirmé universellement. Google le positionne pour des tâches complexes à étapes multiples. La question de savoir s'il rend votre flux de travail plus fiable doit être testée avec des scénarios, outils et critères d'acceptation identiques.

Quel modèle dois-je utiliser pour une qualification de rendez-vous simple ?

Gemini 3.8 Live est le point de départ naturel lorsque vous capturez quelques champs et confirmez des appels d'outils courts. Testez tout de même les interruptions, les corrections et les échecs d'outils via le canal téléphonique réel.

Quand dois-je tester Extended Thinking ?

Lorsque plusieurs règles, recherches ou outils dépendent les uns des autres et qu'une mauvaise décision intermédiaire serait difficile à corriger. Continuez à définir des confirmations, des limites et des transferts clairs.

Realtime remplace-t-il un pipeline STT-LLM-TTS ?

Pas pour tous les cas d'usage. Realtime fournit un chemin de conversation intégré avec moins de contrôles au niveau des composants. Si vous devez contrôler les composants ou une voix TTS spécifique séparément, évaluez le pipeline ou le half-cascade.

Un appel de test réussi suffit-il pour le déploiement ?

Non. Utilisez des cas normaux, d'échec et limites reproductibles, testez les conditions téléphoniques réelles et répétez la suite après des changements pertinents.