Comment migrer vers le CCaaS sans perdre d’appels : un plan en 7 étapes pour 2026

En bref

Pour migrer vers le CCaaS sans perdre d’appels, renvoyez d’abord vos anciens numéros vers de nouveaux numéros sur la plateforme cloud, puis effectuez leur portage en dernier. Tout ce qui précède le portage peut être annulé par un changement de configuration. Un portage terminé, non, et aux États-Unis, un portage prend 2 to 4 weeks une fois les documents conformes. Faites donc l’inventaire, reconstruisez, testez sur des numéros de réserve et lancez un pilote sur une file d’attente pendant que l’ancien système prend encore en charge la plupart des appels.

La plupart des plans négligent le côté support : l’outil de support ne déménage pas, mais ses connexions avec la téléphonie changent. Le coéquipier IA d’eesel travaille dans l’outil de support, il continue donc de répondre aux tickets pendant la bascule.

À qui s’adresse ce guide (et ce qu’il vous faut d’abord)

Ce guide s’adresse aux responsables support ou opérations qui transfèrent une ligne téléphonique de support client depuis un PBX sur site ou une ancienne infrastructure de technologie de centre d’appels vers une solution cloud (CCaaS, centre de contact en tant que service) : Amazon Connect, Genesys Cloud, Talkdesk, Five9, Zendesk Talk, Aircall, Twilio Flex et les autres. Si vous êtes encore en train de choisir une plateforme, mon tour d’horizon des logiciels de centre d’appels présente les principaux candidats. Si vous utilisez Freshdesk, le module intégré Freshdesk Contact Center est une autre option, et Dialpad ainsi que les alternatives à Aircall couvrent les besoins plus légers. Cet article porte sur la migration elle-même.

Je suis ingénieur chez eesel et je consacre l’essentiel de ma semaine aux intégrations, ce qui implique de passer beaucoup de temps dans les API des outils de support et de téléphonie d’autres entreprises. Le schéma que je constate est toujours le même : la téléphonie bénéficie d’un plan de projet, et les connexions entre le système téléphonique et l’outil de support se retrouvent dans une ligne intitulée « intégrations ». C’est au niveau de ces connexions qu’une bascule peut mal tourner sans bruit.

Si vous utilisez aussi un agent IA, la CLI eesel offre à vos ingénieurs un accès secondaire pilotable par scripts pendant la migration : un agent de programmation IA comme Claude Code peut importer des connaissances approuvées (articles d’aide exportés, macros, nouveaux scripts de SVI), puis poser des questions de test à l’agent pour vérifier ses réponses avant toute mise en production. La connexion de l’outil de support lui-même nécessite toujours l’approbation d’une personne disposant d’un accès administrateur.

Préparez ces éléments avant l’étape 1 :

• Une copie de la facture téléphonique ou du Customer Service Record (CSR) pour chaque opérateur. Les documents de portage doivent y correspondre exactement.
• Un titulaire du compte opérateur habilité à signer. AWS demande une signature manuscrite sur la LOA (lettre d’autorisation) et indique que la plupart des opérateurs refusent les signatures électroniques.
• Un accès administrateur à votre outil de support et à votre CRM, car vous allez les reconnecter.
• Vos rapports d’appels des 90 derniers jours (volume par heure, taux d’abandon, durée de traitement), qui serviront de référence pour comparer la nouvelle plateforme.

Pourquoi tant de centres de contact migrent-ils maintenant ?

Pour beaucoup d’équipes, la migration n’est pas facultative. Les grands produits de centre de contact sur site arrivent au terme de leur prise en charge par les fournisseurs, et le réseau téléphonique cuivre du Royaume-Uni est en cours d’extinction. Voici les dates indiquées sur les pages des fournisseurs et des régulateurs eux-mêmes :

Si une échéance de ce type vous pousse à agir, établissez votre calendrier à rebours et commencez tôt les démarches auprès de l’opérateur. AWS indique exiger que les demandes de portage soient ouvertes "several months before pending go-live dates", car les opérateurs bloquent les portages les jours fériés et pendant les opérations de maintenance.

Quelle est la seule étape que vous ne pouvez pas annuler ?

