Intégration d'un assistant téléphonique IA : relier proprement numéro, standard téléphonique et CRM

Un moment typique : une cliente appelle, cela sonne quatre fois au bureau, puis deux fois sur le portable de la patronne, puis la messagerie se déclenche, et peu après un assistant décroche en plus. Personne n'a rien fait de mal, chaque élément fait exactement ce pour quoi il a été configuré. Simplement, on n'a jamais défini dans quel ordre ils devaient fonctionner ensemble.

Dans ce scénario, l'entreprise a accumulé au fil des ans un ensemble téléphonique. Il y a un numéro principal chez l'opérateur, un standard ou un système téléphonique cloud avec plusieurs postes, des mobiles avec renvoi d'appel et un CRM où se trouvent les données clients et les notes. La planification des rendez-vous se fait dans un agenda que tantôt le secrétariat, tantôt les collaborateurs eux-mêmes tiennent à jour.

Un assistant téléphonique IA arrive dans cet ensemble comme participant supplémentaire. Il doit prendre les appels lorsque personne ne peut le faire, recueillir les demandes de façon structurée, enregistrer des rendez-vous et laisser un résultat à l'équipe. Qu'il parle bien n'est que le ticket d'entrée. Son utilité se décide dans le câblage, c'est-à-dire dans la question de savoir quel appel lui parvient et quand, et où va son résultat.

Le premier endroit est le numéro lui-même. Qui a son numéro principal chez un opérateur, utilise un standard cloud chez un deuxième et a ses numéros mobiles chez un troisième doit clarifier qui contrôle réellement l'acheminement des appels. Un renvoi d'appel configuré au mauvais endroit est écrasé par un autre réglage, et personne ne s'en aperçoit avant le premier appel manqué.

Le deuxième endroit est la signalisation des appels. Lorsqu'un appel est renvoyé, le numéro de l'appelant n'arrive pas toujours inchangé à destination. Avec certains renvois, c'est le numéro de la ligne qui renvoie qui apparaît, ou bien l'identification de l'appelant est perdue. Sans numéro d'appelant fiable, le rapprochement avec le CRM échoue, et l'assistant doit demander le nom à chaque fois.

Troisièmement, les données. Un CRM est rarement aussi propre qu'on le souhaiterait : contacts en double, numéros écrits de diverses façons, numéros professionnels et privés mélangés. Un rapprochement qui se fie à un seul numéro tombe donc parfois sur la mauvaise personne, et l'assistant salue quelqu'un avec le nom d'un autre. C'est plus gênant que pas de reconnaissance du tout.

Quatrièmement, la protection des données. Le contenu des conversations, les transcriptions et les enregistrements sont des données personnelles. Où ils sont conservés, combien de temps ils restent et qui peut les lire doit être établi avant le démarrage. Les indications suivantes constituent une orientation technique et ne remplacent pas un conseil juridique. Pour une appréciation contraignante, vous devriez associer votre délégué à la protection des données ou un conseil juridique.

Une image en couches est utile. Tout en bas se trouve le numéro, avec l'opérateur qui le gère. Au-dessus, le standard, qui répartit les appels vers les postes. Au-dessus, l'assistant, qui mène les conversations. Au-dessus, les systèmes métier, où se trouvent clients, rendez-vous et tâches. Chaque couche a ses propres responsabilités, et les erreurs se propagent vers le haut, jamais vers le bas.

Il en découle une règle de contrôle : les problèmes se cherchent de bas en haut. Si l'assistant ne reconnaît pas l'appelant, la cause est rarement la logique de conversation et plus souvent la signalisation en dessous. Si un rendez-vous apparaît en double dans l'agenda, cela tient peut-être à la liaison, pas au dialogue. Qui respecte cet ordre s'épargne de longues recherches au mauvais endroit.

Un exemple tiré de la pratique de ces raccordements : l'assistant se présente à chaque appelant par « Bonjour, vous parlez à l'assistant numérique », alors que l'appel venait d'être transféré par l'équipe. La cause ne se trouve alors pas dans le dialogue, mais dans le fait que le standard marque l'appel comme un nouvel appel. Ces symptômes sont discrets, mais ils marquent l'impression de l'appelant plus que n'importe quelle formulation. C'est pourquoi nous documentons, pour chaque couche, ce qu'elle doit fournir et comment le vérifier.

