Odoo VoIP Configuration : Guide Complet Voxbi 2026
Guide Odoo VoIP configuration avec Voxbi. Prérequis, installation SIP/TLS, CTI, IVR, tests et conformité GDPR pour intégrateurs et DSI.
12 oct. 2026
Répondeur à choix multiple : concevoir un parcours qui réduit l'attente
Repondeur choix multiple. Mettez en place un répondeur à choix multiple performant : configuration IVR, scénarios, tests et conformité RGPD
Un appel arrive à l'ouverture d'une clinique, d'un cabinet juridique ou d'une entreprise multisite. Le standard reçoit des demandes commerciales, des urgences, des questions administratives et des appels destinés à un service déjà saturé. Si le répondeur à choix multiple propose un parcours trop long, sans rappel ni accès clair à un conseiller, l'appelant ne gagne pas en autonomie. Il rencontre simplement une attente déplacée.
Un standard vocal professionnel doit donc faire plus que diffuser un message et distribuer des touches. Il doit qualifier la demande, réduire l'attente, préserver les situations prioritaires et organiser la sortie vers un humain. Pour un intégrateur IT ou un revendeur télécom, la difficulté n'est pas d'ajouter un menu. Elle consiste à concevoir une interface vocale que les équipes peuvent exploiter, mesurer et faire évoluer sans dégrader la relation usager.
Table des matières
Pourquoi configurer un repondeur a choix multiple professionnel
Paramétrer les conditions de redirection et les temporisations
Pourquoi configurer un repondeur a choix multiple professionnel
Un prospect appelle une entreprise de services et entend plusieurs options qui ne correspondent pas à son besoin. Il choisit au hasard, atteint le mauvais groupe, est transféré, puis recommence son parcours. Pendant ce temps, l'accueil reçoit les mêmes demandes, les collaborateurs répondent à des appels mal orientés et le responsable constate seulement que la file reste chargée.
Le répondeur à choix multiple devient utile quand il reflète le fonctionnement réel de l'organisation. Une clinique peut distinguer les rendez-vous, les résultats, les admissions et les urgences. Un cabinet juridique peut séparer les nouveaux dossiers, les clients existants et les factures. Une PME peut proposer les ventes, le support et les demandes générales. La structure doit partir des motifs d'appel observés, pas de l'organigramme interne.
Un outil de qualité de service
Un menu vocal bien conçu agit comme un contrôle qualité en amont. Il recueille l'intention, applique les horaires, envoie l'appel vers la bonne file et annonce immédiatement les situations particulières. Il ne doit toutefois pas chercher à tout automatiser. Une demande ambiguë, sensible ou urgente mérite une voie humaine clairement annoncée.
Les organisations publiques illustrent le risque d'une orientation sans résolution. Les résultats de la préfecture de la Gironde indiquent que 46 % des usagers l'ont contactée via le SVI, mais seulement 21,4 % estiment avoir obtenu une réponse adaptée. La satisfaction de l'accueil téléphonique atteint 47,6 %, selon le rapport consacré aux résultats de la préfecture de la Gironde. Ces données ne condamnent pas le SVI. Elles montrent qu'un parcours peut fonctionner techniquement tout en échouant du point de vue de l'appelant.
Règle opérationnelle : une touche n'a de valeur que si elle mène à une action compréhensible, disponible et suivie.
Le concepteur doit donc relier chaque choix à une destination, une capacité de traitement et un scénario d'échec. Le menu doit prévoir l'absence de saisie, une erreur de touche, une file saturée, un appel hors horaires et une demande qui ne peut pas être traitée par l'automate. Les principes de conception d'un call flow télécom aident à formaliser ces dépendances avant la mise en production.
Architecture et conception d'un menu vocal efficace
L'architecture efficace commence par un accueil court. Le message doit indiquer l'identité de l'organisation, la situation horaire si nécessaire, puis les choix réellement utiles. Une liste longue donne l'impression que l'entreprise demande à l'appelant de comprendre sa structure interne.
Limiter les choix et hiérarchiser les demandes
Le menu principal doit placer en premier les demandes fréquentes ou prioritaires. La vente ne doit pas passer avant une urgence médicale, et une option informative ne doit pas masquer l'accès à un agent. Les options peuvent ensuite ouvrir un second niveau, mais chaque niveau supplémentaire ajoute du temps, des erreurs et un risque d'abandon.
Une architecture solide suit généralement cette logique :
Accueil clair : annoncer le service joint et la durée approximative du parcours.
Choix métier : regrouper les motifs selon le besoin de l'appelant, pas selon les noms des équipes.
Destination préparée : associer chaque touche à une file, un poste, un groupe ou un message utile.
Sortie humaine : rendre l'accès à un conseiller explicite et accessible depuis le menu principal.
Le raccourci vers un agent ne doit pas être caché derrière une formulation vague. Une touche zéro ou une commande vocale annoncée permet à l'appelant de quitter l'arborescence lorsqu'elle ne correspond pas à sa situation. Cette sortie doit aussi respecter les horaires, les compétences disponibles et les règles de priorité.
Concevoir les scénarios de secours
Le message ne doit pas supposer que l'appelant écoute parfaitement ou sait quelle touche choisir. Il faut prévoir la répétition du menu, un traitement de l'absence de saisie et une destination de secours après plusieurs erreurs. Les personnes âgées, les appelants non francophones, les patients stressés et les personnes en situation de handicap doivent pouvoir comprendre le parcours sans maîtriser le vocabulaire interne.
Les résultats de la Gironde rappellent le point essentiel : orienter n'est pas résoudre. Le taux de décroché ne suffit donc pas à évaluer le menu. La résolution au premier contact, l'abandon, le transfert entre services et la satisfaction doivent guider les corrections.
Les calendriers jouent également un rôle architectural. Un message en journée, un message de fermeture, une annonce de jour férié et un scénario de surcharge doivent être distincts. L'appelant doit savoir si son choix reste possible, s'il doit laisser un message ou s'il peut demander un rappel. Un menu vocal utile décrit le prochain événement. Il ne se contente pas de réciter des options.
Paramétrer les conditions de redirection et les temporisations
La conception du menu ne suffit pas. Les paramètres de redirection déterminent ce que vit réellement l'appelant après avoir appuyé sur une touche. Un intégrateur doit tester le délai d'écoute, le temps d'attente avant transfert, l'absence de saisie, la touche invalide et la saturation de la destination.
Un délai trop court pénalise une personne qui cherche son téléphone ou écoute dans un environnement bruyant. Un délai trop long donne l'impression que le système ne répond plus. La bonne valeur dépend du débit du message, de la complexité du choix et du contexte d'appel. Chaque scénario doit être testé avec des utilisateurs qui ne connaissent pas l'arborescence.
Régler la logique d'échec
Le premier silence peut déclencher une répétition du menu. Une nouvelle absence de saisie peut conduire vers l'accueil, une boîte vocale ou une proposition de rappel. Une touche invalide doit générer une correction compréhensible, puis éviter la boucle infinie. Le système doit aussi conserver le contexte lorsque l'appel passe d'un niveau à l'autre.
Le rappel automatique mérite une configuration dédiée. Les données françaises de l'Urssaf indiquent que le callback a augmenté le taux de décroché de 2 points en moyenne, et jusqu'à 4 points dans le centre où il était le plus utilisé. L'acceptation est particulièrement forte quelques minutes après l'entrée dans la file, selon le guide français sur le rappel automatique.
Le rappel ne doit pas être proposé indistinctement. Il faut conserver la position dans la file lorsque le fonctionnement le permet, confirmer le numéro, annoncer la plage de rappel et traiter séparément les situations urgentes. Les indicateurs à suivre sont le taux d'acceptation, le taux de rappel abouti, l'abandon, le délai de réponse et la satisfaction. Un callback mal paramétré peut simplement déplacer l'insatisfaction vers une promesse non tenue.
Organiser les horaires et les sites
Un calendrier de fêtes doit modifier automatiquement le message, les destinations et les règles de rappel. Pour une organisation multisite, le routage peut tenir compte du site demandé, de la langue, de la compétence et de la disponibilité locale. Une fermeture régionale ne doit pas nécessairement fermer toute l'organisation.
| Paramètre | Fonctionnalité | Impact sur l'expérience utilisateur |
|---|---|---|
| Temporisation | Répétition, transfert ou sortie après silence | Évite les boucles et les abandons silencieux |
| Touche invalide | Message correctif et nouvelle tentative | Réduit les erreurs de parcours |
| File saturée | Annonce, conservation de position ou rappel | Limite l'attente passive |
| Calendrier | Message adapté aux horaires et jours fériés | Donne une information fiable |
| Multi-site | Routage selon le lieu et la disponibilité | Oriente vers l'équipe réellement compétente |
Les règles de routage horaire doivent être documentées avec les responsables métier. Le standard ne peut pas décider seul si un appel urgent doit contourner la file, si un site voisin peut répondre ou si une demande doit rester attachée à son agence d'origine.
Comparer le standard on-premise et la solution cloud UE
Le choix entre un PBX installé sur site et un standard cloud dépend moins du discours commercial que du mode d'exploitation attendu. Un système on-premise conserve un intérêt lorsqu'une organisation possède déjà une équipe capable d'administrer le matériel, les téléphones, les liens et les évolutions locales. En revanche, chaque changement d'arborescence peut mobiliser une intervention, une fenêtre de maintenance ou une demande interne.
Dans une organisation multisite, cette contrainte devient visible lors d'un changement d'horaires, d'une fermeture temporaire ou d'une réorganisation des équipes. Le standard cloud permet à un administrateur autorisé de modifier les utilisateurs, les files, les menus et les calendriers depuis une interface web. Les changements ne dépendent plus d'une intervention physique sur chaque serveur.
Arbitrer selon l'exploitation
| Critère | PBX on-premise | Standard cloud hébergé dans l'UE |
|---|---|---|
| Modification du menu | Intervention technique ou ticket | Configuration centralisée par un administrateur |
| Sites multiples | Dépendance aux équipements locaux | Gestion homogène depuis une interface web |
| Maintenance | Matériel, versions et disponibilité à maintenir | Responsabilités réparties avec l'éditeur |
| Déploiement | Préparation et installation sur site | Activation des utilisateurs et des flux à distance |
| Données | Dépend de l'architecture et des prestataires | Dépend de l'hébergement, des sous-traitants et des accès |
Voxbi constitue un exemple de standard téléphonique cloud hébergé dans l'Union européenne. Son Cockpit permet de configurer les utilisateurs, les extensions, les files, les menus vocaux et les calendriers depuis un logiciel en ligne. Cette approche ne supprime pas les responsabilités de l'intégrateur. Elle déplace le travail vers la conception des flux, la gouvernance des accès, les tests et l'accompagnement des équipes.
Le cloud ne doit pas être choisi uniquement pour aller plus vite. L'intégrateur doit vérifier la réversibilité, les niveaux d'administration, la journalisation, les procédures d'incident et la localisation effective des données. Le comparatif entre standard on-premise et cloud fournit un cadre pour poser ces questions avec la DSI et les métiers.
Garantir la conformité RGPD et la souveraineté des données
Un répondeur traite souvent plus de données qu'un simple message d'accueil. Les appels peuvent contenir un nom, un numéro, une demande médicale, une information contractuelle ou une donnée permettant d'identifier une personne. Les enregistrements, les journaux d'appels, les transcriptions éventuelles et les métadonnées doivent donc entrer dans une analyse de traitement cohérente.
Le RGPD s'applique directement dans tous les États membres de l'Union européenne et encadre le traitement, la conservation et la circulation des données personnelles. Un hébergement dans l'Union réduit l'exposition aux transferts internationaux, mais ne constitue pas à lui seul une certification RGPD, comme le rappelle le cadre européen consacré aux règles applicables aux systèmes dignes de confiance.
Vérifier la chaîne de responsabilité
Avant le déploiement, l'intégrateur doit demander une documentation exploitable, pas une simple promesse de souveraineté. La vérification porte notamment sur :
Les finalités : identifier pourquoi les appels, enregistrements et métadonnées sont traités.
Les durées : définir la conservation et les mécanismes de suppression.
Les accès : distinguer les droits des administrateurs, intégrateurs, agents et sous-traitants.
Les prestataires : documenter les acteurs techniques et les éventuels accès à distance.
La sécurité : vérifier le chiffrement des communications, notamment SIP TLS lorsque le service le propose, ainsi que la protection des interfaces et des sauvegardes.
Les personnes concernées : prévoir l'information, l'exercice des droits et le traitement des demandes internes.
La souveraineté doit être évaluée au niveau de l'hébergement, des prestataires et des accès. Un centre de données européen ne répond pas à toutes les questions si un tiers non documenté administre une composante critique ou si les règles de conservation restent floues.
Distinguer RGPD et EU AI Act
La présence d'une fonction d'IA ne transforme pas automatiquement un standard vocal en système conforme au règlement européen sur l'intelligence artificielle. Le règlement, adopté le 13 juin 2024 et entré en vigueur le 1er août 2024, prévoit une application progressive. Les interdictions relatives à certaines pratiques et les obligations générales s'appliquent depuis le 2 février 2025 ; plusieurs obligations de gouvernance, de sanctions et relatives aux modèles d'IA à usage général s'appliquent depuis le 2 août 2025. Les règles concernant certains systèmes à haut risque doivent notamment s'appliquer à partir du 2 août 2026 ou du 2 août 2027 selon leur catégorie, conformément au texte européen et à son calendrier d'application.
Une DSI doit donc qualifier le cas d'usage, le rôle de chaque acteur, les données traitées, le niveau de risque et les exigences de contrôle humain. La localisation européenne soutient la souveraineté et peut simplifier l'analyse des transferts, mais elle ne remplace ni la classification du système ni la documentation attendue. Le guide Voxbi sur la conformité RGPD peut compléter cette grille, qui doit rester validée avec les responsables juridiques et sécurité.
Voxbi propose un standard téléphonique cloud hébergé dans l'Union européenne, avec un Cockpit pour administrer les utilisateurs, files, menus vocaux et calendriers. Pour cadrer un répondeur choix multiple, vérifier la gouvernance des données et préparer le déploiement avec un intégrateur, découvrez Voxbi et demandez une présentation adaptée à votre organisation.
