Votre migration Amazon Connect au Maroc n'est pas un projet informatique.

Une migration Amazon Connect n’est pas un simple chantier IT. C’est une refonte du service client, avec une couche technique au service d’objectifs opérationnels précis. Quand la DSI pilote seule, le projet glisse vite vers les intégrations, les licences et les sujets d’infrastructure. Le lien avec la qualité de traitement se perd, puis la plateforme est jugée sur sa mise en service, pas sur sa capacité à améliorer l’expérience.

Au Maroc, ce décalage de gouvernance explique une grande partie des retards et des reworks. Le bon cadrage ne consiste pas à durcir le contrôle technique. Il consiste à installer, dès le départ, un sponsor métier capable de trancher sur les parcours, les règles d’orientation et les priorités de service. Sans ce relais, la DSI arbitre seule des choix qui modifient pourtant le fonctionnement quotidien des équipes.

La DSI ne peut pas porter seule une migration CCaaS

La DSI lance souvent le projet. L’intégrateur parle architecture. Les métiers arrivent après. Le résultat est prévisible. On migre des flux d’appels, pas des parcours clients. On remplace une plateforme, mais on conserve les mêmes irritants de traitement, les mêmes retours en arrière et les mêmes zones grises entre front et back office.

Une migration CCaaS touche des sujets qui dépassent largement la technique. Les scripts d’accueil changent. Les règles de routage changent. Les horaires de prise en charge changent. Les niveaux de service changent aussi, tout comme les responsabilités entre agents, superviseurs et équipes de support. Si personne côté métier ne porte ces arbitrages, la DSI se retrouve à valider des décisions qu’elle ne peut pas mesurer seule en termes d’impact client.

Posez cette question en réunion : "Qui signe les arbitrages sur les files, les priorités de traitement et les exceptions métier ?" Demandez aussi : "Quel sponsor opérationnel peut modifier un parcours client sans repasser par trois niveaux de validation ?" Exigez un nom par domaine, pas un comité flou. Vérifiez dans le contrat que les ateliers de conception incluent les responsables métier, avec une présence obligatoire sur les décisions de routage et de traitement. Piège fréquent : un projet validé par l’IT, puis bloqué en production parce que les superviseurs découvrent trop tard que les exceptions n’ont jamais été cadrées.

Le vrai périmètre est métier, pas applicatif

Le cadrage classique commence par les licences, les connecteurs et la téléphonie. C’est rassurant pour l’IT, mais trop étroit pour le business. Amazon Connect ne corrige pas un modèle de service mal pensé. Il le rend simplement plus rapide, plus visible et parfois plus coûteux si les règles restent floues.

Le bon périmètre part des motifs de contact. Pourquoi les clients appellent-ils ? Où les demandes se répètent-elles ? À quel moment les transferts explosent-ils ? Où les abandons se produisent-ils ? Quels dossiers reviennent parce qu’ils n’ont pas été traités au bon endroit ? Ce n’est qu’après cette lecture que l’on définit les flux, les connecteurs, les profils et les règles d’accès. Sinon, on obtient une plateforme propre et une expérience dégradée.

Demandez à l’intégrateur : "Quel processus métier change dès la semaine 1, et qui en porte la responsabilité ?" Exigez une cartographie des irritants avant la cartographie des interfaces. Vérifiez qu’un propriétaire métier est nommé pour chaque cas d’usage, avec un critère de validation écrit. Piège précis : une intégration réussie techniquement, mais des agents qui continuent à escalader les mêmes demandes parce que le modèle de traitement n’a pas été revu. Le symptôme est clair : les volumes d’appels baissent peu, tandis que les réitérations augmentent.

Une migration CCaaS sans sponsor métier est un projet technique qui cherche encore sa raison d’être.

Le comité de pilotage doit arbitrer des décisions métier

