Codebase : prête pour votre équipe ?

Votre première version tenait peut-être dans la tête d'une seule personne. Elle savait où intervenir, quelles zones éviter et pourquoi ce choix étrange avait été fait six mois plus tôt. Puis une deuxième personne arrive. Les questions commencent. La troisième modifie un module et en casse un autre. Le problème n'est plus la vitesse de chacun. Votre base de code doit maintenant transmettre ce que son auteur gardait jusque-là en mémoire.

En 2021, j'ai rejoint une scale-up qui livrait des solutions utilisées quotidiennement par des dizaines de milliers de personnes, notamment pour McDonald's, Disney, la SNCF et Total. J'arrivais d'environnements early stage où je pouvais livrer en une journée. Là, chaque ligne était relue et challengée. Une modification apparemment simple pouvait prendre une semaine.

Au début, cette lenteur m'agaçait. J'avais l'impression que le processus prenait le dessus sur le travail. Puis j'ai compris ce que l'organisation protégeait. Un bug pouvait perturber des milliers d'utilisateurs et abîmer une relation commerciale importante. Voilà pourquoi l'équipe consacrait autant de temps aux revues et aux tests : une erreur coûtait bien plus cher.

Je ne copierais pas ces processus dans un MVP qui cherche encore son marché. Ils l'étoufferaient. En revanche, continuer à travailler comme au premier jour quand le produit et l'équipe ont grandi finit par coûter cher.

Le code d'une personne devient le système d'une équipe

Une base de code peut être très efficace pour son auteur et devenir pénible dès qu'une deuxième personne intervient. Le premier développeur connaît les raccourcis et l'histoire du produit. Il n'a pas besoin que le code lui raconte ce qu'il sait déjà.

Une équipe ne partage pas cette mémoire. Où se trouve la facturation ? Quelle partie calcule un tarif ? Que peut-on modifier sans relire toute l'application ? Si les réponses changent selon la personne interrogée, votre architecture repose encore sur des habitudes individuelles.

Voilà ce que structurer veut dire : rendre les responsabilités visibles. Ranger les fichiers ne suffit pas. Un développeur qui travaille sur l'abonnement doit pouvoir trouver les fichiers concernés et vérifier sa modification sans explorer tout le produit.

Le découpage suit souvent les domaines du SaaS : comptes, catalogue, facturation, support ou reporting. Le choix des noms importe moins que la règle commune. Chaque domaine contient ses propres règles, sans que les autres aillent modifier directement ses détails internes.

Le problème apparaît tôt. Deux personnes suffisent pour qu'une base de code difficile à lire commence à ralentir les livraisons. Le découpage du code détermine alors comment l'équipe peut répartir le travail.

Une codebase confuse freine votre recrutement

Embaucher un développeur ne double pas la capacité de livraison du jour au lendemain. Il faut lui transmettre le produit et les décisions passées. C'est normal. La situation se grippe quand chaque réponse exige l'intervention de la personne qui a construit la première version.

On le voit dès l'onboarding. Le nouveau développeur lance le projet, mais ne sait pas où intervenir. Il ouvre plusieurs fichiers, suit des appels dans tous les sens et finit par demander au développeur historique. Celui-ci interrompt son travail, explique le contexte, puis relit toute la modification par prudence. Vous avez recruté une personne. Pourtant, votre capacité réelle reste bloquée par une seule.

Puis chaque fonctionnalité ralentit. Une modification de facturation touche les utilisateurs et le reporting parce que les règles métier sont dispersées. Personne ne sait vraiment évaluer la zone d'impact. L'équipe compense avec des réunions et des validations plus longues. Peu à peu, déployer devient inquiétant.

DORA relie la performance de livraison à la capacité de petites équipes à travailler sur leur périmètre sans dépendre constamment des autres. Cela ne demande pas de transformer chaque module en microservice. La documentation DORA sur les équipes faiblement couplées conseille de réduire les dépendances et de faire évoluer l'architecture progressivement.

Dans ce genre de situation, je regarde où se forme la file d'attente. Si tout passe encore par la personne la plus expérimentée, recruter n'a fait que déplacer le problème. La structure du code et la répartition des responsabilités limitent alors la croissance plus que le nombre de développeurs.

Structurer sans tout réécrire

À ce stade, j'entends souvent la même proposition : « il faut tout réécrire » ou « il faut passer aux microservices ». C'est tentant, parce que le problème paraît profond. Mais on remplace vite une base difficile à lire par un chantier long, plusieurs déploiements et de nouvelles façons de tomber en panne. Une équipe qui grandit a souvent besoin d'un monolithe mieux organisé.

Je commence par les zones qui concentrent le plus de changements ou d'erreurs. La facturation et les permissions reviennent souvent. Je regroupe ensuite leurs règles au même endroit dans le code. Une règle de facturation ne doit pas être recopiée dans plusieurs parties du produit.

Je prends ensuite une fonctionnalité critique et je la suis sans sauter d'un dossier à l'autre. Pour un paiement, on doit retrouver facilement la règle appliquée et le test qui vérifie qu'elle fonctionne. C'est plus utile qu'une belle arborescence remplie de couches abstraites.

