Avant de parler de code ou de technologie, il faut comprendre ce que le système fait réellement. Imaginez un distributeur automatique de forfaits Internet — mais entièrement sur téléphone, sans carte physique, sans guichet, sans humain.
Les 4 grands acteurs du système
Le parcours d'un achat en 6 étapes
Client vs Serveur
Tout sur Internet fonctionne selon un principe simple : un client demande, un serveur répond.
Qu'est-ce qu'une requête HTTP ?
Quand votre application veut communiquer avec le backend, elle envoie une requête HTTP. C'est un message standardisé qui dit : "Je veux telle information" ou "Fais telle action".
| Type de requête | Ce que ça fait | Exemple dans votre projet |
|---|---|---|
| GET | Récupérer une information | Afficher la liste des forfaits disponibles |
| POST | Envoyer / créer quelque chose | Créer un compte utilisateur, passer une commande |
| PUT | Modifier quelque chose | Mettre à jour les infos du profil utilisateur |
| DELETE | Supprimer quelque chose | Supprimer un compte |
Le HTTPS — pourquoi le "S" est vital
HTTP est la langue d'Internet. HTTPS est la même langue, mais dans une enveloppe scellée et cryptée. Sans le S, n'importe qui entre l'utilisateur et votre serveur peut lire les données qui transitent — y compris les numéros de téléphone et les informations de paiement.
Le JSON — le langage commun
Quand votre application et votre backend se parlent, ils utilisent un format standard appelé JSON. C'est simplement de l'information structurée, lisible par les humains et les machines.
L'architecture, c'est le plan de construction de votre système. Elle définit quelles pièces existent, comment elles communiquent, et qui fait quoi. Un système mal architecturé au départ coûte 3 à 5 fois plus cher à réparer ensuite.
Les couches de votre système
Ce que fait concrètement votre backend
Synchrone vs Asynchrone — concept clé
C'est l'un des concepts les plus importants à comprendre pour votre projet.
Asynchrone : Vous commandez un taxi via une app, il vous prévient quand il arrive. En attendant, vous continuez votre vie normalement.
Les appels aux API des opérateurs (MTN, Orange) sont asynchrones. Votre backend envoie la demande d'activation et n'attend pas la réponse bloqué — il continue à traiter d'autres commandes. Quand l'opérateur répond, le système reprend le traitement. C'est ce qui rend le système rapide et scalable.
L'environnement de développement vs production
| Environnement | Usage | Données | Accès |
|---|---|---|---|
| Development | L'IA écrit le code ici | Fausses données de test | Développeurs seulement |
| Staging (Recette) | Vous testez ici avant de livrer | Données de test réalistes | Vous + client |
| Production | Ce que les vrais utilisateurs voient | Données réelles | Tout le monde |
Les API de votre projet
| API | Rôle | Ce que vous envoyez | Ce que vous recevez |
|---|---|---|---|
| MTN MoMo API | Déclencher un paiement Mobile Money | Numéro, montant, référence | Succès ou échec + ID transaction |
| Orange Partner API | Activer data sur SIM Orange | MSISDN, volume data, durée | Confirmation activation ou erreur |
| CinetPay API | Agréger plusieurs paiements | Montant, moyen de paiement, webhook URL | Lien de paiement ou callback |
| Votre propre API | Servir l'application mobile | Requêtes de l'app (commandes, profils...) | Données JSON formatées |
Le Webhook — comprendre les rappels automatiques
Un webhook, c'est l'inverse d'une requête normale. Au lieu de votre système qui demande "est-ce que le paiement est passé ?", c'est CinetPay qui appelle votre système automatiquement dès que le paiement est confirmé.
Les clés API — ce qu'elles sont et comment les protéger
Une clé API (API Key), c'est comme un mot de passe qui identifie votre application auprès d'un service externe. MTN vous en donne une pour accéder à leur système. CinetPay aussi.
Les tables principales de votre système
| Table | Ce qu'elle contient | Importance |
|---|---|---|
| users | Profil, numéro téléphone, statut KYC, date inscription | Critique |
| transactions | Chaque achat : montant, statut, date, référence paiement | Critique |
| forfaits | Catalogue des forfaits disponibles : volume, prix, durée | Élevée |
| provisionnements | Historique des activations data : opérateur, MSISDN, statut | Critique |
| logs_api | Chaque appel aux API externes : requête, réponse, temps | Élevée |
| kyc_documents | Statut vérification identité, référence document (pas le fichier lui-même) | Critique |
Les sauvegardes — ce qu'on oublie toujours
Une base de données sans sauvegarde automatique est une bombe à retardement. Si le serveur tombe ou si une erreur de code supprime des données, sans sauvegarde récente, c'est tout l'historique des transactions clients qui disparaît.
Les migrations — gérer l'évolution de la base
Quand vous ajoutez une nouvelle fonctionnalité, la structure de la base de données doit évoluer. Une migration, c'est un script qui modifie la base de façon contrôlée et réversible.
Le problème du Double-Spending
Imaginez qu'un utilisateur appuie deux fois très vite sur le bouton "Acheter". Sans protection, votre système pourrait traiter deux commandes identiques, débiter deux fois le compte, mais n'activer la data qu'une fois. Ou pire, activer deux fois la data sans avoir été payé deux fois.
La file d'attente — pourquoi c'est indispensable
L'API d'Orange ou de MTN peut prendre 2 secondes, 10 secondes, ou parfois tomber complètement. Si votre backend attend debout que l'opérateur réponde, tout le système est bloqué. La file d'attente résout ça.
La logique de retry (nouvelle tentative automatique)
Si l'API de l'opérateur échoue, le système doit réessayer automatiquement. Mais pas n'importe comment :
| Tentative | Délai avant réessai | Raison |
|---|---|---|
| 1ère | 30 secondes | Peut être une micro-coupure temporaire |
| 2ème | 2 minutes | Délai exponentiel — ne pas surcharger l'opérateur |
| 3ème | 10 minutes | Dernier essai automatique |
| Après échec total | — | Remboursement automatique déclenchée |
Flutter — pourquoi ce choix ?
Flutter est un outil de développement de Google qui permet d'écrire une seule fois le code et d'obtenir automatiquement une application qui fonctionne sur iOS et Android. Sans Flutter, il faudrait deux équipes de développeurs et deux codes séparés.
Les écrans essentiels du MVP
- Écran d'accueil & onboarding Première impression — doit inspirer confiance
- Inscription avec numéro de téléphone + vérification par SMS OTP
- KYC — vérification d'identité Upload CNI + selfie
- Catalogue des forfaits Affichage clair : volume, durée, prix
- Écran de commande & confirmation Récapitulatif avant paiement
- Paiement Mobile Money Interface MoMo ou Orange Money
- Confirmation d'activation Notification push + écran succès
- Historique des achats Liste de toutes les transactions
- Profil utilisateur Gestion du compte, solde, paramètres
- Support client Chat ou formulaire de contact
Les notifications push — comment ça fonctionne
Quand la data est activée, l'utilisateur reçoit une notification sur son téléphone. Ça passe par un service tiers (Firebase Cloud Messaging de Google, gratuit) qui achemine la notification à l'appareil même si l'application est fermée.
L'état de l'application — concept important
Dans une application mobile, l'état, c'est l'ensemble des informations affichées à un instant T. Quand l'utilisateur achète un forfait, l'état doit se mettre à jour partout : le solde affiché, l'historique, le statut de la commande. Si l'état est mal géré, l'utilisateur voit des données incohérentes — ce qui génère des appels au support.
Le flux KYC de votre application
Le Liveness Check — éviter les fraudes
Le liveness check, c'est la vérification que la personne qui prend le selfie est bien vivante et présente — pas une photo d'une photo. L'utilisateur est invité à sourire, tourner la tête, ou cligner des yeux. Ça empêche quelqu'un d'utiliser la photo d'identité d'une autre personne.
Stockage sécurisé des documents
Les niveaux de compte
| Niveau | Condition | Limites |
|---|---|---|
| Non vérifié | Juste le numéro confirmé | Peut parcourir le catalogue, pas d'achat |
| KYC basique | CNI uploadée, en attente validation | Achat limité (ex: max 2 000 FCFA/jour) |
| KYC validé | Identité confirmée | Accès complet à tous les forfaits |
Les deux modèles d'intégration
| Modèle | Comment ça marche | Avantage | Inconvénient |
|---|---|---|---|
| Intégration directe | Vous connectez votre backend directement à l'API MTN et Orange séparément | Moins de frais intermédiaires | Double travail, double maintenance |
| Agrégateur (CinetPay) | CinetPay gère MTN + Orange + d'autres en une seule connexion | Une seule intégration, plus rapide | Commission 1,5% – 3% par transaction |
Le flux de paiement sécurisé
Le problème du décalage de trésorerie
CinetPay collecte l'argent pour vous mais le reverse sur votre compte bancaire avec un délai de 24 à 72 heures. Pendant ce temps, vous avez déjà payé l'opérateur pour activer la data. Vous avez besoin d'un fonds de roulement pour couvrir ce décalage — c'est une dépense réelle à provisionner.
Le provisionnement MSISDN (SIM physique)
Le MSISDN, c'est simplement le numéro de téléphone unique associé à une SIM. Quand un utilisateur achète un forfait, votre backend appelle l'API de l'opérateur avec ce numéro et lui dit "ajoute X mégaoctets sur ce compte". L'opérateur exécute.
La eSIM — comment ça fonctionne
Une eSIM (SIM embarquée), c'est une puce soudée à l'intérieur du téléphone. Au lieu d'insérer une carte physique, on télécharge un "profil réseau" directement sur cette puce via Internet.
Les menaces principales à connaître
| Menace | Ce que c'est en simple | Comment l'éviter |
|---|---|---|
| Injection SQL | Un attaquant envoie du code malveillant à la place d'un numéro de téléphone pour accéder à toute la base de données | L'IA doit utiliser des "requêtes préparées" — jamais construire des requêtes SQL avec du texte utilisateur directement |
| Attaque par force brute | Un robot essaie des milliers de mots de passe par seconde | Limiter le nombre de tentatives de connexion (rate limiting) — bloquer après 5 échecs |
| Vol de token | Quelqu'un intercepte le jeton de connexion d'un utilisateur et se connecte à sa place | Tokens avec durée de vie courte (1h), HTTPS obligatoire, refresh tokens sécurisés |
| Webhook falsifié | Un attaquant envoie un faux message "paiement réussi" pour déclencher l'activation de data sans payer | Vérifier la signature cryptographique de chaque webhook reçu — si la signature ne correspond pas, ignorer |
| Exposition de données | Des données sensibles (CNI, transactions) accessibles sans restriction | Chiffrement des données au repos, contrôle d'accès strict, logs de tous les accès |
L'authentification — JWT (tokens de connexion)
Quand un utilisateur se connecte, votre backend lui donne un jeton JWT (JSON Web Token). C'est comme un badge temporaire. Chaque fois que l'application fait une requête, elle présente ce badge. Le backend vérifie que le badge est valide avant de répondre.
Le rate limiting — freiner les abus
Le rate limiting limite le nombre de requêtes qu'une même adresse IP peut faire en un temps donné. Sans ça, un attaquant peut envoyer des milliers de requêtes par seconde pour tester des mots de passe ou saturer votre serveur.
Le pentest — tester comme un attaquant
Un test de pénétration (pentest), c'est quand vous payez un expert en sécurité pour qu'il essaie de hacker votre propre système avant que les vrais hackers ne le fassent. Il vous remet un rapport avec les failles trouvées et comment les corriger.
Les données que vous collectez
| Donnée collectée | Pourquoi | Durée de conservation | Qui peut y accéder |
|---|---|---|---|
| Numéro de téléphone | Identification + provisionnement | Durée du compte | Backend uniquement |
| Photo CNI | KYC obligatoire | Supprimer après validation | Système KYC + admin |
| Historique transactions | Support client + comptabilité | 10 ans (obligation fiscale) | Admin + utilisateur lui-même |
| Localisation approximative | Détection fraude | 30 jours | Système anti-fraude |
| Logs de connexion | Sécurité | 1 an | Admin sécurité |
Ce que la loi camerounaise exige
- Informer clairement l'utilisateur des données collectées Via une politique de confidentialité accessible dans l'app
- Obtenir le consentement explicite avant toute collecte Case à cocher lors de l'inscription — pas pré-cochée
- Permettre à l'utilisateur de supprimer son compte Et toutes ses données personnelles avec
- Ne pas vendre les données à des tiers Jamais, même à des partenaires commerciaux
- Sécuriser les données contre les accès non autorisés Chiffrement, contrôle d'accès, logs d'audit
- Notifier les utilisateurs en cas de fuite de données Dans les 72h suivant la découverte
La politique de confidentialité dans l'app
Ce n'est pas juste un document juridique à coller quelque part. C'est un écran dans l'application, rédigé en français simple, que l'utilisateur peut consulter à tout moment depuis son profil. Apple et Google refusent les applications sans politique de confidentialité lors de la validation sur les stores.
Les types de tests à connaître
| Type de test | Ce qu'il teste | Qui le fait | Quand |
|---|---|---|---|
| Tests unitaires | Une petite fonction isolée (ex: calculer la marge) | L'IA + développeur | En continu pendant le dev |
| Tests d'intégration | Que les différentes parties communiquent bien entre elles | Développeur + QA | Après chaque module terminé |
| Tests de bout en bout | Simuler un vrai achat de A à Z | QA + vous-même | Avant chaque livraison |
| Tests de charge | Que le système tient quand 1000 personnes achètent en même temps | QA spécialisé | Avant le Go-Live |
| Tests de sécurité | Chercher les failles exploitables | Expert sécurité externe | Avant le Go-Live |
Les scénarios de test critiques à valider vous-même
- Achat réussi complet : paiement MoMo → data activée Le parcours normal qui doit fonctionner parfaitement
- Paiement échoué → aucune activation → pas de débit L'utilisateur ne paie pas et ne reçoit rien
- Paiement réussi mais API opérateur tombe → remboursement auto Le cas le plus délicat — vérifiez que l'argent revient bien
- Double appui sur "Acheter" → une seule transaction créée Protection anti double-spending
- Connexion avec mauvais mot de passe 5 fois → compte bloqué temporairement Rate limiting actif
- Webhook avec fausse signature → rejeté sans action Protection contre les webhooks falsifiés
- Upload CNI corrompue → message d'erreur clair Gestion d'erreurs propre côté utilisateur
- App utilisée sans connexion Internet → message d'erreur clair Pas de crash silencieux
Le déploiement continu — CI/CD
CI/CD (Intégration Continue / Déploiement Continu) est un processus automatique qui prend le code de l'IA, le teste, et le met en ligne sans intervention manuelle. Chaque fois que du nouveau code est validé, le système tourne automatiquement les tests et si tout passe, déploie la nouvelle version.
Les variables d'environnement
Les informations sensibles (clés API, mots de passe de base de données) ne sont jamais écrites dans le code. Elles sont stockées dans des variables d'environnement — des paramètres secrets configurés directement sur le serveur, invisibles dans le code source.
Le monitoring — surveiller que tout tourne
Une fois en production, vous avez besoin de savoir en temps réel si quelque chose ne va pas. Le monitoring, c'est un tableau de bord qui vous alerte immédiatement si une erreur survient, si le serveur est lent, ou si une transaction échoue en masse.
Comment bien prompter l'IA pour du code
| Mauvais prompt | Bon prompt |
|---|---|
| "Fais moi l'intégration MoMo" | "Crée un service backend Node.js qui appelle l'API MTN MoMo pour débiter un compte. Le paiement ne doit se déclencher que si l'utilisateur est KYC validé. En cas d'échec, déclenche un remboursement via l'API de décaissement CinetPay." |
| "Code la sécurité" | "Ajoute un middleware d'authentification JWT sur toutes les routes /api/v1/. Ajoute un rate limiting de 5 requêtes/minute sur /auth/login. Vérifie la signature HMAC-SHA256 sur le endpoint /webhooks/payment." |
Ce que vous devez vérifier dans chaque livraison de l'IA
- Toutes les routes API sont-elles protégées par authentification ? Aucune donnée sensible accessible sans token valide
- Les clés API sont-elles dans des variables d'environnement ? Jamais en dur dans le code
- Les appels aux opérateurs sont-ils asynchrones ? Avec retry automatique et timeout configuré
- Le webhook de paiement vérifie-t-il la signature ? Protection contre les webhooks falsifiés
- L'activation data se déclenche-t-elle APRÈS confirmation paiement ? Jamais avant, jamais sans vérification
- Les erreurs sont-elles loggées en base de données ? Pour le support client et l'audit
- Y a-t-il des tests automatisés pour les flux critiques ? Minimum : achat réussi, paiement échoué, remboursement
Les limites de l'IA à connaître
Le versioning du code — Git
Git est un système qui garde l'historique de chaque modification du code. Si l'IA produit du code qui casse quelque chose, vous pouvez revenir à la version précédente en une commande. C'est la ceinture de sécurité du développement.
La convention de nommage des API — REST
REST est un standard de conception d'API. Il définit comment nommer et organiser vos endpoints de façon logique et prévisible.
La gestion des erreurs — codes de statut HTTP
| Code | Signification | Exemple dans votre projet |
|---|---|---|
| 200 | Succès | Forfait activé avec succès |
| 201 | Créé avec succès | Compte utilisateur créé |
| 400 | Mauvaise requête (erreur client) | Numéro de téléphone invalide |
| 401 | Non authentifié | Token de connexion absent ou expiré |
| 403 | Accès refusé | KYC non validé — achat impossible |
| 404 | Non trouvé | Forfait inexistant |
| 409 | Conflit | Transaction déjà en cours (anti double-spending) |
| 500 | Erreur serveur | Panne interne — à logger immédiatement |
Le versioning d'API — pourquoi /v1/
Remarquez le /v1/ dans tous les endpoints. Quand vous sortez une version 2 de l'API avec des changements incompatibles, les anciennes applications mobiles continuent de fonctionner sur /v1/ pendant que les nouvelles utilisent /v2/. Sans ça, une mise à jour backend peut casser toutes les apps mobiles déjà installées chez les utilisateurs.
Technique
- HTTPS actif sur tous les endpoints Vérifiez le cadenas dans le navigateur sur chaque URL
- Variables d'environnement configurées en production Aucune clé API en dur dans le code
- Base de données avec sauvegardes automatiques quotidiennes activées Testez une restauration avant le Go-Live
- Monitoring Sentry + UptimeRobot configurés et testés Vous devez recevoir une alerte test sur votre téléphone
- Rate limiting actif sur toutes les routes sensibles Connexion, paiement, inscription
- Signature webhook vérifiée sur l'endpoint paiement Testez un webhook avec fausse signature — il doit être rejeté
- Logique de retry active sur les appels opérateurs Simulez une panne de l'API MTN — le retry doit se déclencher
- Remboursement automatique testé et fonctionnel Déclenchez manuellement un échec d'activation — l'argent doit revenir
- Tests de charge effectués (simulation 500 utilisateurs simultanés) Le serveur ne doit pas tomber
- Pentest réalisé et failles critiques corrigées Rapport signé par le prestataire sécurité
Légal & Business
- Politique de confidentialité accessible dans l'app En français, compréhensible, à jour
- CGU (Conditions Générales d'Utilisation) acceptées à l'inscription Case à cocher non pré-cochée
- Compte marchand CinetPay / Monetbil validé et testé Effectuez un vrai paiement test de 100 FCFA
- Contrat d'interconnexion MTN signé Accès production confirmé
- Contrat d'interconnexion Orange signé Accès production confirmé
- Récépissé SVA / licence ART obtenu Document en main
- Fonds de roulement disponible sur le compte Minimum 3 mois d'exploitation projetée
Stores & Distribution
- Compte Apple Developer actif Membership annuel payé
- Application soumise à Apple et validée Délai moyen 5 à 10 jours ouvrés
- Compte Google Play Developer actif Frais uniques payés
- Application soumise sur Google Play et validée Délai moyen 1 à 3 jours
- Captures d'écran et description en français prêtes Requises par les deux stores
- Politique de confidentialité URL publique fournie aux stores Apple la vérifie systématiquement
Après le Go-Live — la première semaine
- Surveiller Sentry toutes les heures les 3 premiers jours Les premières erreurs réelles arrivent toujours dans cette fenêtre
- Vérifier manuellement les premières transactions réelles Confirmer que la data est bien activée chez les premiers utilisateurs
- Surveiller les délais de réponse des API opérateurs Une dégradation progressive peut signaler un problème d'accord B2B
- Activer un canal de support client dès J1 WhatsApp Business ou email dédié — les premiers utilisateurs auront des questions