Le portage du numéro. Toutes les autres étapes d’une migration CCaaS sont des configurations que vous pouvez rétablir. Le portage transfère le numéro vers un nouvel opérateur, et AWS précise qu’une fois l’opération terminée, "the gaining carrier has sole control of the phone number." Le retransférer nécessite une nouvelle LOA, de nouveaux documents et un nouveau portage.

Cela change l’ordre dans lequel vous devez organiser le travail. La question n’est pas « à quelle date basculons-nous ? », mais « combien de temps pouvons-nous faire fonctionner les deux systèmes avant de franchir l’étape irréversible ? ». AWS et Salesforce donnent la même réponse pour gagner ce temps : commencer par le renvoi d’appels.

La checklist Voice de Salesforce avertit que le portage "is highly regulated, can't be rushed," et recommande trois actions : réserver un nouveau numéro pour les tests et la production, y renvoyer le trafic depuis le numéro d’origine jusqu’à ce que les tests soient terminés, puis porter le numéro d’origine. Le guide de migration d’AWS décrit cette même phase de renvoi comme permettant un "rapid rollback (which depends on a relatively simple change to call forwarding rules) without any dependencies on a carrier."

Le renvoi n’est pas gratuit, alors ne le laissez pas en place pendant des mois. AWS souligne que, tant qu’il est actif, vous payez l’appel entrant sur l’ancien numéro, le renvoi sortant et l’appel entrant sur le nouveau numéro, et que chaque appel mobilise un circuit sortant. Je considère le renvoi comme une assurance de quelques semaines, pas comme une configuration permanente.

Étape 1 : inventorier ce que fait l’ancien système

La plupart des surprises lors d’une migration viennent d’une fonction de l’ancien système que personne n’avait documentée. C’est la même leçon que les équipes apprennent lorsqu’elles changent d’outil de support. Avant de concevoir quoi que ce soit, listez tout :

Deux éléments méritent une attention particulière. Le premier est le SMS. Genesys avertit que les SMS d’un numéro porté "will not be automatically transferred along with voice service. In fact, the SMS services will likely be disrupted." Si vous envoyez des SMS de commande ou des rappels de rendez-vous depuis un numéro de support, signalez-le maintenant. Le second est toute étape du SVI qui interroge un système interne, comme « saisissez votre numéro de compte » avec vérification dans une base de données. Cette logique doit être reconstruite sur la nouvelle plateforme, et il est facile de l’oublier parce qu’elle se trouve dans un parcours que personne n’a ouvert depuis des années.

Étape 2 : concevoir la nouvelle configuration (reconstruisez-la, ne la copiez pas)

Les parcours d’appels ne se transfèrent pas d’une plateforme à l’autre. Un consultant Amazon Connect l’a dit clairement sur Hacker News :

"when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create "contact flows". You can export the flow to JSON. But it isn't portable to other environments without some remapping."

raw_anon_1111, Hacker News

Puisque vous reconstruisez de toute façon, simplifiez. Les recommandations d’AWS disent "don't limit yourself" au transfert à l’identique de l’ancien centre d’appels, et Salesforce recommande de partir de ses parcours de contact par défaut et de les enrichir. Un SVI à sept niveaux qui avait du sens en 2014 se réduit généralement à trois options et un rappel. Si vous utilisez Zendesk, mon guide du SVI Zendesk Talk présente une arborescence téléphonique allégée.

Une partie de ce que faisait l’ancien SVI relève désormais d’un standardiste téléphonique IA, capable de répondre aux questions simples avant même que l’appelant n’arrive dans une file d’attente.

Deux décisions de conception à prendre à cette étape :

1. Comment l’ancien et le nouveau système coexisteront. Les agents migrent généralement par groupes, et AWS note que la phase de migration "might take several months," avec des équipes sur différentes plateformes qui se transfèrent des appels. AWS suggère des numéros de transfert dédiés entre les plateformes afin de mesurer séparément les transferts interplateformes.
2. Ce qu’il advient des anciens enregistrements. AWS propose deux options : migrer les enregistrements et les rapports (vérifiez d’abord le format audio), ou les archiver sur place jusqu’au terme de leur durée minimale de conservation. L’archivage est souvent moins cher, mais quelqu’un doit être responsable de l’accès aux anciennes archives.