Séparer la décision de l'exécution est tout aussi utile. L'assistant devrait décider de quoi il s'agit, mais les systèmes métier devraient faire respecter ce qui est autorisé : créneaux libres, champs obligatoires, doublons. Ainsi, une erreur dans la conversation reste une erreur dans la conversation et ne devient pas une entrée erronée que quelqu'un devra corriger laborieusement plus tard.

Il existe pour l'essentiel deux voies pour placer l'assistant dans le trajet de l'appel. La première est le renvoi d'appel : le numéro existant reste, et sous certaines conditions l'appel est transmis à un numéro de l'assistant. La seconde est une connexion SIP, où le standard remet l'appel directement à l'assistant via une liaison basée sur SIP, un peu comme un poste supplémentaire.

Le renvoi d'appel se configure vite, nécessite peu d'interventions et peut être désactivé à tout moment. Ses limites tiennent au contrôle : selon l'opérateur, l'identification de l'appelant est perdue, le renvoi consomme des lignes supplémentaires, et l'on ne voit pas facilement dans le standard ce qu'il est advenu de l'appel. Pour une exploitation pilote, c'est néanmoins souvent un début pragmatique.

La connexion SIP est plus propre, mais plus lourde. Elle reçoit plus fiablement le numéro de l'appelant et les informations complémentaires, permet de remettre un appel de façon ciblée à l'assistant ou de le rendre à un humain, et fournit de meilleurs journaux. En contrepartie, le standard doit la prendre en charge, et la configuration, le chiffrement et le plan de numérotation doivent être corrects. Avec les standards cloud, c'est en général plus facile qu'avec d'anciens équipements matériels.

Notre recommandation est une succession d'étapes, pas un choix exclusif. Qui démarre petit utilise le renvoi d'appel et apprend quels appels aboutissent réellement chez l'assistant. Qui veut plus ensuite, par exemple passer l'appel à certaines personnes ou afficher le numéro de l'appelant pendant la conversation, passe à la connexion directe. Une alternative, déplacer entièrement le numéro principal vers l'assistant, nous ne la recommandons qu'avec un retour en arrière clair.

Techniquement, la téléphonie connaît plusieurs conditions dans lesquelles un appel est renvoyé : immédiatement, en cas d'occupation, sans réponse après une durée de sonnerie donnée, lorsque l'appareil est injoignable et selon l'horaire, par exemple le soir ou les jours fériés. Chacune de ces conditions a un caractère différent, et celle que vous choisissez détermine la façon dont l'assistant est perçu au quotidien.

Pour « occupé », l'intention est claire : qui est en pleine conversation ne devrait pas devoir prendre d'autres appels en plus. « Après X secondes sans réponse » est plus délicat. Si la durée de sonnerie est trop courte, l'assistant intervient alors que quelqu'un aurait décroché un instant plus tard ; si elle est trop longue, l'appelant raccroche avant. Un repère consiste à choisir la durée de sonnerie non pas au jugé, mais d'après les moments où les appelants raccrochent au quotidien. Cela peut se vérifier dans les journaux d'appels.

Les règles horaires semblent peu spectaculaires et sont pourtant la source d'erreurs la plus fréquente. L'agenda du standard ne connaît peut-être pas les fermetures annuelles, les ponts ni le passage à l'heure d'été, et un assistant qui répond encore lundi matin selon la logique de fin de journée paraît peu professionnel. C'est pourquoi nous saisissons les horaires particuliers dans une source unique et en déduisons les règles, au lieu de les tenir à plusieurs endroits.

Il importe que chaque règle ait un but reconnaissable que l'équipe puisse énoncer. « L'assistant décroche lorsque les deux lignes sont occupées et que personne ne répond après 20 secondes » est une règle. « Il intervient un peu comme ça » n'en est pas une. Qui met les règles par écrit découvre généralement au passage que la pratique antérieure était contradictoire.

Après l'appel commence la partie moins visible. L'assistant détermine le numéro de l'appelant, le met dans un format uniforme et cherche avec lui dans le CRM. C'est précisément ici que naissent la plupart des erreurs en aval, car le même numéro peut être enregistré sous la forme « 0151… », « +49 151… » ou avec des espaces et des parenthèses. Une normalisation avant la comparaison est donc une obligation, pas un bonus.

