Sur Glyph, une marketplace d'impression à Yaoundé, j'ai développé les trois briques : le backend en Go, l'application mobile en Expo, la console d'administration en Next.js. Seul.
La réaction habituelle, quand je le raconte, oscille entre « c'est impossible » et « ça doit être bâclé ». Les deux méritent une réponse honnête.
Le mythe de l'équipe minimale
Il existe une croyance tenace selon laquelle un produit sérieux exige au minimum un backend, un frontend, un mobile, un designer et un chef de produit. Cinq personnes avant la première ligne de code.
C'est faux pour une raison simple : la coordination a un coût qui croît plus vite que la production. À cinq, tu passes tes journées en synchronisation, en spécifications d'interfaces, en revues croisées, en attente. À un, ce coût est nul.
Saitama, dans One Punch Man, ne s'est pas entraîné avec un coach, une salle high-tech ou un programme de nutritionniste. Cent pompes, cent abdos, cent squats, dix kilomètres, tous les jours, pendant un an et demi. La blague du manga, c'est que cette routine ridicule fonctionne mieux que toutes les méthodes sophistiquées.
Le parallèle a ses limites — je ne prétends pas battre une équipe de dix. Mais l'idée tient : la régularité et la simplicité battent la sophistication mal exécutée. Un développeur seul qui livre tous les jours dépasse une équipe de cinq bloquée en réunion de cadrage depuis trois semaines.
Ce que la contrainte impose
Tu ne peux pas te permettre d'être malin
Quand tu es seul, chaque abstraction que tu écris, c'est toi qui la maintiendras à 2 h du matin dans six mois. Cette perspective a un effet remarquablement assainissant sur les envies d'architecture.
Sur le backend Go de Glyph, l'architecture tient en quatre couches :
cmd/server point d'entrée, injection des dépendances
internal/domain entités métier pures, zéro dépendance
internal/repository contrats + implémentations MongoDB
internal/service cas d'usage
internal/handlers HTTP
Aucun générateur de code. Aucune injection de dépendances par réflexion. Aucun framework maison. Des fonctions qui prennent des paramètres et renvoient des valeurs.
Ce n'est pas impressionnant. C'est lisible six mois plus tard, ce qui vaut infiniment mieux.
Tu dois choisir tes technologies pour la sortie, pas pour l'entrée
Le critère habituel de choix technologique : « avec quoi vais-je aller le plus vite ? » Le bon critère quand tu es seul : « qu'est-ce qui va me coûter le moins cher à exploiter ? »
Go pour le backend, ce n'est pas le langage où j'écris le plus vite. C'est celui qui produit un binaire unique, sans dépendances système, qui démarre en trente millisecondes et consomme trente mégaoctets de RAM. Sur un VPS partagé avec d'autres projets, ça compte tous les jours.
Expo pour le mobile, ce n'est pas la solution la plus puissante. C'est celle qui me permet de livrer iOS et Android sans posséder de Mac dédié à la compilation et sans gérer deux chaînes natives.
Ces choix sont des choix d'exploitant, pas de développeur. C'est le changement de perspective le plus utile que le travail en solo m'ait apporté.
Tu deviens le premier utilisateur de tes propres interfaces
Quand la même personne écrit l'API et le client qui la consomme, une chose amusante se produit : les mauvaises API disparaissent en quelques heures.
Un endpoint qui oblige à faire trois appels pour afficher un écran ? Je le sens en écrivant l'écran, je retourne le corriger. Une réponse qui renvoie des identifiants sans les libellés associés ? Corrigée avant même d'être documentée.
Dans une équipe, cette friction devient un ticket, une discussion, un compromis, parfois un « on fera avec ». Seul, la boucle de retour est immédiate et l'ego n'a pas le temps de s'en mêler.
Ce que la contrainte interdit
Il faut être honnête sur les limites, sinon ce texte n'est qu'une publicité.
Tu n'as pas de relecteur. Personne ne te dit « ce nom de variable est incompréhensible » ou « tu viens de réinventer la roue ». Ma parade : je relis mes diffs le lendemain matin, avant de fusionner. Le décalage suffit à retrouver un œil neuf. Imparfait, mais mieux que rien.
Tu n'as pas de spécialiste. Quand un problème de sécurité pointe le nez, tu n'as pas de référent. Tu lis, tu apprends, tu doutes. Sur les sujets sensibles — paiement, authentification, isolation de données — je m'impose de ne rien inventer : je suis les recommandations officielles à la lettre, même quand elles me semblent excessives.
Tu es un point de défaillance unique. C'est le vrai risque, et il est pour le client. Ma réponse : une documentation écrite comme si je disparaissais demain. Le dépôt de Glyph contient un README qui permet à quelqu'un d'autre de faire tourner l'ensemble en une commande, et un fichier d'architecture qui explique les décisions et leurs raisons.
C'est aussi ce que je regarde en priorité quand je reprends le projet d'un autre : est-ce que quelqu'un a écrit pourquoi, pas seulement quoi.
Le vrai sujet : la charge cognitive
Le coût réel du travail en solo n'est pas la quantité de code. C'est le changement de contexte.
Passer de Go à TypeScript, de MongoDB à React Query, d'une logique de commande à une grille tarifaire, c'est vider et recharger sa mémoire de travail plusieurs fois par jour. C'est épuisant d'une manière que le simple volume de travail n'explique pas.
Ce qui m'aide :
- Une brique par jour, pas trois. Lundi backend, mardi mobile. Pas backend le matin et mobile l'après-midi.
- Écrire l'état avant d'arrêter. Trois lignes dans un fichier de notes : où j'en suis, ce qui bloque, la prochaine action. Reprendre le lendemain coûte deux minutes au lieu de quarante.
- Des conventions identiques partout. Même façon de nommer, même structure de dossiers, même gestion d'erreur, quel que soit le langage. Le cerveau reconnaît des motifs même quand la syntaxe change.
Ce dernier point est celui qui a le plus d'effet, et il est presque invisible dans le code final.
Le problème actuel de la profession
On a construit un écosystème qui suppose l'abondance. Les tutoriels supposent une équipe. Les architectures de référence supposent des microservices, donc plusieurs équipes. Les outils supposent un budget infra.
Or l'immense majorité des développeurs dans le monde travaille seul ou à deux, sur des produits réels, avec des contraintes de coût sérieuses. Cette réalité est très mal documentée, parce que ceux qui écrivent le contenu technique le plus visible travaillent dans de grandes structures.
Le résultat, c'est une génération de développeurs qui découpe en microservices un produit qui a trois utilisateurs, parce que c'est ce que fait Netflix. Le mimétisme architectural coûte cher.
La question à se poser avant chaque décision technique : « est-ce que je résous mon problème, ou celui de quelqu'un dont j'ai lu l'article ? »
Ce que je recommanderais à quelqu'un qui démarre seul
- Un monolithe. Toujours. Tu le découperas quand une raison mesurée l'exigera. Elle ne viendra probablement jamais.
- Une base de données relationnelle, sauf raison impérieuse. Postgres fait 90 % de ce dont tu crois avoir besoin d'un outil spécialisé.
- Le déploiement dès le premier jour. Un « hello world » en production le lundi vaut mieux qu'une architecture parfaite non déployée le vendredi.
- Écrire les décisions. Un fichier, une décision par section : le contexte, le choix, l'alternative écartée. C'est le document que tu reliras le plus.
- Livrer petit, souvent. C'est la routine de Saitama : rien d'impressionnant pris isolément, redoutable sur la durée.
Glyph est décrit sur sa fiche projet. Si tu portes un produit seul et que tu veux un avis extérieur sur tes choix techniques, écris-moi — le premier échange est gratuit.