Attendez-vous à ce que la nouvelle plateforme exige de réelles compétences d’administration. Si vous quittez aussi Zendesk, mon guide de migration depuis Zendesk couvre le volet tickets. Un ingénieur téléphonie senior qui évaluait Genesys Cloud CX sur G2 a écrit :

"Genesys Cloud CX is extremely capable, but that capability comes with complexity. There are many situations where something that appears relatively straightforward ends up requiring Architect customization, Data Actions, APIs, or external automation."

Justin H., ingénieur téléphonie senior, avis G2

C’est une description juste de la plupart des plateformes CCaaS d’entreprise, Genesys compris. Prévoyez du temps d’ingénierie pour la reconstruction et évitez de vous retrouver dans une impasse : les pièges de la dépendance fournisseur qui concernent les outils IA s’appliquent aussi aux plateformes téléphoniques.

Étape 3 : refaire les connexions côté outil de support

C’est l’étape que la plupart des plans résument à une seule ligne, et c’est celle à laquelle je consacrerais plus de temps que vous ne le pensez. Le système téléphonique migre. Votre outil de support, votre centre d’aide, vos macros, votre CRM et votre agent IA restent là où ils sont. La téléphonie migre ; les connexions entre la téléphonie et l’outil de support doivent être reconstruites. Chacune doit être retestée.

Vérifiez trois connexions en particulier :

• Journalisation des appels en tickets. Chaque appel crée-t-il ou met-il à jour un ticket dans l’outil de support, avec l’enregistrement et l’appelant associés ? Si vous passez à un outil téléphonique connecté à votre outil de support, comme CloudTalk et Zendesk, testez l’apparence du ticket lors d’un appel réel.
• Affichage automatique de la fiche appelant. Lorsque le téléphone sonne, l’agent voit-il la fiche du client ? Cela dépend souvent de la correspondance entre le format de l’identifiant de l’appelant et celui du CRM, qui change d’un opérateur à l’autre.
• Rapports. La durée de traitement et le taux d’abandon sont calculés différemment sur chaque plateforme. Un utilisateur de Genesys Cloud sur G2 a trouvé les rapports personnalisés "difficult to navigate." Convenez des nouvelles définitions avec la direction avant la mise en production, sinon votre premier rapport mensuel ressemblera à une catastrophe qui n’en est pas une.

Vérifiez ensuite ce que les automatisations de votre outil de support font des tickets d’appel. C’est un détail souvent négligé : les configurations IA bien gérées excluent souvent volontairement les tickets téléphoniques. Lesson Pro, un groupe de marques de cours utilisant deux comptes Zendesk, fait ajouter à eesel des notes et des brouillons sur 1,900 tickets par mois, mais laisse les messages vocaux de côté. Luxedo, sur Gorgias, demande à son agent d’ignorer les tickets d’appels téléphoniques, les spams et les enquêtes pour ne rien dépenser dessus. Si votre nouvelle plateforme téléphonique nomme ou étiquette les tickets d’appel différemment de l’ancienne, ces règles cessent de fonctionner sans bruit, et l’IA se met soudain à rédiger des réponses aux transcriptions de messages vocaux. Vérifiez les déclencheurs, les vues et les automatisations qui filtrent les tickets d’appel.

L’avantage, c’est que le support par e-mail et par chat ne dépend pas du tout de la plateforme téléphonique. Un agent IA qui travaille dans l’outil de support continue de fonctionner pendant toute la migration. smava, une entreprise allemande de comparaison de prêts, utilise eesel sur un seul Zendesk pour deux marques : 27,000 tickets traités en un mois, 14,600 catégorisés et 15,300 brouillons de réponse préparés. Une file de ce type ne dépend pas de l’opérateur téléphonique utilisé.

SamCart présente un cas similaire sur Freshdesk : un agent traite les tickets Freshdesk et un autre gère le chat du site web, de sorte que le support écrit dispose de ses propres circuits.

Étape 4 : tester sur des numéros de réserve

Construisez la nouvelle configuration sur des numéros temporaires et testez-la avant qu’un appel client ne l’atteigne. La checklist de mise en production d’AWS demande que chaque ligne de service concernée ait "successfully run UAT scripts" à l’aide d’un numéro de téléphone temporaire.

