Développement Firebase quand le marché a ses propres règles

La plupart des tutoriels Firebase supposent une connexion haut débit stable, un compte Stripe et un environnement de conformité qui pardonne les erreurs. Le Cameroun n'offre aucun de ces éléments par défaut. Je construis depuis Douala depuis avant que le Port en eaux profondes de Kribi ne devienne une alternative logistique sérieuse au port historique, et les contraintes logicielles que je rencontre reflètent les contraintes d'infrastructure : les règles sont réelles, les pénalités pour les ignorer sont réelles, et les contournements doivent être conçus plutôt qu'empruntés à une réponse Stack Overflow écrite pour une startup américaine.

Le développement Firebase sur ce marché n'est pas plus difficile en principe. Il est plus difficile en exécution, parce que les hypothèses intégrées à la plateforme ne correspondent pas clairement à ce que le marché exige réellement. Ceci est un compte rendu de la façon dont je travaille à travers cela, du début à la fin.

Le problème de connectivité est une décision architecturale

Les écouteurs en temps réel de Firestore sont élégants quand la latence est faible et les connexions sont stables. À Douala, les connexions s'interrompent. Les données mobiles sont la méthode d'accès principale pour une grande part des utilisateurs, et la couverture 4G est inégale en dehors des districts centraux. Si vous concevez une application Firebase de la façon dont vous la concevriez pour un utilisateur à Berlin ou Londres, vous livrerez quelque chose qui échoue silencieusement pour les personnes qu'elle est censée servir.

La solution n'est pas compliquée, mais elle doit être délibérée. J'active la persistance hors ligne de Firestore sur chaque client dès le premier jour. J'écris en local-first, ce qui signifie que l'application suppose que le réseau est absent et traite une connexion active comme un bonus plutôt qu'une exigence. Je teste sur des connexions limitées avant de tester sur des connexions rapides. Cet ordre est important. Une fonctionnalité qui fonctionne sur le Wi-Fi rapide et s'arrête sur la 3G n'est pas une fonctionnalité terminée.

Les notifications push via Firebase Cloud Messaging nécessitent le même traitement. La livraison n'est pas garantie sur les réseaux contraints, donc tout flux qui dépend de l'arrivée rapide d'une notification a besoin d'un plan de secours, généralement une vérification par interrogation quand l'application revient au premier plan.

Les rails de paiement ne passent pas par Firebase

Firebase gère bien l'authentification, les données et les fonctions. Il ne gère pas l'argent, et au Cameroun la couche monétaire est l'endroit où la plupart des projets deviennent compliqués.

L'argent mobile est la méthode de paiement dominante. MTN Mobile Money et Orange Money couvrent ensemble la majorité des transactions pour les produits grand public. Aucun des deux ne s'intègre à Stripe directement. Le chemin pratique est un agrégateur, et l'agrégateur ajoute sa propre couche de conformité, y compris les exigences KYC qui doivent être reflétées dans votre modèle de données dès le départ, pas rétrofitées plus tard.

J'ai appris cela concrètement sur la construction de la Plateforme de services financiers. Le rail de paiement n'était pas camerounais, mais la leçon s'est transférée : les systèmes financiers sécurisés exigent que le modèle de conformité soit une architecture porteuse, pas un ajout improvisé avant le lancement. Les temps de réponse sur cette plateforme ont chuté de 30 pour cent une fois que nous avons arrêté de traiter la couche de paiement comme une préoccupation secondaire et lui avons accordé la même attention d'ingénierie que le produit principal.

Pour Firebase spécifiquement, cela signifie que Cloud Functions porte beaucoup de poids. L'orchestration de paiement sensible vit côté serveur, pas dans le code client. Les règles de sécurité Firestore appliquent ce que la couche fonction permet. Le client ne touche jamais directement les identifiants de paiement.

La conformité n'est pas optionnelle et elle arrive avant que vous ne lanciez

Le Cameroun a une exigence obligatoire de Bordereau Électronique de Suivi de Cargaison pour tous les envois maritimes, appliquée par le Conseil national des chargeurs du Cameroun. L'amende pour arriver sans un BESC validé est lourde. Je mentionne ceci parce que c'est une analogie utile pour la conformité logicielle sur le même marché : l'exigence de documentation existe avant que les marchandises ne se déplacent, pas après leur arrivée.

