Merci pour toutes vos réponses... très intéressant tout ça

En fait ma réflexion vient d'un article d'un de mes anciens collègues au sujet d'une technologie dite
"Software Defined". Le contexte est donc celui du monde professionnel mais ma question était vraiment générale. Il affirme dans son article qu'on peut traduire l'expression par "défini par les applications". J'étais en train de rédiger un tweet pour lui demander depuis quand "application" était la traduction littérale de "software" lorsque, avant de cliquer sur Envoyer, j'ai tout de même réfléchi deux secondes et, dans le doute, je me suis au final abstenu. Parce que oui, au fond, quelle différence y a-t-il entre le logiciel et l'application ? Et puis j'ai également inclut le terme "programme" dans ma réflexion puisqu'il me paraissait assez proche.
Voici les quelques idées que j'ai développées à ce sujet :
D'abord, je me suis tout de suite dirigé vers la même analyse que Lutin_Bleu. Au fond les 3 expressions désignent la même chose mais le terme a évolué au fil du temps rendant les précédents "has been". Mais si les 3 termes existent, c'est bien qu'il doit y avoir des différences. Personnellement, je pense qu'il y a 3 approches à considérer : celle du développeur, celle de l'utilisateur et celle de l'exploitant (la personne en charge du bon fonctionnement du programme/logiciel/application dans un environnement technique particulier). Selon que l’on se place dans la peau de l’un ou de l’autre, on ne parle pas forcément de la même chose.
Vision développement :
Un programme renvoie pour moi la notion de "lignes de codes". C'est un ensemble d'instructions regroupées en bloc unitaire que l'on conçoit à un moment T pour effectuer une tâche spécifique. Le programme est testé intensivement et n’est rendu disponible qu’une fois dépourvu de tout « bug » (en théorie). Niveau cycle de vie, une fois le programme conçu, on y touche quasiment plus, il n’évolue que très peu et restera tel quel pour l'éternité, quitte à devoir coder un autre programme si la tâche pour laquelle il a été conçu évolue. Ça renvoie à l'idée de mainframe évoquée par Lutin_Bleu.
Un logiciel serait un ensemble plus évolué et packagé (jaquette de Marine) de programmes. Il porte pour moi les notions de modularité, de fonctionnalités et d’évolutivité. Niveau cycle de vie, le logiciel est plus évolutif que le programme. Des correctifs sont apportés pour résoudre les anomalies (bugfix) et il est amené à évoluer en termes de fonctionnalités via des versions majeures.
Une application se rapproche beaucoup d’un logiciel mais sa richesse fonctionnelle et sa modularité sont moindres. Par contre, son cycle de mise à jour est beaucoup plus rapide. Il n’y a pas de notion de « versions d’application » qui sortent à intervalle régulier mais un socle commun appelé « application » qu’on « patche » fréquemment pour ajout de fonctionnalités et/ou bugfix. Le terme application évoque un mode de déploiement « agile », à la différence du logiciel et de son fameux cycle en V.
Vision utilisateur :
Il n’y a pas (ou plus) vraiment d’utilisateurs de programme. Le programme renvoie à la notion d’automatisation d’une tâche. On lance un programme qui effectue une tâche ou tourne en continue mais l’interaction avec un utilisateur final est toujours indirecte. Comme l’évoque STDM, un programme est souvent consommé par un logiciel qui l’englobe. Un programme ne s’installe pas, il s’exécute simplement, après compilation dans le meilleur des cas.
Le terme logiciel est fortement lié à la bureautique et au PC. Il s’installe et est amené à être consommé directement par un utilisateur final et la notion d’interface graphique, absente pour un programme, apparait. L’interface graphique masque la complexité et permet l’utilisation du logiciel à une personne non technique ne comprenant pas forcément son fonctionnement propre. C’est le fameux clic-bouton = un certain résultat. Autant on a tendance à penser qu’un programme est un système déterministe qui réagit donc toujours de la même façon à un évènement, autant le logiciel induit une part da variabilité dans le sens où quand on obtient pas ce que l’on veut d’un logiciel, on a tendance à répéter instinctivement exactement la même action en espérant un résultat différent (« Allez, ça va marcher »).
L’application, dans le monde grand public, est plus « moderne » puisqu’elle est liée à l’émergence des appareils mobiles. Avec Windows 10, les choses vont peut-être évoluées mais quand on installe une application, c’est forcément sur une tablette ou un smartphone. Elle induit la notion de tactile et l’interface graphique devient primordiale. Etre « user-friendly » n’est plus un simple avantage, c’est devenu une obligation (« nice-to-have » vs. « must-have »). On doit pouvoir utiliser l’application n’importe où et n’importe quand alors que le logiciel n’est à utiliser que bien installé derrière son bureau. Alors qu’on s’attend à devoir chercher dans les menus, se former ou monter en compétence sur un logiciel, une application se doit de pouvoir immédiatement mettre à disposition tout son potentiel à un utilisateur novice.
Dans le monde professionnel, la distinction entre logiciel et application pour un utilisateur est plus liée à l’utilisation locale ou distante. Un logiciel est utilisé en local sur sa machine, chaque collaborateur dispose de son environnement logiciel et celui-ci se suffit à lui-même. L’application est plus vue comme un service hébergé en central (dans l’entreprise ou dans le « cloud ») auquel on accède souvent via un navigateur. Un utilisateur qui se plaint d’un logiciel va taper son PC et maudire les développeurs alors que l’utilisateur insatisfait de l’utilisation d’une application va se plaindre de la qualité du réseau ou de devoir utiliser un navigateur spécifique pour y accéder.
Vision exploitation (monde pro)
Un programme est développé de manière spécifique pour une tâche et nécessite donc très peu d’effort d’exploitation. Si des bugs sont constatés, on contourne le problème plutôt que de le résoudre ou on arrête de l’utiliser.
Le logiciel renvoie souvent à la problématique de sa distribution aux collaborateurs. Le challenge pour les équipes IT est de mettre à disposition un logiciel en minimisant l’impact sur l’activité des collaborateurs, si possible de manière complètement transparente. Les montées en version nécessaires sont minutieusement planifiées et un retour arrière ainsi qu’un « accompagnement au changement » doivent être inclus dans le plan de migration. Existe également le problème de la compatibilité avec les autres applications et/ou processus métier et/ou plateformes utilisées. Une fois le logiciel déployé, c’est gagné, l’utilisateur est maitre de son utilisation.
L’application étant généralement centralisée et non distribuée, se posent davantage les questions de gestion des matrices flux, de communication entre les serveurs applicatifs, les bases de données, les utilisateurs finaux. Les infrastructures applicatives doivent être redondantes et constamment surveillées pour être correctement dimensionnées. Un upgrade est plus impactant que pour un logiciel car il y a mutualisation, mais le périmètre est souvent mieux maitrisé car centralisé et non dépendant de la bonne volonté ou des cas particuliers des utilisateurs finaux.
Je m’arrête là pour le moment même si une deuxième réflexion est en cours pour en revenir au « Software Defined ». Quelle différence fait-on entre UN logiciel et LE logiciel. J’imagine que la traduction « application » pour « software » peut s’entendre facilement dans le premier cas mais dans l’expression « Sofware Defined », il est plus question du 2ème cas d’après moi.