Rédigez votre scénario de test en commençant par les échecs, puis par le parcours nominal :

Vérifiez aussi vos limites de capacité avant de tester à grande échelle. AWS indique que les nouvelles instances peuvent démarrer avec des quotas aussi faibles que "10 concurrent calls or 5 phone numbers", alors demandez des augmentations tôt. Et testez depuis les configurations réelles des agents : AWS recommande des casques USB filaires plutôt que Bluetooth ainsi qu’une connexion Ethernet filaire, et suggère de prévoir un budget pour les adaptateurs avant le début de la migration.

Étape 5 : lancer un pilote sur une file avec renvoi d’appels

Choisissez une file à faible risque (demandes générales, ligne informatique interne, petite région ; mon article sur les centres d’appels et centres de services explique pourquoi les lignes informatiques fonctionnent différemment) et renvoyez son numéro vers la nouvelle plateforme. Gardez les lignes à fort volume et à forts enjeux, comme la facturation, sur l’ancien système jusqu’à ce que le pilote fonctionne sans problème.

Décidez de vos seuils de retour arrière avant de commencer, avec des chiffres. La checklist de mise en production d’AWS vous demande de surveiller en temps réel les appels décrochés, le taux d’abandon, la durée moyenne de traitement et la longueur des files d’attente, et de garder un pont de conférence ouvert "until go-live (or rollback) activities have been completed." J’écrirais quelque chose comme « si le taux d’abandon dépasse le double de la référence des 90 derniers jours pendant une heure, nous rétablissons le renvoi précédent », et je définirais qui a l’autorité pour prendre cette décision.

Migrez ensuite les autres files par groupes. AWS indique que la période à deux plateformes est coûteuse et que, plus elle dure, plus "the risk of human errors such as making changes on the wrong platform." augmente. Avancez régulièrement, pas lentement.

Étape 6 : porter les numéros

Une fois que chaque file a fonctionné sans problème sur des numéros renvoyés, portez les numéros d’origine. Voici ce que les principales plateformes indiquent concernant les délais :

Le délai réglementaire est plus court que tous ceux-ci. Aux États-Unis, la FCC exige qu’un portage simple soit réalisé en un jour ouvré et un portage non simple en quatre jours ouvrés. Mais un bloc de numéros de centre de contact sur un trunk est rarement « simple », et les semaines du tableau correspondent aux formalités, à la validation et à la planification autour de la bascule réelle.

C’est sur les documents que les portages échouent. AWS énumère les quatre motifs de rejet courants : un solde ou des frais de portage sortant impayés, un nom ou une adresse qui ne correspond pas au CSR, un numéro qui ne peut pas être porté, et des informations manquantes comme une signature. Une LOA rejetée "resets the porting timelines." AWS exige aussi que la LOA date des 15 derniers jours, alors ne la signez pas un mois à l’avance.

Deux autres règles prennent souvent les équipes au dépourvu :

1. Ne résiliez pas trop tôt chez l’ancien opérateur. La FCC conseille de lancer le portage auprès du nouveau fournisseur avant de résilier l’ancien service, et Aircall avertit que les numéros d’un compte résilié peuvent être perdus définitivement.
2. Connaissez votre délai d’annulation. AWS exige un préavis de 5 jours ouvrés pour annuler ou reprogrammer, et une fois le numéro arrivé chez le nouveau RespOrg, "the port is complete."

Le jour du portage, AWS avertit que l’opération "can be disruptive", car les routes sont mises à jour chez les opérateurs, y compris ceux qui ne sont pas impliqués, et que "in rare cases it can take several hours" avant la stabilisation. Effectuez le portage un matin calme en semaine, gardez des agents connectés aux deux systèmes, surveillez la baisse du trafic sur l’ancienne plateforme et passez des appels de test sur chaque parcours.

Étape 7 : stabiliser, puis éteindre l’ancien système

