Long-term support

En informatique, une version Long-term support ou LTS (en français Support à long terme) désigne une version spécifique d'un logiciel dont le support est assuré pour une période de temps plus longue que la normale.

Il s'agit de la mise en œuvre de la politique de gestion du cycle de vie d'un produit dans le domaine du génie logiciel, avec notamment l'application des principes de l'ingénierie de la fiabilité au processus de développement et de maintenance du logiciel. Le support à long terme étend la durée de la maintenance applicative ; il modifie également le type et la fréquence de publication des mises à jour (correctifs) pour réduire le risque, les dépenses et les perturbations liés au déploiement de logiciels, tout en favorisant la fiabilité. Le Support à long terme n'implique toutefois pas de support technique.

Le support à long terme commence par le gel des fonctionnalités : des patchs peuvent être livrés pour corriger des bugs et combler de failles de sécurité, mais aucune nouvelle fonctionnalité — susceptible de causer des régressions — n'est acceptée. Le responsable de la maintenance distribue des correctifs sous forme de patches unitaires, de packages ou des service packs. À la fin de la période de support, le produit passe en fin de vie.

Le terme support à long terme est généralement réservé à des versions définies d'un logiciel, dont l'éditeur garantit en général une période de maintenance minimale de deux ans, soit une période largement plus longue que la durée de vie d'une version ordinaire. Un terme apparenté est le support à court terme (STS, Short-term support), qui désigne un support de durée ordinaire^[1].

Cette section ne cite pas suffisamment ses sources (décembre 2017). 

Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Traditionnellement, le cycle de vie des logiciels de nombreux projets open source suivent soit la règle dite release early, release often (publiez tôt, publiez souvent), soit un calendrier de publication à dates régulières. Dans les deux cas, chaque nouvelle version peut apporter des correctifs de bugs, des correctifs de vulnérabilités ou de nouvelles fonctionnalités.

Généralement, les grandes organisations et certains professionnels travaillant sur des projets critiques recherchent prioritairement la stabilité et pour cette raison maintiennent longtemps en service une version validée d'un logiciel. Tant qu'elle est commissionnée, cette version ne peut recevoir que des correctifs de sécurité. Le monde professionnel part du principe que les ajouts de fonctionnalités peuvent introduire des régressions dans les logiciels^[2]. Le rétroportage dans la version déployée des seuls correctifs de sécurité intégrés dans chaque nouvelle version publiée est théoriquement possible, mais en pratique cette solution est très complexe et très coûteuse à mettre en œuvre.

Même sans les risques, pour ces types d'utilisateurs, de nouvelles fonctionnalités sont également souvent coûteux. Mise à jour d'une application web avec une configuration sensible, par exemple, peut avoir besoin de la coopération de beaucoup de gens: les Développeurs de rénovation; un administrateur de base de données pour la base de données de schéma de changements; les testeurs de logiciels pour les tests de régression; un gestionnaire de projet pour la planification, la liaison, et la facilitation; un administrateur système ou le responsable de publication pour le déploiement de logiciels de supervision; et IL les opérations de personnel pour les sauvegardes, installation, et de récupération en cas de catastrophe.

Les versions LTS d'un logiciel permettent généralement de répondre à ces préoccupations en apportant uniquement des mises à jour justifiées par un objectif de sécurité — le risque lié à l'installation de ces mises à jour doit toujours être moins élevé que le risque de ne pas les installer.

Ce tableau répertorie uniquement les logiciels disposant de versions LTS en plus des versions normales. De nombreux projets, comme Ubuntu, fournissent un support à long terme pour chaque version dont la majeure est un chiffre pair.

a. ↑ La période de support de Debian, la distribution dont dérive Ubuntu, est d'un an après la sortie de la version stable suivante^[19],[20].

• Rétroportage
• Politique de sécurité informatique
• Devops
• Plan de reprise d'activité
• ISO/CEI 12207, un standard international pour les cycles de vie des logiciels
• Gestion des risques en entreprise
• Qualité logicielle
• Progiciel
• Test de fiabilité de logiciel
• Coût du cycle de vie
• Gestion de vulnérabilités

• Tharwon Arnuphaptrairong, « Top Ten Lists of Software Project Risks: Evidence from the Literature Survey », Proceedings of the International MultiConference of Engineers and Computer Scientists 2011, vol. 1,‎ 2011 (ISBN 978-988-18210-3-4, ISSN 2078-0966, lire en ligne [PDF], consulté le 7 août 2013)
• « What makes software dependable? », sur bcs.org, BCS, 5 février 2007 (consulté le 12 août 2013)
• Bill Brenner, « Outdated software is risky business », sur Search Security, TechTarget (consulté le 12 août 2013)
• « Deploying software: Principles to ensure frequent, low-risk deployments », sur Government Service Design Manual, Government Digital Service (consulté le 12 août 2013)
• Patrick J. Graydon et John C. Knight, « Practical Limits on Software Dependability: A Case Study » [PDF], 2010 (consulté le 12 août 2013)
• Jez Humble, « Four Principles of Low-Risk Software Releases », sur InformIT, Pearson Education, 16 février 2012 (consulté le 12 août 2013)
• Bev Littlewood et Lorenzo Strigini, « Software Reliability and Dependability: A Roadmap » [PDF] (consulté le 12 août 2013)
• Aaron Weiss, « The Hidden Security Risks of Legacy Software », sur eSecurity Planet, 8 juin 2012 (consulté le 12 août 2013)
• Shona Ghosh, « Windows XP: Microsoft’s ticking time bomb », sur PC Pro, Dennis Publishing, 19 décembre 2013 (consulté le 2 janvier 2014)

• Portail de l’informatique