FreePBX Odoo Integration : Guide Pas à Pas

Une PME française peut très bien avoir un FreePBX stable, des files d'attente bien réglées et des postes qui donnent satisfaction, tout en demandant à ses équipes de saisir manuellement chaque appel dans Odoo. Le problème n'est alors pas la téléphonie. C'est la rupture entre le téléphone et le dossier client.

Le choix ne consiste pas seulement à trouver un connecteur compatible. Il faut décider s'il vaut mieux relier FreePBX à Odoo, avec une couche d'intégration à maintenir, ou abandonner le PBX existant au profit de la téléphonie native d'Odoo. La bonne réponse dépend du parc téléphonique, des scénarios d'appel, du niveau de personnalisation attendu et de la capacité de l'entreprise à administrer deux environnements.

Table des matières

• Pourquoi relier FreePBX à Odoo et quand cela reste pertinent

  • Le coût caché de la coexistence

• Prérequis techniques et versions à aligner

  • Les flux à inventorier

• Architecture SIP, AMI, ARI et WebRTC expliquée

  • Le schéma mental d'un appel

• Installer et configurer un module CTI Odoo pour FreePBX

  • Préparer FreePBX

  • Préparer Odoo

• Click-to-call, webhooks et synchronisation REST API

  • Deux flux utiles sur le terrain

• Sécurité, hébergement UE et conformité GDPR

  • Les vérifications à exiger

• Tests, mise en production et dépannage

  • Diagnostiquer par symptôme

  • Garder FreePBX ou repartir sur la téléphonie native

Pourquoi relier FreePBX à Odoo et quand cela reste pertinent

Un cabinet d'expertise comptable de 18 postes peut hésiter longtemps entre conserver son FreePBX et migrer vers la VoIP native d'Odoo. Le premier choix préserve les trunks, les règles de routage et les habitudes des collaborateurs. Le second promet un environnement plus unifié, mais impose de vérifier la couverture fonctionnelle, le fournisseur téléphonique et les conditions de sortie.

L'intégration FreePBX-Odoo apporte une valeur concrète quand elle reste centrée sur les usages. Un appel entrant peut déclencher une popup avec la fiche client, l'appel peut être journalisé dans le CRM, et un commercial peut lancer un appel depuis un devis grâce au click-to-call. Dans un secteur réglementé, la traçabilité des communications peut aussi faciliter les contrôles internes, à condition de définir précisément les durées de conservation et les droits d'accès.

Elle ne corrige pas une mauvaise architecture réseau. Une connexion WAN insuffisante dégradera la qualité audio, même si la fiche Odoo s'ouvre parfaitement. Elle ne supprime pas non plus la maintenance du pont entre le PBX et l'ERP. Les mises à jour d'Asterisk, de FreePBX, d'Odoo ou du module CTI peuvent modifier les événements, les droits d'accès ou les méthodes d'authentification.

Règle pratique : l'intégration est pertinente si FreePBX est déjà stable, si l'entreprise utilise des files d'attente ou un SVI élaboré, si elle conserve des postes analogiques, ou si son métier exige une téléphonie spécialisée. Sans ces contraintes, la téléphonie native d'Odoo mérite une comparaison sérieuse.

Le coût caché de la coexistence

Le coût d'une intégration ne se limite pas au développement initial. Il comprend la surveillance des événements d'appel, les tests après mise à jour, la rotation des secrets, le diagnostic des appels non journalisés et la gestion des exceptions de numérotation. Pour un environnement bien documenté, l'effort récurrent peut représenter 0,5 à 1,5 jour par mois, hors incidents, selon l'effectif et la complexité du flux.

Ce chiffre doit être traité comme une enveloppe de maintenance, pas comme une promesse universelle. Un connecteur standard avec peu de scénarios réclame moins de suivi qu'un dispositif qui synchronise appels, files, enregistrements et tickets d'assistance.

En France, l'existence d'intégrateurs proposant déjà une offre associant Odoo, FreePBX et VoIP montre que cette architecture a une place dans l'écosystème local. La fiche partenaire française d’ARIOS Telecom sur l'annuaire Odoo associe notamment Networking, VOIP, FreePBX et Odoo.

