Le mythe du développeur solo désorganisé
Il y a une image persistante du développeur indépendant qui code en mode chaotique : tâches dans la tête, horaires erratiques, projets qui s'empilent sans structure. C'est parfois vrai. Mais ça ne dure pas, et ça ne scale pas.
Travailler seul ne signifie pas travailler sans méthode. Ça signifie que la méthode, c'est vous qui la définissez, vous qui l'appliquez, et vous qui la faites évoluer quand elle ne fonctionne plus. C'est une responsabilité, pas une liberté sans contrainte.
Voici comment j'organise mon travail au quotidien.
La gestion du temps : blocs thématiques, pas de multitâche
Je n'essaie plus de travailler sur plusieurs projets en alternance rapide dans la même journée. Chaque changement de contexte coûte du temps de réinstallation mentale : retrouver où on en était, relire ce qu'on avait écrit, reprendre le fil.
Ma journée est découpée en blocs thématiques. Un bloc de développement sur un projet donné (minimum deux heures pour entrer vraiment dans le travail). Un bloc communication et gestion (réponses aux emails, mise à jour des devis, suivi de projet). Un bloc veille ou apprentissage si la semaine le permet.
Le multitâche au sens de "basculer toutes les dix minutes entre un bug et un email et une feature" est l'ennemi de la productivité réelle. Les notifications sont désactivées pendant les blocs de développement.
Git : feature branches et commits qui racontent quelque chose
Sur chaque projet, j'utilise Git avec un workflow par branches. Pas de développement directement sur main. Chaque fonctionnalité, chaque correction significative vit dans sa propre branche : feature/newsletter-planning, fix/formulaire-contact-validation, refactor/posts-index-query.
Avant de merger sur main, je relis le diff. Cette relecture est souvent l'occasion de trouver un var_dump() oublié, une variable mal nommée, une requête SQL qu'on pourrait simplifier.
Les messages de commit sont écrits pour être lisibles six mois plus tard. "Fix bug" ne dit rien. "Fix : validation email absente sur le formulaire de contact (retourne 500 si champ vide)" dit exactement ce qui s'est passé.
Les outils du quotidien
PhpStorm. Pour le code. L'autocomplétion Blade, la navigation dans les classes Laravel, l'intégration du débogueur Xdebug : je ne reviendrais pas à un éditeur de texte générique.
TablePlus. Pour les bases de données. L'interface est propre, la connexion à plusieurs environnements (local, production) est rapide, les requêtes ad hoc sont immédiates.
Laravel Herd. Pour l'environnement local. PHP, MySQL, et le routing .test gérés nativement sur macOS. Pas de configuration Docker à maintenir.
sshpass + scripts shell. Pour le déploiement sur o2switch. Pas de CI/CD complexe pour des projets de cette taille : un script shell qui build les assets, les copie en SCP, remet les permissions et vide les caches. Reproductible, documenté, sans dépendance à une plateforme tierce.
Terminal. Pour tout le reste : Artisan, npm, git, sshpass.
Pas de Jira, pas de Trello
Pour un développeur solo, Jira et même Trello sont surdimensionnés. Ces outils sont faits pour coordonner des équipes : la valeur est dans la visibilité partagée. Tout seul, cette visibilité est dans ma tête, et ce qui compte c'est de pouvoir la projeter rapidement.
J'utilise un fichier NOTES.md par projet, versionné avec Git, qui contient : l'état actuel, ce qui reste à faire, les décisions prises et pourquoi, les points bloquants. C'est suffisant pour reprendre le travail après une interruption de plusieurs jours sans perdre vingt minutes à retrouver le fil.
La review hebdomadaire
Chaque vendredi, je prends trente minutes pour faire le point.
Ce qui a été fait cette semaine sur chaque projet actif. Ce qui était prévu et n'a pas été fait (et pourquoi). Ce qui bloque. Les échéances de la semaine suivante.
Ce n'est pas une cérémonie Agile. C'est un moment de recul pour ne pas se laisser emporter par l'urgence du quotidien et perdre la vision d'ensemble de chaque projet.
Ce que ça change sur la durée
Travailler seul avec une méthode, c'est plus confortable que de travailler seul en mode réactif. La méthode n'empêche pas les imprévus : elle les absorbe mieux. Quand un projet urgent arrive, on sait exactement où on en est sur chaque autre projet, on peut prendre une décision informée sur la réorganisation.
Et ça donne de la crédibilité auprès des clients. Un développeur solo organisé, qui livre à l'heure et qui peut dire précisément où en est un projet à n'importe quel moment, c'est quelqu'un avec qui on a envie de retravailler.