Un comité qui suit seulement les risques, les charges et les jalons ne pilote pas une transformation. Il entretient un calendrier. Sur une migration CCaaS, les vrais arbitrages portent sur la délégation, les exceptions, la répartition front/back et les règles d’escalade. Ce sont ces décisions qui déterminent si le client obtient une réponse rapide ou un renvoi de plus.

Dans beaucoup d’organisations marocaines, le blocage vient d’un vide entre la DSI et les directions opérationnelles. Chacun suppose que l’autre décidera. Pendant ce temps, les paramétrages avancent. Les règles se figent. Les équipes terrain découvrent trop tard des choix déjà inscrits dans l’outil. Le projet devient alors un empilement de compromis techniques, sans validation claire sur l’usage réel.

Imposez un comité qui tranche sur des décisions visibles par le client. Posez cette question : "Qui a le pouvoir de valider un changement de parcours en moins de 48 heures ?" Demandez un ordre du jour centré sur les parcours, les exceptions et les responsabilités, pas seulement sur les livrables IT. Vérifiez que chaque arbitrage est signé par le métier concerné et qu’un délai de décision est fixé noir sur blanc. Piège fréquent : un comité qui reporte tout à la prochaine réunion, puis découvre en recette que personne n’a validé les cas limites.

Le budget doit suivre la transformation, pas la plateforme

Quand le budget est absorbé par la licence, l’intégration et la migration des postes, il ne reste presque rien pour l’adoption. C’est une erreur récurrente. La valeur d’une CCaaS se crée dans les scénarios, la formation ciblée, le pilotage quotidien et l’ajustement des opérations après la bascule. Sans cela, la plateforme est déployée, mais le service ne change pas vraiment.

Le sous-investissement métier se voit très vite. Les agents gardent leurs anciens réflexes. Les superviseurs n’exploitent pas les nouveaux tableaux de bord. Les responsables continuent à gérer par contournement, parce que les scripts n’ont pas été retravaillés et que les règles de traitement restent ambiguës. Le coût caché apparaît alors sous forme de recontacts, de temps perdu et de frustration interne.

Demandez : "Quelle part du budget est réservée à la conduite du changement métier, et qui la contrôle ?" Exigez une ligne dédiée pour les scripts, les formations par rôle, les tests de parcours et la stabilisation post-bascule. Vérifiez contractuellement que les ateliers de recette incluent les équipes opérationnelles, avec des critères d’acceptation liés aux usages réels. Piège précis : un budget entièrement consommé par la mise en service technique, puis aucune marge pour corriger les écarts de terrain. Le symptôme est immédiat : la production démarre, mais les équipes reviennent aux anciens outils ou aux procédures manuelles.

Le succès se mesure sur l’opération, pas sur la mise en production

Une migration n’est pas réussie le jour du cutover. Elle l’est quand les équipes traitent mieux, plus vite et avec moins d’escalades. Si les KPI restent centrés sur l’IT, vous mesurez la disponibilité de la plateforme, pas la qualité du service rendu. Le vrai test commence après la mise en production, quand les volumes réels, les exceptions et les pics d’activité révèlent la solidité du dispositif.

Les métriques utiles sont concrètes : taux de résolution au premier contact, qualité des routages, temps de traitement réel, taux de transfert, réitérations, stabilité des parcours et volume d’escalades vers le back office. Ces indicateurs montrent si la gouvernance tient. Les indicateurs techniques seuls ne disent rien de l’expérience vécue par le client ni de la charge support supportée par les équipes.

Avant la bascule, faites valider un tableau de bord métier par les opérations. Posez cette question : "Quels KPI seront suivis à J+30 et à J+90, et qui les commente ?" Demandez un seuil d’alerte contractuel sur les réitérations, les transferts et les abandons. Vérifiez que le plan de stabilisation prévoit des revues hebdomadaires avec décisionnaire métier. Piège fréquent : un go-live célébré comme un succès alors que les indicateurs de service se dégradent dès la deuxième semaine, faute de pilotage opérationnel réel.