Bonjour,
Si j’ai bien compris, Debian est disponible en 4 versions : oldstable, stable, testing et instable (SID) mais existe-t-il une version LTS? Selon le wiki oui (supporté par une équipe de bénévoles donc rien de garantie/officiel). Et pour combien de temps sont supportés les versions stable? 1 an ? Jusqu’à la prochaine version stable ? J’essaie de m’y retrouver là-dedans 
Merci
D’abord, RTFM sur le site debian, il y a les réponses à tes questions:
https://wiki.debian.org/fr/DebianReleases
Non, il est disponible en bien plus de versions que ça, les release anterieures à la oldstable sont toutes disponibles, donc théoriquement, on en est à 10 versions, mais c’est un détail.
Toutes les releases de debian sont LTS.
La date de fin de support de la Buster n’est pas encore fixée, mais pour les autres, voilà les dates:
https://wiki.debian.org/fr/LTS
Et il y a une équipe pour faire aussi du LTS étendu qui va encore plus loin:
https://wiki.debian.org/fr/LTS/Extended
A noter qu’en réalité, certains correctifs de sécurité sont quand même étendus parfois à des versions théoriquement non supportées, la date est surtout un engagement que ça sera mis à jour >au moins< jusqu’à la date de fin de support.
La durée de vie complète:
Si on prend la Wheezy:
Je comprend mieux ! Mais j’hésite car je cherche une distribution stable qui peut passer vers une version de testing (paquets plus récents), qui peut m’aider à évoluer dans l’administration Linux et que je pourrais rencontrer en entreprise. Debian m’a l’air d’avoir toutes ces caractéristiques non??
Bonsoir Soufian Ta.
Si tu souhaites utiliser des logiciels plus récents sur une debian stable,
tu peux utiliser les rétroportages. Voiçi de la documentation à ce sujet.
Si ce n’est pas suffisant, Debian te permets aussi de migrer de stable vers testing.
Tout ton système ainsi que tes logiciels seront mis à niveau vers une version plus récente.
Voiçi la procédure.
Dans les deux cas, bien lire attentivement.
Debian testing ( actuellement Debian 11 Bullseye est très stable , au sens ordinaire du terme c’est à dire qu’il n’y a pas de plantage) tout en ayant des versions de logiciels plus récentes.
Avec l’utilisation du noyau de sid (instable) pour etre plus proche du dernier noyau j’ai une machine qui tourne comme une horloge
apt policy linux-image-amd64
linux-image-amd64:
Installé : 5.3.7-1
Candidat : 5.3.7-1
Table de version :
*** 5.3.7-1 995
100 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
5.2+107 990
990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
4.19+105+deb10u1 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
4.9+80+deb9u9 500
500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages
4.9+80+deb9u6 500
500 https://cdn-aws.deb.debian.org/debian-security stretch/updates/main amd64 Packages
3.16+63+deb8u6 500
500 https://cdn-aws.deb.debian.org/debian-security jessie/updates/main amd64 Packages
De plus grâce au principe de l’étiquettage, Debian est d’une grande souplesse
https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.fr.html#sect.apt.priorities
Je crois que tu n’as pas compris le principe de base du versioning de debian:
la testing n’est pas une version de test de la stable.
C’est la future stable en constitution, avec des versions de paquets plus récents qui bougent tout le temps le temps que ça converge vers la stabilité, et qui ne bénéficie pas encore des mise à jour de sécurité:
seule la stable et oldstable y ont droit, et les correctifs de sécurités arrivent dans la testing que quand les mainteneurs des paquets défaillant décident de passer à une nouvelle version de paquet.
Donc je suis d’accord dans l’absolu avec @grandtoubab le plus souvent, la version testing est déjà suffisament stable pour une exploitation en prod sereine.
Sauf sur ces questions de sécurité, ou le comblement des failles n’est pas toujours aussi rapide qu’en stable.
Du coup, pour un truc sérieux en prod, si vraiment j’ai besoin des versions les plus récentes de certains paquets, je préfère installer la stable, et ajouter les dépots backports qui contiennent des versions plus récentes que dans la stable, mais recompilés pour la stable:
https://wiki.debian.org/fr/Backports
Oui, ou passer directement à CentOS avec du EPEL au besoin 
Blague à part pour de la production c’est Debian et si il y a des paquets trop vieux faut se poser la question de pourquoi vouloir un truc qui demande des paquets plus récents ?
Typiquement les version de PHP sont souvent clairement à la ramasse avec les Framework très utilisé ça deviens compliqué, idem pour tous ce qui est js.
Dans ce cas plutôt que de pourrir son système je préconise de passer par des environnement cloisonnés tel qu’avec python ou docker …selon les besoins c’est nettement plus simples et facile à entretenir.
Je mets au défi de maintenir un serveur Debian en stable avec des ajouts provenant de dépôts tiers sans jamais rencontrer de problèmes.
Les backports ne sont pas des dépots tiers, ils sont gérés dans le projet debian.
Ceux là oui, mais généralement les gens finissent par installer des dépôts tiers pour obtenir des paquets dans des versions récentes et pas fourni dans les backports.
En exemple le dépôt de SURY 
@mattotop: je pense m’être mal exprimé mais j’avais bien compris le système ! Et quand aux paquets rétro porté, eux ont bien les correctifs de sécurité (même ceux en testing mais pas tous)?
Alors là, c’est plus compliqué, je ne suis pas trop sur.
Il y a des mises à jours de sécurité directement dans les dépots backports, mais la vitesse de mise en places des versions corrigées doit dépendre de si c’est backporté depuis la testing où les mises à jour pour la sécurité ne sont pas la priorité, et la sid, ou on applique les patchs dés qu’ils sortent et tant pis si une sous version est cassée 1 jour ou 2.
Donc c’est une bonne question, sur les quelques paquets backportés, il y a un moins bon niveau de mises à jour de sécurité.
Peut-on passer de la branche « testing »vers la branche « stable » facilement ou pas (pour avoir quelques mises à jours de paquets récents)?
Pareil que dans l’autre sens.
Non.
Les paquets testing dépendent eux mêmes de versions de paquets de la testing et comportent un risque de faire glisser le coeur de ton systéme en testing par le jeu des dépendances.
Mixé avec des trucs venus de stable, le tout non testé ensemble, c’est pas propre.
Les versions backport sont parfois les mêmes que celles en testing au niveau du code source, mais elles sont compilées avec des dépendances uniquement en stable ou au pire en backports.
Pour avoir quelques paquets récents, on ne mélange pas des paquets testing sur une stable, on installe des backports.
Et donc si on passe d’une stable vers une testing et qu’on fasse un apt-update, on aura la liste des paquets testing. Puis si on repasse en stable et que l’on fasse un update, les paquets testing ne seront plus mit à jours c’est bien cela?
Pas du tout.
“passer en [stable|testing]” consiste à configurer apt pour qu’il soit capable d’accéder à la version que tu veux en plus de l’autre, et forcer le systéme à réinstaller tous les paquets avec en priorité les versions correspondantes à celle que tu souhaite (quitte à régresser dans le cas ou tu passes de testing à stable).
apt update ne sert pas à changer quoi que ce soit, ça fait juste une mise à jour sur ta machine de la liste des paquets disponibles en ligne, ça n’installe rien.
Sinon, concernant le passage de stable à testing, je n’ai pas dit que c’était facile, simple, ni sans risque.
J’ai juste dis que passer de l’une à l’autre demandait le même boulot de configuration d’apt et présentait le même risque que ça se passe mal avec un peu à mettre les mains dans le cambouis.
J’ai bien écris « apt-update et liste des paquets » dans mon commentaire plus haut !
J’ai donc lu trop vite.
perso j’hésite pas a me rajouter les maj de securité Buster sur ma testing avec l’étiquettage qui va bien
/etc/apt/preferences.d$ cat security
Package: *
Pin: release o=Debian,a=stable,l=Debian-Security
Pin-Priority: 990
Ainsi j’ai le meilleur chromium
apt policy chromium
chromium:
Installé : 78.0.3904.97-1~deb10u1
Candidat : 78.0.3904.97-1~deb10u1
Table de version :
78.0.3904.97-1 100
100 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
*** 78.0.3904.97-1~deb10u1 990
990 https://cdn-aws.deb.debian.org/debian-security buster/updates/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian buster-proposed-updates/main amd64 Packages
100 /var/lib/dpkg/status
76.0.3809.100-1 990
990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
73.0.3683.75-1 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
73.0.3683.75-1~deb9u1 500
500 https://cdn-aws.deb.debian.org/debian-security stretch/updates/main amd64 Packages
70.0.3538.110-1~deb9u1 500
500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages
57.0.2987.98-1~deb8u1 500
500 https://cdn-aws.deb.debian.org/debian-security jessie/updates/main amd64 Packages
Autre mise à jour de sécurité ce 18 novembre 2019
apt policy thunderbird
thunderbird:
Installé : 1:68.2.2-1~deb10u1
Candidat : 1:68.2.2-1~deb10u1
Table de version :
1:68.2.2-1+b1 100
100 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
*** 1:68.2.2-1~deb10u1 990
990 https://cdn-aws.deb.debian.org/debian-security buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
1:68.2.2-1~deb9u1 500
500 https://cdn-aws.deb.debian.org/debian-security stretch/updates/main amd64 Packages
1:60.9.0-1 990
990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
1:60.9.0-1~deb10u1 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
1:60.9.0-1~deb8u1 500
500 https://cdn-aws.deb.debian.org/debian-security jessie/updates/main amd64 Packages
1:60.8.0-1~deb9u1 500
500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages