Le paysage du développement

La pratique du développement est bien sûr largement influencée par le contexte technique et organisationnel dans lequel elle a lieu. Le domaine qui nous intéresse ici, celui du développement d’applications qui s’exécutent sur le Web en général, et plus particulièrement de la sous-catégorie que forment les métatechnologies, reste jeune et faiblement structuré : les méthodes et techniques y changent plus rapidement que dans le champ de l’informatique traditionnelle. Malgré une certaine tendance à la consolidation et à la maturation, le Web ne mérite pas (encore) d’être qualifié comme un espace techniquement et professionnellement figé. Certains usages et applications sont de fait devenus des piliers d’angle plutôt stables depuis des années (forums, pages statiques, CMS, etc.) mais une bonne partie du Web, dont le domaine des métatechnologies, reste peuplé de techniques et d’usages encore fortement expérimentaux. L’innovation et la conception s’y font largement, pour paraphraser Sylvie Lainé-Cruzel [2001, p. 20], « en aveugle » parce que le terrain des possibilités techniques reste largement ouvert et les usages fluctuants. L’expérimentation de nombre de nouvelles voies, dont nous pouvons témoigner aujourd’hui avec le Web 2.0, nous parait plus résulter d’une sorte de consensus collectif implicite entre développeurs et usagers, d’un accord informel pour progresser dans certaines directions plutôt que d’autres, que d’un effort planifié ou réfléchi par des chercheurs attachés à l’industrie ou au domaine académique. Le chaos expérimental qui marque toute technique dans sa jeunesse constitue cependant le milieu à partir duquel des éléments plus stables commencent à se dégager, des éléments qui représenteront par la suite des points de référence et influenceront fortement l’évolution de l’ensemble du domaine. Ce phénomène de structuration de l’avenir par le présent, que Rosenberg [1994] nomme la « dépendance au chemin » (path-dependecy), ne concerne pas seulement la technique, mais il s’y manifeste très visiblement. Une fois qu’une décision technique commence à se diffuser, il devient chaque jour plus difficile de dévier de la direction qu’elle fixe. En effet, elle Le paysage du développement Métatechnologies et délégation  développe une force d’attraction en influençant son contexte technique (elle provoque l’apparition d’objets techniques porteurs ou dépendants d’elle-même) et social (des habitudes et « arts de faire » se stabilisent). Le chaos expérimental se consolide en un chemin spécifique dont il est difficile de diverger, c’est-à-dire qu’au sein du très large éventail des directions possibles se développe une structuration qui rend certaines voies bien plus attractives que d’autres.165 En ce qui concerne les métatechnologies, le contexte technique et social reste encore assez ouvert, bien que certains standards commencent à émerger. Le paysage n’est pourtant pas encore découpé en parcelles. Le Web en général s’est certainement industrialisé mais il reste encore beaucoup de place pour des acteurs indépendants et innovateurs – le grand nombre d’applications qui sont sorties de la nuée du Web 2.0 confirme cette intuition. Notre travail s’intéresse surtout à ces zones qui ne sont pas encore conquises par les grandes entreprises avec leurs lourds appareils bureaucratiques, stratégiques et méthodologiques. Autour de l’Internet, des modes de production se sont installés qui s’inspirent plus de la métaphore du bazar que celle de la cathédrale [Raymond 1998]. On peut y découvrir certains éléments d’une manière de concevoir le développement du logiciel en rupture avec les habitudes et façons de penser établies, qui ouvrent un certain nombre de pistes pour interroger, depuis un angle nouveau, notre horizon méthodologique. Le design orienté-société que nous allons présenter par la suite, dont nous pensons qu’il devrait complémenter les deux grands courants étudiés ici dans le cadre du développement de métatechnologies, repose en partie sur une appréciation spécifique du paysage de la création informatique. Cette perspective part de l’idée que cette création peut être vue non seulement comme une ingénierie mais aussi comme un processus d’écriture. 2.3.1 L’écriture informatique Afin de comprendre ce dont il est question dans l’acte de développer un objet informatique, il est nécessaire de rappeler qu’il s’agit, en fin de compte, de produire un texte ; un texte bien particulier certainement, mais qui constitue néanmoins le résultat d’un geste d’écriture. Cette dimension nous semble essentielle et nous allons l’introduire comme base de notre raisonnement sur un design du logiciel inspiré par les sciences humaines. Avant de pouvoir avancer sur ce chemin, nous sommes obligés de montrer en quoi un programme informatique est une écriture, et de poser les conséquencesqui découlent de ce fait. Une première indication se trouve dans la question difficile de savoir ce qui constitue la conception dans la réalisation d’un logiciel.

Conception : schéma ou code ?

