Construire un produit logiciel n’est pas compliqué!

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, mais en fait 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 (c.-à-d. 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 est que si nous suivons les préconisations de ces experts, nous obtenons à peu près le résultat qu’ils avaient prédit.

Construire une maison est un problème compliqué. Nous faisons appel à des experts : des architectes, des ingénieurs en résistance des matériaux, etc. Si leurs recommandations sont bien suivies, nous obtenons à peu près la maison qu’ils ont imaginée. Cuisiner est aussi une situation compliquée. Si nous suivons la recette et les recommandations du chef, nous obtenons à 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 maison 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 établis a priori. Nous ne pouvons é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, elle commande un logiciel. Quand elle reçoit le produit, cela lui donne d’autres idées, lui permet de s’apercevoir que certaines de celles qu’elle 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 correcte par rapport au besoin du commanditaire. Celui-ci reconnaissait que sa demande avait bien été comprise et même satisfaite, mais finalement, le résultat était moins bien qu’escompté et lui donnait 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. En premier lieu, nous faisons appel à des experts en recueil du besoin, en pensant que si nous réalisons ce qu’ils ont formalisé, nous obtiendrons le logiciel qui satisfera parfaitement le commanditaire (ex. le client). Nous faisons 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 connues : les industries lourdes, les travaux publics et le bâtiment. Or, nous avons 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 tenterons de répondre dans un prochain article à la question de la place des experts si nous changeons de méthodologie, que nous utilisons différemment leurs capacités et que nous ne suivons plus leurs préconisations dans le but de déduire des liens causes-conséquences a priori.

Ce billet a d’abord été publié sur thefnublog.com