Intégrer la téléphonie au CRM : click-to-call, remontée de fiche, journalisation

Un commercial qui recopie un numéro du CRM vers son téléphone, puis note l'appel à la main dans la fiche, perd une à deux minutes par contact et oublie un appel sur trois. Multipliez par vingt appels et dix personnes : c'est un poste à temps plein qui s'évapore chaque semaine, et un historique client dans lequel on ne peut plus avoir confiance. Intégrer la téléphonie au CRM règle les deux, à condition de savoir ce que recouvrent les trois promesses des brochures, click-to-call, remontée de fiche et journalisation, et par quelle couche technique chacune passe réellement.

Les trois fonctions, dans l'ordre de valeur

Le click-to-call : un numéro de la fiche devient cliquable et l'appel part depuis le poste de l'agent, sans saisie. Il supprime les erreurs de numérotation et fait gagner trente secondes par appel ; c'est la fonction la plus simple à obtenir et la plus visible.

La remontée de fiche (screen pop) : lorsqu'un appel entrant arrive, le CRM ouvre la fiche du contact dont le numéro correspond, avant même le décroché. L'agent sait qui appelle, ce qu'il a commandé, le ticket ouvert. C'est elle qui change la qualité de la conversation, et elle n'est utile que si le numéro appelant est transmis proprement et si les numéros en base sont normalisés.

La journalisation : chaque appel, entrant ou sortant, abouti ou non, est inscrit dans la fiche avec l'horodatage, la durée, le sens, l'agent, le résultat et, le cas échéant, le lien vers l'enregistrement. C'est la fonction la moins spectaculaire et la plus rentable : elle rend l'historique exhaustif sans dépendre de la discipline de chacun, et elle alimente les rapports qui comptent (contacts par commercial, délai de rappel d'un lead, taux de joignabilité par créneau).

Ajoutez, pour un plateau, la qualification depuis le CRM (le code résultat saisi dans la fiche met à jour le composeur) et la création de fiche à la volée pour un appelant inconnu. Le reste, tableaux de bord et scripts d'appel intégrés, se construit sur ces briques.

Les quatre couches techniques possibles

Derrière les mêmes fonctions, quatre architectures très différentes, qu'il faut identifier avant de signer parce qu'elles n'ont ni le même coût ni la même fragilité.

• Le connecteur natif : une application publiée sur la place de marché du CRM par l'éditeur de la téléphonie, ou l'inverse. C'est le cas le plus confortable, mais aussi le plus opaque : vérifiez ce qu'il fait réellement (le click-to-call seul est fréquent), ce qu'il journalise, et ce qu'il devient quand l'une des deux parties change de version d'API.
• Le poste WebRTC embarqué : le téléphone est une barre dans le navigateur, dans la même fenêtre que le CRM, voire un composant inséré dans ses pages. Le numéro appelant est connu du script côté client, qui interroge le CRM et ouvre la fiche. C'est l'architecture la plus propre pour un plateau : aucun logiciel sur le poste, un seul écran, et les prérequis sont ceux détaillés dans notre article sur le poste agent WebRTC.
• Les API et webhooks : l'IPBX ou la plateforme émet un événement à chaque appel (sonnerie, décroché, raccroché, enregistrement disponible) vers une URL, et un petit service intermédiaire crée ou met à jour l'activité dans le CRM via son API ; à l'inverse, le click-to-call du CRM appelle l'API de la téléphonie pour lancer l'appel. C'est la voie la plus flexible et la plus durable, au prix d'un peu de développement ou d'un outil d'automatisation.
• Le CTI de poste : un logiciel installé sur le PC pilote le téléphone physique ou le softphone (TAPI, extensions de navigateur). Fonctionne, mais dépend du poste, du système et de l'utilisateur ; à réserver aux organisations qui ont déjà des téléphones de bureau et refusent le WebRTC.

Sur un IPBX libre, les événements viennent de l'interface de gestion (AMI ou ARI pour Asterisk, ESL pour FreeSWITCH) ; les plateformes de centre d'appels exposent le plus souvent une API HTTP et des webhooks. Si votre solution n'offre ni l'un ni l'autre, l'intégration se limitera à ce que le connecteur natif veut bien faire ; c'est l'un des critères de notre grille de choix d'une solution de call center.

Le travail invisible : les numéros

