Dans le cadre d'une réflexion sur le métier d'ingénieur de développement logiciel dans le milieu de la recherche, il est utile de préciser ce que l'on entend par programme et par logiciel, les deux termes n'étant pas, pour moi, synonymes, et la distinction entre les deux devrait permettre de comprendre l'activité de développement.
En effet, ces deux objets, le programme et le logiciel, sont de même nature mais on "sent" une différence, difficilement qualifiable.
Si l'on cherche sur wikipedia, on trouvera les définitions suivantes:
Programme: En informatique, un programme est une suite d'opérations pré-déterminées destinées à être exécutées de manière automatique par un appareil informatique en vue d'effectuer des travaux, des calculs arithmétiques ou logiques, ou simuler un déroulement.
Le code source est la forme sous laquelle un programme est créé par un programmeur: Un ensemble de textes décrivant formellement, étape par étape, les opérations à effectuer; rédigés conformément aux règles d'un langage de programmation.
Le code source est transformé automatiquement en programme exécutable: une suite d'instructions machine qui peuvent être exécutées de manière automatique par un processeur - composant électronique moteur des appareils informatiques.
[Suit une typologie des programmes comprenant "microprogramme", "programme applicatif", "composant logiciel", ...]
Logiciel: En informatique, un logiciel est un ensemble d'informations relatives à des traitements effectués automatiquement par un appareil informatique. Y sont incluses les instructions de traitement, regroupées sous forme de programmes, des données et de la documentation. Le tout est stocké sous forme d'un ensemble de fichiers dans une mémoire.
Un logiciel serait donc un ou des programmes + des données + de la documentation. Cependant, la documentation est elle-même écrite dans un langage, puis compilée et enfin exécutée en quelque sorte par la machine pour l'afficher. Une interaction est même possible (hyperliens, recherche). On peut d'ailleurs trouver simplistes les interfaces de documentations. Par ailleurs, certains programmes intègrent la documentation (aide contextuelle, ...). Les données elle-mêmes peuvent être du code ou même des programmes. Enfin, j'ai du mal à considérer des commandes UNIX telles ls ou cat comme des logiciels. Elles viennent pourtant avec une documentation (pages man).
Cette distinction n'est donc pas satisfaisante.
Je vais maintenant proposer une autre distinction, puis mettre celle-ci à l'épreuve pour voir si elle peut expliquer les différents critères souvent cités.
Pour proposer cette autre distinction, j'ai besoin d'introduire le concept de méta-stabilité, comme en parle Gilbert Simondon. Dire qu'un objet est méta-stable, c'est dire qu'il est en équilibre instable. L'illustration habituelle est un rocher en équilibre au bord d'un précipice. Sous l'effet d'un peu d'énergie, il chute. Il avait donc un potentiel de chute, libéré, actualisé par une poussée. Le rocher était dans un état "en haut de la falaise" et est passé dans un autre état "en bas de la falaise"
Au contraire, un objet en équilibre stable revient à sa position initiale après avoir subit la poussée: c'est l'image du rocher au fond d'une cuvette. On dit que son potentiel est épuisé.
Le logiciel est bien sûr un objet méta-stable. Le développement le fait passer d'un état à un autre. On identifie d'ailleurs ces états à l'aide des gestionnaires de versions.
Je vais considérer qu'un programme et un logiciel sont de même nature, c'est-à-dire des instructions dans un langage compréhensible par la machine, en identifiant les données et la documentation à des "programmes" au sens de wikipédia.
Ensuite, je pose que ce qui distingue un programme d'un logiciel, c'est le potentiel d'évolution, un programme étant plutôt en équilibre stable alors qu'un logiciel étant plutôt méta-stable. C'est-à-dire qu'il est plus difficile de faire évoluer un programme qu'un logiciel.
On pourra dire qu'un logiciel a un avenir: il pourra grandir, évoluer, se voir ajouté des fonctionnalités.
Au contraire, un programme n'a qu'un devenir, c'est-à-dire qu'il n'est voué au mieux qu'à se maintenir et à terme à disparaître (par inadaptation, incompatibilité, remplacement par un autre).
En ce sens, un programme est un logiciel "punk", sans avenir (tel le slogan "no future"). Sur une ligne de tension entre les pôles "programme" et "logiciel", l'extrême point du côté "programme" est purement "punk": pas d'avenir, aucune prise en compte de l'existant, geste spontané de création brute répondant à un besoin immédiat, voire à une pulsion.
Dans la philosophie utilitariste de John Stuart Mill, le programme serait un expédient, tandis qu'un logiciel serait utile.
Le principe du potentiel comme distinction étant posé, mettons-le à l'épreuve d'autres critères utilisés intuitivement pour distinguer programme et logiciel.
Il faut ici signaler qu'en pratique, il n'y a pas de purs programmes ou purs logiciels, dans le sens où les premiers auraient un potentiel nul, tandis que les seconds auraient un potentiel infini. Chaque programme-logiciel a des parties "plutôt programme" et des parties "plutôt logiciel", le potentiel final résultant des potentiels de chaque partie. Par ailleurs, le potentiel est toujours orienté dans une direction d'évolution. Seul le programme vide est un logiciel de potentiel infini dans toutes les directions. Je reviendrai sur ces directions d'évolution plus loin.
Voyons maintenant différents critères candidats pour distinguer programme et logiciel.
La taille est l'un de ces critères, un programme étant plutôt petit et un logiciel plutôt "plus gros", agglomérant d'autres programmes. Remarquons déjà qu'un logiciel peut-être plus petit que les programmes ou la somme des programmes qu'il utilise. Selon que l'on considère que le logiciel inclut ou non les programmes qu'il utilise, il sera plus gros ou peut-être moins gros que ces derniers.
Cependant, si l'on pouvait calculer une taille moyenne, les logiciels, sans distinction de sous-partie, auraient une taille supérieure à celle des programmes. Cette tendance est le résultat normal du potentiel présent dans un logiciel. Rappelons qu'un logiciel ne 'naît' pas avec une taille importante mais commence par être de petite taille mais son potentiel lui permet de rapidement grandir. Au contraire, un programme au potentiel limité voit ses possibilités de croissance rapidement limitées.
La taille d'un programme-logiciel n'est donc pas un critère mais une conséquence de la présence ou non de potentiel.
Un autre critère pouvant orienter l'appellation logiciel ou programme est la documentation fournie, sans penser à cette documentation comme un programme mais une pure description. Il convient de distinguer documentation de développement et documentation utilisateur.
Pour la documentation de développement, sa naissance même vient de la volonté de conserver un potentiel d'évolution au logiciel, en permettant la transmission de connaissance sur l'architecture, les algorithmes, etc., bref toutes les informations permettant d'acquérir et comprendre la forme du logiciel pour la faire évoluer. Le logiciel a une documentation de développement justement parce que l'on souhaite développer un logiciel et non pas écrire un programme.
Il est à noter que la présence de cette documentation n'est pas une condition nécessaire et suffisante à maintenir le potentiel, la forme (c'est-à-dire la structure) du programme pouvant être telle que les évolutions sont compromises. Cependant, il peut aussi arriver que la forme du logiciel permette des évolutions dans une direction mais que le manque de documentation handicape et diminue ce potentiel.
Concernant la documentation utilisateur, nous avons vu précédemment qu'elle n'est pas un critère. On pourra cependant remarquer qu'une documentation utilisateur, en favorisant l'utilisation, intervient dans l'évolution du logiciel en motivant la nécessité d'un potentiel d'évolution. C'est le cas des logiciels libres: leur utilisation rend plus probable leur maintenance, leur pérennité et l'investissement qui sera source de potentiel pour le logiciel.
Concernant l'aspect structuration et modularité comme critère, on pourrait penser qu'un logiciel bénéficie d'une plus grande structuration et d'un plus haut degré de modularité. Cela est souvent vrai en pratique, mais cela est davantage lié à la taille, elle-même conséquence de la présence de potentiel.
La taille augmentant, un besoin d'abstraction apparaît afin de séparer et abstraire les problèmes à résoudre et les calculs à effectuer. Cette structuration à base d'abstractions est à son tour source de potentiel d'évolution.
Il est cependant possible d'écrire un programme structuré mais dans lequel les optimisations ont rendu difficiles les modifications. Il reste que le degré d'abstraction d'un logiciel détermine fortement son potentiel d'évolution.
Le degré d'abstraction est donc un bon critère de distinction, mais n'est qu'une autre façon d'exprimer le potentiel d'un logiciel.
Le temps de développement comme autre critère de distinction n'est pas satisfaisant: On peut parfaitement passer du temps sur un programme, par exemple pour l'optimiser, diminuant par là-même son potentiel d'évolution. On peut aussi passer du temps sur un logiciel justement pour préserver les abstractions et donc le potentiel d'évolution.
Enfin, dire qu'un logiciel est de qualité supérieure à un programme nécessiterait de définir précisément ce qu'est la qualité d'un logiciel: est-ce la correction ? la performance ? la complétude ? la maintenabilité ? l'ergonomie ?
Selon le sens donné à "qualité", programme et logiciel ne sont pas toujours distingués. Ainsi une optimisation d'un programme le rend plus performant au détriment de sa maintenabilité.
Le potentiel d'évolution semble donc être le bon critère de distinction entre programme et logiciel, bien qu'il ne soit pas quantifiable et qu'il varie selon la direction d'évolution envisagée.
Le métier du développeur de logiciel consiste à gérer la tension entre les pôles "programme" et "logiciel", sachant qu'il est impossible de faire un logiciel complètement abstrait, qu'il faut bien implémenter les fonctionnalités telles qu'elles sont voulues tout en ne connaissant pas toutes les évolutions qui seront souhaitées par la suite, et tout en conservant une part d'abstraction pour anticiper les évolutions pour ne pas "tomber" dans le programme optimisé dans sa forme pour les seules fonctionnalités désirées au moment du développement.
Encore une fois, le potentiel s'exprime par rapport à une direction d'évolution et non pas de façon absolue. La connaissance de cette ou ces directions est nécessaire au développeur pour arbitrer les abstractions à privilégier et les parties à optimiser.
Cette connaissance consiste en une sorte d'idéalité Logiciel visée par le développeur. Cela sera le sujet d'un prochain billet.
Il serait intéressant d'étudier les rapports entre forme et contraintes: le logiciel est développé par rapport à des contraintes et par anticipation de contraintes à venir, mais le processus de développement lui-même crée d'autres contraintes, en quelque sorte "colatérales" aux réponses apportées aux contraintes connues.
Par ailleurs, les interfaces de modules, de composants, sont un cas un peu particulier dans la mesure ou la nécessité de compatibilité arrière nécessite d'avoir un "potentiel de non-évolution" en quelque sorte, tout en permettant des aménagements dans la partie implémentation.
On parle bien de logiciel libre et non de programme libre, le potentiel d'évolution revêtant une grande importance dans le mouvement du logiciel libre qui consiste justement, en autorisant les modifications, à permettre les améliorations. Des "programmes libres" n'auraient que peu d'intérêt puisque leur possibilité d'évolution seraient limitées.