Le 7 mai 2026, OpenAI a lancé GPT-Realtime-2 avec un raisonnement de classe GPT-5. Quelques jours plus tard, ElevenLabs a ajouté discrètement un champ visited_agents à sa réponse de conversation : un tableau qui suit, agent par agent, quels agents IA ont participé à un même appel.
Personne n'en a beaucoup parlé. Pourtant, c'est probablement le changement de design le plus important pour les agents IA vocaux depuis dix-huit mois.
Pourquoi? Parce qu'il officialise une idée que les meilleurs intégrateurs murmuraient depuis le début de l'année : votre PME au Québec n'a peut-être pas besoin d'un agent IA vocal. Elle a peut-être besoin de plusieurs, qui se parlent, se relaient et se spécialisent.
Ou pas. Et c'est exactement la question qu'on traite ici.
Ce qui se cache derrière le mot « multi-agents »
Un agent vocal monolithique fait tout : il répond, qualifie, prend rendez-vous, transfère, recueille des paiements, parle anglais et français, gère votre Google Calendar. Un seul cerveau. Un seul prompt. Une seule personnalité.
Une architecture multi-agents éclate ce cerveau en plusieurs spécialistes :
- L'accueil — qualifie l'appelant en 15 secondes et route.
- La prise de rendez-vous — connaît votre calendrier, vos services, vos durées.
- Le SAV / facturation — accède au CRM, aux factures, aux dossiers clients.
- Le transfert intelligent — passe la main à un humain avec le contexte complet.
Chaque agent a son propre prompt, sa propre voix (optionnel), ses propres outils. Ils se passent l'appel comme on se passe une perche, en transmettant l'historique de la conversation.
Vu de l'appelant, c'est un service. Vu de l'intérieur, c'est une équipe.
Les chiffres qu'il faut connaître avant de décider
Le débat « un seul agent vs plusieurs » n'est pas philosophique. Il est mesurable. Les benchmarks publiés en début d'année par Innervation AI sur les architectures multi-agents en 2026 donnent une vue assez claire :
- +23 % de précision sur les tâches qui demandent du raisonnement complexe quand on passe au multi-agents.
- 15× plus de tokens consommés. Oui, vous lisez bien. Multipliez votre coût LLM par quinze pour des conversations équivalentes en longueur.
- −39 à −70 % de performance sur les tâches qui demandent un raisonnement séquentiel strict — exactement le type de tâche d'une prise de rendez-vous étape par étape.
- 200 ms de surcoût de coordination à 5 agents. À 50 agents, on dépasse 2 secondes. Sachant qu'au téléphone, vous avez déjà la règle des 800 ms de latence à respecter avant que l'appelant ne raccroche, ce détail n'est pas un détail.
- Anthropic, sur ses propres tests internes, observe +90,2 % d'amélioration avec un design « lead-agent + helpers » sur des tâches de recherche distribuée.
- Sans orchestrateur central, les erreurs se propagent par un facteur de 17,2×. Avec un orchestrateur, on tombe à 4,4×. La fiabilité est une décision d'architecture, pas une chance.
Traduit pour une PME québécoise : multi-agents coûte cher, ralentit parfois, et améliore surtout les cas où il y a vraiment plusieurs « domaines » à couvrir. Ce n'est pas magique. C'est un compromis.
La règle des trois domaines
Voici la règle qu'on utilise chez TECHMA avec nos clients PME au Québec, dérivée des recommandations de plusieurs équipes de recherche :
Qu'est-ce qu'un « domaine fonctionnel »? Un bloc de connaissance qui demande son propre vocabulaire, ses propres règles métier, son propre outil externe. Exemples :
- Prise de rendez-vous (avec accès au calendrier)
- Renseignement sur les produits / services
- Support technique de premier niveau
- Suivi de commande ou de livraison
- Réclamation / litige
- Pré-qualification commerciale
Une clinique dentaire avec un seul service (rendez-vous) reste largement dans le « un seul agent ». Un concessionnaire automobile qui doit gérer ventes, après-vente, pièces, financement et collision — cinq domaines — bascule vers le multi-agents.
Trois scénarios concrets de PME québécoises
Scénario 1 : Le salon de coiffure indépendant (1 succursale, 8 employés)
Volume : ~80 appels/semaine. Tâches : prendre rendez-vous, donner les prix, gérer les annulations.
Verdict : agent unique. Un seul domaine fonctionnel (prise de rendez-vous), un seul outil externe (le calendrier en ligne), pas de bilingue lourd. Le multi-agents introduirait du coût et de la latence sans bénéfice mesurable. C'est exactement le type de cas où, à plus de 45 % de précision sur agent unique, ajouter des agents donne un rendement négatif.
Scénario 2 : La franchise de restaurants (4 succursales, livraison + sur place)
Volume : ~600 appels/semaine. Tâches : réservation, commande à emporter, modification de commande, suivi de livreur, plaintes, questions sur les allergènes, bilingue obligatoire.
Verdict : architecture multi-agents légère. Deux ou trois agents — accueil, prise de commande, transfert humain — avec un orchestrateur central. C'est la zone grise où la calcul du ROI départage : si les revenus mensuels sauvés dépassent le surcoût en tokens et en setup, le multi-agents paie. Sinon, agent unique amélioré reste plus prudent.
Scénario 3 : Le concessionnaire automobile (1 succursale, 5 départements)
Volume : ~400 appels/semaine. Tâches : ventes neuf, ventes occasion, service après-vente, pièces, carrosserie, financement, plus les appels d'urgence pneus à l'automne.
Verdict : multi-agents net. Cinq à six domaines, chacun avec ses propres données, ses propres horaires, ses propres scripts. Un agent monolithique devient ingérable : son prompt explose en longueur, il se trompe de département, il oublie le contexte. Le multi-agents redevient l'architecture la plus simple à maintenir, même si elle coûte plus cher à opérer.
Pourquoi 2026 change la donne (et pas avant)
Trois choses se sont alignées dans les six derniers mois :
1. Le raisonnement est devenu suffisamment rapide. Avec GPT-Realtime-2 d'OpenAI, un agent peut raisonner « comme un GPT-5 » sans casser le tempo de la conversation. Avant, un agent qui devait décider « est-ce que je transfère à mon collègue agent? » bouffait 1,5 seconde de silence. Aujourd'hui, c'est instantané.
2. Les plateformes ont rattrapé. ElevenLabs a ajouté en mai un suivi des « visited_agents » dans ses conversations, ce qui permet enfin de débugger qui a fait quoi pendant un appel. C'est petit comme changelog, mais énorme pour qui opère plusieurs agents. La trace est dans le changelog ElevenLabs. OpenAI, de son côté, pousse son Agents SDK avec gestion native des handoffs — visible dans l'annonce OpenAI sur gpt-realtime.
3. Le coût des LLM a baissé assez pour absorber les 15× du multi-agents sur des PME qui font de gros volumes. Ce qui aurait coûté 800 $ par mois en 2024 en coûte 90 aujourd'hui pour un volume équivalent. Le calcul ROI bascule.
Les pièges qu'on voit le plus souvent
Le piège du « plus c'est mieux ». Certains intégrateurs vendent du multi-agents à des dentistes solo parce que ça impressionne en démo. C'est de l'overkill. Plus de complexité, plus de points de panne, plus de débogage. Si votre menu vocal traditionnel tenait sur trois options, vous n'avez probablement pas besoin de cinq agents IA.
Le piège de la latence cachée. Chaque transfert d'agent à agent ajoute entre 150 et 400 ms si c'est bien conçu. Sur trois transferts, vous mangez votre budget de 800 ms. À 1,2 seconde de silence entre deux phrases, l'appelant pense que la ligne est coupée.
Le piège de l'observabilité. Quand un appel échoue dans un système multi-agents, savoir « lequel » a planté est non trivial. Sans tableau de bord qui trace les handoffs (et c'est précisément ce que le nouveau champ visited_agents d'ElevenLabs apporte), vous serez aveugle. Prévoyez l'outillage avant le déploiement, pas après.
Le piège de la gouvernance. Plus d'agents = plus de prompts à maintenir = plus de versions à gérer. Une mise à jour de prix doit-elle se propager à tous les agents? Comment? Qui valide? Si vous n'avez pas de réponse claire à ces questions, restez sur un agent unique encore six mois.
Comment on conçoit ça chez TECHMA pour les PME du Québec
Notre équipe gère intégralement la mise en place — pas de configuration en libre-service à faire vous-même. Concrètement, pour une PME qui envisage le multi-agents, on fonctionne ainsi :
D'abord, on cartographie les vrais domaines fonctionnels en écoutant 30 à 50 appels réels. Pas en imaginant. Trois fois sur quatre, ce qu'un client pense avoir comme « cinq services différents » est en réalité trois domaines plus deux variantes du même.
Ensuite, on décide de l'architecture : agent unique enrichi, ou multi-agents avec orchestrateur central. Le réflexe par défaut est l'agent unique. On ne passe au multi-agents que quand on peut prouver, données à l'appui, que c'est rentable.
Si on bascule au multi-agents, on tient à trois principes :
- Un orchestrateur central qui décide des routages — pas de pair-à-pair anarchique entre agents.
- Un agent « secours humain » prêt en tout temps, qui prend le relais avec le transcript complet quand un agent IA bloque.
- Une journalisation de chaque handoff dans un dashboard que le client peut consulter — pour ne pas être aveugle sur ce que les agents font.
C'est de l'ingénierie d'agents, pas du prompt engineering.
Faut-il attendre?
Honnêtement, pour 70 % des PME que nous voyons au Québec, oui — la réponse est encore « un seul agent, bien fait ». Le multi-agents répond à un vrai problème, mais à un problème de volume et de complexité que la majorité des PME n'a pas. Pas encore.
Pour les 30 % qui ont vraiment plus de trois domaines fonctionnels avec du volume soutenu, l'environnement de 2026 est probablement le premier moment où le calcul tient. Latence sous contrôle, plateformes mûres, coûts LLM raisonnables.
Le seul mauvais choix, c'est de bâtir un système multi-agents par effet de mode, puis de payer 15× le coût pour des appels qu'un seul agent aurait gérés mieux.
Si vous hésitez, la bonne première étape n'est pas de choisir une architecture. C'est de réécouter trente de vos appels entrants des deux dernières semaines et de compter, à la main, combien de domaines fonctionnels distincts apparaissent vraiment. Le chiffre vous dira presque tout.