Découplage et cohésion

Quand on fait des logiciels 💻, et même si on ne sait pas toujours le mesurer, on cherche le faible couplage 🔗 et la forte cohésion 🤝. On veut minimiser la quantité d'information échangée entre les modules pour permettre à l'ensemble du système de fonctionner tout en maximisant les liens qui unissent les divers éléments au sein d'un module 🧩.

On connaît aussi la loi de Conway 📜. Elle établit un lien entre les systèmes et l'organisation qui les conçoit 🏗️.

Toute organisation qui conçoit un système, au sens large, concevra une structure qui sera la copie de la structure de communication de l’organisation. 🗣️

En combinant ces métriques et cette loi, on peut déduire un corollaire. ⊢

Toute organisation qui conçoit un système doit avoir une structure de communication favorisant le faible couplage et la forte cohésion. 🔄

Mais qu'est-ce que ça signifie ? 🤷‍♂️

Dans un système logiciel, un module, ce n'est pas toujours évident à appréhender. On peut en avoir des visions statiques ou dynamiques : fichiers de codes, fichiers binaires 💾, dossiers 🗂️, process, threads, containers, VMs, etc. Et, en plus, ça dépend beaucoup des technos utilisées ⚙️.

Un seul truc est à peu près constant : quand on veut présenter un système pour l'expliquer à quelqu'un, on ne lui montre pas tous les détails 🧐. On utilise un niveau d'abstraction intermédiaire. Et c'est un bon point de départ pour caractériser des modules.

Pour les organisations composées d'humains 🧑‍🤝‍🧑, c'est pareil. On peut s'amuser à lister les fonctions de tous les individus dans une organisation de 500 personnes 🏢 mais, le plus souvent, on n'y comprendra rien. On va utiliser une abstraction intermédiaire en groupant les individus 👥.

Ces groupes sont nos modules 🧩. Ils faut donc qu'ils aient, en leur sein, une forte cohésion 🤝. Dans un logiciel, un module a une forte cohésion quand tous ses élements internes concourrent au même but 🎯. Pour les groupes d'individus, c'est pareil. On obtient cette forte cohésion quand un ensemble d'individus partagent un même but 🤗, c'est à dire quand le groupe devient une équipe 🛡️.

Au sein de notre organisation, les équipes doivent avoir un faible couplage ⛓️‍💥. Si chaque équipe a besoin de toutes les autres équipes pour atteindre son but, cela fonctionne difficilement 🚧. C'est la raison pour laquelle notre organisation doit privilégier des équipes capables de produire de la valeur par leur seule action 💪 et limiter les dépendances entre équipes.

On retrouve ces idées, et bien d'autres, dans l'approche Team Topologies 🌍.

Cette approche me parle beaucoup car elle prend le contrepied de la plupart des approches pour structurer une organisation 🧭. Bien trop souvent, on groupe les personnes parce que leurs métiers se ressemblent et non pas parce qu'elles ont un but en commun 🌟. Et comme il faut quand même atteindre les buts, on conçoit des processus pour fluidifier les dépendances entre les groupes 🚦. On déploie des outils pour disséminer et synchroniser les informations qui circulent sur ces dépendances 🌐. Bref, on donne une grosse importance aux processus et aux outils.

En approchant le problème différemment, on peut se focaliser sur les individus. Mettre beaucoup de liens entre les individus quand il en faut et en retirer là où il n'en faut pas 🚪.

Pour bien concevoir un logiciel, il faut donc donner plus de valeur aux individus et à leurs interactions qu'aux processus et aux outils 🏅.

Ça vous rappelle pas un truc ? 🤔