On-premise, hébergé ou cloud
Trois formules, et c'est celle du milieu qui crée le plus de confusion. L'on-premise, c'est votre logiciel sur votre matériel dans vos locaux : contrôle total, et chaque mise à niveau, chaque panne et chaque décision de capacité vous incombe. L'hébergé, c'est en général ce même logiciel sur le matériel de quelqu'un d'autre — déplacé, pas ré-architecturé, toujours versionné et toujours plafonné par instance. Le cloud est un service multi-tenant où la capacité est élastique et où les mises à niveau arrivent sans fenêtre de maintenance.
Les fournisseurs emploient « hébergé » et « cloud » indifféremment, et ce ne sont pas les mêmes achats. La question qui les sépare : si le volume d'appels triple lundi, la capacité suit-elle automatiquement, ou faut-il que quelqu'un la provisionne ?
Ce que vous cessez de maintenir
C'est là le bénéfice honnête, et il est opérationnel plutôt que perceptible par l'appelant. Les cartes de téléphonie et les serveurs média, le cycle de correctifs, la planification de capacité pour les pics saisonniers, et le site de reprise après sinistre qui existe pour être testé et ne sert jamais. Tout cela cesse d'être à votre charge.
Ce qui ne disparaît pas, c'est le flux d'appel. L'arbre doit toujours être conçu, et un menu mal conçu est exactement aussi frustrant depuis le cloud qu'il l'était depuis le sous-sol — le modèle de déploiement n'a aucun avis sur la pertinence de l'option quatre.
Bascule et disponibilité
Les taux de disponibilité sont annoncés pour la plateforme, et la plateforme n'est pas tout le trajet. Un appel traverse votre opérateur, le SIP trunk, le réseau entre les deux, puis le service. Un chiffre annoncé sur le dernier segment ne vous renseigne que sur le dernier segment.
Demandez ce qui se passe en cas de panne plutôt qu'à quelle fréquence elle survient. Où vont les appels — un numéro de repli, un message enregistré, une tonalité d'occupation — et cette bascule se déclenche-t-elle automatiquement ou faut-il que quelqu'un s'en aperçoive d'abord ? Le second cas est fréquent et rarement annoncé.
Modèle de coûts
Le changement fait passer de l'investissement aux charges d'exploitation, et il déplace celui qui ressent le coût. L'on-premise, c'est un achat important puis des années d'amortissement : la croissance est presque gratuite jusqu'à ce qu'elle cesse brutalement de l'être, au moment où vous dépassez la capacité. Le cloud se facture par canal ou à la minute : la croissance coûte proportionnellement et rien n'est immobilisé.
Pour un volume stable et prévisible, l'on-premise peut rester moins cher sur un tableur — c'est une vraie réponse, pas une concession. Pour un volume qui connaît des pics, l'élasticité vaut plus que le tarif unitaire, car l'alternative consiste à acheter pour le pic et à rester inactif le reste de l'année.
Migration
Le portage des numéros est l'élément le plus long, et il comporte une bascule à date fixe — planifiez la date de mise en service autour de lui plutôt qu'autour de la construction. Reconstruisez l'arbre au lieu de le transcrire : un IVR qui a accumulé des branches pendant dix ans contient des options que personne n'a choisies depuis des années, et une migration est l'occasion la moins coûteuse que vous aurez de les supprimer.
Si vous migrez de toute façon, c'est aussi le moment de vous demander si le menu a encore la bonne forme — voir IVR contre agent vocal IA. Non pas parce que l'IVR cloud serait une étape intermédiaire ; beaucoup d'exploitations devraient simplement faire tourner un menu bien conçu dans le cloud et s'en tenir là. Mais la migration est le moment où la question coûte le moins cher à trancher, et le budget de latence dont vous héritez mérite d'être compris d'abord — le calculateur de latence montre où passe réellement le temps, et c'est rarement là où on l'imagine.
