points de vue

En ingénierie, l’ingénieur passe par une étude et une conceptualisation du produit de façon à pouvoir le faire ensuite réaliser par des équipes de spécialistes. Cela peut même passer par différents phases de prototypage. Or, en développement logiciel, l’élaboration de ces plans ne découle pas d’une démarche scientifique et repose avant tout sur les compétences, les a priori du ou des ingénieurs impliqués et sur les effets de modes. Le résultat est qu’infailliblement les plans seront entaillés de lacunes au point que le code produit divergera insidieusement de la conception, rendant caduc les plans et la documentation amont. De plus, la réalisation même sera faite elle aussi par des ingénieurs de même métier ; il n’y a pas de réelle différence entre ceux qui codent et ceux qui architecturent l’application. Les spécialités ne seront en fait qu’artificielles et se résumeront à des sous-domaine (IHM, WEB, base de données, ….), reliquat de la politique de la division des tâches propre à la production industrielle. L’image ci-dessous caricature bien cette ingénierie logicielle : A côté de ceci, quelque soit la qualité des études et de la conceptualisation amont, la réalisation même du logiciel va immanquablement diverger de ce qui aura été planifiée par le caractère socio-psychologique du codeur ; ne dit on pas qu’il y a autant de code possible qu’il y a de codeurs ? Une petite illustration ici d’un même code en Haskell écrit par différents développeurs. En fait, dans le développement logiciel, les aspects de conceptualisation et de réalisation sont intrinsèquement liés. C’est la raison pour laquelle, la réaction à cette pure approche d’ingénierie et industrielle a conduit à l’émergence de ce que l’on appelle de nos jours l‘agilité.

Il n’en est pas moins que le développement logiciel n’est pas exempte de techniques que l’on peut qualifier d’ingénierie. Nous pouvons prendre l’exemple des patrons de conceptions et d’architectures mais aussi le TDD (Test Driven Development). Mais cela n’en fait pas pour autant une ingénierie. Les développeurs associent souvent leur activité à de la création dans lequel le code en serait l’émanation. Le code s’articule avec lui même pour former in fine un logiciel duquel l’utilisateur ne percevra que son interface (texte ou graphique). Mais derrière cette interface se cache l’œuvre d’une ou plusieurs personnes. La programmation est perçu comme l’art de transcrire une démarche intellectuelle de création dans du code et le programmeur se perçoit avant tout comme un créateur. C’est ainsi que l’on a vu apparaître des programmes écris sous forme de poésie (Poétique des codes). Et, à l’image du peintre qui s’appuie sur des théories scientifique pour jouer avec les couleurs, la lumière, … sur des outils et des techniques en vue d’accomplir son œuvre (caravage, impressionisme, …), le programmeur, lui aussi, va se saisir d’algorithmies, de frameworks, et de techniques de programmation pour créer le code qui va donner naissance au logiciel attendu. On a souvent comparé la programmation avec l’architecture et les techniques de programmation se sont même inspirées de ce domaine avec, par exemple, les patrons de conception (inspiré des travaux de Christopher Alexander ). Je pense que cette comparaison est loin d’être infondée et, à l’image de l’architecte, le programmeur va profiter de techniques à base scientifique pour concevoir son œuvre qui sera, dans les deux cas, à fonction utilitaire. Et comme l’architecte, le programmeur se sent créateur, voir artiste. La différence ici est que l’œuvre finale n’est pas une maison, un pont, un établissement, mais un logiciel qui est d’essence immatérielle, virtuelle, et que si le travail de l’architecte repose sur un savoir scientifique multi-disciplinaire, celui du programmeur reposera avant tout sur une base essentiellement mathématiques. La Tour Eiffel est un exemple d’une œuvre de création située entre la science et l’art.

Il n’est reste pas moins que l’objectif final est de sortir un logiciel utile et pratique et surtout à coût contrôlé. Pourtant, si toute activité industrielle résulte de la production en masse d’un produit à l’origine issue d’une ingénierie, il n’en ait pas ainsi avec le logiciel. Le programme, une fois créé, peut être copié indéfiniment et peut évoluer et changer par son ou ses créateurs sans faire intervenir une production de masse impliquant différent corps de métiers ; il vit en étroite connexion avec ses géniteurs. Si le logiciel n’a pas pour ambition d’être une œuvre d’art, il n’en reste pas moins une activité de création. D’ailleurs, n’appelle t’on pas les entreprises dont l’activité est de vendre un ou plusieurs logiciels d‘éditeur ? Et leur métier l’édition de logiciel ? Et celle-ci n’est-il pas régit par le droit sur les auteurs ? Pourtant il existe dans l’industrie d’autre métier qui relève de la création comme, par exemple, le marketing ou la communication. Et, étrangement, l’industriel accordera au marketing cette nature créatrice de l’activité qu’il refuse à la programmation. Bien sûr, il n’en reste pas moins que la programmation, bien qu’activité de création, reste toute de même fortement imprégnée de son essence scientifique - le langage Haskell en est d’ailleurs un parfait exemple. La programmation est donc une activité située entre la science et l’art. Pour cette raison, elle ne semble guère convenir à une approche industrielle caractérisée avant tout par une mécanisation du travail.