Jusqu’à il y a peu, nous avons mal jugé la nature de la création des produits informatiques. On croyait que c’était « compliqué ». Par conséquent, on a mis au point des méthodes non adaptées pour créer des logiciels.

Construire un logiciel n’est pas du tout compliqué

En 2000, David John Snowden, dit Dave Snowden, a finalisé le Cynefin.Il s’agit d’un modèle permettant de catégoriser les situations dans lesquelles on se trouve afin d’aider à la prise de décision.
Ce modèle comporte 5 domaines mutuellement exclusifs (ie. une situation ne peut être que dans un seul de ces domaines à la fois).

Aujourd’hui, nous nous intéresserons à deux d’entre eux uniquement.
Le premier est le domaine dit « compliqué ». Voici quelques unes de ses caractéristiques. Dans ce domaine des liens causes-conséquence peuvent être établis a priori. Toutefois, seuls des experts sont capables de les établir. La conséquence (oui, oui, on fait ce qu’on peut pour s’amuser, hein) c’est que si on suit les préconisations de ces experts, on obtient à peu près le résultat qu’ils avaient prédit.
Construire une maison est un problème compliqué. On fait appel à des experts : des architectes, des ingénieurs en résistance des matériaux, etc. Si leurs recommandations sont bien suivies, on obtient à peu près la maison qu’ils ont imaginée. Cuisiner est aussi une situation compliquée. Si on suit la recette et les recommandations du chef, on obtient, à peu près, le plat souhaité.

C’est exactement ce que j’ai demandé mais ce n’est pas ce que je veux

Mais construire un produit logiciel n’est pas compliqué, contrairement à la construction de maisons ou à la cuisine.
En effet, c’est plutôt une situation « complexe ».
Dans le Cynefin, le domaine complexe possède ces caractéristiques : les liens causes-conséquences ne peuvent pas être établi a priori. On ne peut établir de telles relations qu’a posteriori. C’est en voyant un résultat concret que je peux me dire que ce que j’ai obtenu est le fruit d’un agissement.
Souvent, les situations complexes sont aussi décrites comme adaptatives. Cela signifie que chercher à répondre à cette situation modifie sa nature.
C’est exactement la description de la construction d’un produit informatique : une personne a un besoin, il commande un logiciel. Quand il reçoit le produit, cela lui donne d’autres idées, lui permet de s’apercevoir que certaines qu’il avait émises ne sont pas pertinentes, etc. Bref la nature de son souhait est modifiée suite à la réponse logicielle apportée à la situation initiale. Il n’a pas été possible de prévoir les nouvelles demandes qui allaient être émises si on apportait la réponse logicielle choisie.
Il y a quelques années j’ai entendu cette phrase prononcée par le commanditaire d’une application lors d’une démonstration qu’un développeur faisait : « C’est exactement ce que j’ai demandé mais ce n’est pas ce que je veux ». Ça a été le déclic. C’est là que j’ai pris conscience de la nature complexe et adaptative du développement logiciel. L’équipe de développement avait apporté une réponse a priori correct au besoin du commanditaire. Celui-ci reconnaît que sa demande a bien été comprise et même satisfaite, mais finalement, le résultat est moins bien qu’escompté et lui donne envie de changer une partie de l’application.

Mauvais outil, mauvais…

Le développement en Cascade ou en Cycle en V, est une réponse à une situation compliquée. On fait appel à des experts en recueil du besoin en premier lieu,en pensant que si on réalise ce qu’ils ont formalisé, on obtiendra le logiciel qui satisfera parfaitement le commanditaire (ex. le client). On fait ensuite appel à des experts techniques : architectes, urbanistes, etc.
Les désignations de ces experts nous illustrent d’ailleurs bien de quelles industries on s’est inspiré pour créer cette méthodologie. Dans les années 50 quand les premières études pour formaliser une méthodologie de création de logiciels sont apparues (elles ont donné le modèle de la Cascade ou Waterfall puis du cycle en V), on s’est inspiré des industries qu’on connaissait : les industries lourdes et le BTP. Or, on a vu plus haut que construire des bâtiments était une situation « compliquée » ce que n’est pas la construction de produits logiciels.
Ces méthodologies sont donc inadaptées.

Que faire des experts ?

Nous tenteront de répondre dans un prochain article à la question de la place des experts si on change de méthodologie, qu’on utilise différemment leurs capacités et qu’on ne suit plus leurs préconisations dans le but de déduire des liens causes-conséquences a priori.

Mise à jour du 06/06/2017 : l’article traitant de la place des experts dans une organisation agile est disponible ici

Mise à jour du 01/06/2018 : un jeu permettant de vivre, en % minutes, une expérience dans chaque domaine du Cynefin Framework est disponible ici