Dans Haikyū!!, Hinata est trop petit pour jouer au volley à haut niveau. C'est un fait, il ne va pas grandir. Alors il ne travaille pas sa taille : il travaille sa vitesse, sa détente, sa lecture du jeu. La contrainte ne disparaît pas — elle force un jeu différent, et ce jeu finit par être imprenable.
Je n'écris pas cet article pour me plaindre. Les obstacles que je vais lister sont réels, et je les vis toutes les semaines. Mais chacun a une réponse, et certaines de ces réponses m'ont rendu meilleur que si le problème n'avait jamais existé.
C'est ce qui manque dans la plupart des textes sur le sujet : la partie « voilà ce que je fais ».
1. Le courant
Le problème. Les coupures. Parfois annoncées, souvent pas. Une heure, une demi-journée. Et le pire n'est pas la coupure : c'est le micro-coupure qui redémarre la machine en plein build.
Ce que je fais. Un onduleur qui tient le poste de travail et la box. Un ordinateur portable dont l'autonomie est un critère d'achat, pas un bonus. Et la règle qui a le plus changé ma vie : je commite tôt et souvent, sur une branche, même quand ce n'est pas fini. Une coupure ne me coûte plus qu'un git stash oublié.
Coût total : quelques centaines d'euros, amortis au premier incident évité. Ce n'est pas du confort, c'est la différence entre « il disparaît parfois » et « il est fiable ».
2. Les données, pas la connexion
Le problème. Contrairement à l'idée reçue, la fibre existe et elle est correcte. Ce qui coûte, c'est le volume.
Un npm install sur un projet React, c'est plusieurs centaines de mégaoctets. Une image Docker, un ou deux gigaoctets. Un SDK Android, davantage. Quand le forfait se compte, chaque rm -rf node_modules réflexe devient une dépense.
Ce que je fais. Un cache local agressif : npm config set cache, un registre proxy, des images Docker construites en couches pour ne retélécharger que ce qui change. J'évite de supprimer node_modules « pour voir ». Et je garde un partage de connexion mobile en secours, parce qu'une panne de fibre le jour d'une livraison ne se négocie pas.
Bénéfice inattendu : cette discipline me rend attentif au poids de ce que je livre. Je remarque les bundles trop lourds parce que je les télécharge. Mes utilisateurs en profitent.
3. Le matériel
Le problème. Une machine correcte coûte ici le même prix qu'en Europe, parfois plus avec les droits de douane, pour un revenu local très différent. Et la réparation est aléatoire : une pièce peut prendre trois semaines.
Ce que je fais. J'achète moins souvent et mieux : de la RAM et du SSD plutôt que du processeur, parce que c'est ce qui limite réellement sur nos charges de travail. Je garde l'ancienne machine comme secours plutôt que de la revendre. Et j'ai un vrai téléphone d'entrée de gamme comme appareil de test, pas un flagship : c'est ce que mes utilisateurs ont réellement.
Ce dernier point est passé de contrainte budgétaire à avantage professionnel. Je vois les écrans qui rament parce que je les subis.
4. Recevoir l'argent
C'est l'obstacle le plus concret, et celui dont on parle le moins.
Le problème. Recevoir un virement d'Europe ou du Canada implique des frais, des délais, et parfois un refus pur et simple. 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.
Ce que je fais. J'ai plusieurs canaux, jamais un seul, et je les propose dès le devis plutôt que de découvrir le blocage à la première facture. Je facture en euros ou en dollars avec une mention claire sur qui supporte les frais de transfert — sinon ils sont retirés de ton montant et tu l'apprends en recevant moins que prévu.
Le détail qui change tout : négocier les frais dans le contrat, pas après.
5. Le préjugé
Le problème. À compétence égale, le tarif proposé 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.
Et il y a la méfiance initiale : un développeur à Londres bénéficie d'un préjugé favorable, moi je dois prouver.
Ce que je fais. Je rends la preuve facile à constater. Livrer petit et souvent — trois merge requests par semaine construisent plus de confiance qu'une grosse livraison mensuelle. Écrire ce que je fais, chaque jour, dans le ticket. Annoncer les problèmes tôt.
Et je ne brade pas. Un tarif bas attire les clients qui cherchent un tarif bas, et ceux-là sont les plus difficiles. C'est le point qui m'a demandé le plus de temps à comprendre.
Au bout de six mois avec un client, ce préjugé disparaît complètement. Il faut simplement savoir qu'il faut le traverser.
6. L'isolement
Le problème. Pas de collègue à qui montrer un bout de code. Peu de conférences accessibles. Une communauté locale réelle mais petite. Sur un problème pointu, tu es seul avec la documentation.
C'est l'obstacle le plus insidieux, parce qu'il ne se voit pas et qu'il use lentement.
Ce que je fais. J'écris. Ces articles ne sont pas seulement du contenu : expliquer quelque chose à quelqu'un reste le meilleur détecteur de ce qu'on n'a pas compris. J'ai animé un groupe de formation React Native où l'on faisait de la revue de code entre nous — construire localement ce qui n'existe pas encore.
Et je relis mes propres diffs le lendemain matin avant de fusionner. Le décalage suffit à retrouver un œil neuf. C'est imparfait, c'est mieux que rien.
7. L'administratif
Le problème. Le statut, les impôts sur des revenus étrangers, la facturation à l'international, la preuve de revenus quand une banque la demande. Rien de tout ça n'est enseigné, et l'information disponible est contradictoire.
Ce que je fais. Je garde tout, systématiquement : contrats, factures, relevés. Un dossier par client, par année. Ça paraît excessif jusqu'au jour où on te demande trois ans d'historique.
Et j'ai payé un comptable. C'est la dépense que j'ai le plus repoussée et la plus rentable.
Ce que la contrainte apporte réellement
Je ne vais pas romantiser : ces obstacles coûtent du temps et de l'argent, et certains sont injustes.
Mais quelque chose de réel en sort. Quand ton contexte quotidien comprend des coupures, une bande passante comptée et des appareils modestes, tu développes des réflexes que tes collègues n'ont pas. Tu remarques les écrans qui bloquent sur un appel réseau. Tu conçois des applications qui fonctionnent hors connexion parce que c'est ta vie. Tu sais ce qu'un paiement Mobile Money fait vraiment quand il rate.
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. C'est la vitesse de Hinata : elle n'existe que parce que la taille manquait.
À quelqu'un qui débute ici
Dans l'ordre où je le referais :
- Onduleur avant second écran. La fiabilité avant le confort.
- Un portfolio qui montre du réel — contexte, réalisation, résultat. Il travaille pendant que tu dors, et il vaut mieux que dix candidatures.
- Écris. Un article sérieux sur un sujet que tu maîtrises te positionne mieux qu'un CV.
- Une mission courte d'abord. Personne ne confie six mois à un inconnu ; deux semaines bien exécutées ouvrent la suite.
- Règle le canal de paiement avant la première facture, pas après.
- Ne brade pas.
Mon parcours complet est sur la page d'accueil, et j'ai écrit ailleurs sur le travail à distance depuis Bafoussam pour des clients européens. Si tu débutes ici et que tu veux poser une question, elle est la bienvenue.