Ne mettez pas l’ancien PBX hors service le lendemain du portage. Gardez-le en fonctionnement pendant un cycle de facturation complet et au moins une période chargée, afin de comparer les rapports (et vos chiffres de ROI du centre d’appels) et de récupérer d’anciens enregistrements en cas de litige. Prévenez le service financier que les coûts se chevauchent : AWS note que sa propre facturation augmente et que les coûts de l’ancien système ne diminuent qu’après la mise en production du nouveau centre de contact.

AWS signale aussi une lacune non technique : "user training, process changes, and service desk changes are often overlooked until the project is close to completion." Avant d’éteindre l’ancien système, assurez-vous que votre équipe informatique interne ou votre centre de services sait qui est responsable de la nouvelle plateforme et comment y signaler un incident. AWS suggère d’ouvrir un incident de test et d’en suivre tout le traitement.

Qu’en est-il du 911 et des agents à distance ?

Il s’agit d’une obligation légale aux États-Unis, pas d’une option de confort. Selon la Kari's Law, tout système téléphonique multilignes installé après le 16 février 2020, ce qui inclut votre nouvelle configuration cloud, doit permettre aux utilisateurs de composer directement le 911 sans préfixe comme « 9 », et doit envoyer une notification (avec un numéro de rappel et une localisation) à une personne susceptible de la voir.

Les règles de localisation sont plus strictes pour les agents travaillant à domicile. Selon le 47 CFR 9.16, les appareils utilisés hors site doivent fournir automatiquement une localisation permettant l’intervention des secours (une adresse postale validée) lorsque c’est techniquement possible, ou à défaut une localisation que l’utilisateur met à jour manuellement. En pratique, voici ma lecture : recueillez l’adresse de chaque agent à domicile, donnez-lui un moyen simple de la mettre à jour lorsqu’il déménage et testez le parcours d’un appel au 911 selon la procédure de test de votre service d’urgence local. Demandez à votre fournisseur CCaaS comment son téléphone logiciel gère cela avant la mise en production, pas après.

Checklist de préparation à la bascule

Cochez chaque élément une fois terminé. Si vous ne pouvez pas tous les cocher, le jour du portage n’est pas encore arrivé.

Combien de temps prend une migration CCaaS ?

Pour une équipe dans un seul pays avec un seul opérateur, deux à trois mois constituent un calendrier réaliste : quelques semaines d’inventaire et de conception, quelques semaines de reconstruction et de tests, un pilote, puis les 2 to 4 weeks de formalités de portage menées en parallèle. Plusieurs pays allongent le délai, puisqu’AWS annonce deux à six mois pour les portages hors des États-Unis et du Canada, et considère plus de 10 plages de numéros ou 10 sites comme "a project" nécessitant l’intervention de son équipe chargée du compte.

Le côté outil de support peut avancer beaucoup plus vite, et c’est tout l’intérêt de le garder séparé. Un agent IA qui travaille dans l’outil de support n’attend pas la téléphonie. Luxedo a connecté eesel à Gorgias en juillet, construit ses connaissances et ses instructions en août, puis activé le déclencheur durant la dernière semaine d’août, le tout sur Gorgias. Mon calendrier de déploiement du support IA détaille pourquoi la plupart des équipes se situent entre deux et huit semaines.

Essayez eesel pendant la migration de votre téléphonie

Une migration CCaaS représente quelques mois stressants pour une équipe support : les agents apprennent à utiliser un nouveau téléphone logiciel, la file pilote est instable et la direction veut savoir pourquoi les rapports ont changé. C’est un mauvais moment pour voir aussi s’accumuler les demandes par e-mail et par chat. Le coéquipier IA d’eesel rejoint votre outil de support existant (Zendesk, Freshdesk, Gorgias et d’autres), apprend à partir de votre centre d’aide, de vos macros et de vos anciens tickets (la même base de connaissances que celle utilisée par vos agents téléphoniques), et prépare des brouillons ou répond directement, afin que la file des demandes écrites reste calme pendant la migration de la téléphonie. Vous pouvez le tester en simulation sur d’anciens tickets avant qu’il ne réponde à qui que ce soit, et les forfaits commencent à $299 par mois pour 500 tickets sur la page des tarifs.

Essayez eesel gratuitement avec 100 crédits, ou réservez une démo si vous souhaitez de l’aide pour planifier son déploiement autour de votre bascule.