Prérequis techniques et versions à aligner

Un projet FreePBX-Odoo échoue rarement parce qu'un bouton manque dans l'interface. Il échoue parce que l'inventaire technique a été fait trop tard. Avant toute installation, l'intégrateur doit cartographier les trunks SIP, les postes, les flux audio, les accès d'administration et les dépendances du module retenu.

Le point de départ est la version exacte du connecteur. La documentation d'un module Odoo indique une compatibilité avec FreePBX 16.0.45 et Asterisk 18 ou supérieur. Un autre module mentionne également Odoo 19 et FreePBX 17, ce qui confirme une évolution du marché des connecteurs, mais ne dispense pas de tester la combinaison précise retenue dans l'entreprise. Ces éléments figurent dans la fiche du module Odoo utilisant WSS et la pile Asterisk.

Les flux à inventorier

Le flux SIP porte la signalisation entre le trunk, le PBX et les terminaux. Le flux RTP transporte l'audio. AMI remonte les événements Asterisk, tandis qu'ARI sert aux scénarios de contrôle plus avancés. WebRTC et WSS interviennent lorsque le client web devient le terminal téléphonique.

L'inventaire doit aussi couvrir :

• Le trunk opérateur, déjà opérationnel avant l'intégration.

• Les extensions et les files, avec leurs règles de débordement.

• Les accès AMI et ARI, limités aux adresses et actions nécessaires.

• Le certificat TLS, lorsque les flux chiffrés ou le WebRTC l'exigent.

• Les modules Odoo, notamment Contacts, CRM et Assistance si les appels doivent alimenter ces applications.

• Le poste de test, séparé du déploiement général, avec un numéro réservé.

L'entreprise doit conserver une matrice des versions, des secrets et des responsables. Sans cette documentation, chaque incident devient une enquête sur l'ensemble de la chaîne.

Architecture SIP, AMI, ARI et WebRTC expliquée

Un appel peut sonner correctement dans FreePBX tout en restant invisible dans Odoo, ou remonter dans le CRM sans audio. La cause vient souvent d'une confusion entre les protocoles. Chacun intervient à un niveau différent, et cette séparation guide le diagnostic.

SIP gère la signalisation. Il établit, modifie et termine les sessions entre le trunk, FreePBX et les téléphones. Le son suit un flux distinct, généralement en RTP. Un téléphone peut donc recevoir la sonnerie alors que l'audio ne passe pas, par exemple à cause d'un codec, d'un pare-feu ou d'un mauvais routage RTP.

AMI, ou Asterisk Manager Interface, expose les événements d'Asterisk sur une interface de gestion. Le connecteur l'utilise pour détecter un appel entrant, lire le numéro présenté et déclencher une action dans Odoo. AMI convient bien à la remontée d'événements. Son accès doit toutefois être filtré par adresse et limité à un compte dédié. Un compte trop puissant, exposé depuis un réseau non maîtrisé, augmente directement le risque d'intrusion.

ARI, ou Asterisk REST Interface, fournit une API REST et une connexion WebSocket pour contrôler plus finement les canaux, les bridges et certains scénarios de communication. Il devient pertinent lorsque l'intégration doit agir sur le déroulement de l'appel, synchroniser plusieurs états ou orchestrer une logique qui dépasse la simple notification. Pour une popup et un historique d'appel, ARI ajoute souvent une complexité que AMI suffit à éviter.

WebRTC avec WSS permet à un softphone de fonctionner dans le client web. Le conseiller appelle depuis Odoo sans installer de logiciel téléphonique supplémentaire, à condition de configurer correctement le certificat, le proxy, les permissions du microphone et le support audio. Les bases de cette technologie sont détaillées dans ce guide sur le WebRTC.

Le schéma mental d'un appel

