Qu'est-ce que le CPaaS ?

Le terme ne repose sur aucune spécification. Les définitions en circulation proviennent de cabinets d'analystes et de fournisseurs, dans le cadre de catégories de marché qu'ils entretiennent. Plusieurs de ces glossaires ne sont pas consultables publiquement.

Que désigne réellement ce label ?

Un travail précis que vous devriez sinon faire vous-même.

Sans fournisseur, envoyer des SMS à grande échelle représente quatre tâches :

• Contrats opérateur et connexions dans chaque marché.
• Approvisionnement en numéros et formalités d'enregistrement associées.
• Règles par pays sur ce qui peut être envoyé et par qui.
• Les opérations qui maintiennent la livraison en état de marche.

Avec un fournisseur, c'est une requête HTTP.

Le schéma se répète pour chaque canal. WhatsApp et RCS ont des propriétaires de plateforme plutôt que des opérateurs, donc le travail devient approbations, examen de modèles et vérification d'entreprise. La logique est identique : quelqu'un détient la relation et l'expose sous forme d'API.

Comment en évaluer un ?

Par ce qu'il prend en charge, car l'API est la partie facile.

Cinq questions, chacune avec une réponse vérifiable :

• D'où vient le numéro, et qui l'enregistre ? Acheter un numéro est facile. Le faire approuver pour envoyer dans un pays donné, c'est le vrai travail. Un fournisseur qui vous renvoie cette tâche vous laisse la partie difficile.
• Que se passe-t-il quand un canal modifie ses règles ? Les politiques de canal évoluent. Soit le fournisseur absorbe le changement, soit il devient votre incident.
• Le détail de l'échec est-il exploitable ? Un échec de livraison signalé uniquement comme échoué ne permet aucune action. Un échec qui nomme une cause, si. La page de filtrage SMS de Bird expose ce que les opérateurs signalent ou non en retour.
• L'interface est-elle documentée comme un contrat ? Une spécification OpenAPI publiée est un engagement différent d'un simple site de documentation.
• La tarification par pays est-elle visible avant de vous engager ? Le prix d'un message varie selon la destination. Des tarifs invisibles tant que vous n'êtes pas client ne peuvent pas être comparés à ceux d'un concurrent.

Le CPaaS est-il la même chose que l'omnicanal ?

Non. Ils répondent à des questions différentes. Un produit peut satisfaire l'un sans satisfaire l'autre.

Le CPaaS concerne qui gère les télécoms. L'omnicanal concerne le partage d'état entre vos canaux. Un fournisseur peut exposer six canaux via une seule API tout en conservant pour chacun sa propre liste de contacts et son propre registre de consentement. Cela satisfait le premier critère, pas le second. Omnicanal vs multicanal explique comment tester la seconde affirmation.

Les acronymes voisins, CCaaS et UCaaS, désignent des produits de centre de contact et de communications internes, pas des API pour développeurs. Ils partagent le suffixe as-a-service, et pas grand-chose d'autre.

Quelle est la position de Bird à ce sujet ?

Contre le modèle tarifaire, pas contre la fonctionnalité.

Bird publie cette position sous le titre "The end of CPaaS". L'affirmation à l'intérieur est plus étroite que le titre. L'argument de Bird est que la messagerie s'est banalisée et que ses marges tendent vers zéro. Ce qui prend fin, selon cet argument, c'est la pratique tarifaire qui repose sur l'incapacité des acheteurs à comparer les tarifs entre pays et opérateurs. L'argument ne dit pas que la fonctionnalité va disparaître.

Cet argument a une forme vérifiable : les tarifs par pays d'un fournisseur sont-ils visibles avant de signer ? Les propres tarifs de Bird sont publiés par pays sur les pages de tarification, et non communiqués sur demande.