Les conventions viennent au moment où un désaccord commence à coûter du temps. Où placer une règle métier ? Quel test exiger sur un paiement ? Une bonne convention tranche une question qui revient. Un document de trente pages que personne ne consulte ne structure rien.

Les revues de code servent à partager la connaissance et à protéger les frontières choisies. GitHub rappelle qu'une revue permet de discuter une modification avant sa fusion et d'en partager le contexte. Avec CODEOWNERS, la bonne personne peut être sollicitée automatiquement selon la zone touchée, comme l'explique la documentation GitHub sur les revues. Le nom de l'outil m'importe peu. Une décision importante ne doit pas rester enfermée dans la tête de son auteur.

La documentation doit rester proche du travail réel. Pour commencer, un guide fiable pour lancer le projet et une cartographie simple des domaines suffisent déjà. DORA associe la qualité de la documentation à la performance de l'organisation et rappelle qu'elle demande un entretien actif. Documentez ce que le code ne peut pas expliquer seul. Supprimez le reste dès qu'il devient faux. La synthèse DORA sur la qualité de la documentation donne un bon cadre.

Ce travail avance pendant les développements. Quand l'équipe touche une zone confuse, elle clarifie sa responsabilité et ajoute le test qui manquait. Cette méthode évite de geler la roadmap pendant trois mois pour obtenir une architecture théorique qui sera déjà dépassée à la fin.

Décider quand investir dans la structure

Les premiers symptômes ont l'air ordinaires. La même personne valide presque toutes les modifications, pendant que les nouveaux arrivants contournent certaines zones par peur de les casser. À ce moment-là, la base de code impose déjà sa taxe.

Le temps d'onboarding donne un indicateur plus honnête. Le jour où le développeur installe le projet ne dit pas grand-chose. Regardez plutôt quand il peut livrer une modification utile et expliquer son impact sans assistance permanente. C'est ce passage à l'autonomie qui commence à rembourser le recrutement.

Le niveau d'investissement dépend du stade du SaaS. Avant le product-market fit, gardez peu de règles et protégez les zones où une erreur serait grave. Avec des clients actifs et plusieurs développeurs, formalisez les domaines et les revues. Quand plusieurs équipes travaillent sur le même produit, attribuez clairement à chacune la responsabilité d'une partie du code.

On peut cadrer ce travail sans lire chaque ligne. Demandez à l'équipe de dessiner les grands domaines du produit, puis de montrer où une fonctionnalité traverse leurs frontières. Repérez aussi les modifications qui exigent toujours la même personne. Cette carte des dépendances sera bien plus utile qu'un débat abstrait sur l'architecture idéale.

Je reviens toujours à la même question : « une nouvelle personne peut-elle prendre la responsabilité d'une partie du produit sans ralentir tout le monde ? » Si la réponse est non, commencez par clarifier la responsabilité de chaque domaine et les dépendances entre eux. Vous parlerez de réécriture seulement si ce travail montre que le problème est vraiment global.

Ce travail complète la réflexion sur la composition d'une équipe tech avec peu de moyens. Il peut aussi être cadré dans une mission de développement SaaS lorsque l'équipe doit continuer à livrer pendant la restructuration.

Ce qu'il faut retenir

Une base de code prête à grandir n'est pas parfaite. Elle rend les responsabilités assez claires pour qu'une nouvelle personne puisse comprendre une partie du produit et la modifier sans dépendre en permanence du développeur historique.

Commencez par les domaines qui changent souvent ou génèrent le plus de risque. Clarifiez leurs frontières pendant les développements. Les conventions et les revues doivent résoudre les frictions que l'équipe rencontre réellement. La structure grandit avec l'équipe, pas avec les ambitions théoriques de l'architecture.

Questions fréquentes

Faut-il passer aux microservices quand l'équipe grandit ?

Non. Plusieurs développeurs peuvent travailler efficacement dans un monolithe bien découpé. Les microservices deviennent pertinents lorsque des équipes doivent faire évoluer et déployer des parties du produit de manière indépendante. Encore faut-il qu'elles puissent assumer le coût opérationnel supplémentaire.

Quelle documentation faut-il pour accueillir un développeur ?

Commencez par un guide fiable pour lancer le projet et une carte des principaux domaines. Ajoutez les décisions d'architecture encore actives, puis les procédures liées au déploiement. Une documentation courte et maintenue aide davantage qu'un inventaire exhaustif qui vieillit dès la prochaine livraison.

Quand faut-il refactorer la base de code ?

Refactorez lorsqu'une zone ralentit régulièrement les fonctionnalités ou dépend d'une seule personne. Traitez d'abord les modules les plus sollicités et avancez par étapes pendant la roadmap. Une réécriture complète ne se justifie que si le problème est global et démontré.

Conclusion

Réservez un échange de 30 minutes pour identifier les parties de votre SaaS qui limitent déjà l'autonomie de l'équipe et cadrer une restructuration progressive.