Allez, vous avez tous déjà entendu ça ! Comme si ce pauvre logiciel pouvait souffrir d’un incident mécanique, d’une panne de carburant comme un simple véhicule ou bien être victime d’une grève surprise.
Mettons-nous bien d’accord, un logiciel n’est qu’une suite de codes qui ne peuvent ni tomber en panne de leur propre fait, ni être victime d’aucun état d’âme qui leur ferait changer d’avis sur la conduite à tenir dans une situation donnée.
Alors d’où peut bien venir cette expression ?
Recadrons d’abord le débat : ce que l’on appelle un logiciel est en fait un ensemble de composants logiciels souvent répartis sur plusieurs supports physiques : la machine cliente, un serveur applicatif et une base de données pour le schéma le plus classique. Le tout est bien évidemment relié par le biais d’un autre ensemble de composants physiques pour constituer un réseau complexe : base de données, processus internes aux machines ou bien Intranet ou internet.
Vous avez dit physique ?
Et oui, le logiciel ne peut vivre sans un support matériel, certes comportant peu de pièces mécaniques, mais fait toutefois de nombreux éléments électroniques qui peuvent perdre leur alimentation électrique, surchauffer ou tout simplement s’user et donc fonctionner plus ou moins bien, voire de façon aléatoire.
Mais en général on tombera alors dans la panne franche : plus de son, plus d’image.
Et comment tous ces éléments parviennent-ils à s’accorder ?
Et bien justement, c’est encore une cause fréquente de panne : il y a tellement de composantes impliquées, qu’il est tout simplement impossible de tester tous les cas de figure.
Une pièce logicielle un peu rare, pas à jour ou justement trop à jour, et crac la réponse n’est pas celle prévue ou la question n’est pas comprise, et la sanction tombe : ça ne marche pas.
Le faux bug
Toujours dans l’idée des cas non prévus, la situation non imaginée par le développeur : une réponse non conforme et pas de traitement de l’erreur, une étreinte fatale où deux éléments tentent de s‘approprier la même ressource sans imaginer pouvoir échouer. Le logiciel ne fonctionne plus temporairement, voire aussi longtemps que les conditions d’échec sont réunies, et c’est une vraie panne logicielle qui requiert l’intervention d’un expert en soins d’urgence !
Ainsi donc, oui un logiciel peut tomber en panne, directement du point de vue de l’utilisateur, ou bien victime collatérale de dommages externes ou encore d’un comportement inapproprié de l’utilisateur du point de vue du technicien, mais le fait est qu’il ne fonctionne plus et que c’est bien ça la définition d’une panne.
Cet article pourrait vous intéresser :
C’est quoi un bug ?
Olivier Piochaud, Président Directeur Général d’Apsynet
