FreePBX Odoo Integration : Guide Pas à Pas
Guide complet FreePBX Odoo integration en français : prérequis, architecture SIP/AMI, click-to-call, sécurité GDPR et mise en production.
4 oct. 2026
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.
Vous êtes probablement face au même scénario que beaucoup d'équipes PME et ETI en ce moment, un standard qui a déjà basculé vers l'IP, un besoin de faire remonter les appels dans Odoo, et des numéros qui ne s'affichent pas toujours comme prévu. Sur le papier, la bascule semble simple. Sur le terrain, tout se joue dans la séparation nette entre ce que gère Odoo et ce que doit gérer le cloud PBX.
Table des matières
Comprendre la migration vers la téléphonie IP dans Odoo
Dans beaucoup de migrations, le problème n'est pas la téléphonie elle-même, c'est la rupture entre la voix et le métier. Un commercial décroche, mais l'appel ne remonte pas dans la fiche client. Un technicien rappelle un ticket, mais personne ne sait à quelle opportunité rattacher l'échange. C'est précisément là que la configuration Odoo VoIP change de nature, elle devient une brique de continuité entre téléphonie, CRM, Ventes et Assistance.
Le contexte français va dans ce sens. Selon l’Arcep, en 2024, les entreprises représentaient 35 % du trafic vocal total sur les réseaux français, soit 2 points de plus en un an, et 33 % du trafic de voix sur large bande, en hausse de 3 points sur la même période observatoire 2024 des marchés entreprises. Ce n'est pas un simple déplacement technique, c'est un changement d'architecture, la voix dépend désormais de la stabilité IP, des flux réseau et du traitement applicatif, pas d'un combiné branché à part.
Règle pratique : quand Odoo et la téléphonie travaillent ensemble, le poste de travail devient une extension du système d'information, pas un îlot téléphonique isolé.
Pour les équipes qui migrent, la bonne lecture est simple. Odoo doit rester la couche utilisateur, avec l'affichage des contacts, des opportunités et des tickets. Le cloud PBX doit porter le routage, les files d'attente, les menus, la supervision et la logique télécom. Un guide utile sur cette séparation fonctionnelle est disponible dans cet article sur le cloud-based PBX.
Installation du module et premiers paramètres SIP
La première erreur sur le terrain consiste à vouloir tout paramétrer d'un seul coup. La bonne séquence commence plus sobrement, avec l'activation de l'application Téléphone/VoIP, puis l'attribution du rôle VoIP à chaque utilisateur concerné dans Paramètres → Utilisateurs & Sociétés → Utilisateurs → Droits d'accès → Productivité. Sans ce droit, l'interface peut être visible, mais l'utilisateur reste bloqué au moment d'émettre ou de recevoir.
Ensuite, la configuration du fournisseur se fait dans Téléphone → Configuration → Paramètres. C'est ici que le standard cloud expose les éléments à faire correspondre dans Odoo, serveur SIP, identifiants individuels, domaine SIP, environnement de production et connexion en WebSocket sécurisé. Pour un usage navigateur, le support WebRTC n'est pas un détail technique, c'est ce qui permet au client web de passer correctement les flux vocaux.
Point de contrôle : Odoo ne doit pas être utilisé comme un annuaire télécom complet. Il reçoit des paramètres ciblés, le reste vit côté opérateur ou côté PBX cloud.
Le bon réglage consiste à mapper chaque champ explicitement à la fiche utilisateur. Il ne faut pas mélanger identifiant SIP, identifiant d'autorisation, extension navigateur et extension de poste. Dans les projets mal montés, ces valeurs finissent souvent dans le mauvais champ, et le résultat est classique, un utilisateur qui voit son compte comme “configuré” alors que le serveur ne le reconnaît pas réellement.
La syntaxe des numéros mérite la même rigueur. Odoo attend le format international avec le signe +, donc un numéro français doit être saisi en +33 quand c'est le format retenu par le projet. Sans ce préfixe, le widget peut afficher « Numéro incorrect ». Pour des intégrateurs et revendeurs télécom, c'est un point de validation à faire avant même de tester la première sonnerie. Un complément utile sur la liaison entre Odoo et le standard cloud se trouve dans ce guide de connexion, connecter Odoo à Voxbi.
Intégration CTI et sécurisation des connexions
La partie CTI ne sert pas à “faire joli” dans l'interface, elle sert à éviter les doubles saisies et les erreurs de contexte. Quand le poste téléphonique et Odoo ne partagent pas la même logique d'identité, les clics pour appeler, les retours de fiche et la journalisation d'appels deviennent vite incohérents. La discipline consiste donc à faire coïncider l'extension Odoo avec l'extension de poste, puis à contrôler le parcours du clic jusqu'à l'appel établi.
Sécuriser le transport, pas seulement l'accès
Pour les flux vocaux, la base technique repose sur TLS et WebRTC. Dans un environnement navigateur, cela aide à traverser les pare-feu et les proxys sans sacrifier la confidentialité des échanges. Le point important n'est pas seulement que ça “marche”, c'est que les flux restent compatibles avec une politique de sécurité réaliste, surtout dans des équipes commerciales et support qui travaillent à distance ou sur plusieurs sites.
La logique doit rester nette, Odoo porte l'interface et le suivi métier, le PBX cloud porte l'acheminement téléphonique. Quand cette frontière est respectée, les équipes n'ont pas besoin de contourner le système avec des procédures manuelles. L'appel part depuis la fiche, l'identité de l'interlocuteur reste lisible, et la traçabilité suit sans bricolage.
CTI, REST API et TAPI dans le bon périmètre
L'intégration CTI peut s'appuyer sur des mécanismes comme REST API et TAPI, mais ils n'ont pas le même rôle que le SIP. Le SIP transporte la voix et l'établissement de session, tandis que les interfaces CTI servent à déclencher, synchroniser ou enrichir l'expérience depuis Odoo. C'est une distinction que beaucoup d'équipes brouillent au déploiement.
Erreur fréquente : traiter le CTI comme un simple “plug-in”. En pratique, il faut définir ce qui est déclenché depuis Odoo, ce qui reste dans le PBX, et ce qui revient dans le CRM.
Pour une lecture plus large du sujet, le rappel sur la définition du CTI aide à cadrer les responsabilités techniques avant d'ouvrir les accès de production. C'est aussi le bon moment pour stabiliser le mapping des extensions, avant que les utilisateurs ne commencent à tester en masse.
Mise en place des utilisateurs et routage des appels
Le routage doit être pensé comme une responsabilité du standard cloud, pas comme une accumulation de réglages dispersés dans Odoo. Dans les déploiements propres, Odoo sert à l'authentification, à l'affichage et à l'historisation, tandis que le PBX gère les files d'attente, les menus IVR et les plages horaires. Cette séparation évite de forcer Odoo à faire un travail télécom qu'il n'a pas vocation à porter.
Relier chaque utilisateur à sa vraie extension
Chaque compte doit avoir une correspondance claire entre l'utilisateur Odoo et son extension téléphonique. Si un collaborateur change de poste, le mappage doit être mis à jour immédiatement, sinon les appels entrants partent vers la mauvaise personne ou ne remontent plus correctement dans les journaux. Le standard cloud reste la source de vérité pour les éléments de routage, Odoo reste la couche d'usage.
Dans le cockpit Voxbi, cette logique permet de définir les files d'attente, les menus IVR et les horaires d'ouverture sans toucher à l'ergonomie Odoo. Cette approche évite de disperser les règles dans plusieurs écrans. Le responsable IT garde la main sur la téléphonie, les équipes métier gardent une interface claire.
Valider les numéros avant le passage en production
Le contrôle des numéros sortants ne doit jamais être laissé pour après. Odoo exige le format international, signe + compris, et c'est souvent là que les configurations échouent quand elles passent d'un annuaire local à un contexte multi-pays ou multi-sites. Le numéro doit être stocké dans un format cohérent dès le départ, sinon les appels ne s'associent pas proprement aux contacts.
Quand le format des numéros varie d'un utilisateur à l'autre, le problème ne vient pas du clic pour appeler, mais de la donnée de référence.
Un bon déploiement se reconnaît vite, les utilisateurs appellent depuis la fiche contact, les appels entrants se rangent au bon endroit, et les alertes d'erreur de format disparaissent. Pour les intégrateurs, c'est aussi le moment de valider que le plan de numérotation du standard cloud correspond bien au fonctionnement attendu par les équipes commerciales et support. Le rappel sur les flows télécom complète utilement cette approche.
Tests de validation et diagnostic des problèmes courants
Un test réussi n'est pas un simple appel qui passe. Il faut contrôler le microphone, l'appel entrant, l'appel sortant, l'affichage du numéro et la remontée correcte dans l'interface Odoo. Si un seul maillon échoue, la configuration est incomplète, même si la première sonnerie semble rassurante.
Symptôme contre cause probable
| Symptôme | Cause probable | Solution recommandée |
|---|---|---|
| Le widget ne se connecte pas | Problème de WebSocket sécurisé ou identifiants mal mappés | Vérifier WSS, le domaine SIP et la correspondance entre chaque champ utilisateur |
| L'audio est coupé | Réseau local instable ou souci de compatibilité WebRTC | Contrôler le navigateur, le pare-feu et la qualité du réseau IP |
| Le numéro s'affiche comme incorrect | Numéro saisi sans format international | Reprendre le contact en +33 ou dans le format international retenu |
| Le CTI ne déclenche rien | Extension Odoo et extension de poste non alignées | Corriger le mappage des extensions et tester avec un seul utilisateur pilote |
| Les appels ne remontent pas dans l'interface | Rôle utilisateur absent ou association compte-extension incomplète | Revalider les droits VoIP et la fiche utilisateur |
Cette matine aide à séparer les pannes côté poste, côté client web et côté serveur SIP. C'est souvent plus utile qu'une longue liste de vérifications sans ordre. Dans un projet bien tenu, le diagnostic suit la chaîne logique, identité, connexion, transport, affichage.
Distinguer ce qu'Odoo fait et ce que le PBX fait vraiment
Odoo gère l'expérience de travail, le PBX gère le réseau téléphonique. Si le problème vient du routage, des files, des menus ou des horaires, la correction se fait dans le standard cloud. Si le problème vient du droit utilisateur, du widget ou de la saisie du numéro, la correction se fait côté Odoo.
Cette frontière claire évite les tests en boucle. Les équipes support ne perdent pas de temps à chercher dans le mauvais outil. Les intégrateurs gagnent aussi un cadre de recette plus propre, avec une vérification fonctionnelle par couche au lieu d'un contrôle global flou.
Gouvernance des données et conformité RGPD
La conformité ne découle jamais automatiquement du fait qu'un outil est en cloud. Pour une téléphonie intégrée à Odoo, il faut d'abord cartographier les traitements, puis préciser la base juridique, les mesures de sécurité, les sous-traitants et la politique d'effacement rappels RGPD d'Odoo. Le vrai sujet n'est pas seulement de savoir si l'appel passe, c'est de savoir ce qui est enregistré, où, par qui, et pendant combien de temps.
L'hébergement en Union européenne réduit l'exposition aux transferts internationaux, mais ne remplace pas l'analyse des sous-traitants ni des éventuels fournisseurs soumis à des législations étrangères cadre général CNIL. Pour un standard téléphonique cloud, cela peut concerner les enregistrements, les métadonnées, les journaux techniques et les données utilisateurs. Une promesse de “conformité RGPD” reste insuffisante si les flux de support, les accès distants ou le chiffrement ne sont pas documentés de façon concrète bonnes pratiques CNIL.
Ce qu'un intégrateur doit faire figurer dans le dossier
La gouvernance doit couvrir la finalité des enregistrements, les durées de conservation, les droits d'accès par rôle, les exports possibles et la procédure de suppression. Il faut aussi distinguer les appels commerciaux ordinaires des environnements sensibles, où la transcription et l'analyse vocale appellent une évaluation plus stricte. Dans les établissements de santé, les collectivités ou les écoles, cette séparation n'est pas théorique, elle conditionne le niveau de contrôle attendu.
Hébergement et sous-traitance : documenter l'endroit où sont stockés les flux, qui les administre et quels prestataires interviennent.
Accès et permissions : limiter l'écoute des enregistrements aux rôles nécessaires, sans accès élargi par défaut.
Rétention et suppression : définir une durée claire et une suppression automatique quand elle s'applique.
Support et administration : tracer les accès distants et les interventions techniques.
Traitements sensibles : activer une revue renforcée dès qu'il y a transcription ou analyse vocale.
Le cadre réglementaire européen sur l'IA ne doit pas non plus être présenté comme acquis aujourd'hui. Le calendrier prévoit une application progressive, avec la majorité des règles qui commencent à s'appliquer le 2 août 2026, ainsi qu'une période de transition pour certaines obligations jusqu'au 2 décembre 2026 calendrier officiel de l'AI Act. Pour une téléphonie cloud intégrant des fonctions d'IA, cela impose une lecture prudente, système par système, au lieu d'un label de conformité global.
Les équipes qui veulent aller vite doivent donc cadrer la voix comme un traitement métier à part entière, pas comme une simple fonctionnalité annexe. Voxbi apporte un PBX cloud hébergé dans l'Union européenne, avec des appels, des métadonnées et des données administratives pensés pour rester sous contrôle dans un cadre d'exploitation européen. Pour un déploiement Odoo propre, l'étape suivante consiste à demander une démonstration, valider les besoins de routage et vérifier comment Voxbi s'aligne avec votre gouvernance RGPD, votre organisation IT et votre mode de support.