La remontée de fiche échoue d'abord sur les données. Un numéro appelant arrive en format international (+33612345678) ou national (0612345678) selon l'opérateur et la configuration du trunk ; les fiches contiennent des espaces, des points, des indicatifs collés, des numéros de standard partagés par dix contacts. Avant toute intégration, normalisez les numéros en base au format E.164, décidez de la règle lorsqu'un numéro correspond à plusieurs fiches (afficher une liste de choix plutôt que d'ouvrir la mauvaise), et prévoyez le cas du numéro masqué. Comptez que ce chantier de données représente souvent la moitié de l'effort réel du projet.

Côté sortant, le numéro présenté doit être celui du service, pas celui du poste, et il doit être rappelable et bien réputé ; un click-to-call massif depuis un numéro unique produit les effets décrits dans notre article sur les appels marqués spam.

Enregistrements liés et conformité

Attacher l'enregistrement à l'activité CRM est séduisant et dangereux. Séduisant, parce que le manager réécoute l'appel depuis la fiche, et que le litige se tranche en deux clics. Dangereux, parce que le CRM devient alors un dépôt d'enregistrements avec ses propres règles d'accès et de conservation, rarement alignées sur celles que le RGPD impose à l'enregistrement d'appels.

La bonne pratique est de ne pas copier le fichier dans le CRM mais d'y stocker un lien vers la plateforme de téléphonie, qui garde la main sur l'authentification, la journalisation des écoutes et la purge automatique à l'échéance. Quand l'enregistrement est supprimé, le lien meurt, et le CRM ne conserve que la trace de l'appel. Les durées et l'information des personnes sont celles de notre article sur l'enregistrement des appels et le RGPD ; l'intégration CRM n'y ajoute qu'une obligation, celle d'inscrire ce flux dans le registre des traitements et dans le contrat de sous-traitance de chacun des deux éditeurs.

Même prudence pour les données de l'appel : la journalisation transporte des numéros, des durées, parfois des transcriptions. Limitez les champs synchronisés à ce qui sert, et tenez compte de l'hébergement du CRM lorsque les données partent hors de l'Union européenne.

Ce que permettent les CRM courants

Sans promettre un connecteur clé en main pour chacun, voici où se situe le point d'entrée technique des CRM que nous rencontrons le plus chez les TPE, PME et plateaux francophones.

• HubSpot : un cadre d'extension dédié aux appels permet d'embarquer un téléphone WebRTC tiers dans l'interface, de journaliser automatiquement les appels comme activités et d'y attacher un enregistrement ; l'API gère la création d'engagements d'appel pour les intégrations serveur.
• Pipedrive : API riche sur les activités et les personnes ; le click-to-call passe par des liens tel: ou callto: interceptés par le poste, et la journalisation par création d'activité de type appel via webhook.
• Odoo : module VoIP intégré qui pilote un softphone WebRTC relié à un Asterisk ou un trunk compatible, avec click-to-call et journal d'appels dans les contacts et opportunités ; pour une plateforme externe, les API XML-RPC ou JSON-RPC créent les activités.
• Zoho CRM : espace d'intégration téléphonique qui standardise la remontée de fiche et la journalisation pour les fournisseurs qui l'implémentent, et API REST pour le reste.
• CRM métier ou maison : si l'application accepte un lien tel: et expose une URL que l'on peut appeler avec un numéro en paramètre, la remontée de fiche se fait en ouvrant cette URL à la sonnerie ; c'est modeste, mais cela couvre déjà l'essentiel.

Dans tous les cas, demandez une démonstration sur vos propres données, avec un appel entrant réel depuis un mobile, un appel sortant depuis la fiche, puis la vérification de l'activité créée. Les écarts entre la fiche produit et le comportement réel apparaissent en dix minutes.

Conduire le projet sans le subir

Commencez par la journalisation, pas par le click-to-call : c'est elle qui donne les chiffres pour piloter le reste, et elle ne change rien aux habitudes des utilisateurs. Enchaînez avec la remontée de fiche sur une équipe pilote, mesurez le délai moyen entre la sonnerie et l'ouverture de la fiche (sous deux secondes, sinon l'agent a déjà décroché à l'aveugle), puis généralisez. Gardez un mode dégradé : la téléphonie doit continuer à fonctionner quand le CRM est indisponible, et inversement, ce qui exclut les architectures où l'un bloque l'autre.

Enfin, fixez dès le départ les indicateurs que l'intégration doit améliorer : délai de rappel d'un lead entrant, nombre de contacts argumentés par commercial, part des appels journalisés. Ce sont ceux de notre article sur les KPI d'un centre d'appels, et c'est leur évolution, pas la liste des fonctions livrées, qui dira si le projet a servi à quelque chose.