Travailler en solo à grande échelle : gérer des dizaines de projets avec une petite équipe
Il existe un moment dans la croissance de toute petite structure où le nombre de projets actifs dépasse ce qu’on peut garder en mémoire de travail. Les commandes nécessitent un suivi sur plusieurs places de marché. L’infrastructure demande une maintenance régulière. De nouvelles fonctionnalités sont en développement. Les clients posent des questions sur les expéditions, la conformité et les projections. Tout cela est un vrai travail, et les heures disponibles n’augmentent pas avec le nombre de projets.
La plupart des conseils sur la gestion de cette situation supposent que vous allez recruter davantage. C’est souvent la bonne réponse. Mais ce n’est pas toujours la bonne réponse, notamment lorsque les projets sont diversifiés — différentes piles technologiques, différents domaines, différents rythmes opérationnels — et lorsque le chiffre d’affaires supplémentaire d’un projet donné ne justifie pas un poste dédié. Les petites équipes gérant des dizaines de projets ont besoin de systèmes, pas seulement de plus de personnes.
Cet article décrit l’approche que nous utilisons : les choix d’outillage qui ont tenu dans le temps, les principes opérationnels qui réduisent la charge de coordination, et la tension entre construire de nouvelles choses et maintenir ce qui fonctionne déjà.
La tension centrale
La tension fondamentale dans les opérations à grande échelle d’une petite équipe se situe entre les deux choses qui se disputent la même ressource — l’attention. Construire de nouvelles choses nécessite une attention ininterrompue et exploratoire. Maintenir les systèmes existants nécessite une attention réactive, capable de répondre aux sollicitations. Ces modes ne sont pas compatibles, et passer de l’un à l’autre a un coût qui n’apparaît dans aucun outil de gestion de projet.
Mais en réalité, la plupart des problèmes opérationnels ne viennent pas d’un échec à choisir l’un ou l’autre mode. Ils viennent de l’absence de choix — de laisser la frontière entre maintenance et développement se brouiller jusqu’à ce que ni l’un ni l’autre ne se fasse correctement. Les tâches de maintenance en attente s’accumulent parce que le développement les relègue au second plan. Le travail de développement s’enlise parce que les interruptions de maintenance s’accumulent. Les deux en souffrent.
La discipline que nous appliquons est une répartition du temps décidée explicitement plutôt que subie. Une proportion définie de chaque semaine est réservée à la maintenance — revues d’infrastructure, mises à jour des dépendances, vérifications de supervision, rapports aux clients — et n’est pas disponible pour le travail de développement quel que soit l’intérêt du moment. Le temps de développement est protégé des interruptions de maintenance sauf pour les incidents réels. L’allocation n’est pas rigide à la minute, mais elle est assez réelle pour ne pas être absorbée silencieusement par d’autres priorités.
Choix d’outillage
Le principe que nous appliquons à l’outillage est : standardiser sans compromis au sein d’une pile technologique et minimiser le nombre de piles. Chaque outil supplémentaire est une source potentielle de panne, quelque chose à apprendre, une dépendance potentielle qui peut bloquer un travail sans rapport quand il pose problème. Le coût d’un outil n’est pas sa redevance de licence — c’est l’attention permanente que demandent toutes les tâches qui l’impliquent.
Pour l’infrastructure, nous utilisons Docker chez un seul fournisseur. Pas Kubernetes, pas une architecture multi-cloud, pas un service mesh. Docker Compose sur un VPS correctement dimensionné gère la charge de travail de tout ce que nous exploitons actuellement, avec une documentation claire qui rend la récupération après une panne simple. La complexité opérationnelle d’une infrastructure plus sophistiquée coûterait plus en attention de maintenance qu’elle n’économiserait dans toute autre dimension.
Pour le développement d’applications, nous nous limitons à un petit ensemble de technologies standardisées : TypeScript pour les frontends web, Python pour les services backend et les pipelines de données, PostgreSQL (souvent TimescaleDB) pour le stockage persistant, Redis pour la mise en file d’attente et le cache. Les nouveaux projets adoptent cette pile technologique par défaut sauf raison impérieuse de s’en écarter. La raison impérieuse doit être énoncée explicitement et mise en balance avec le coût de maintenance d’une pile technologique non standard sur le long terme.
Pour la gestion de projets et de tâches, nous utilisons un système suffisamment simple pour que l’outil lui-même ne devienne pas un projet. La charge de maintenance d’un système de gestion de projet complexe dépasse souvent la charge des projets qu’il est censé coordonner. La structure qui importe est : chaque projet a un état actuel défini, une prochaine action définie, et un responsable désigné. Tout le reste est un détail optionnel.
La discipline ici est de résister à la pression d’adopter de nouveaux outils qui résolvent des problèmes que vous n’avez pas encore. Une nouvelle plateforme d’observabilité, un nouveau pipeline de déploiement, un nouvel outil de communication d’équipe — chacun est présenté comme une solution. Mais en réalité, le coût d’adoption est réel et immédiat, tandis que le bénéfice est spéculatif et différé. Nous évaluons les nouveaux outils en nous demandant : quel problème précis que nous rencontrons actuellement cet outil résout-il, et sa résolution justifie-t-elle les coûts d’adoption et de maintenance ?
Opérations asynchrones en priorité
La communication synchrone — appels, réunions, chat en temps réel — a un coût fixe par interaction indépendamment de la complexité du sujet. Elle a aussi un coût d’organisation qui dépasse souvent le coût de l’interaction elle-même. Pour les petites équipes avec des portefeuilles de projets diversifiés, la charge de la coordination synchrone peut consommer une part disproportionnée du temps de travail disponible.
Nous privilégions le fonctionnement asynchrone : la communication écrite et la documentation sont la règle, et les interactions synchrones sont réservées aux situations où l’écrit ne suffit réellement pas. Lorsqu’une réponse se trouve dans la documentation, il faut la consulter, et si la documentation n’existe pas, l’écrire est la réponse à la question — pas un appel synchrone qui répond à cette occurrence mais laisse la suivante sans réponse.
L’expression pratique de ce principe est que les décisions sont prises par écrit. Quand une décision technique ou opérationnelle significative est prise — un choix de base de données, un changement de processus de déploiement, une modification d’un flux de travail client — la décision est documentée avec le raisonnement, les alternatives considérées et le résultat attendu. Cette documentation n’est pas pour la postérité. C’est pour la prochaine fois que la même question se pose, ce qui, dans une petite équipe gérant plusieurs projets, arrive plus souvent que chacun ne le pense.
Les mises à jour de statut sont écrites et planifiées plutôt que verbales et réactives. Chaque projet a un bref état hebdomadaire — statut actuel, changements récents, travail à venir et tout blocage — qui est écrit plutôt que rapporté en réunion. L’acte d’écrire la mise à jour révèle souvent des problèmes qui n’auraient pas émergé lors d’un point verbal, parce que l’écriture impose le niveau de précision qui rend les problèmes visibles.
Développer ou acheter
Chaque outil que vous construisez est un projet que vous vous engagez à maintenir indéfiniment. C’est facile à oublier quand la décision de construction est prise, parce qu’à ce moment-là le coût est le coût de construction et le bénéfice est la capacité que l’outil procure. Le coût de maintenance continu n’est pas visible avant plus tard, mais il est réel et se cumule.
Nous appliquons trois critères aux décisions de développement ou d’achat. Premièrement : l’outil existe-t-il sous une forme qui résout adéquatement le problème ? Une solution adéquate n’est pas nécessairement parfaite. Un outil commercial qui résout correctement quatre-vingt-dix pour cent du problème est presque toujours préférable à un outil sur mesure qui résout cent pour cent du problème au prix d’une maintenance continue, parce que l’écart de dix pour cent est généralement plus petit que le coût de maintenance continu de l’outil sur mesure.
Deuxièmement : le problème nécessite-t-il une connaissance de nos données ou systèmes spécifiques qu’aucun outil externe ne peut avoir ? Les pipelines de données, la logique métier et les intégrations entre systèmes que nous contrôlons se prêtent à un développement sur mesure. Les fonctions génériques — envoi d’e-mails, traitement des paiements, authentification, tableaux de bord de supervision — se prêtent à l’achat d’une solution existante à moins que les options commerciales ne soient réellement inadaptées.
Troisièmement : sommes-nous prêts à partager les données concernées avec un service tiers ? Certaines données opérationnelles — détails des commandes, informations clients, dossiers financiers — ne doivent pas transiter par des services commerciaux qui les enregistrent, les analysent ou les utilisent à leurs propres fins. Les solutions auto-hébergées pour ces fonctions se justifient pour des raisons de confidentialité même quand les alternatives commerciales sont techniquement supérieures. C’est pourquoi nous auto-hébergeons notre outil d’analyse de données, notre backend Supabase et notre pile de supervision.
Mais en réalité, les décisions de construction les plus coûteuses que nous ayons prises n’étaient pas manifestement erronées sur le moment. Elles ressemblaient à des outils sur mesure raisonnables pour des besoins spécifiques. Le coût est apparu dix-huit mois plus tard, quand l’outil avait besoin d’être mis à jour pour s’adapter à un changement de dépendance, ou quand un nouveau membre de l’équipe devait comprendre une base de code sans documentation externe, ou quand un bug dans l’outil sur mesure bloquait une livraison client sans aucun canal d’assistance permettant de faire remonter le problème. La leçon n’est pas de ne jamais construire. C’est d’être honnête sur le coût sur toute la durée de vie, pas seulement le coût de construction.
La vision en portefeuille
Gérer des dizaines de projets simultanément est plus facile quand chaque projet est compris comme un élément d’un portefeuille plutôt que comme une obligation indépendante. Un portefeuille a des projets dont les rendements se cumulent — générant des rendements qui croissent dans le temps avec un investissement continu relativement faible — et d’autres qui stagnent ou déclinent. La question d’allocation des ressources est différente pour chacun.
Les projets dont les rendements se cumulent méritent un investissement de maintenance pour protéger ce qui fonctionne, mais nécessitent rarement de nouveaux développements importants. Une activité d’e-commerce disposant d’un positionnement organique stable, d’un ensemble d’avis satisfaisant et d’une logistique fiable génère déjà ses rendements. Le travail consiste à préserver son fonctionnement plutôt qu’à l’améliorer. C’est une posture fondamentalement différente d’un projet encore en construction — et elle nécessite moins d’attention, ce qui libère de la capacité pour les projets dont les rendements ne se cumulent pas encore.
Les projets dont les rendements ne se cumulent pas nécessitent une évaluation claire : la trajectoire est-elle susceptible de s’améliorer avec un investissement supplémentaire, ou est-il temps d’accepter le résultat et de réaffecter les ressources ? Les petites équipes avec de nombreux projets sont particulièrement exposées au biais des coûts irrécupérables — continuer à investir dans des projets qui ne fonctionnent pas à cause des efforts déjà dépensés. La vision en portefeuille rend ce mode d’échec plus visible, car elle force une comparaison : l’attention consacrée à maintenir un projet au point mort est une attention qui n’est pas disponible pour les projets dont les rendements pourraient se cumuler.
Le vrai goulot d’étranglement
La vision conventionnelle des contraintes de passage à l’échelle d’une petite équipe se concentre sur l’argent et le temps. Plus de projets nécessitent plus d’argent pour les financer et plus de temps pour les exécuter. C’est vrai mais incomplet.
La principale contrainte pour une petite équipe gérant des projets diversifiés dans plusieurs domaines est l’attention — plus précisément, la qualité de l’attention disponible pour les décisions qui nécessitent du contexte. Les tâches opérationnelles routinières peuvent être systématisées, déléguées ou automatisées. Les décisions portant sur les prochains développements, la réponse à un changement de marché, l’opportunité d’entrer sur une nouvelle place de marché ou la pertinence d’une approche technique nécessitent le jugement éclairé d’une personne connaissant l’ensemble du contexte. Ce type d’attention n’augmente pas linéairement avec la taille de l’équipe, et il ne peut pas être éliminé par la systématisation.
L’implication est que le levier le plus important dans les opérations d’une petite équipe n’est pas l’efficacité — faire les mêmes choses plus vite — mais la sélectivité : choisir d’abord ce qui mérite d’être fait. Un projet qui nécessite une attention constante pour rester viable n’est pas un projet bon marché même si ses coûts directs sont faibles. Un projet qui fonctionne de manière fiable avec une intervention minimale est un élément de portefeuille plus précieux que son chiffre d’affaires ne le suggère, parce qu’il ne consomme pas l’attention que les tâches nécessitant un jugement approfondi demandent.
Nous rendons cela explicite dans la sélection de projets. Avant de nous engager dans une nouvelle initiative, nous estimons non seulement l’effort de construction mais le besoin d’attention en régime permanent : combien d’heures par semaine son exploitation demandera-t-elle une fois le projet réalisé ? Les projets où le besoin d’attention en régime permanent est élevé par rapport au rendement sont moins attractifs qu’ils n’y paraissent quand seuls le coût de construction et les gains potentiels sont pris en compte. Le budget d’attention est fini, et contrairement à l’argent ou au temps, vous ne pouvez pas en acheter davantage.
Ressources connexes
- Ingénierie de la distribution : construire des systèmes qui vendent à votre place — le principe sous-jacent à la construction de systèmes opérationnels qui demandent peu d’attention
- Plus d’une centaine de conteneurs Docker : notre routine de contrôle mensuel — la discipline de maintenance qui rend la charge d’infrastructure prévisible
- Construire un entrepôt de données Amazon avec FastAPI et TimescaleDB — un exemple de décision de construction et l’infrastructure de données sur laquelle repose le portefeuille