Choisir les versions de logiciels à déployer

Une question que je vois très souvent débattue dans les milieux informatiques est : « quelle version d’un logiciel devrais-je installer ? » Cela peut concerner une base de données, une application, un micrologiciel ou, probablement le plus souvent, des systèmes d’exploitation, et avec la fin de support imminente de Windows XP, le sujet a atteint son paroxysme.

Il existe en somme deux camps dans ce débat. L’un estime qu’il faut toujours utiliser le logiciel le plus récent et, par hypothèse, le meilleur. L’autre pense que le logiciel doit mûrir et adopte une approche attentiste, ou considère même chaque version comme un produit différent et non comme un continuum de développement.

Les deux approches ont leurs mérites et aucune ne devrait exister totalement sans l’autre. Mettre à jour un logiciel aveuglément, à la légère, n’est pas sage, et éviter les correctifs et les mises à jour sans raison ne l’est pas davantage. Il est important de garder à l’esprit un examen attentif des facteurs et une certaine empathie pour le processus de développement logiciel lorsqu’on prend ces décisions.

Tout d’abord, il y a deux scénarios complètement différents à considérer. L’un est la mise à jour d’un logiciel actuel et existant, en supposant que l’état actuel des choses « fonctionne », avec la possibilité acceptée que « fonctionner » puisse inclure une faille de sécurité qui a été découverte et nécessite une mise à jour pour être colmatée. L’autre scénario est un nouveau déploiement où il n’y a rien actuellement et où l’on part de zéro.

Commençons par le second cas, car il est bien plus facile de fournir des recommandations à son sujet.

Dans le cas de nouveaux déploiements de logiciels (ou de nouveaux systèmes d’exploitation), utilisez toujours la version actuelle, la plus récente du logiciel, à moins qu’il n’existe une limitation technologique clairement connue qui l’empêche – telle que des bogues connus ou des incompatibilités logicielles.

Le logiciel n’est pas comme les autres types de produits, surtout pas dans le monde actuel des correctifs et des mises à jour diffusés en ligne. Je suppose que la mentalité selon laquelle d’anciennes versions de logiciels seraient préférables aux versions actuelles provient d’une combinaison de produits physiques (montres, voitures, vaisselle, mobilier, vin), où une année ou un modèle précis peut être supérieur à un modèle plus récent pour diverses raisons, et de modes hérités de livraison de logiciels, où les produits logiciels finis étaient simplement « jetés par-dessus le mur », l’état final étant, tout simplement, l’état final, sans aucune possibilité raisonnable de mises à jour, de correctifs ou de corrections. Aucun de ces cas ne s’applique aux logiciels d’entreprise modernes (à de très rares exceptions près).

Le développement logiciel s’apparente grosso modo à un continuum. Les processus de développement normaux font que les nouveaux logiciels sont construits par-dessus les anciens, soit directement (en créant des mises à jour d’une base de code existante), soit indirectement (en reconstruisant à partir des connaissances acquises lors de la création d’une version précédente du logiciel). L’idée étant que chaque version ultérieure du logiciel est supérieure à celle qui la précède. Cela n’est bien sûr pas garanti : il existe des notions telles que les erreurs de régression ou tout simplement un développement de mauvaise qualité, mais dans l’ensemble, les logiciels s’améliorent avec le temps – surtout lorsqu’on parle de logiciels de classe entreprise utilisés en entreprise et faisant l’objet d’un développement actif. Un nouveau logiciel n’est pas seulement la phase suivante de l’ancien logiciel ; il représente aussi, dans la quasi-totalité des cas, l’état actuel des correctifs, des corrections de bogues, des mises à jour et, le cas échéant, des changements d’approche ou de technique. Un nouveau logiciel, provenant d’ateliers de qualité, est presque toujours meilleur qu’un ancien logiciel. Le logiciel évolue et mûrit.

