Introduction
L’intégration d’un système de téléphonie comme Asterisk avec un ERP/CRM tel que Dolibarr est un projet courant visant à centraliser les données clients et à améliorer la productivité des équipes commerciales et support. Cependant, dans un contexte réglementaire de plus en plus strict (RGPD, sectoriels…), cette interconnexion ne se limite pas à un chantier technique. Elle soulève des enjeux critiques de conformité, de sécurité des données et de traçabilité.
Cet article partage un retour d’expérience concret sur une telle intégration, en mettant l’accent sur les écueils à éviter et les bonnes pratiques pour garantir qu’elle renforce, au lieu de compromettre, la conformité de l’organisation.
1. Le périmètre de l’intégration et ses promesses
Typiquement, l’objectif est de faire remonter automatiquement dans Dolibarr les informations liées aux appels téléphoniques :
- Fiche client/contact : affichage automatique lors d’un appel entrant.
- Historique des interactions : enregistrement des appels (date, durée, numéro, agent).
- Création d’événements/opportunités : déclenchement automatique d’une fiche de contact ou d’uneaction commerciale/suite à un appel.
- Enregistrement des conversations (si activé) : lien direct entre le fichier audio et la fiche client dans Dolibarr.
Promesse opérationnelle : Une vue à 360° du client, une réduction des saisies manuelles et une meilleure gestion des leads.
Promesse de conformité (souvent sous-estimée) : Une traçabilité centralisée et fiable des interactions clients, une gestion sécurisée des données sensibles (conversations enregistrées), et une base pour des politiques de rétention des données claires.
2. Les défis de conformité rencontrés : au-delà de la technique
a) La qualification des données traitées
Problème : Un appel téléphonique n’est pas qu’un flux technique. Il est une conversation, potentiellement couverte par le secret des correspondances (article L. 34-5 du Code des postes) et contenant des données à caractère personnel (voire des données sensibles selon le contexte – santé, situation financière, etc.).
Leçon : Avant toute ligne de code, il faut une analyse juridique avec le DPO (Data Protection Officer) ou un conseil. Quelles données (numéros, enregistrements, transcriptions, notes de l’agent) seront transférées ? Sur quelle base légale (exécution du contrat, consentement) ?
b) La gestion des enregistrements téléphoniques
Problème : L’enregistrement des appels est un point de friction majeur. Où sont stockés les fichiers audio ? Qui y a accès ? Comment garantir leur intégrité ? Comment respecter le droit à l’effacement ?
Leçon apprise :
- Stockage : Ne jamais stocker les enregistrements bruts dans le répertoire web de Dolibarr. Ils doivent être dans un espace sécurisé, accessible via un lien ou une référence, avec des permissions fines (ex. : seul le commercial et son manager).
- Consentement : L’intégration doit bloquer l’enregistrement et son rattachement à une fiche client si le consentement n’a pas été préalablement et explicitement obtenu et enregistré (ex. : message vocal d’information au début de l’appel).
- Durée de conservation : Définir une règle claire (ex. : 5 ans après la dernière activité client), automatisée via un script de purge, et documentée dans la politique de rétention.
c) La sécurisation des flux et des accès
Problème : L’API ou le middleware qui relie Asterisk (souvent sur un serveur dédié) à Dolibarr (sur un autre serveur ou en SaaS) est un vecteur d’attaque. Quels identifiants sont utilisés ? Les communications sont-elles chiffrées ?
Leçon apprise :
- Privilégier des clés API spécifiques et à权限 restreintes (scoped), non des identifiants administrateur.
- Chiffrer les flux (HTTPS, TLS) entre les deux systèmes.
- Restreindre les accès IP côté Asterisk et Dolibarr aux seules adresses des serveurs concernés.
- Logger toutes les interactions de l’API pour une audit trail complète : qui a appelé l’API, quelle donnée a été lue/écrite, quand.
d) La transparence et les droits des personnes (RGPD)
Problème : Un client peut exercer son droit d’accès ou de rectification. Comment retrouver toutes ses données dans le système intégré ? L’historique des appels est-il inclus dans le dossier client ?
Leçon apprise : L’intégration doit permettre, via le module « Export des données personnelles » de Dolibarr, d’inclure systématiquement l’historique des appels et les liens vers les enregistrements (si consentement donné et données toujours conservées). C’est une fonctionnalité à valider en phase de recette.
e) La documentation et l’auditabilité
Problème : En cas de contrôle (CNIL, autorité sectorielle), il faut prouver comment les données circulent, sont protégées et détruites.
Leçon apprise : Rédiger une fiche de traitement spécifique pour l’intégration « Téléphonie-Asterisk/Dolibarr » et la jointe au registre des traitements. Elle doit décrire :
- Les données échangées.
- Les mesures de sécurité (techniques et organisationnelles).
- Les durées de conservation.
- Les acteurs (responsable de traitement, sous-traitants – hébergeur audio, etc.).
3. Architecture technique recommandée pour la conformité
Notre retour d’expérience a fait évoluer l’architecture vers un modèle plus robuste :
- Middleware dédié et sécurisé : Un micro-service (en Python/Node.js) fait l’interface entre Asterisk (via son CDR, son AMI, ou des events Asterisk) et l’API REST de Dolibarr. Il Centralise la logique métier et de conformité.
- Rôle du middleware : Vérifier le consentement, appliquer les règles de masquage des numéros (si nécessaire), formater les données, gérer les erreurs de manière sécurisée (pas de fuite de logs).
- Stockage externe et indexé : Les fichiers d’enregistrement sont déposés sur un stockage objet (S3, MinIO) avec des politiques de rétention automatiques. Le middleware stocke uniquement la référence (URL signée temporaire ou ID) dans Dolibarr, jamais le fichier brut dans la base de données SQL.
- Journalisation centralisée (SIEM) : Tous les logs du middleware, d’Asterisk et les accès aux fichiers audio sont agrégés dans un outil de type ELK ou Graylog. C’est indispensable pour l’investigation et l’audit.
4. Checklist de conformité avant mise en production
- [ ] Analyse d’impact (DPIA) réalisée si le traitement est à haut risque (enregistrement systématique, public, etc.).
- [ ] Consentement : mécanisme fiable, tracé, et révocable intégré au flux.
- [ ] Documentation technique et juridique à jour (fiche de traitement, architecture, procédures).
- [ ] Tests de sécurité : pentest de l’API et du middleware, revue des permissions.
- [ ] Plan de reprise/continuité : Que devient l’historique téléphonique en cas de panne de Dolibarr ou d’Asterisk ? (Les CDR d’Asterisk sont une sauvegarde minimale).
- [ ] Formation des utilisateurs : Les commerciaux doivent savoir que les appels sont enregistrés/stockés, comprendre les règles de confidentialité et savoir utiliser les nouvelles fonctionnalités dans le respect des droits.
- [ ] Validation de la purge : script testé pour supprimer les données trop anciennes dans Dolibarr ET sur le stockage audio.
Conclusion
Intégrer Dolibarr et Asterisk n’est pas un simple projet d’« automatisation ». C’est un projet de gouvernance des données clients. La conformité ne doit pas être un frein, mais un cadre qui guide l’architecture.
Notre expérience nous a appris que :
- Impliquez le DPO et la juridiction dès l’amont, pas en fin de projet.
- Préférez une architecture modulaire avec un middleware qui incarne les règles de conformité, plutôt qu’une connexion directe et opaque.
- Documentez exhaustivement chaque flux de données et chaque mesure de sécurité.
- Pensez « parcours client » et droits des personnes : l’intégration doit faciliter, non entraver, l’exercice de leurs droits.
En suivant cette approche, l’intégration Dolibarr/Asterisk dépasse son rôle opérationnel pour devenir un véritable atout en termes de traçabilité, de qualité des données et de confiance client, tout en positionnant l’entreprise sur des bases solides face aux exigences réglementaires présentes et futures.