~/mesha-vegas$
$ cd ../

2026-05-29

Développer depuis Bafoussam pour Londres : ce que ça demande vraiment

Deux ans à contribuer à une plateforme britannique depuis l'Ouest Cameroun. Ce qui marche, ce qui coince, et pourquoi le fuseau horaire est le moindre des obstacles.

  • #remote
  • #afrique
  • #carriere
  • #freelance
  • #collaboration
  • #cameroun
$7 min read10 reads
Développer depuis Bafoussam pour Londres : ce que ça demande vraiment

Quand un jeune joueur camerounais signe en Europe, la question posée n'est jamais « sait-il jouer ? ». On l'a vu jouer, c'est pour ça qu'il signe. La question, c'est l'adaptation : le rythme, la langue, le froid, la pression, l'isolement.

Le travail à distance depuis l'Afrique fonctionne exactement pareil. La compétence technique n'est pas le sujet — elle se démontre en deux semaines. Ce qui décide, c'est tout le reste.

Je contribue depuis 2024 à une plateforme de gestion de soins à domicile pour un client britannique, depuis Bafoussam. Voici ce que ces deux ans m'ont appris, sans enjolivement.

Le fuseau horaire est un faux problème

C'est l'objection qu'on entend le plus, et c'est la plus facile à démonter.

Le Cameroun est à UTC+1. Londres est à UTC+0 ou +1 selon la saison. Le décalage est de zéro à une heure. Je suis plus synchrone avec Londres qu'un développeur à Lisbonne ne l'est avec Berlin.

Avec le Canada, c'est cinq à huit heures — réel, mais gérable : je livre le matin, ils relisent l'après-midi, je récupère leurs retours le lendemain matin. Ce rythme quotidien fonctionne mieux que les gens ne le croient, à condition d'accepter qu'une réponse arrive en un jour et de structurer le travail pour ne pas bloquer dessus.

L'objection du fuseau sert souvent à en masquer une autre, moins avouable : la crainte que le travail ne soit pas au niveau. Autant l'affronter directement.

Les vrais obstacles

L'électricité, pas la connexion

Contrairement à l'idée reçue, la connexion Internet n'est pas le problème principal. La fibre existe à Bafoussam, elle est correcte, elle est chère mais abordable pour un professionnel.

Le problème, c'est le courant. Les coupures existent, parfois plusieurs heures.

Ma réponse est matérielle, pas rhétorique : un onduleur qui tient le poste de travail et la box, un ordinateur portable dont l'autonomie est un critère d'achat, et un partage de connexion mobile en secours. Coût total : quelques centaines d'euros, amortis au premier incident évité.

Ce n'est pas un détail de confort. C'est ce qui fait la différence entre « il disparaît parfois » et « il est fiable ». Un client ne juge pas ton contexte, il juge ta disponibilité.

La preuve de fiabilité doit précéder la confiance

Un développeur à Londres bénéficie d'un préjugé favorable. Moi, je dois prouver avant qu'on me fasse confiance. C'est injuste et c'est ainsi.

La bonne réponse n'est pas de s'en plaindre, c'est de rendre la preuve facile à constater :

  • Livrer petit et souvent. Trois merge requests par semaine construisent plus de confiance qu'une grosse livraison mensuelle, même de meilleure qualité. La régularité visible est un signal.
  • Écrire ce qu'on fait. Un commentaire quotidien sur le ticket : ce qui avance, ce qui bloque. Ça coûte deux minutes et supprime toute anxiété côté client.
  • Annoncer les problèmes tôt. Dire « ça va prendre deux jours de plus » au jour 1 se gère. Le dire au jour 3 crée une crise.

Au bout de six mois, ce préjugé disparaît complètement. Il faut simplement savoir qu'il faut le traverser.

L'écrit devient la compétence principale

En présentiel, on compense un message flou en se retournant vers son collègue. À distance et en asynchrone, un message ambigu coûte une journée.

