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

le 03/11/2009 par Yannick Martel
Tags: Product & Design

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:

ManufacturingDéveloppement logiciel
Les tâches sont...RépétitivesNon répétitives
Les tâches sont...PrédictiblesNon prédictibles
Les besoins exprimés sont...Une contrainte forteUn axe de pilotage
Les besoins exprimés sont...FixesEvolutifs
Le travail est...BornéNon borné
Le coût du retard est...HomogèneNon homogène
La durée des tâches est...HomogèneNon homogène
La variabilité est...Toujours du gaspillageNécessaire et pas toujours du gaspillage
Les produits intermédiaires sont...Des objets physiquesDe l'information
La création de valeur se fait...Par transformation de la matièrePar création d'information
Les stocks sont...VisiblesInvisibles

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 ?

Une voiture est fabriquée dans une usine. Aux options près, elle est identique à celles qui l'ont précédées. Elle est conforme à un plan de fabrication déjà utilisé pour d'autres voitures.Une fonctionnalité est implémentée sur un logiciel. Il va peut-être se conformer à un plan si une conception détaillée a été faite, mais ce sera la première et la dernière fois que ce "plan" sera utilisé.
Un dossier de fabrication est fourni à une usine pour mettre en place une chaîne pour un nouveau modèle de voiture. Ce dossier a déjà été validé par d'autres usines ou des équipes d'ingénierie en fabriquant un prototype.Un dossier de conception détaillé est fourni à une équipe de développement. Il n'a jamais servi à fabriquer du logiciel. On ne sait donc pas s'il est suffisamment complet ni compréhensible.
Le délai pour une étape de fabrication est prévisible, et a pu être estimé avant le démarrage de la première chaîne de fabrication, en particulier par des prototypes.Le délai pour le développement de composants logiciels est très imprévisible, sauf dans les cas où la même équipe a déjà réalisé des adaptations du même type. Qui plus est, il dépend fortement du développeur individuel et de l'équipe.
Un incident provoque l'arrêt de la chaîne, un lot de voiture n'est pas fabriqué. La perte d'argent est linéaire en général et se réduit aux voitures devant être réalisées.Certains éléments du logiciels ne sont pas réalisés. Il se peut que dans ce cas le logiciel en entier n'ait plus aucune valeur. La perte est non linéaire, et potentiellement hors de proportion par rapport au coût de réalisation des éléments manquants.
Les tests de fonctionnement de grille-pain sont réalisés par un sous-traitant. Le responsable produit, l'usine et le sous-traitant se mettent d'accord sur les tests à réaliser et rédigent un document qui est appliqué par le sous-traitant. Un changement de spécification résulte dans un changement dans le document, mais le coût en est répercuté sur les milliers de grille-pain qui sont testés ensuiteLes tests autour d'une nouvelle fonctionnalité sont réalisés par un sous-traitant. Le client final, l'équipe de développement et le sous-traitant se mettent d'accord sur les tests et rédigent un document. Quand une spécification change, le document est changé, mais ce coût de changement n'est porté que par un seul logiciel.
Le service achat d'une usine négocie l'achat de boulons, ou même de pompes ou de produits plus complexes. Il va préciser la qualité attendue et les tolérances, et pourra ainsi se mettre d'accord sur le prix d'un lot. Des tests par échantillonnage seront ensuite réalisés et permettront de s'assurer de la conformité des livraisons.Le service achat négocie l'achat de prestations de développement informatique. Il ne sait pas préciser la qualité d'une ligne de code, d'un homme-jour ou d'un point de fonction. Il ne va négocier que le prix, éventuellement des profils d'intervenants. Personne ne sait ensuite mesurer clairement la qualité du logiciel et le respect de tolérances permises. C'est donc le seul paramètre de prix qui va être utilisé pour piloter l'intervention, sans définition claire de la qualité associée.

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.