Au-delà de la qualité du logiciel lui-même, il y a la notion d’investissement dans l’avenir. Un logiciel n’est pas quelque chose qui peut rester indéfiniment sur l’étagère. Il doit rester, dans une certaine mesure, à jour, sinon il cesse de fonctionner parce que la plateforme sur laquelle il s’exécute change, qu’un nouvel artefact apparaît, que des failles de sécurité sont découvertes ou que les besoins évoluent. Installer un ancien logiciel signifie investir dans le passé, investir dans l’installation, l’apprentissage, l’utilisation et la prise en charge d’une technologie ancienne. C’est ce qu’on appelle la « dette technique ». Cette ancienne technologie peut durer des années, voire des décennies, mais un ancien logiciel perd de la valeur avec le temps et devient de plus en plus coûteux à prendre en charge, tant pour les éditeurs, s’ils continuent à le supporter, que pour les utilisateurs finaux, qui doivent le supporter.

La même notion de dette technique s’applique aux éditeurs de logiciels concernés. La création d’un logiciel, et surtout la maintenance de plusieurs versions de ce logiciel, représente un coût très important. Les éditeurs de logiciels ont tout intérêt à réduire le support des anciennes versions afin de concentrer leurs ressources sur les versions actuelles (c’est une raison majeure de la popularité des déploiements SaaS : l’éditeur contrôle les versions disponibles et peut éliminer les versions héritées au moyen de mises à jour). Si les clients exigent la prise en charge d’anciennes versions, le coût doit être absorbé quelque part, et il l’est souvent à la fois par un impact financier répercuté sur l’ensemble des clients et par une diminution de l’attention portée au nouveau produit, les équipes de développement devant se scinder pour assurer le correctif des anciennes versions tout en développant la nouvelle. Plus l’effort consacré aux anciennes versions est important, moins il reste d’effort à consacrer aux nouvelles améliorations.

Dans le cadre de ce que je viens de dire, il importe de parler de la maturité du code. La maturité du code est souvent avancée comme une raison de déployer du « vieux code », mais je pense qu’il s’agit là d’une incompréhension, par les informaticiens, des processus de développement logiciel. Si l’on songe à une lignée de code publiée, le simple fait qu’elle soit publiée et utilisée ne la rend pas réellement plus mature. Le code ne change pas une fois dans la nature, il reste simplement là. Sa maturité est « figée » le jour de sa publication. S’il est corrigé, alors oui, il « mûrirait » après sa publication. Les versions ultérieures du même logiciel, fondées sur la même base de code mais plus à jour, constituent véritablement le code le plus « mature », car il a été revu, mis à jour, testé, etc., dans une plus large mesure que la première version de ce même code.

Cela est contre-intuitif si on le compare, par exemple, à une voiture, où chaque sortie est une chose nouvelle, avec de nouvelles occasions de problèmes mécaniques et des préoccupations de fiabilité différentes – où attendre quelques années vous donne l’occasion de voir quels problèmes de fiabilité sont mis au jour. Le logiciel n’est pas ainsi. Ainsi, le désir d’un logiciel plus mature devrait vous pousser à déployer le « dernier cri » plutôt que ce qui a « fait ses preuves ».

Si l’on conçoit les numéros de version des logiciels un peu comme des âges, cela apparaît clairement. Linux 3.1 est bien plus ancien, en termes de maturité logicielle, que Linux 2.4. Il bénéficie d’une décennie de développement supplémentaire.

Prenons un exemple concret, très pertinent aujourd’hui. Vous êtes dans une entreprise sur le point d’installer votre ou vos premiers serveurs. Windows Server 2012 R2 vient de sortir. Devriez-vous installer Windows Server 2008, 2008 R2 (2010), Server 2012 ou Server 2012 R2 (fin 2013) ?