Ce que j'ai appris à faire :

  • Le contexte avant la question. « J'ai un souci sur le calcul des heures » ne sert à rien. « Sur le calcul des heures majorées, le cas d'une visite à cheval sur minuit n'est pas défini dans la spec — je propose de compter chaque tranche à son tarif. Ça te va ? » se répond en dix secondes.
  • Proposer plutôt que demander. Une question ouverte demande une réflexion à ton interlocuteur. Une proposition ne demande qu'un accord.
  • Écrire dans le ticket, pas en message privé. Ce qui est dans le ticket est retrouvable dans six mois. Ce qui est en message privé est perdu.

Cette discipline m'a rendu meilleur y compris sur les projets locaux. C'est le bénéfice inattendu du travail à distance : il force une clarté qu'on n'atteint jamais autrement.

La langue, honnêtement

Mon anglais est professionnel, pas natif. À l'écrit, aucun problème. En réunion, sur un sujet technique dense avec plusieurs interlocuteurs qui se coupent la parole, je perds parfois le fil.

Ce que je fais : je demande l'ordre du jour à l'avance, je prends des notes pendant, et je résume par écrit après — « voici ce que j'ai compris, corrige-moi ». Ce résumé est utile à tout le monde, y compris aux anglophones natifs.

Le prétendre parfait serait une erreur. Le compenser par de la méthode fonctionne.

Ce que ça apporte, et qu'on sous-estime

Une contrainte technique qui rend meilleur

Quand ton contexte quotidien comprend des coupures, une bande passante variable et des appareils modestes, tu développes des réflexes que tes collègues n'ont pas.

Je remarque les écrans qui bloquent sur un appel réseau, parce que je les subis. Je remarque les bundles trop lourds, parce que je les télécharge. Je remarque les interfaces inutilisables sur un écran de 5 pouces, parce que c'est mon téléphone de test.

Ces réflexes profitent au produit entier — y compris aux utilisateurs londoniens. La contrainte est un avantage compétitif, à condition de la présenter comme telle plutôt que de s'en excuser.

Une compréhension de marchés que d'autres n'ont pas

Un client européen qui vise l'Afrique a besoin de quelqu'un qui sait qu'on paie en Mobile Money, que les données se comptent, que les prénoms occidentaux ne sont pas universels. Ce savoir ne s'apprend pas dans la documentation.

Le problème actuel, et il est réel

Le travail à distance a ouvert des portes, mais l'accès reste très inégal.

Le paiement est l'obstacle le plus concret. Recevoir de l'argent d'Europe ou d'Amérique du Nord au Cameroun implique des frais, des délais et parfois des refus purs et simples. Certaines plateformes de freelance ne desservent pas nos pays. Certains clients renoncent en découvrant qu'ils ne peuvent pas payer par leur processus habituel.

Les préjugés à l'embauche persistent. Le taux journalier proposé pour un travail identique varie selon le lieu de résidence. On appelle ça « ajustement au coût de la vie » ; c'est une décote appliquée à la géographie plutôt qu'à la valeur produite.

L'isolement professionnel est le plus insidieux. Pas de collègues à qui montrer un bout de code, peu de conférences accessibles, une communauté locale petite. C'est pour ça que j'écris ces articles, et que j'ai animé un groupe de formation React Native : construire localement ce qui n'existe pas encore.

Ce que je conseillerais à quelqu'un qui vise ça

  1. Rends ton travail visible. Un portfolio qui montre des projets réels avec le contexte et le résultat vaut plus que dix candidatures.
  2. Écris. Un article technique bien fait sur un sujet que tu maîtrises te positionne mieux qu'un CV. Il travaille pendant que tu dors.
  3. Commence par une mission courte. Personne ne confie un projet de six mois à un inconnu. Deux semaines bien exécutées ouvrent la suite.
  4. Investis dans ta fiabilité matérielle avant d'investir dans ton matériel. Un onduleur avant un second écran.
  5. Ne brade pas. Le tarif bas attire les clients qui cherchent le tarif bas, et ceux-là sont les plus difficiles. Un tarif juste, défendu par des références concrètes, attire de meilleurs interlocuteurs.

Ce dernier point m'a demandé le plus de temps à comprendre.


Mon parcours complet est sur la page d'accueil, et les études de cas ici. Si tu cherches un développeur qui connaît les deux réalités — produits pour l'Afrique, standards européens — écris-moi.