Paiement mobile, appareils d'entrée de gamme, réseaux instables, monnaies multiples. Ce qu'un produit conçu au Canada doit changer pour fonctionner en Afrique de l'Ouest.
Un produit conçu pour le marché canadien et déployé tel quel en Afrique de l'Ouest échoue rarement à cause de la traduction. Il échoue sur des hypothèses techniques que personne n'a formulées explicitement — parce qu'elles sont invisibles quand elles sont vraies.
Les hypothèses invisibles.
« L'utilisateur a une carte de crédit. » La pénétration de la carte de crédit est faible dans la plupart des marchés ouest-africains. Le paiement mobile, lui, est massif. Si ton parcours de paiement suppose une carte, tu n'as pas un problème d'adaptation : tu n'as pas de produit sur ce marché.
« La connexion est stable. » Elle est intermittente, et elle est facturée au volume. Une application qui recharge l'intégralité de son état à chaque écran ne coûte rien à Ottawa. À Lomé, elle coûte du crédit à l'utilisateur, qui la désinstalle.
« L'appareil est récent. » Le parc réel est dominé par des Android d'entrée de gamme, avec peu de mémoire vive et un stockage limité. Une application de 90 Mo ne s'installe pas sur un appareil dont il reste 400 Mo de libre.
« Une devise, une taxe. » Le franc CFA est arrimé à l'euro à parité fixe, ce qui simplifie une partie du problème — mais les taux de change, les frais de transfert et la fiscalité locale ne se traitent pas dans une variable de configuration.
Ce que ça change en conception.
Priorité au hors ligne. L'application doit fonctionner sans réseau et se synchroniser quand il revient. Cela impose une file d'opérations locale, une résolution de conflits explicite et une gestion visible des états. C'est une décision d'architecture, pas une fonction — l'ajouter après coup revient à réécrire la couche de données.
Le poids comme critère. Fixe un budget en octets — pour l'application installée et pour chaque écran — et fais-le échouer ta chaîne d'intégration s'il est dépassé. Sans mesure automatique, il augmente à chaque sprint sans que personne ne le remarque.
Le paiement mobile comme parcours principal, pas comme option secondaire ajoutée dans un menu. Les flux d'autorisation diffèrent de ceux d'une carte : confirmation par message, délais plus longs, statuts intermédiaires, échecs silencieux. Le parcours doit être conçu pour cette réalité, pas adapté.
Les numéros de téléphone comme identifiant. Le courriel est souvent secondaire. Formats internationaux, portabilité, réattribution des numéros par les opérateurs — un numéro peut changer de propriétaire, et ton modèle de comptes doit le prévoir.
Ce que ça change en exploitation.
Les fuseaux et les jours ouvrables : le Togo est à UTC, Ottawa oscille entre UTC−4 et UTC−5. Une tâche planifiée « à minuit » s'exécute au milieu de la journée de quelqu'un. Le soutien à la clientèle : le canal privilégié est fréquemment la messagerie instantanée plutôt que le courriel.
Et les tests sur du vrai matériel. Un émulateur ne reproduit ni la lenteur d'un appareil d'entrée de gamme, ni une connexion qui tombe au milieu d'une requête. Achète deux téléphones bas de gamme et teste dessus. C'est la dépense la plus rentable du projet.
Concevoir pour la contrainte la plus forte, puis relâcher. L'inverse n'est jamais vrai.●
Un produit conçu pour un appareil d'entrée de gamme sur réseau instable fonctionne parfaitement sur fibre à Ottawa. C'est exactement le même raisonnement que le bilinguisme conçu dès l'origine ou la conformité posée en semaine 1 : la contrainte intégrée tôt coûte peu et améliore le produit pour tout le monde.
Ce qu'on ne fait pas.
On ne « localise » pas un produit canadien pour l'Afrique de l'Ouest en changeant la devise et la langue. Si le marché ouest-africain fait partie du plan, il entre dans le cadrage en semaine 1 — au même titre que le marché principal.