Vos équipes se marchent dessus ? Le problème vient peut-être de votre codebase

Au début d’un projet, tout semble simple. L’équipe est petite, la codebase est unique, et les échanges sont rapides. On avance vite, sans trop de contraintes.

Mais avec le temps, l’équipe grandit. Le produit aussi. Et ce qui fonctionnait au début commence à montrer ses limites.

Quand les équipes se marchent dessus

J’ai déjà travaillé sur un projet où plusieurs équipes intervenaient sur la même codebase. Chacune avançait sur ses fonctionnalités, mais très vite, les problèmes sont apparus.

Un changement dans une partie de la codebase cassait autre chose. Plusieurs équipes modifiaient les mêmes fichiers. Les dépendances devenaient de plus en plus difficiles à gérer.

Et surtout, personne ne savait vraiment où commençaient et où s’arrêtaient ses responsabilités.

Petit à petit, cela a entraîné beaucoup de coordination, des conflits, et le delivery a commencé à ralentir : les fonctionnalités mettaient plus de temps à sortir, les changements devenaient plus risqués, et chaque évolution demandait plus de coordination.

Le problème n’était pas technique

La codebase était organisée d’un point de vue purement technique.
Un monolithe fortement couplé au framework, structuré selon ses conventions.

Au début, cela semblait logique. Mais au fil du temps, il devenait de plus en plus difficile de s’y retrouver lorsqu’on devait faire évoluer la codebase.

Et surtout, le langage utilisé dans le code ne reflétait pas celui du métier.

On se retrouvait à utiliser des termes techniques ou liés au framework, qui ne faisaient pas sens pour les équipes produit ou métier. Les échanges devenaient plus compliqués, simplement parce qu’on ne parlait pas la même langue.

Le vrai problème n’était pas seulement technique.
La codebase avait grandi… mais elle n’avait jamais été structurée pour ça.

Elle n’était pas conçue pour permettre à plusieurs équipes de travailler efficacement dessus. Et l’organisation des équipes ne correspondait pas à la manière dont la codebase était construite.

Les équipes se retrouvaient à intervenir sur les mêmes zones du codebase, fortement couplées entre elles, à dépendre les unes des autres et à se bloquer.

Découper selon le métier

Pour résoudre ce problème, nous avons utilisé le DDD.

L’idée n’est pas de rajouter des patterns ou de la complexité, mais au contraire de simplifier en découpant la codebase selon le métier.

L’objectif est de faire en sorte que la codebase reflète le métier, et non l’inverse.

On identifie des Bounded Contexts : des zones du codebase qui correspondent chacune à une partie du métier.

On peut les voir comme des “applications dans l’application”. Chaque contexte a sa propre logique, son propre langage et ses propres règles.

Ils sont découplés les uns des autres, et leurs interactions sont clairement définies.
On sait qui dépend de qui, quelles informations circulent et comment elles doivent être échangées.

Cette vision d’ensemble est formalisée dans une Context Map, qui permet de représenter les relations entre les différents contextes et de clarifier les dépendances.

Donner des responsabilités claires

Une fois ces contextes identifiés, nous les avons associés aux équipes.

Chaque équipe est devenue responsable d’un ou plusieurs contextes. Ce découpage a permis de réduire fortement les collisions dans le code et de définir les responsabilités.

Les équipes savaient précisément sur quelles parties du codebase elles pouvaient intervenir, et surtout sur lesquelles elles ne devaient pas intervenir.

En limitant les dépendances et les zones de conflit, ce fonctionnement a permis aux équipes de mieux se repérer dans la codebase et de gagner en autonomie.

Structurer pour mieux livrer

Après ce découpage, les frictions entre équipes ont diminué et il est devenu plus simple de faire évoluer la codebase sans impacter les autres équipes.

Les interactions n’ont pas disparu, mais elles sont devenues plus claires et surtout moins bloquantes.

La codebase est elle aussi devenue plus facile à faire évoluer.

En conclusion

Quand une équipe grandit, la complexité ne vient pas uniquement du code.
Elle vient aussi de la manière dont la codebase et les équipes sont structurées.

Tant que cette structure n’est pas claire, les équipes se marchent dessus et le delivery ralentit, ce qui impacte directement la capacité à livrer de nouvelles fonctionnalités.

Structurer la codebase autour du métier permet de redonner du sens, de clarifier les responsabilités et de limiter les frictions.

Et c’est souvent ce qui permet aux équipes de retrouver une capacité à livrer, de manière plus fluide et plus sereine.