Migration CCaaS : les 7 erreurs qui font dérailler un Go-Live.

Une migration CCaaS, c'est rarement la technologie qui pose problème. C'est presque toujours l'humain, la donnée, ou le calendrier — souvent les trois.

1. Sous-estimer la phase d'audit.

Beaucoup d'équipes voient l'audit comme un mal nécessaire à expédier en deux semaines. C'est une erreur. L'audit est l'étape qui détermine 80 % de la réussite du projet — celle où l'on découvre les flux non-documentés, les intégrations fragiles, les habitudes opérationnelles qui n'apparaissent dans aucun schéma.

Quatre semaines d'audit économisent six mois de Go-Live.

2. Confondre éditeur et architecture.

Choisir Genesys ou Amazon Connect, ce n'est pas une décision d'architecture. C'est un choix de partenaire. L'architecture vient ensuite : intégrations CRM, parcours client, gouvernance des flux, supervision. Le vendor lock-in commence à l'architecture, pas au logo.

Trois questions à poser avant de signer :

Premièrement : que se passe-t-il si l'on change d'éditeur dans cinq ans ? Deuxièmement : qui possède les données conversationnelles ? Troisièmement : à quel coût l'export ?

3. Sous-investir la formation.

Un conseiller mal formé est un conseiller frustré. Un conseiller frustré est un client mal servi. La formation n'est pas un poste à comprimer — c'est l'investissement qui rentabilise tout le reste.

4. Geler la date avant de connaître le périmètre.

La date de Go-Live se fixe souvent en comité de direction, calée sur un événement commercial ou la fin d'un contrat éditeur — bien avant que quiconque ait audité le périmètre réel. Le projet court alors après une échéance qui n'a jamais été calculée, seulement annoncée. Quand le périmètre rattrape le calendrier, on coupe dans le test ou dans la reprise de données. Les deux se paient au cutover.

Une date annoncée n'est pas une date tenable. C'est une date qu'il faudra défendre ou repousser.

5. Traiter la reprise de données comme une formalité.

Historiques d'interactions, enregistrements, configurations de routage, base de connaissances : la valeur vit dans la donnée, et c'est toujours le dernier lot qu'on traite. On découvre trois semaines avant le cutover que l'historique conversationnel n'est pas exportable dans un format exploitable, ou que des enregistrements à conserver plusieurs années vivent sur la plateforme qu'on s'apprête à éteindre. La reprise ne se règle pas en fin de projet. Elle se cadre dès l'audit.

6. Basculer en big bang un vendredi soir.

Le cutover total — toutes les files, toutes les équipes d'un coup — parce que « c'est plus simple à coordonner ». C'est surtout plus simple à rater. Un basculement progressif, un flux et une population pilote à la fois, coûte plus cher à orchestrer et sauve le projet le jour où quelque chose tombe. Le big bang n'a qu'un seul plan de secours : revenir en arrière. Et revenir en arrière le samedi matin, clients en ligne, ce n'est pas un plan.

7. Lancer sans sponsor ni décideur unique.

Un Go-Live est une suite de décisions sous contrainte : on accepte ce défaut mineur ou on repousse ? on bascule ou on attend ? Sans sponsor exécutif et sans décideur unique identifié, chaque arbitrage remonte un comité — et le projet s'arrête le temps que la politique tranche. La gouvernance n'est pas un livrable de confort. C'est ce qui permet de décider en deux heures au lieu de deux semaines.