Pour le logiciel, l'équivalent est la résidence des données et le cadre juridique OHADA qui régit les transactions commerciales dans toute l'Afrique francophone. Si vous construisez un produit qui stocke des dossiers financiers ou des données personnelles pour les utilisateurs camerounais, vous devez savoir où Firestore écrit ces données, quelle région Google Cloud vous utilisez, et si cela satisfait les obligations que votre contrat ou secteur crée. La configuration du projet Firebase par défaut ne vous pose pas ces questions. Vous devez vous les poser vous-même.

Sur la construction d'OptimalTax, un produit d'automatisation fiscale du secteur public qui a atteint 99 pour cent de précision de calcul, les exigences de conformité ont façonné le modèle de données avant qu'une seule ligne de code Firebase ne soit écrite. Cet ordre, conformité d'abord, schéma deuxième, implémentation troisième, est le seul ordre qui fonctionne quand le risque d'audit est réel.

Développement Firebase dans le corridor Afrique-Europe

Une part significative des produits que je construis pour les clients camerounais ont des utilisateurs ou des contreparties en Europe. La Plateforme commerciale MO Business Solutions sert plus de 500 entreprises opérant dans le corridor Europe-Afrique. Ce type d'empreinte signifie que le RGPD s'applique d'un côté et les obligations adjacentes à l'OHADA s'appliquent de l'autre, et le projet Firebase doit satisfaire les deux simultanément.

Les décisions pratiques que cela force :

• —Configuration Firestore multi-région, avec des choix explicites sur l'endroit où chaque classe de données vit
• —Firebase Auth avec des réclamations personnalisées pour coder la juridiction, afin que les règles de sécurité puissent se brancher sur la localisation de l'utilisateur
• —Cloud Functions qui enregistrent chaque événement d'accès aux données dans une collection d'audit séparée, parce que les deux régimes réglementaires veulent savoir qui a touché quoi et quand
• —Les politiques de rétention définies au niveau de la collection, pas laissées à la valeur par défaut de Firebase

Rien de ceci n'est exotique. Tout cela est invisible dans le démarrage rapide Firebase standard, qui est écrit pour un produit à juridiction unique sans exigence d'audit.

À quoi ressemblent réellement les deux premières semaines d'un engagement

Un client vient me voir avec une idée de produit et une base d'utilisateurs camerounaise. La première conversation ne porte pas sur les fonctionnalités Firebase. Elle porte sur le rail de paiement, l'exigence de résidence des données, les obligations de conformité dans son secteur et le profil de connectivité de ses utilisateurs cibles.

À la fin de la première semaine, j'ai un modèle de données, un squelette de règles de sécurité Firestore et une architecture Cloud Functions qui reflète les contraintes de paiement et de conformité. Le projet Firebase est configuré pour la bonne région. La persistance hors ligne est activée. L'intégration de l'agrégateur d'argent mobile est délimitée.

La deuxième semaine est la première tranche verticale fonctionnelle : authentification, un flux de données principal, une initiation de paiement, tout fonctionnant contre une infrastructure réelle. Pas un prototype. Une tranche qui pourrait aller en production si nous nous arrêtions là.

C'est le même rythme que j'utilise sur un MVP Sprint, qui dure huit à douze semaines et livre un produit délimité et déployable. Les contraintes ne ralentissent pas le sprint. Elles sont simplement résolues à l'avant plutôt que découvertes à l'arrière.

Commencer une conversation ne coûte rien

Si vous comparez des partenaires pour une construction Firebase qui doit fonctionner au Cameroun, ou dans le corridor Afrique-Europe, les questions qui valent la peine d'être posées sont spécifiques : comment gérez-vous l'intégration de l'argent mobile, dans quelle région les données Firestore vivront-elles, et à quoi ressemble votre documentation de conformité à la remise.

J'ai des réponses à ces questions. Vous pouvez en savoir plus sur la façon dont les engagements sont structurés sur la page des services, ou si vous voulez aller droit au but, le formulaire de contact est le moyen le plus rapide de commencer.