Pour beaucoup d’entreprises, on a l’impression de parler d’entre deux et quatre produits entièrement différents, qui ont probablement chacun des raisons distinctes d’être choisis. Cela est, dans l’ensemble, faux. Chaque nouvelle version n’est qu’une mise à niveau, une mise à jour, un correctif et un enrichissement fonctionnel de la précédente. Chacune, à son tour, est plus avancée et plus mature que celle qui la précède. Chaque nouvelle version bénéficie du travail réalisé sur la version originale de son prédécesseur, ainsi que des corrections de bogues, des correctifs et des ajouts de fonctionnalités effectués entre la sortie originale et la sortie suivante. Chaque nouvelle version est, en réalité, une « version mineure » de celle qui la précède. Si l’on regarde les numéros de révision du noyau, au lieu des appellations marketing des versions, cela prend peut-être davantage de sens.

Windows Server 2008 était Windows NT 6.0. Windows Server 2008 R2 était Windows NT 6.1, manifestement une révision mineure, voire un « correctif » de la version précédente. Windows Server 2012 était Windows NT 6.2 et notre Windows Server 2012 R2 actuel est Windows NT 6.3. Si nous utilisions les numéros de révision plutôt que les appellations marketing, il paraîtrait presque insensé d’installer délibérément une version ancienne, moins mature, moins à jour et moins corrigée. Nous voulons les dernières mises à jour, les dernières corrections de bogues et que les derniers problèmes de sécurité aient été traités.

Pour les nouveaux déploiements de logiciels, plus le logiciel installé est récent, meilleures sont les chances de tirer parti des dernières fonctionnalités et plus le délai est long avant que l’inévitable obsolescence ne fasse son œuvre. Tout logiciel vieillit, aussi l’installation d’un logiciel plus récent offre-t-elle les meilleures chances que ce logiciel dure le plus longtemps possible. Elle offre la meilleure souplesse face à un avenir inconnu.

Suivre ce raisonnement pourrait nous amener à penser que déployer des logiciels en préversion, voire en bêta, aurait également du sens. Et bien qu’il puisse exister des cas particuliers où cela a effectivement du sens, par exemple dans des « groupes de test » pour évaluer un logiciel avant de le déployer à l’ensemble de l’entreprise, ce n’est généralement pas le cas. La nature d’un logiciel en préversion est qu’il n’est pas pris en charge et peut contenir du code qui ne le sera jamais. Utiliser un tel code de manière isolée peut être bénéfique, mais pour un usage général, ce n’est pas conseillé. Il existe des processus importants qui sont suivis entre les versions d’aperçu ou bêta et les versions finales du code, quel que soit le niveau de maturité du produit dans son ensemble.

Cela nous amène à l’autre situation, celle où nous mettons à jour un logiciel existant. Il s’agit, bien entendu, d’un scénario complètement différent d’une installation neuve, et de très, très nombreux facteurs supplémentaires entrent en jeu.

L’un des facteurs les plus importants dans la plupart des situations est celui des licences. Mettre à jour un logiciel régulièrement peut entraîner des frais de licence qu’il faut intégrer à l’équation des avantages et des coûts. Certains produits, comme la plupart des logiciels open source, n’ont pas ce coût et peuvent être mis à jour dès que de nouvelles versions sont disponibles.

L’autre facteur réellement important dans la mise à jour des logiciels est le coût en effort humain de la mise à jour – contrairement à une installation neuve, où l’effort d’installation revient en somme au même entre l’ancien et le nouveau logiciel. En réalité, un nouveau logiciel tend à être plus facile à installer qu’un ancien, simplement en raison des améliorations et des progrès. Maintenir une version unique d’un logiciel pendant une décennie signifie que, durant cette période, des ressources n’ont pas été consacrées aux processus de mise à niveau. Effectuer une mise à niveau annuelle durant cette période signifie que des ressources ont été utilisées dix fois pour réaliser des mises à niveau distinctes. Cela rend la mise à jour bien plus difficile à justifier sur le plan des coûts. Mais il y a plus que le seul effort du processus de mise à jour lui-même : il y a aussi la formation continue nécessaire pour les utilisateurs finaux, qui seront contraints de subir davantage de changements, plus souvent, du fait des mises à niveau permanentes.

