Oui, ce titre est légèrement provoc’ quand on a plus souvent entendu "Le tout est plus que la somme de ses parties". Et pourtant, comme nous allons le voir par la suite, il n’est pas moins vrai. Le but de cet article n’est pas de fournir des éléments immédiatement activables, mais d’ouvrir les perspectives sur ce qu’il se passe quand on ajoute des choses dans un système, qu’il soit humain, technique ou autre. Mais d’abord, …
Vous êtes sûrement déjà tombés dans des situations où la logique de gouvernance d’un système est qu’en ajoutant une chose ou en retirant une autre, alors on ajoute ou retire des "capacités" à ce dit-système. Par exemple, ajouter un testeur à cette équipe pour augmenter la qualité de ce qui est produit par l’équipe. On suppose alors que le simple fait d’ajouter cette personne suffira à ce que l’ensemble du système qu’est l’équipe soit doté de cette capacité. Même exemple avec une application, il suffit d’ajouter une fonctionnalité à celle-ci pour que le système que l’on nomme application soit tout simplement et uniquement doté des qualités de la fonctionnalité.
Un des angles morts de ce raisonnement est que l’ajout d’un élément au système peut faire "émerger" de nouvelles capacités. Émerger dans le sens où aucune des pièces ou composantes du système n’est initialement en possession de cette capacité, mais que celle-ci "nait" de par l’organisation des composants entre eux. L’organisation n’est pas seulement "comment sont positionnés ou agencés ces composants", mais aussi "comment ils interagissent", "comment ils se réagencent suite à l’ajout", et "comment ils modifient et se font modifier au sein de leur environnement".
Si on reprend l’exemple de l’ajout d’un testeur au sein s’une équipe, le mode de pensée critique inhérent à ce rôle va "filtrer" des défauts, il dotera donc effectivement l’équipe d’une capacité supplémentaire de filtre de ce qui est jugé être un défaut de l’application, ce qui résultera d’une meilleure qualité produite par ce système. Le testeur étant doté de cette capacité, son ajout à l’équipe "ajoute" de fait cette qualité. Mais les bénéfices ne s’arrêtent pas là.
Par exemple, les interactions entre le testeur et les développeurs peuvent avoir un autre impact : Par l’apport de ce mode de pensée critique, l’équipe observera probablement des patterns qui mènent à la production de défauts du même type, et alors l’équipe se dote d’une capacité d’analyse et prévention de certains défauts dès la conception. Avant l’apparition de ce testeur, cette capacité de design prévenant certains défauts n’existait ni chez le testeur, ni chez les développeurs, qui vont certes tenter ce qu’il peuvent pour prévenir les défauts mais de façon incomplète comme cela se produit souvent lorsque l’on est à la fois juge et parti. Cette capacité de prévention de défauts apparait alors de l’organisation entre les développeur et le testeur, car le testeur arrive après la production des développeurs. Il constate ce qui a été réalisé et utilise la capacité qu’il possédait déjà avant. Mais elle "nait" aussi de la nouvelle interaction entre le testeurs et développeurs, puisqu’en présentant les défauts et discutant de la typologie des défauts passés, les développeurs peuvent constater des patterns liés à leur façon de produire et concevoir. C’est une capacité émergente aussi car si nous "désassemblons" cette équipe, nous perdrions cette capacité dans le sens où aucune personne n’en est seule porteuse. Le testeur ne l’aura pas car le développement ne fait pas partie de son travail — il doit garder une distance pour rester critique — et que les développeurs n’auraient que la connaissance des patterns qu’ils ont rencontré par le passé, et n’auraient pas, seuls, la capacité de rester totalement critiques sur ce qu’ils produisent
Et c’est bien souvent pour expliquer en ce sens qu’une équipe est plus que la somme des personnes qui la composent que l’expression "le tout est plus que la somme de ses parties" est utilisée. On veut transmettre le fait qu’en tant qu’humains nous avons la capacité de nous organiser et interagir pour faire "naître" de nouvelles capacités d’équipe, que nous ne sommes pas des "ressources" ou "composants" individuels qu’il suffit d’ajouter ou déplacer, et que notre organisation et nos interactions nous permettent bien plus en tant qu’équipe.
Mais cet usage fréquent de l’expression "le tout est plus que la somme de ses parties" en fait parfois un argument qu’on mobilise à tout va, mobilisé comme une règle nébuleuse devant interrompre les débats entre la perception "assemblage de composants" versus "système complexe", ce qui nous empêche à la fois d’avoir du recul sur tous les effets, mais aussi de comprendre les mécanismes sous-jacents des propriétés d’une équipe. En décortiquant l’exemple précédent on peut remarquer certaines choses, notamment que pour que cette capacité émerge, il y a aussi des conditions. Par exemple, si l’équipe est agencée de façon à ce que le testeur arrive après le développement, mais qu’il ne communique que par la remontée de tickets de défauts observés, l’équipe n’aurait pas les conditions nécessaires d’une conversation riche et moins structurée entre testeur et développeurs lui permettant de déceler des typologies de défauts. Pire encore, elle pourrait même perdre certaines capacités portées par ses membres qui font qu’on peut aussi dire que …
Car si la communication entre testeur et développeurs est perdue, ou bien se résume à un sens unique sous forme de tickets, ou encore que l’organisation fait sentir que la qualité est le problème du testeur, alors la nature des tâches de ce dernier va changer. C’est à dire que le testeur, qui jusque là utilisait sa pensée critique pour trouver par exemple des failles de parcours, tomberait plus facilement sur des problèmes récurrents ou de qualité technique, et serait ralenti dans sa tâche de détection de défauts plus complexes et occasionnels, voire réduit lui-même à remonter les régressions élémentaires et récurrentes qui s’accumuleraient. L’équipe, composée notamment du testeur et de sa capacité de pensée critique, réprimerait alors de par son organisation et ses règles d’interaction la capacité de l’un de ses membres. Le tout serait alors moins que la somme des parties.
Un autre exemple dont on connait l’adage, ajouter des gens à un projet en retard aura pour résultat de retarder encore plus le projet. Quand bien même l’équipe serait dotée de "bras supplémentaires" et d’un "cerveau en plus", le projet ralentirait par "l’ajout" d'une personne. Par exemple parce que chaque tâche nécessiterait un fort taux de coordination pour être réalisée, ce qui réprimerait alors les capacités de "production" de chaque membre.
Idem en logiciel, l’ajout successif de fonctionnalités peut à la fois faire naître et réprimer des capacités. Dans une base de code où l’on "empile" les fonctionnalités sans remettre en question l’organisation et l’interaction des composants, l’entropie s’accumule et réduit la capacité à faire évoluer le programme. Tandis que dans une base de code où le refactoring fait partie des pratiques courantes de développement, les réflexions et apprentissages ont le potentiel d’accélérer le développement par une meilleure compréhension du domaine et de la façon dont on devrait y répondre par l’organisation et l’interaction d’éléments du code.
Ces exemples montrent des effets de répression de capacité que l’on peut considérer comme négatif. Mais dans certains systèmes, la répression peut être un effet voulu. Très simplement : introduire une règle ou loi au sein d’un collectif peut changer le mode d’organisation et d’interaction de façon à réprimer des comportement non désirés. Ou encore, ajouter une quality gate dans un pipeline de Continuous Integration pourrait réprimer l’apparition de certaines propriétés, bugs, comportements dans la suite du workflow.
Cependant, on peut encore aller bien plus loin en questionnant ces expressions, car dire que le "tout est plus ou moins que la somme de ses parties", …
L’expression, contenant les mots "plus" et "moins", est plus souvent utilisée pour décrire des effets souhaitables ou non que des ajouts ou suppression de capacités. Dans certains cas, l’apparition d’une capacité ou propriété peut être un effet bénéfique pour le système, dans d’autres, cette même capacité peut être défavorable au système. Par exemple, ajouter un comité de validation de tous les changements que subit une application a des chances de ralentir le processus de développement, de retarder la mise en production qui mettra à l’épreuve cette application. Ce pourrait être un effet défavorable, car dans le cas où cette application a besoin d’évoluer fréquemment pour obtenir du feedback du marché, les hypothèses contenues dans le système pourraient vite devenir obsolètes à cause de la vitesse d’évolution de ce marché. Dans un autre contexte, comme dans le développement de systèmes médicaux, ce garde-fou serait d’une valeur inestimable car il protègerait des vies. "Plus" ou "moins" dépend alors de ce que l’on recherche. Et le simple fait de considérer ce qui est souhaitable ou non influe sur notre décisions d’ajouter ou retirer des éléments d’un système.
La réflexion ne peut donc s’arrêter à "un composant = une capacité pour le système", ni à "un composant modifie les propriétés du système", mais doit encore s’étendre pour comprendre "ce qui est voulu ou non". C’est à dire qu’il faut également considérer le contexte dans lequel le système s’intègre, et qui lui-même ajoutera, réprimera, ou fera émerger des propriétés. Car considérer que quelque chose est souhaitable ou non, c’est aussi établir une règle qui modifiera notre façon de concevoir le système, et donc qui réprimera ou fera émerger des capacités dans la conception du système.
Quand on dit donc "Le tout est plus que la somme des parties", on doit donc considérer que ce "plus" peut vouloir dire quelque chose de différent pour chaque participant de la conversation, et que si l’on ne se met pas d’accord sur l’objectif de ce tout on ne se comprendra pas en parlant de ce tout. Cette première question devrait donc déjà enrichir le débat (ex: Que doit accomplir ce code ? Que doit accomplir cette équipe ?). On peut ensuite se poser les questions complexes de ce que réprimeraient ou feraient émerger la modification de ce tout, non seulement en ajoutant ou supprimant des parties (ex: ajouter ou supprimer du code ? embaucher des devs en plus ou non ?), mais aussi en modifiant l’organisation et les modes d’interactions de ces parties pour modifier les propriétés du tout (ex: refactoring de code, nouvelle gouvernance, …). De quoi mettre la puce à l’oreille la prochaine fois qu’on vous jettera un "le tout est plus que la somme des parties".