Le rapprochement donne trois états possibles : exactement une correspondance, plusieurs ou aucune. Ce n'est que dans le premier cas que l'assistant peut saluer personnellement, et même alors il devrait confirmer le résultat avec délicatesse, par exemple par « Est-ce bien Madame … ? », au lieu de le présupposer. S'il y a plusieurs correspondances, il pose la question ; s'il n'y en a aucune, il crée un nouveau contact à l'état de brouillon, qu'une personne vérifie avant qu'il ne soit repris dans la liste des clients.

Le résultat d'une conversation comprend plus qu'une transcription. Nous enregistrons dans le CRM un court résumé, la demande dans une catégorie fixe, la prochaine action convenue et le renvoi vers la transcription. Le résumé sert à l'équipe, la transcription de justificatif en cas de questions. Qui n'enregistre que la transcription produit des textes que personne ne lit.

L'agenda et l'attribution des rendez-vous passent par une interface qui interroge les créneaux libres et renvoie les réservations avec une confirmation. L'assistant ne réserve que lorsque le système a confirmé la réservation, puis communique le rendez-vous à l'appelant. Si la réservation est refusée, par exemple parce que le créneau a entre-temps été pris, il propose des alternatives au lieu de donner une assurance qui ne vaut pas.

Lors de la portabilité du numéro, c'est-à-dire le transfert d'un numéro existant vers un autre opérateur, la planification décide de la durée d'interruption. Le changement a lieu à un moment déterminé, et dans la fenêtre de temps autour il devrait exister une voie supplémentaire, par exemple un numéro de secours branché en parallèle. Nous recommandons de ne pas fixer la portabilité en même temps que le démarrage de l'assistant. Deux changements à la fois rendent chaque perturbation plus difficile à attribuer.

Les numéros masqués constituent le deuxième cas particulier. Qui appelle avec un numéro masqué ne peut pas être reconnu automatiquement, et c'est son droit. L'assistant entre alors dans la conversation sans rapprochement et demande aimablement le nom et un numéro de rappel, sans faire de ces indications une condition. L'important est que ce chemin ne paraisse pas un pis-aller, mais soit un déroulement à part entière.

Le troisième cas est la panne : le CRM est inaccessible, l'interface de l'agenda ne répond pas, ou l'assistant lui-même est en défaut. L'appel ne doit dans aucun de ces cas se perdre dans le vide. Nous prévoyons une logique de repli : si l'assistant est injoignable, le standard revient après peu de temps à la règle antérieure. Si seul le CRM est en panne, l'assistant recueille tout de même la demande et la conserve en tampon jusqu'à ce que le transfert fonctionne de nouveau.

Tout raccordement comporte une décision sur ce qui est conservé. La variante sobre ne retient que le résumé structuré et la demande. La plus étendue conserve en plus la transcription, une autre variante aussi l'enregistrement sonore. À chaque niveau, l'utilité pour les questions ultérieures et le contrôle qualité augmente, mais aussi la responsabilité. Selon le principe de minimisation des données : conservez ce dont vous avez démontrablement besoin, et non ce qui est techniquement possible.

La suppression exige un plan réalisable techniquement : durées de conservation fixes par type de données, suppression automatique à l'échéance et procédure pour les demandes d'accès et de suppression de personnes concernées. Nous décrivons dans quels systèmes se trouvent les données, afin que la suppression ne se fasse pas seulement dans le CRM tandis que des transcriptions subsistent dans le système téléphonique et des journaux chez l'opérateur. La durée de conservation est fixée par l'entreprise avec son conseil juridique.

Un enregistrement sonore est juridiquement plus exigeant qu'une transcription, car il capte la voix. Il faudrait clarifier expressément si et à quelles conditions l'enregistrement est permis avant que l'assistant ne passe en production. Les appelants doivent pouvoir voir dès le début qu'ils parlent à un système automatique et si la conversation est enregistrée. Les droits d'accès sont le troisième levier : tout le monde dans l'équipe n'a pas besoin de pouvoir lire chaque conversation, et plus les droits sont restreints, plus il sera facile d'expliquer plus tard pourquoi les données se trouvent où elles se trouvent.

Il est réaliste de s'attendre à ce que moins d'appels restent sans réponse et que l'équipe trouve après la fermeture des entrées structurées plutôt que des petits papiers. De plus, une partie des reprises disparaît, car le contact, la demande et le souhait de rendez-vous se trouvent déjà dans le bon système. Que cela représente beaucoup ou peu dans votre entreprise dépend du volume d'appels, des horaires et de la qualité de vos données. Des chiffres concrets ne peuvent être donnés qu'après une phase pilote.