Cela pourrait faire passer la mise à jour des logiciels pour quelque chose de négatif, mais ce n’est pas le cas. Il s’agit simplement d’une équation dont chaque côté doit être pesé. Des mises à jour régulières signifient souvent des changements petits et progressifs plutôt que de grands bonds, ce qui permet aux utilisateurs finaux de s’adapter plus naturellement. Des mises à jour régulières signifient que les processus de mise à jour sont souvent plus faciles et plus prévisibles. Des mises à jour régulières signifient que la dette technique est toujours maîtrisée et que les avantages des versions plus récentes – qu’il s’agisse de fonctionnalités, de gains d’efficacité ou d’améliorations de sécurité – sont disponibles plus tôt, ce qui permet d’en tirer parti pendant une plus longue période.

En reprenant ce que nous avons appris des deux scénarios ci-dessus, il y a toutefois un autre enseignement important à en tirer. Une fois la décision de procéder à une mise à jour prise, la question est souvent : « vers quelle version mettons-nous à jour ? » En réalité, cependant, toute mise à jour qui dépasse un simple processus de correctif standard s’apparente vraiment à une décision d’achat de « nouveau logiciel » miniature, et la logique selon laquelle nous installons « toujours » la version disponible la plus récente lors d’une installation neuve s’applique ici aussi. Ainsi, lorsque nous effectuons une mise à jour, nous devrions presque toujours mettre à jour aussi loin que possible – idéalement jusqu’à la version actuelle.

Pour reprendre l’exemple de Microsoft, prenons une organisation qui a déployé Windows XP aujourd’hui. L’entreprise décide d’investir dans un cycle de mise à jour vers une version plus récente, et non dans le seul maintien des correctifs. Plusieurs versions de la plateforme bureautique Windows sont encore activement prises en charge par Microsoft. Il s’agit de Windows Vista, Windows 7, Windows 8 et Windows 8.1. Une mise à jour vers l’une des versions moins récentes laisse moins de temps avant la fin de vie de cette version, ce qui accroît le risque organisationnel ; l’utilisation de versions plus anciennes signifie un investissement continu dans des technologies déjà anciennes, ce qui se traduit par une augmentation de la dette technique et un accès moindre à de nouvelles fonctionnalités qui pourraient s’avérer bénéfiques une fois disponibles. Dans cet exemple précis, les versions plus récentes sont également considérées comme plus sûres et nécessitent moins de ressources matérielles.

Chaque entreprise doit trouver le juste équilibre qui lui convient pour les cycles de mise à jour de ses logiciels existants. Chaque entreprise et chaque logiciel sont différents. Les logiciels d’entreprise comme Microsoft Windows, Microsoft Office ou une base de données Oracle suivent très bien ces modèles. Les petits projets logiciels et ceux qui s’approchent du sur-mesure peuvent avoir un cycle de publication plus dynamique et imprévisible, mais ils suivront généralement quand même la plupart de ces règles. Envisagez d’appliquer de l’empathie au processus de développement logiciel afin de comprendre comment vous et votre éditeur de logiciels pouvez le mieux collaborer pour apporter la plus grande valeur à votre organisation, et combinez cela avec votre besoin de réduire la dette technique afin de tirer parti de votre investissement logiciel de la meilleure façon possible pour votre organisation.

Mais les règles empiriques sont relativement simples :

Lors d’un nouveau déploiement ou d’une mise à jour, visez la version la plus récente du logiciel qui soit raisonnable. Profitez de toute occasion de déploiement pour éliminer autant que possible la dette technique.

Lorsqu’un logiciel existe déjà, pesez des facteurs tels que l’effort humain, les coûts de licence, la cohérence de l’environnement et les tests de compatibilité au regard des avantages en matière de fonctionnalités, de performances et de dette technique.