Dans un article fortement débattu et ainsi devenu célèbre, Jack W. Reeves [1992] s’interroge, à partir de sa propre pratique de programmeur / développeur / concepteur / designer166, sur les différents possibilités de définition du design logiciel (software design). Il choisit comme point de départ de son argumentation la comparaison entre génie civil et génie logiciel. Pour le premier, il y aurait séparation évidente entre la conception (le design) d’un objet (p.ex. d’un pont), qui prend habituellement la forme d’un plan technique (blueprint), et sa construction réelle en tant qu’objet matériel ; deux gestes clairement différents ressortent de cette distinction : conceptualiser (to design) et construire (to build). Ces deux activités ne diffèrent pas seulement par leur contenu pratique, mais concernent également des professions distinctes, l’architecte pour la première et l’ingénieur en bâtiment pour la seconde, et, de plus, elles se trouvent dans un rapport d’enchaînement temporel où l’une doit être achevée pour que l’autre puisse commencer. Selon Reeves, une telle séparation ne pourrait pas être établie si facilement en ce qui concerne le génie logiciel. L’auteur met en doute l’idée courante selon laquelle on peut distinguer, de façon analogue au génie civil, une conception sous forme de schéma, plan ou diagramme, représentée si possible en un langage conceptuel167, de la réalisation ou implémentation du programme écrit en un langage de programmation. Son argument se base sur le constat que le « vrai » logiciel n’est pas le listing en langage de programmation, mais le résultat de la compilation168 du code source, la suite des signes binaires, le seul code qui peut être exécuté par la machine directement. En conséquence, Reeves affirme que le design ou la conception d’un logiciel (l’équivalent du plan dans notre métaphore précédente) ne se réduit pas à la série de schémas ou de modèles qui préparent le travail d’écriture du code, mais comprend surtout et essentiellement le code source même, tel qu’il est écrit par un développeur. L’activité de conceptualisation comporterait donc le double geste de « planifier » le code d’une part et de l’écrire de l’autre, ainsi que la circulation inévitable entre ces deux pôles tout au long du projet. Pour l’auteur, la stricte séparation des processus de conception et d’implémentation ou de réalisation relève d’une posture artificielle qui ne correspond guère à la pratique de développement où les deux activités s’impliquent mutuellement. Dans une telle perspective, la phase de construction se résume, pour l’être humain, à l’acte de cliquer sur le bouton « compiler » dans l’environnement de développement utilisé, ce dernier se chargeant de traduire le code source en code binaire.169 De ce changement de perspective il découle qu’un logiciel est très cher à conceptualiser (parce que le processus prend beaucoup de temps) mais quasiment gratuit à construire (parce que la machine fait le travail automatiquement).

Les conséquences – caractéristiques du logiciel

La double nature du code informatique, le fait d’être écriture et machine en même temps, n’est pas sans conséquence pour la dimension économique de la production du logiciel. Quand on analyse le processus de création de n’importe quel produit industriel, trois phases se dégagent immédiatement : la conception, la production et la distribution. Nous avons vu avec Reeves que l’étape de production d’un logiciel peut être comprise comme le processus mécanique de traduction d’un texte / concept (le code source) en un objet technique (le code binaire). Economiquement, le coût de cette phase intermédiaire s’avère quasiment nul et à la construction automatique (compilation) s’ajoute le fait que l’information numérique peut être copiée sans perte de qualité et avec très peu d’investissement énergétique, ce qui réduit aussi quasiment à zéro la production « matérielle » comme source de dépenses. De ce fait, le logiciel diffère fortement des machines traditionnelles parce que pour lui, la confrontation avec la matière entendue au sens de la physique, dimension indispensable de toute machine, se fait seulement au moment où le logiciel est exécuté sur un ordinateur. En amont, le logiciel est information et fait partie des phénomènes « à (très(très)) petite énergie » [Baltz 2003]. Le coût de production (dans le sens industriel) concerne donc surtout le matériel (hardware). Mais même ici, la réduction des prix et le fait qu’un ordinateur peut exécuter tous les programmes écrits pour le système d’exploitation qu’il utilise rend cette partie de l’investissement économique très faible comparée à celui qui accompagne les produits industriels classiques. 170 Cette conception ne considère pas la question du texte « littéraire » qui ouvrirait à d’autres interrogations, en particulier en rapport avec le texte informatique. Cf. Balpe, Jean-Pierre : Contextes de l’art numérique. Paris : Hermes Science 2000 Métatechnologies et délégation – 241 – La deuxième dimension, celle de la distribution, est également affectée par la matérialité étrange, la légèreté171, du logiciel. Depuis un moment déjà, le coût des supports matériels est plutôt faible. D’abord les disquettes, puis les CD et maintenant les DVD sont peu chers à produire et leur faible encombrement les rend très mobiles. Les programmes voyagent facilement. Avec l’Internet, il devient encore plus facile de « transporter » un logiciel du producteur au consommateur. La plupart des applications commerciales se vendent aujourd’hui en boîte dans un magasin ou par service postal ainsi que (souvent moins cher) par téléchargement direct. Encore une fois, les coûts tendent vers zéro.172 Cela nous reconduit au constat de Reeves qui affirme que les coûts dans la chaîne économique d’un logiciel se concentrent sur la phase première, la conception, qui consiste, selon lui, non pas seulement en sa modélisation mais surtout au laborieux travail d’écriture et de validation173 du code. Mais aussi ici, y regarder de plus près s’avère payant. Qu’est-ce qui est cher dans la conception ? Les outils nécessaires ? Non, parce qu’un ordinateur à 500 € est plus que suffisant comme poste de travail pour un designer ou un programmeur. L’espace immobilier ? Pas vraiment non plus, parce que la programmation est un « office work » (travail de bureau) [Turing 1948, p. 4] qui ne demande que des bureaux suffisamment grands pour mettre les postes de travail. Non, ce qui coûte cher dans la conception de logiciels, c’est la main d’œuvre : les personnes et leurs compétences. En ce sens, le temps devient en fin de compte la contrainte et donc le facteur de coût principal. Le temps de modéliser, de coder et de déboguer / valider, le temps d’acquérir les connaissances nécessaires, le temps de se ressourcer.