L'intérêt se mesure d'après les points cités plus haut : part des appels décrochés, part des entrées exploitables, nombre de remises et de corrections manuelles, ainsi que le délai entre l'appel et le retour de l'équipe. Il n'existe pas de garantie que cela génère davantage de commandes. Qui le promet confond disponibilité et demande.

Quatrième cas : plusieurs sites, plusieurs numéros ou des collaborateurs avec leurs propres lignes directes. Ici, l'affectation relève d'un tableau unique qui précise quel numéro correspond à quelle équipe, quel agenda et quel message d'accueil. Sans ce tableau, la logique se développe en règles isolées, et personne ne peut plus comprendre pourquoi un appel aboutit à un endroit donné.

Avant toute bascule, il y a un test avec un numéro de test propre que seule l'équipe connaît. Nous y vérifions les parcours de conversation, la reconnaissance, la réservation dans l'agenda et la remise, avec des cas volontairement gênants : numéro masqué, numéro avec doublon dans le CRM, appel peu avant la fermeture, appel pendant la fermeture annuelle, coupure en pleine conversation. Les erreurs trouvées ici ne coûtent rien.

Vient ensuite une phase pilote d'ampleur limitée. L'assistant ne prend d'abord que les appels en dehors des heures d'ouverture ou seulement en cas d'occupation. Une personne lit chaque jour les résultats et repère les mauvaises attributions. De ces repérages naît une courte liste d'ajustements pour la conduite de la conversation, les règles de rapprochement et l'agenda. Ce n'est que lorsque la liste ne fait plus apparaître de nouveaux points pendant plusieurs jours que le périmètre est étendu.

Pour l'évaluation, nous définissons à l'avance quelques points de mesure. Combien d'appels l'assistant a-t-il pris, dans combien a-t-il abouti à une entrée exploitable, à quelle fréquence l'appel a-t-il été remis à un humain et combien d'entrées ont dû être corrigées manuellement ? Ces questions trouvent leur réponse dans le journal d'appels et le CRM. Des chiffres de comparaison avant le démarrage sont utiles, mais doivent être considérés comme une approximation, car la mesure antérieure était rarement complète.

Un critère clair de retour en arrière est important. Si plus d'une part convenue des appels est mal traitée, l'équipe désactive la règle et revient à l'ancien renvoi. Fixer ce critère à l'avance évite les discussions sous la pression du temps et donne à tous les participants l'assurance qu'un essai ne devient pas une impasse.

De la conception découlent quelques principes. Écrire d'abord les parcours d'appel, choisir ensuite la technique. Commencer par le renvoi d'appel et ne passer à la connexion directe qu'en cas de besoin. Traiter l'identification de l'appelant comme une aide, non comme une certitude. Conserver ce qui est nécessaire et penser dès le début à la suppression. Et configurer chaque étape de façon que le retour à la solution antérieure reste ouvert à tout moment.

La prochaine étape est modeste. Notez les numéros de téléphone de votre entreprise, l'endroit où le routage des appels est configuré et les systèmes qui doivent recevoir les résultats des appels. De là naît, lors d'un premier échange, une évaluation de la voie de raccordement adaptée à votre téléphonie, des données à nettoyer et de ce à quoi pourrait ressembler un pilote prudent. Nous vous dirons aussi si l'effort ne se justifie pas dans votre situation.

Il peut être tout à fait honnête de conclure que votre solution actuelle suffit. Si vous recevez peu d'appels et que leur perte compte à peine, un renvoi d'appel plus clair vers un mobile et un message de messagerie vocale soigné peuvent suffire. Un assistant se justifie là où des appels arrivent à des heures où personne ne peut décrocher, et où la conversation débouche sur une étape suivante concrète. Cette distinction, nous la faisons volontiers avec vous, avant d'écrire la moindre ligne de configuration.

Trois éléments suffisent pour la préparation : une liste de vos numéros avec l'opérateur, une capture d'écran ou une description des règles de renvoi actuelles et un extrait du CRM avec une vingtaine de contacts typiques. Nous voyons ainsi à quel point les numéros sont proprement enregistrés et quel nettoyage serait judicieux avant un pilote.