Quand on met la poussière sous le tapis.
Cet article fait partie d'une série introduite par ici.
Ce système implique la résolution d’un problème par une solution qui vient travailler sur les symptômes plutôt que sur la source du problème, provoquant parfois un enlisement, et un besoin de nouvelles solutions palliatives.
Ce type de système vous évoque-t-il une situation à laquelle vous êtes confronté ?
Si oui, je vous suggère de saisir un crayon et de reprendre l’illustration en replaçant les labels génériques par ceux de la situation à laquelle vous pensez.
C’est, de mon point de vue, un type de système si répandu qu’il est facile à observer sous différentes formes.
On peut imaginer une application pleine de bugs, et qui ne semble pas plus se stabiliser. Plus il y a d’incidents, plus on passe de temps à en résoudre, et donc plus on se précipite pour les résoudre car on doit aussi développer de nouvelles fonctionnalités.
Un autre exemple peut être une entreprise mobilisant des consultants pour résoudre un type de problème. Les contextes n’allant pas en se simplifiant, plus le temps passe, plus l’entreprise devient incapable de résoudre ce type de problème, et plus elle se repose sur des consultants.
Dans ce dernier exemple, on remarque d’ailleurs qu’en prenant un écosystème plus large que l’entreprise demandant conseil, et en incluant l’entreprise de conseil, on retrouve un archétype « Success To The Successful ». Cet archétype mettra alors en évidence là où la compétence se renforce et là où elle s'affaiblit. En revanche, elle ignorera la différence entre problème(s) de fond et palliatif spécifiquement chez l'entreprise comme le ferait l'archétype "Shifting the burden". Un choix de perspective.
On peut aussi imaginer l’effet de tout aide à notre mémoire. Plus on se repose sur un support particulier pour mémoriser des choses (liste de rappel, carnet de contacts…), moins on devient capable de les mémoriser. Vous avez peut-être d'ailleurs déjà fait le lien avec l'assistance par la GenAI.
Cet archétype est pour moi le meilleur argument à une formation à la pensée systémique. Car bien que facile à identifier, il est difficile d’en trouver la « root cause », pour la raison précise que la systémie en révèle de multiples origines, et à considérer les patterns plutôt que les événements.
Dans le cas du logiciel, plus l’on corrige de bugs en surface, moins on a de temps pour en corriger l’origine. Dans le cas de l’entreprise demandant conseil, plus elle se repose sur un conseil externe, moins elle devient autonome.
Dans le cas de la mémoire, moins on la sollicite, plus il devient difficile de la solliciter spontanément.
Dans ces cas, « la solution » serait bien entendu d’y investir du temps. Cela dit, si c'était si simple, nous l'aurions fait dans de nombreuses situations. Qu’est-ce qui nous en empêche ? Le manque de tests ? Le manque de compétence ? L’urgence ? La pression d’une partie prenante ? Le manque de financement ? Bien entendu, l’issue d’une résolution profonde serait satisfaisante pour tout le monde. Ce qui pose problème, c'est l'impact de l'investissement préalable, devenant toujours plus important à mesure que la situation s’enlise. Elle ne peut alors être résolue sans considérer l’ensemble de ces contraintes grandissantes.
Si vous aboutissez à la conclusion que « La » cause (unique) est une personne ou une équipe, considérez que vous avez échoué. Les personnes, majoritairement de bonne intention, font ce qu’elles font bien souvent parce qu’elles ont été amenées à ces agissements. La question doit plutôt être, comment composer avec, ou résoudre ce qui les pousse à cela.
Un exemple de plus pour l’illustrer : si l’on détermine qu'un incident au sein d'un système technique provient des agissements d’une personne fatiguée le jour où elle l’a manipulé, considérez qu’une autre personne sera inévitablement fatiguée un autre jour, et qu’il faut plutôt concevoir une façon permettant de mieux gérer les oublis, les erreurs, ou d’y être plus résiliant. On peut par exemple imaginer de l'automatisation (ex: tests, monitoring...), des checklists, etc.
Si vous imaginez une solution potentielle à la situation que vous avez dessiné plus haut, tentez de la dessiner. Le système au global produit-il les résultats souhaités ? Imaginez que les effets des flèches produisent leur contraire, que se passe-t-il ?
Ce système est cité dans « la cinquième discipline » de Peter Senge, et « Thinking in systems » de Donella Meadows.
