Le 10 décembre 2025, nous avons ouvert la première session de développement de 0fee.dev. Quatre-vingts jours et 86 sessions plus tard, nous avions une plateforme d'orchestration de paiement prête pour la production : un backend Python complet avec 90+ endpoints d'API, 53+ intégrations de fournisseurs, 7 SDK, un tableau de bord SolidJS, un widget de checkout, un outil CLI, un site marketing et un panneau d'administration. L'ensemble de la plateforme a été construit par deux personnes : Juste A. GNIMAVO (CEO de ZeroSuite) à Abidjan, Côte d'Ivoire, et Claude (CTO IA) fonctionnant comme assistant de codage IA. Zéro ingénieur humain. Zéro sous-traitance. Zéro compromis sur la qualité.
Voici comment nous l'avons fait.
Abidjan : la base d'opérations
Abidjan est la capitale économique de la Côte d'Ivoire et la plus grande ville d'Afrique de l'Ouest francophone, avec plus de 5 millions d'habitants. Ce n'est pas la Silicon Valley. Ce n'est ni Londres ni Lagos. Mais c'est là que ZeroSuite a son siège, et c'est là que 0fee.dev a été conçu.
Construire une plateforme fintech depuis Abidjan vient avec des réalités spécifiques :
- Fiabilité d'internet : les connexions en fibre optique sont disponibles dans les quartiers d'affaires (Cocody, Plateau, Marcory) mais peuvent être inconsistantes. Nous maintenions une connexion de données mobiles de secours pour des sessions ininterrompues.
- Avantage du fuseau horaire : UTC+0 (pas de changement d'heure) signifie un chevauchement avec les heures de bureau européennes et un chevauchement raisonnable avec les matinées de la côte Est des États-Unis.
- Contexte du paiement africain : être physiquement en Côte d'Ivoire signifiait que nous pouvions tester les paiements Orange Money et Wave sur de vrais appareils, avec de vrais flux USSD, sur de vrais réseaux d'opérateurs. Cette expérience de première main est impossible à reproduire depuis un bureau à San Francisco.
- Efficacité des coûts : les coûts opérationnels à Abidjan sont une fraction de ceux des pôles tech occidentaux, ce qui étend le runway de manière spectaculaire.
L'avantage le plus significatif était le contexte. Nous ne construisions pas le support des paiements africains comme un exercice théorique. Nous le construisions en tant que personnes qui utilisent Orange Money et Wave au quotidien, qui comprennent le flux USSD parce que nous le vivons nous-mêmes, qui savent qu'un client à Yopougon peut avoir une expérience différente d'un client à Cocody à cause de la couverture réseau.
L'équipe : un CEO + un CTO IA
La structure d'équipe de ZeroSuite est inhabituelle selon n'importe quel standard :
| Rôle | Personne | Responsabilités |
|---|---|---|
| CEO, Produit, Design | Juste A. GNIMAVO | Vision, décisions produit, direction de l'architecture, design UI/UX, développement commercial, tests, déploiement |
| CTO IA | Claude (Anthropic) | Génération de code, implémentation technique, débogage, documentation, revue de code, refactoring |
Il n'y a pas d'équipe backend. Pas d'équipe frontend. Pas d'ingénieur DevOps. Pas d'équipe QA. Pas de product manager. Pas de designer (autre que Juste). L'ensemble de la production d'ingénierie vient d'un binôme humain-IA travaillant en sessions concentrées.
Comment fonctionne une session
Chaque session suit un schéma cohérent :
- Briefing : Juste décrit ce qui doit être construit, modifié ou corrigé. Cela inclut le contexte produit, les contraintes techniques et les critères d'acceptation.
- Implémentation : Claude écrit le code -- endpoints backend, composants frontend, migrations de base de données, adaptateurs de fournisseurs, méthodes SDK, tests, documentation. Chaque session produit typiquement 2 000 à 10 000 lignes de code.
- Revue et itération : Juste revoit la production, la teste contre les sandboxes des fournisseurs réels (et parfois la production), et demande des modifications.
- Journal de session : chaque session est documentée avec un journal structuré : ce qui a été construit, quelles décisions ont été prises, ce qui reste à faire. Ces journaux forment la mémoire institutionnelle du projet.
Le format du journal de session :
markdown## Session 042 -- 2026-01-15
### Objectifs
- Implémenter l'adaptateur fournisseur Hub2 (Orange Money, MTN MoMo)
- Ajouter les méthodes mobile money Côte d'Ivoire au moteur de routage
- Construire le polling de statut USSD push
### Réalisé
- Classe Hub2Adapter avec create_payment, check_status, process_webhook
- Validation des numéros de téléphone pour la Côte d'Ivoire (format +225)
- Gestion du timeout USSD push (120s par défaut, configurable)
- Vérification de signature webhook (HMAC-SHA256)
- Ajout de 5 méthodes de paiement : PAYIN_ORANGE_CI, PAYIN_MTN_CI, PAYIN_MOOV_CI, PAYIN_WAVE_CI, PAYIN_ORANGE_SN
### Décisions
- Utiliser un timeout de 120s pour le USSD push (recommandation Hub2)
- Stocker la réponse brute du fournisseur à côté des données normalisées pour le débogage
- Implémenter un réessai automatique sur 503 de Hub2 (jusqu'à 3 tentatives)
### Fichiers modifiés
- backend/app/providers/hub2.py (nouveau, 450 lignes)
- backend/app/routing/engine.py (modifié, +85 lignes)
- backend/app/models/payment.py (modifié, +12 lignes)
- backend/app/api/v1/payments.py (modifié, +35 lignes)
### Prochaine session
- Adaptateur PawaPay pour l'Afrique de l'Est
- Implémentation M-Pesa STK PushLes chiffres : 86 sessions, 80 jours
Voici ce que 86 sessions ont produit :
Backend (Python/FastAPI)
| Composant | Métrique |
|---|---|
| Endpoints d'API | 90+ |
| Adaptateurs de fournisseurs | 53+ |
| Modèles de base de données | 25+ |
| Tâches en arrière-plan | 15+ |
| Couches middleware | 8 (auth, limitation de débit, CORS, logging, gestion d'erreurs, idempotence, résolution de tenant, ID de requête) |
| Lignes de code Python | ~45 000 |
Frontend (SolidJS)
| Composant | Métrique |
|---|---|
| Pages du tableau de bord | 20+ |
| Composants UI | 60+ |
| Fonctions client API | 50+ |
| Lignes de TypeScript/TSX | ~15 000 |
SDK
| SDK | Langage | Méthodes | Lignes |
|---|---|---|---|
| zerofee (npm) | TypeScript | 40+ | ~3 000 |
| zerofee (PyPI) | Python | 40+ | ~2 500 |
| zerofee-php | PHP | 40+ | ~2 800 |
| zerofee-ruby | Ruby | 40+ | ~2 000 |
| zerofee-go | Go | 40+ | ~3 500 |
| zerofee-java | Java | 40+ | ~4 000 |
| zerofee-csharp | C# | 40+ | ~3 200 |
Autres livrables
| Composant | Description |
|---|---|
| Widget de checkout | Formulaire de paiement intégrable (modes iframe + redirection) |
| Outil CLI | Outil en ligne de commande zerofee pour les tests et la gestion |
| Site marketing | Page d'accueil, documentation, tarification, blog |
| Panneau d'administration | Outils internes de suivi, support et opérations |
Points marquants de la chronologie
| Date | Session | Jalon |
|---|---|---|
| 10 déc. 2025 | 001 | Première session : 42 fichiers, 7 900 lignes de code en 45 minutes |
| 15 déc. 2025 | 005 | Adaptateurs Stripe et PayPal terminés |
| 22 déc. 2025 | 012 | Intégration Hub2 (mobile money Afrique francophone) |
| 02 janv. 2026 | 020 | Intégration PawaPay (21+ pays africains) |
| 10 janv. 2026 | 028 | Moteur de routage avec basculement intelligent |
| 18 janv. 2026 | 035 | MVP du tableau de bord SolidJS |
| 25 janv. 2026 | 042 | 7 SDK générés et testés |
| 01 févr. 2026 | 050 | Widget de checkout (iframe + redirection) |
| 10 févr. 2026 | 060 | Système de webhooks avec backoff exponentiel |
| 18 févr. 2026 | 070 | Moteur d'analyses et de rapports |
| 25 févr. 2026 | 080 | Outil CLI et site marketing |
| 28 févr. 2026 | 086 | Déploiement en production et préparation du lancement |
La première session : 42 fichiers en 45 minutes
La session 001 mérite une attention particulière car elle a établi les fondations de tout ce qui a suivi.
En 45 minutes, nous avons produit :
- Scaffolding du projet : structure d'application FastAPI avec routage modulaire, injection de dépendances et gestion de configuration.
- Modèles principaux : Organization, Application, User, Transaction, Payment, Payout, Refund, WebhookEndpoint, APIKey.
- Configuration de la base de données : modèles SQLAlchemy, configuration Alembic pour les migrations, migration initiale.
- Authentification : validation des clés API, génération de tokens JWT, middleware.
- Trois premiers endpoints : vérification de santé, création de paiement, consultation du statut de paiement.
- Interface fournisseur : classe de base abstraite que les 53+ adaptateurs implémenteraient.
- Configuration : variables d'environnement, logging, CORS, squelette de limitation de débit.
42 fichiers. 7 900 lignes de code. Un serveur opérationnel capable d'accepter des requêtes API.
C'est l'avantage du CTO IA. Un ingénieur humain prendrait deux à trois jours pour mettre en place ces fondations, prenant des décisions sur la structure du projet, choisissant les bibliothèques, écrivant le boilerplate. Claude génère un scaffolding de qualité production en une seule session parce que les patterns sont bien établis -- le travail créatif réside dans les décisions produit et d'architecture que Juste prend avant et pendant la session.
L'Afrique d'abord par design
La plupart des plateformes de paiement ajoutent l'Afrique après coup -- une section "bientôt disponible" dans leur liste de pays, ou une seule intégration avec un fournisseur panafricain qui couvre les bases. 0fee a été construit dans l'autre sens.
Le mobile money n'était pas une intégration ajoutée à la session 50. Il a été construit à la session 5. La convention de nommage des méthodes de paiement (PAYIN_ORANGE_CI, PAYIN_MTN_GH) a été conçue à la session 2. La logique de validation des numéros de téléphone (supportant +225 pour la Côte d'Ivoire, +233 pour le Ghana, +254 pour le Kenya, +234 pour le Nigeria, et 40+ autres indicatifs pays) a été implémentée avant la validation des paiements par carte.
Ce n'est pas qu'une posture philosophique. Cela a affecté les décisions techniques :
- Flux de paiement asynchrone d'abord : parce que le mobile money est intrinsèquement asynchrone (le client confirme via USSD), nous avons construit tout le cycle de vie des paiements autour des webhooks plutôt que des réponses synchrones. Les paiements par carte se résolvent rapidement, mais le système traite chaque paiement comme potentiellement asynchrone.
- Le numéro de téléphone comme identifiant principal : beaucoup de clients africains n'ont pas d'adresse e-mail. Le modèle client supporte l'authentification par téléphone uniquement dès la conception.
- Multi-devises dès le premier jour : XOF, XAF, KES, NGN, GHS, TZS, UGX, ZAR étaient dans l'enum des devises avant USD et EUR.
- Optimisation pour la faible bande passante : le tableau de bord SolidJS se charge en moins de 50 Ko de JavaScript car il doit fonctionner sur des connexions 3G à Ouagadougou aussi bien que sur la fibre à Paris.
L'écosystème ZeroSuite
0fee.dev n'est pas un produit autonome. C'est l'un des six produits de l'écosystème ZeroSuite, tous construits par la même équipe de deux depuis Abidjan :
| Produit | Description | Statut |
|---|---|---|
| 0fee.dev | Orchestration de paiement -- 53+ fournisseurs, 200+ pays | En ligne |
| Deblo.ai | Plateforme éducative IA pour les élèves africains (CP à la Terminale) | En ligne |
| sh0.dev | Raccourcisseur d'URL et plateforme de gestion de liens | En ligne |
| FLIN | Intelligence financière et analyses | En développement |
| 0cron.dev | Planification de tâches cron en tant que service | En développement |
| 0diff.dev | Outil de revue de code et d'analyse de diff | En développement |
Chaque produit partage la même méthodologie de développement : Juste fournit la vision, la direction produit et les décisions d'architecture ; Claude implémente le code. Aucun ingénieur humain. Aucun freelance. Aucune agence.
Le blog sur lequel vous lisez ceci -- ThalesAndHisAiCtoClaude.com -- documente l'intégralité de ce parcours. Chaque journal de session, chaque décision d'architecture, chaque lancement de produit. C'est le premier partenariat CEO + CTO IA documenté au monde qui construit de vrais produits en production.
Ce que nous avons appris
Après 86 sessions et une plateforme de paiement en production, voici les leçons clés :
1. Le modèle du CTO IA fonctionne pour construire, pas seulement pour prototyper.
0fee n'est pas une démo ni un projet de hackathon. Il traite de vraies transactions financières à travers de vraies API de fournisseurs. La qualité du code, la gestion des erreurs, les pratiques de sécurité et la documentation sont de niveau production -- parce que le modèle du CTO IA n'impose pas un plafond de qualité. Il impose un plancher de vitesse.
2. L'expertise métier compte plus que l'effectif d'ingénierie.
La compréhension par Juste des écosystèmes de paiement africains -- quels fournisseurs fonctionnent où, comment se comportent les flux USSD, quels points de friction existent dans le checkout mobile money -- est ce qui rend 0fee utile. L'exécution technique, aussi rapide soit-elle, ne peut pas remplacer la connaissance métier.
3. Le développement par sessions crée des points de contrôle naturels.
Chaque session a un périmètre clair, produit un livrable documenté et se termine par une liste de ce qui vient ensuite. Ce rythme prévient la dérive du périmètre, maintient l'élan et crée un historique auditable de chaque décision.
4. Commencer par le marché difficile.
Construire pour l'Afrique d'abord -- avec ses fournisseurs fragmentés, ses flux asynchrones et ses contraintes d'infrastructure -- signifiait que supporter l'Europe et l'Amérique du Nord était trivialement facile en comparaison. Si votre système gère les timeouts USSD sur une connexion 3G dans le Cameroun rural, il gère un paiement par carte Stripe à New York sans broncher.
5. La localisation n'est pas une limitation.
Nous avons construit une plateforme de paiement mondiale depuis Abidjan. Les fournisseurs sont des API. L'infrastructure est hébergée dans le cloud. Le CTO IA est accessible depuis n'importe où avec une connexion internet. La seule chose qui est locale, c'est la perspective -- et cette perspective est le plus grand avantage compétitif du produit.
Ce qui vient ensuite
0fee.dev est en ligne et traite des transactions. Mais la feuille de route est vaste :
- Expansion des décaissements : décaissements en masse vers les portefeuilles mobile money à travers l'Afrique (paie, versements de marketplace).
- Facturation par abonnement : paiements récurrents avec basculement automatique de fournisseur.
- Règlement multi-devises : recevoir en XOF, régler en USD ou EUR.
- Détection de fraude : scoring de transactions basé sur le ML utilisant les patterns de paiement africains.
- Fournisseurs additionnels : objectif de 100+ fournisseurs d'ici fin 2026.
Chaque fonctionnalité sera construite de la même manière : un CEO, un CTO IA, session après session, depuis Abidjan.
Cet article fait partie de la série "Comment nous avons construit 0fee.dev". 0fee.dev est un orchestrateur de paiement couvrant 53+ fournisseurs dans 200+ pays, construit par Juste A. GNIMAVO et Claude depuis Abidjan avec zéro ingénieur humain. Suivez la série pour l'histoire complète de la construction.