Pour un appel entrant, l'opérateur remet la communication à FreePBX via SIP. Asterisk publie ensuite un événement AMI, le connecteur transmet les données à Odoo, puis Odoo recherche le partenaire correspondant et affiche la popup. L'agent décroche avec un poste SIP ou un softphone WebRTC. Chaque étape possède ses propres journaux, ce qui permet d'isoler plus vite une panne.

Le choix dépend du besoin réel. AMI convient aux événements, comme l'arrivée d'un appel ou la fin d'une communication. ARI convient au contrôle, lorsque Odoo ou un service intermédiaire doit modifier le déroulement de l'appel. Cette décision influence aussi la maintenance du connecteur, car une orchestration ARI demande davantage de tests et de suivi qu'une simple remontée AMI.

Installer et configurer un module CTI Odoo pour FreePBX

Une PME peut installer un connecteur en quelques heures, puis découvrir que les appels manqués, les transferts et les doublons CRM ne sont pas correctement traités. Le premier arbitrage porte donc sur le module retenu. Un module du store Odoo accélère le démarrage et couvre souvent la popup, le click-to-call et l'historisation. Un développement spécifique épouse mieux le workflow commercial, mais augmente l'effort de tests, de documentation et de maintenance. Il faut chiffrer cet effort avant de comparer les options.

L'inventaire des scénarios doit précéder l'installation. Un module standard peut convenir à une équipe mono-société avec une file simple et une journalisation classique. Il devient plus contraignant avec plusieurs sociétés, des files imbriquées, des règles de qualification ou des enregistrements soumis à des restrictions particulières. Dans ces cas, le coût d'adaptation et de maintenance peut annuler le gain initial du module prêt à l'emploi.

Préparer FreePBX

Le trunk SIP se teste indépendamment d'Odoo. Les extensions, groupes d'appel, files et règles de numérotation doivent fonctionner avant l'ajout de la couche CTI. L'accès Manager utilise un compte dédié, limité aux événements et actions demandés par le connecteur.

Les appels sortants, redirections ou commandes d'exécution ne sont autorisés que si le workflow les utilise. Le compte ne reçoit pas de privilèges administratifs généraux. Les accès sont restreints par réseau, journalisés, puis révoqués si le projet change d'intégrateur.

Préparer Odoo

Dans Odoo, l'intégrateur installe le module, renseigne l'hôte FreePBX, le canal d'administration, le secret et le contexte de numérotation. Les numéros sont normalisés avant toute recherche de contact. Cette règle évite qu'un même client apparaisse sous plusieurs formats et empêche l'ouverture de la popup.

Le mapping doit préciser :

• Le contact cible, partenaire, prospect ou ticket.

• Le sens de l'appel, entrant, sortant ou manqué.

• Le responsable, utilisateur Odoo associé au poste.

• La trace CRM, activité, note ou enregistrement d'appel.

• Le traitement des inconnus, création d'un prospect ou simple journalisation.

Le click-to-call se valide d'abord sur un poste pilote. Le client web doit pouvoir accéder au microphone, le softphone doit être enregistré et le connecteur doit distinguer un appel initié par l'utilisateur d'un appel automatique. Les principes fonctionnels sont rappelés dans cet article sur la définition du CTI.

Un appel entrant vers le support mérite aussi un test séparé. Odoo peut ouvrir le dossier du client ou créer une activité pour un agent. La création automatique d'un ticket attend la définition de règles contre les doublons, les appels courts et les appels indésirables.

Click-to-call, webhooks et synchronisation REST API

Dans une PME, un bouton d'appel qui fonctionne un jour sur deux coûte rapidement du temps au support. Le click-to-call doit donc déclencher une séquence maîtrisée : Odoo envoie la demande, FreePBX fait sonner le poste du conseiller, puis compose le numéro externe. Le poste SIP ou le canal WebRTC doit être opérationnel avant le déploiement auprès des utilisateurs.

Les webhooks transmettent les changements d'état entre FreePBX et Odoo. Le début d'appel peut envoyer le numéro entrant afin d'ouvrir la fiche correspondante. La fin d'appel peut compléter le journal CRM avec la durée, le statut et l'identifiant technique. Chaque événement nécessite un schéma documenté, une authentification, un traitement des erreurs et une stratégie de rejeu. Sans ces garde-fous, une interruption réseau crée des journaux incomplets ou des doublons.

