Comment ça marche

Un catalogue,
trois voies d'intégration

Clementine se place entre deux groupes qui ne peuvent pas se rejoindre efficacement seuls. Les applications grand public mondiales ont des utilisateurs en Afrique du Nord mais aucun moyen de les faire payer. Les opérateurs télécoms, distributeurs, fabricants d'appareils et boutiques d'applications ont des clients qui paient mais aucun moyen efficace de sourcer des dizaines d'applications mondiales, une négociation à la fois. Clementine réunit en un seul endroit les accords éditeurs, les intégrations de facturation locale et la localisation arabe/française, puis met ce catalogue à disposition des distributeurs via l'une des trois voies techniques ci-dessous.

Le modèle en trois étapes

Clementine ne développe pas les applications de son catalogue, et ne construit pas les boutiques que ses partenaires distributeurs exploitent déjà. Elle résout la partie intermédiaire — celle qu'aucun des deux camps ne peut résoudre seul.
  • Un éditeur signe un seul accord. Une relation couvre les six marchés au lieu de six négociations distinctes. L'éditeur ne fournit aucun travail technique : aucun SDK à intégrer, aucune API à appeler de son côté.
  • Clementine se charge du travail local. Facturation opérateur et rails de mobile money, prise en charge de la localisation arabe et française, et marketing local — assemblés une fois, par marché, et réutilisés sur l'ensemble du catalogue.
  • Les distributeurs proposent le catalogue à leurs clients. Via leur propre application, leur propre boutique ou une application prête à être rebrandée — les trois voies ci-dessous.

Pourquoi les éditeurs n'intègrent rien

C'est le point que l'on comprend le plus souvent à l'envers, il mérite donc d'être dit clairement : le SDK, l'API et l'application en marque blanche sont destinés aux distributeurs. Un éditeur qui rejoint le catalogue n'intègre rien dans son application, n'appelle aucune API et ne publie aucune version pour prendre en charge Clementine. C'est délibéré. La feuille de route technique d'une application mondiale est la ressource la plus rare de toute discussion d'expansion, et exiger six intégrations opérateur pour ouvrir un marché de taille incertaine est précisément la raison pour laquelle la plupart des applications mondiales n'ont aujourd'hui aucune présence nord-africaine. Supprimer la demande d'ingénierie supprime la principale raison pour laquelle la réponse est généralement « pas cette année ».

Voie 1 — SDK mobile

Un SDK prêt à l'emploi pour un distributeur qui dispose déjà d'une application grand public avec une base installée — l'application de gestion de compte d'un opérateur, l'application de fidélité d'un distributeur, l'application mobile d'une banque. Le SDK ajoute le catalogue Clementine, le paiement et la gestion des droits directement dans l'application que le client a déjà sur son téléphone. Idéal pour les distributeurs qui ont une application et une audience, et veulent ajouter une source de revenus sans construire une boutique de zéro.
  • Ce qui est inclus : navigation et recherche dans le catalogue, paiement via facturation opérateur et mobile money, gestion des abonnements et des droits, couches d'interface arabe/française avec RTL complet.
  • Ce que construit le distributeur : le placement et la navigation dans son application existante, et le merchandising qu'il souhaite autour.
  • Effort : la voie d'ingénierie la plus légère offrant une véritable surface in-app. Cadrée par partenaire — la variable est généralement le cycle de publication de l'application hôte, pas l'intégration elle-même.

Voie 2 — API REST

Une intégration headless pour les distributeurs qui veulent maîtriser entièrement l'expérience. Le catalogue, la facturation et la localisation de Clementine sont exposés comme services backend ; la boutique, le merchandising et l'interface de paiement appartiennent entièrement au distributeur. Idéal pour les opérateurs qui construisent un produit « content club », les fabricants d'appareils qui font du bundling au niveau du terminal, et les partenaires techniquement matures disposant d'un design system et d'une équipe plateforme.
  • Ce qui est inclus : points d'accès catalogue et métadonnées, gestion des droits et des abonnements, initiation de facturation et callbacks, ressources de localisation.
  • Ce que construit le distributeur : l'intégralité du front-end, ainsi que sa propre analytique et sa logique de merchandising.
  • Effort : la voie la plus lourde, et celle qui offre le plus de contrôle. Adaptée aux partenaires disposant déjà d'une équipe plateforme.

Voie 3 — Application en marque blanche

Une application iOS et Android complète, prête à être rebrandée, préchargée avec le catalogue, la facturation et la localisation déjà câblés. Le distributeur applique son nom, son logo et ses couleurs, et lance. Idéal pour les distributeurs qui veulent aller vite sans effort d'ingénierie propre — y compris ceux qui ont une base client et une relation de facturation mais aucune application grand public existante sur laquelle s'appuyer.
  • Ce qui est inclus : l'application complète, sur les deux plateformes, avec catalogue, paiement, droits et interface arabe/française/anglaise, RTL compris.
  • Ce que fournit le distributeur : les éléments de marque, les comptes sur les stores et la relation commerciale avec ses clients.
  • Effort : la voie la plus rapide vers le lancement, et la moins flexible sur le design de l'expérience.

Choisir une voie d'intégration

 SDK mobileAPI RESTMarque blanche
Pour quiDistributeurs disposant d'une application grand publicDistributeurs construisant leur propre boutiqueDistributeurs sans application, ou pressés
Effort d'ingénierieModéréÉlevéMinimal
Contrôle de l'expériencePartiel: dans votre applicationTotalMarque uniquement
Front-end construit parClementine (embarqué)Le distributeurClementine
Facturation opérateur et mobile moneyInclusInclusInclus
Arabe / français / RTLInclusRessources fourniesInclus
Rapidité de lancementMoyenneLa plus lenteLa plus rapide

Les trois voies sont réservées aux distributeurs et s'appuient sur le même catalogue, les mêmes rails de facturation et le même travail de localisation. Les éditeurs n'en intègrent aucune.

Questions fréquentes

Les éditeurs d'applications doivent-ils intégrer un SDK ?+
Non. Le SDK, l'API REST et l'application en marque blanche sont tous destinés aux distributeurs. Un éditeur qui rejoint le catalogue signe un accord commercial et ne fournit aucun travail technique — aucun SDK, aucun appel d'API, aucune publication d'application.
Quels marchés un seul accord couvre-t-il ?+
Les six : le Maroc, l'Algérie, la Tunisie, la Libye, la Mauritanie et l'Égypte. Tout l'intérêt du modèle est qu'un éditeur négocie une fois plutôt que six, et qu'un distributeur source un catalogue une fois plutôt qu'application par application.
Un distributeur peut-il commencer par une voie et en changer ensuite ?+
Les trois voies partagent un même catalogue et un même ensemble de services de facturation et de localisation : ce sont des front-ends différents sur le même back-end. Un distributeur qui lance en marque blanche pour aller vite puis construit sa propre boutique sur l'API suit une progression normale, pas une migration vers un autre produit.
Quels types d'applications le catalogue est-il conçu pour porter ?+
Santé et bien-être, éducation et apprentissage des langues, divertissement, rencontres et réseaux sociaux, mobilité et livraison, productivité et IA grand public, voyage, enfance et sécurité familiale, et jeux mobiles. Les applications de fintech, néobanque et paiement, ainsi que le e-commerce de biens physiques nécessitant un dédouanement, sont explicitement hors périmètre. Ce sont les catégories pour lesquelles la plateforme est conçue — et non une liste de titres signés.

De quel côté du marché êtes-vous ?

Les deux parcours sont différents, les conversations aussi.