Devons-nous changer de paradigme pour le développement d’applications informatiques?

Ce me semble être un des secrets les mieux gardés du moment en informatique : nous opérons souvent sur un paradigme qui est faux en utilisant la métaphore de l’usine et de la production « industrielle ».

A quoi bon des métaphores ?

De nos jours, la métaphore la plus fréquemment utilisée pour désigner une organisation en charge de développement logiciel est celle d’une usine, ou software factory en bon franglais. Nous parlons également de spécification et de conception de logiciel, laissant entendre que le reste n’est plus une tâche de création, qu’il n’y a plus qu’à faire comme c’est prévu, à suivre le plan de fabrication.

Ainsi, avec l’arrivée des concepts issus du Lean Management, nous sommes tentés d’utiliser de plus en plus des méthodes et outils organisationnels issues des chaînes d’assemblage – et il n’y aurait plus qu’à assembler des composants prédéfinis, réutilisables, et tous nos soucis seraient résolus. Nous pourrions donc nous inspirer des méthodes utilisées pour monter des voitures ou des ordinateurs, et plus de projets en retard, plus de besoins métier inassouvis ! Cette métaphore a remplacé celle de la construction de bâtiment et de ponts – je ne suis pas trop sûr de savoir pourquoi, d’ailleurs. Peut-être la précédente n’était-elle pas suffisamment fertile en concepts associés permettant de guider nos organisations informatiques, ou peut-être s’est-on rendu compte que la métaphore ne fonctionnait pas.

Oui, mais quel est le problème ?

La question est liée à l’utilité d’une métaphore. Une métaphore est bonne et utile si elle « fonctionne » et inspire par analogies de nouvelles idées, démarches, concepts, analyses, etc. par un rapprochement de domaines distincts. Une bonne métaphore donne des outils pour imaginer et décider, par jeu d’analogies. Par exemple, la fenêtre est une métaphore pratique pour l’espace d’interaction avec une application informatique, parce qu’elle permet d’imaginer l’accès à des « domaines » différents, de voir ce qui se passe dans ces « zones ». Elle permet d’imaginer de l’ouvrir, de la fermer, d’attacher un contexte mental à une fenêtre. La métaphore touche à ses limites lorsqu’on parle de superposer plusieurs fenêtres, ce qu’on ne peut pas avec des vraies fenêtres dans des murs….

Ou alors, un pont peut être une bonne métaphore pour une interface applicative: il permet de faire passer des objets (métaphores pour les données) d’un côté à l’autre; il est une construction particulière, supplémentaire, nécessitant un effort; il faut se mettre d’accord sur le point de départ et d’arrivée. Par contre, il ne représente qu’une interface point à point, et ne permet pas d’imaginer de réutiliser des interfaces pour faire des services partagés.

Nous voyons donc qu’une métaphore peut être utile, mais peut également avoir des limites, et il faut dans ce cas en être conscient pour l’utiliser correctement. Une métaphore peut être complètement nocive si la plupart des décisions que l’on prend en l’utilisant ne sont pas pertinentes- ou encore si elle amène naturellement à prendre des décisions « évidentes » dans le contexte de la métaphore mais qui en fait sont nuisibles.

Imaginons par exemple un chef de projet informatique qui a un problème de retard prévu sur les livraisons. Dans les usines, pour augmenter rapidement la quantité produite, on fait des heures supplémentaires. Le chef de projet utilise la métaphore de l’usine et la pense pertinente. Il demande donc à ses développeurs de venir travailler le samedi. Sauf qu’en l’occurrence le problème n’était pas sur la quantité produite, mais sur la clarté du besoin et les arbitrages associés. Le résultat est que les développeurs ont produit plus, mais plus de choses non conformes aux attentes. Du coup il y a plus de corrections à apporter sur la base de retours utilisateurs, et le « retard » augmente !

Pourquoi la métaphore de l’usine est-elle un mauvais guide ?

Mon propos aujourd’hui est donc d’affirmer que cette nouvelle métaphore de l’usine appliquée au développement de logiciel est fausse, incorrecte. Complètement et tout simplement. Et elle n’a jamais été même proche de la réalité. Et donc les analogies et orientations que nous pourrions prendre en nous appuyant sur cette métaphore seront au mieux hasardeuses, au pire nocives.

Comparons les modèles d’usine de fabrication et de développement logiciel:

Ces quelques critères de comparaison font apparaître des obstacles à une transposition directe de méthodes issues de la fabrication d’objets physique au développement de logiciel, et donc autant de faiblesses de l’application de la métaphore de l’usine dans le domaine informatique.

Pouvons-nous illustrer ce propos ?

En synthèse, pourquoi cette métaphore ne fonctionne-t-elle pas ?

En fait, le développement d’un logiciel, au sens très large, incluant l’analyse du besoin, conception technique, conception fonctionnelle, le développement lui-même, les tests et la mise en production, tout ceci est une activité de conception de produit et pas de fabrication. Le produit en question est un produit logiciel, qui vise à satisfaire un certain besoin, à couvrir un certain « marché », bien souvent à usage unique comme les logiciels d’entreprise, ou au moins dont la duplication se fait rapidement et sans difficulté particulière, comme les logiciels grand public. Cette conception est d’abord génération d’information, et non pas mouvement d’atomes, et c’est elle qui crée la quasi-totalité de la valeur du produit logiciel.

Pourquoi essayons-nous néanmoins d’appliquer les modèles de fabrication issus de l’industrie ?

Souvent, cette application de modèles issus de l’industrie se fait dans un objectif de rationalisation et d’amélioration d’efficacité. Les projets informatiques ne vont pas bien, et/ou coûtent trop cher, et nous cherchons donc des solutions issues de domaines où les activités tournent mieux, où elles sont prévisibles et répétables – plus rassurantes donc. Nous cherchons aussi les (objectivement impressionnantes) économies d’échelle et gains (réels) d’efficacité que la production industrielle a permis, et que nous n’avons pas atteints dans le logiciel. Un regard très – trop – rapide sur le développement logiciel fait apparaître des zones « d’amateurisme », que l’on va s’empresser de corriger en demandant un fonctionnement plus « professionnel », plus « industriel ».

Mais tout ceci est illusion. Reprendre les mots et les pratiques de la fabrication en série ne permet pas de mieux « fabriquer » du logiciel « en série ».

Que faire alors ?

Est-ce une bonne ou une mauvaise nouvelle ? Les deux. La mauvaise est que nous allons devoir changer nos métaphores, ce qui va entraîner un changement dans l’espace des solutions et des outils. La bonne est que nous allons pouvoir nous tourner vers des espaces sémantiques nouveaux et une littérature différente pour nous inspirer dans la compréhension de nos processus et la recherche de pistes d’amélioration. Nous pouvons par exemple nous inspirer des méthodes et démarches de conception de produit utilisées dans l’industrie, comme décrit dans Managing the Design Factory, et nous découvrons que les problématiques, les enjeux, et même certaines des solutions et outils utilisées peuvent réellement nous aider à mieux comprendre et gérer nos systèmes d’information.

Les constructeurs automobiles savent que la conception de nouveaux modèles de voiture n’est pas un processus de fabrication « industriel », sur lequel on peut adapter les métaphores d’une usine. Ma réponse à la question du titre est donc: oui, changeons, inspirons-nous de leurs pratiques et d’autres, mais des bonnes, sans copie servile mais en transposant avec pertinence.