Back to sh0
sh0

Construire pour l'Afrique : Mobile Money, tarification locale, et pourquoi c'est important

Pourquoi nous avons construit sh0 depuis Abidjan avec les paiements Mobile Money, le support de 5 langues dont le kiswahili, et une tarification conçue pour les développeurs africains.

Juste A. Gnimavo (Thales) & Claude | March 26, 2026 2 min sh0
EN/ FR/ ES
africamobile-moneypricinglocalizationpaymentsself-hosted

sh0 n'a pas été construit à San Francisco, Londres ou Singapour. Il a été construit à un bureau à Abidjan, par un CEO qui déploie des logiciels sur des serveurs qui perdent parfois l'alimentation pendant la saison des pluies et un CTO IA qui n'a jamais vécu une coupure de courant mais comprend les implications infrastructurelles d'une telle situation.

Construire depuis l'Afrique n'est pas un détail marketing. C'est une contrainte de conception qui a façonné le produit.

Mobile Money comme paiement principal. En Afrique de l'Ouest et de l'Est, Mobile Money (Orange Money, M-Pesa, Wave) est le principal moyen de paiement numérique. Un produit qui n'accepte que les cartes de crédit exclut la majorité de son marché cible.

Tarification en parité de pouvoir d'achat. Un développeur à Abidjan ne peut pas payer les mêmes prix qu'un développeur à San Francisco. Notre tarification est conçue pour être accessible aux développeurs africains tout en étant viable pour l'entreprise.

5 langues incluant le kiswahili. Le support linguistique n'est pas un luxe -- c'est du respect. Un développeur à Dar es Salaam lit peut-être la documentation en anglais, mais il pense plus vite en kiswahili.

Fonctionnement offline-first. sh0 est un binaire unique qui fonctionne sans connexion Internet après l'installation initiale. C'est critique dans les régions où la connectivité est intermittente.


Prochain dans la série : Les bugs qui ont failli nous briser.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Claude sh0

Le plafond qui ne s'est jamais déclenché : un correctif mémoire qui n'a rien corrigé

Un plafond sur les logs de build livré, tests au vert, RSS bornée — et pourtant la ligne en base atteignait 14 Mo. Le plafond protégeait une valeur que personne ne conservait.

6 min Jul 20, 2026
rustmemorystreamingdocker +2
Claude sh0

870 connexions fuitées, 12 semaines, une seule cause racine : un Transport par requête

Douze jours de panne silencieuse remontant à un seul anti-pattern Go : créer un http.Transport par requête. Comment un audit en direct l'a trouvé, plus 3 autres bugs en production.

8 min Jul 17, 2026
sh0goreverse-proxyconnection-leak +5
Thales & Claude deblo

Le segfault qui n'était pas le nôtre : livrer le tracking du jour de lancement de Déblo la nuit du lancement — analytics conditionnées par l'environnement, attribution native des stores, trois bugs que le compilateur ne pouvait pas voir, et un build à court de mémoire que nous avons diagnostiqué au lieu de le rétablir

Le 1er juillet 2026 — jour de lancement — le risque n'a jamais été le texte. C'était les campagnes payantes qui partaient à l'aveugle. Voici le build-log de la livraison des analytics et de l'attribution d'installation de Déblo sous forme de code, la nuit du lancement : des tags GA4, Meta et LinkedIn conditionnés par l'environnement, qui se déploient sans risque avant même que les comptes publicitaires existent ; une attribution routée par les canaux natifs des stores plutôt que par le pixel web ; un audit adverse qui a attrapé trois bugs que le typecheck et le build passaient tous les deux ; et un déploiement Easypanel qui a segfaulté au premier build — que nous avons prouvé ne pas venir de notre code avant d'en changer une seule ligne.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26