Deux flux utiles sur le terrain

La popup temps réel lance une recherche sur le numéro entrant. Odoo renvoie l'identifiant du partenaire lorsqu'il existe, puis affiche la fiche adaptée. Pour un numéro inconnu, l'interface peut proposer la création d'un prospect. Cette création doit rester soumise à une règle claire afin de préserver la qualité de la base.

Le ticket d'assistance applique une règle métier aux appels manqués. Le système peut créer une activité ou un ticket Helpdesk, en ajoutant la file concernée et les métadonnées autorisées. Une transcription reste un chantier distinct : son dispositif, son hébergement et sa base légale doivent être validés avant tout envoi vers Odoo.

L'API REST sert aux tableaux de bord et aux applications internes qui consultent l'historique. L'endpoint doit imposer une authentification, journaliser les accès et retourner uniquement les champs nécessaires. Pour Power BI ou un outil RH, les enregistrements audio restent exclus par défaut. L'effort de maintenance se répartit entre les contrats de webhook, les droits d'API, les changements de versions et le contrôle des erreurs. Ce suivi doit être prévu dans le choix du connecteur, surtout face à la VoIP native d'Odoo, qui réduit le nombre d'interfaces à maintenir.

Le click-to-call dans un environnement téléphonique connecté mérite le même niveau de contrôle que les autres interfaces. Le bouton est visible, mais la fiabilité dépend de la chaîne complète, du poste web jusqu'au journal CRM.

Sécurité, hébergement UE et conformité GDPR

Un appel entrant peut contenir un numéro, une identité, un horaire, une note et parfois un enregistrement vocal. Ces éléments doivent être recensés dans le registre des traitements, avec leur finalité, leurs destinataires et leur durée de conservation. Un serveur situé en Europe ne suffit donc pas à établir la conformité GDPR.

La Commission européenne décrit la souveraineté du cloud et des données autour de la protection, du contrôle et de l'indépendance des données et des services. Le client doit aussi pouvoir maîtriser les accès cryptographiques et retrouver qui a consulté les informations, où et quand. Pour un connecteur FreePBX-Odoo, ces points concernent le PBX, l'instance Odoo, les sauvegardes et les éventuels services intermédiaires.

Les vérifications à exiger

• Hébergement et traitement, dans des environnements européens documentés, avec les clauses de sous-traitance adaptées.

• Chiffrement des flux, notamment SIP sur TLS, média sécurisé lorsque la chaîne le permet, puis HTTPS ou WSS pour les interfaces applicatives.

• Gestion des secrets, dans un coffre ou un mécanisme protégé, jamais dans un fichier de configuration accessible.

• Journalisation, avec une durée définie par le responsable du traitement et les obligations applicables.

• Accès aux enregistrements, limité selon les rôles, contrôlé et révisé régulièrement.

La localisation dans l'UE ne règle pas à elle seule la question juridique. Il faut vérifier les sous-traitants, les accès administrateurs, les clés de chiffrement et les possibilités de transfert. L'analyse de la souveraineté européenne des données face aux lois extraterritoriales rappelle ce point.

Le registre interne doit préciser les finalités, les personnes concernées, les destinataires, les mesures de sécurité et les règles d'effacement. Une analyse d'impact peut s'imposer si les appels, les enregistrements et le profilage créent un risque élevé. Les exigences détaillées sont résumées dans notre guide sur la conformité RGPD. Le cadre français d'intégration fiscale Odoo rappelle aussi qu'un déploiement Odoo doit respecter les exigences locales, au-delà de la seule connectivité téléphonique.

Tests, mise en production et dépannage

La recette commence sur une ligne isolée, avec des scénarios représentatifs du quotidien. Un appel entrant doit parcourir le SVI, rejoindre la bonne file, ouvrir la fiche correspondante dans Odoo et générer un événement exploitable. Un appel sortant doit partir depuis la fiche contact, respecter le plan de numérotation et apparaître dans l'historique avec le bon utilisateur.

