Ce nouvel article, depuis longtemps, pour faire part d’un constat et surtout d’un conseil concernant les mises à jour de vos logiciels professionnels (et autres).
Ici et là, je suis témoin de demandes désespérées de la part d’utilisateurs peu, voire pas du tout compétents en informatique, pour se faire dépanner après avoir procédé à une mise à jour d’un de leurs logiciels de gestion, quand ce n’est pas le système d’exploitation lui-même qui a été « upgradé ».
La très forte démocratisation de l’informatique « grand public », son déploiement sur un nombre croissant de supports (ordinateurs, tablettes, smartphones, …) et surtout la propension des éditeurs à masquer les réalités informatiques aux utilisateurs béotiens sont certainement à l’origine de ce comportement qui pousse les utilisateurs à mettre à jour leurs applications sans auparavant réellement tenir compte des impacts, notamment négatifs, de ces actions.
Or elles peuvent en avoir, parfois compliquées et coûteuses à réparer !
Sans revenir sur les différents métiers informatiques, et pour faire court, le développeur écrit les programmes et en valide les fonctionnalités, l’informaticien de production s’assure que les applications une fois mises en production fonctionneront comme attendu dans l’environnement de production et pour finir l’exploitant informatique en assure le fonctionnement nominal au jour le jour.
Trois métiers distincts et complémentaires donc.
Aussi, lorsque les développeurs livrent une nouvelle version de logiciel, a fortiori celle qu’on nomme « majeure » et qui est supposée apporter de nouvelles fonctionnalités en même temps qu’elle corrige des dysfonctionnements, les informaticiens de production les « qualifient » avant toute mise en production.
C’est que l’environnement de développement du logiciel n’est pas celui qui sera utilisé en cible, parfois les écarts sont importants, et il ne s’agit pas d’y aller à l’aveuglette sous peine de prendre le risque d’un arrêt de production informatique, avec les conséquences techniques et surtout financières qui s’enchaîneront.
Comme on le voit, cette méthode de qualification des logiciels à mettre en production permet de s’affranchir d’un certain nombre d’incidents, mais aussi de mettre en œuvre les actions qui permettront d’assurer un mise en production sans accrocs et en permettront ensuite une exploitation correcte.
Un métier, comme je le précisais plus haut, que je pratique depuis une 30aine d’année.
Mieux vaut prévenir que guérir !
Tout logiciel est par essence « buggé », il n’existe pas de logiciel sans anomalie, « faire la preuve d’un logiciel » reste encore un vœu pieu. Mais dans la chaîne de développement d’un logiciel, entre sa version alpha initiale, et les versions mineures qui suivront bien plus tard, il y a un long parcours (bêta, release candidate, majeure/stable) et, pour qui n’a pas les compétences techniques nécessaires et suffisantes, toutes les versions précédant la première voire la seconde version mineure d’un logiciel devrait être évitée, y compris donc la première version stable ou majeure, car en cas de problème il faudra faire marche arrière, si toutefois cela a été préparé, ou appliquer des corrections d’environnement dans une dynamique de fuite en avant rarement maîtrisée, donc elle-même source d’incidents et de coûts…
Par myahoo sur Wikimedia — Travail personnel, Domaine public
Aussi, à moins d’avoir la nécessité impérative d’une ou plusieurs fonctionnalités nouvelles apportées par une nouvelle version majeure d’une application, je recommande toujours de patienter au moins jusqu’à la sortie de la première version mineure, qui généralement ne tarde pas beaucoup après la majeure correspondante et qui corrigera les premiers bugs.
Un exemple ? La dernière version majeure 16.04 LTS d’Ubuntu embarque PHP en version 7 avec les gains de performance que cela induit et quelques nouvelles fonctionnalités qui ne sont pas essentielles dans un environnement de production professionnel. Cette version d’Ubuntu remplacera à terme (avril 2019 !) la précédente version LTS (support long terme), la 14.04, il n’y a donc pas lieu de se précipiter et il est raisonnable d’attendre quelques mois avant de procéder à la mise à jour, et dans tous les cas après les tests de validation qui s’imposent (la « qualification »).
En attendant, nombre de logiciels utilisant PHP ne sont pas (encore) compatibles avec la version 7, mais toujours avec la précédente 5.6. Et donc les utilisateurs qui ont installé cette nouvelle version d’Ubuntu 16.04 / PHP 7 constatent alors des dysfonctionnements dans leurs logiciels professionnels, voire pas de fonctionnement du tout !
On le voit, ici aussi « patience est mère de sûreté »… et changer pour changer est une prise de risque non calculé, qui au final peut coûter cher ! Dans le cadre des missions auprès de ses clients, i.d & l apporte toujours une valeur ajoutée au regard de ces aspects de migrations logicielles, un service conseil coûtera toujours moins qu’une grosse réparation et évitera bien des cheveux blancs.
Ordi-Linux - Reconditionnement d’ordinateurs sous Linux
Cliquez pour vous abonner et rester informé !