Je fais exécuter les tests par un opérateur métier et par l'intégrateur. Le premier vérifie le parcours réel. Le second contrôle les journaux, les identifiants et les délais de traitement. Cette double lecture révèle souvent un problème que le simple test « l'appel aboutit » ne montre pas.

Les scénarios couvrent les cas ordinaires comme les interruptions :

• Appel entrant, présentation du numéro, popup, transfert et débordement.

• Appel sortant, click-to-call, sonnerie du poste et journalisation.

• Appel manqué, création d'une activité ou d'un ticket selon la règle définie.

• DTMF, navigation dans le SVI et transfert vers un groupe.

• Enregistrement, création, accès, lecture et suppression selon la politique retenue.

• Déconnexion, reprise du service après une interruption AMI, WebSocket ou Odoo.

Une charge simulée complète la recette si l'entreprise prévoit un usage intensif. Elle sert à vérifier que FreePBX, le proxy, Odoo et les files de tâches restent cohérents lorsque plusieurs événements arrivent ensemble. Il faut observer les doublons, les délais, les événements perdus et les appels qui restent sans fiche associée, plutôt que retenir uniquement le nombre d'appels traités.

Diagnostiquer par symptôme

Le diagnostic doit partir des journaux FreePBX et Odoo, puis remonter vers les files d'attente, les connexions PJSIP, les échecs d'authentification et les tâches différées. Un tableau de bord utile affiche les événements reçus sans correspondance, les appels sans partenaire et les erreurs de synchronisation. Ces indicateurs permettent de distinguer une panne téléphonique d'un défaut de traitement dans Odoo.

Le déploiement progressif limite le risque. Le pilote doit conserver une procédure de retour arrière, un responsable identifié et un journal des changements. Après la bascule, l'équipe vérifie encore les appels entrants, les appels sortants et les tickets avant d'étendre le connecteur à tous les utilisateurs.

Garder FreePBX ou repartir sur la téléphonie native

FreePBX reste cohérent lorsque l'entreprise possède un héritage matériel, des scénarios multi-sites, des files spécialisées ou une personnalisation téléphonique déjà intégrée au CRM. Odoo prend alors la couche métier, tandis que FreePBX conserve la responsabilité des appels. Ce choix évite une migration forcée, mais il maintient une frontière technique à surveiller.

La téléphonie native d'Odoo convient mieux à un périmètre simple, avec peu de règles spécifiques et une volonté de réduire le nombre de composants. La documentation Odoo décrit désormais une application Téléphone intégrée à CRM et Assistance, alors que les versions antérieures reposaient davantage sur des PBX externes et des fournisseurs tiers. La décision porte donc moins sur la possibilité de connecter les outils que sur la plateforme que l'entreprise veut exploiter dans la durée.

Pour trancher, il faut chiffrer séparément la migration, les tests et la maintenance annuelle du connecteur. La comparaison doit couvrir :

• Le coût de migration, avec les postes, les numéros, les règles et la formation.

• La dépendance fournisseur, notamment pour les numéros, les enregistrements et les APIs.

• La réversibilité, avec l'export des historiques et la conservation des données.

• La charge d'exploitation, intégration, supervision et mises à jour comprises.

Pour une PME française, conserver un FreePBX fiable peut être plus prudent qu'une migration motivée par une interface plus moderne. En revanche, maintenir deux plateformes sans besoin fonctionnel clair ajoute des tests de compatibilité, des incidents possibles et une charge qu'il faut justifier. Le bon choix reste celui que l'équipe peut comprendre, tester, maintenir et rétablir sans dépendre d'une seule personne.

Voxbi propose un standard téléphonique cloud hébergé dans l'Union européenne, avec intégration native à Odoo, click-to-call et synchronisation des appels. Pour comparer cette approche à une architecture FreePBX-Odoo et évaluer le périmètre adapté à votre organisation, consultez Voxbi.