> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Quelle version de ClickHouse utiliser en production ?
> Cette page fournit des recommandations sur la version de ClickHouse à utiliser en production
Tout d'abord, voyons pourquoi cette question revient si souvent. Il y a deux raisons principales :
1. ClickHouse évolue à un rythme soutenu, avec généralement plus de 10 versions stables par an. Cela laisse un large éventail de versions possibles, et le choix n'est pas forcément évident.
2. Certains utilisateurs veulent éviter de passer du temps à déterminer quelle version convient le mieux à leur cas d'usage et préfèrent simplement suivre la recommandation de quelqu'un d'autre.
La seconde raison est plus fondamentale. Nous allons donc commencer par celle-ci, puis revenir à la manière de s'orienter parmi les différentes versions de ClickHouse.
## Quelle version de ClickHouse recommandez-vous ?
Il est tentant de faire appel à des consultants ou de s'en remettre à des experts reconnus pour vous décharger de la responsabilité de votre environnement de production. Vous installez une version précise de ClickHouse recommandée par quelqu'un d'autre ; s'il y a un problème, ce n'est pas votre faute, c'est celle de cette personne. C'est un très mauvais raisonnement. Personne d'extérieur ne connaît mieux que vous ce qui se passe dans l'environnement de production de votre entreprise.
Alors, comment choisir correctement la version de ClickHouse vers laquelle effectuer une mise à niveau ? Ou comment choisir votre première version de ClickHouse ? Avant tout, vous devez investir dans la mise en place d'un **environnement de préproduction réaliste**. Dans l'idéal, il pourrait s'agir d'une copie miroir totalement identique, mais c'est généralement coûteux.
Voici quelques points clés pour obtenir une fidélité raisonnable dans un environnement de préproduction sans coûts excessifs :
* L'environnement de préproduction doit exécuter un ensemble de requêtes aussi proche que possible de celui que vous prévoyez d'exécuter en production :
* N'en faites pas un environnement en lecture seule avec des données figées.
* N'en faites pas un environnement en écriture seule qui se contente de recopier les données sans produire de rapports typiques.
* Ne le remettez pas à zéro au lieu d'appliquer des migrations de schéma.
* Utilisez un échantillon de données et de requêtes réelles de production. Essayez de choisir un échantillon qui reste représentatif et permette aux requêtes `SELECT` de renvoyer des résultats pertinents. Utilisez l'obfuscation si vos données sont sensibles et que vos politiques internes ne permettent pas qu'elles quittent l'environnement de production.
* Assurez-vous que la préproduction est couverte par vos outils de monitoring et d'alerte de la même manière que la production.
* Si votre production s'étend sur plusieurs datacenters ou régions, faites en sorte que votre préproduction fasse de même.
* Si votre production utilise des fonctionnalités complexes comme la réplication, les tables distribuées et les vues matérialisées en cascade, assurez-vous qu'elles sont configurées de manière similaire en préproduction.
* Il faut trouver le bon compromis entre, d'un côté, utiliser en préproduction à peu près le même nombre de serveurs ou de VM qu'en production, mais de plus petite taille, et de l'autre, en utiliser beaucoup moins, mais de même taille. La première option peut permettre de détecter davantage de problèmes liés au réseau, tandis que la seconde est plus facile à gérer.
Le deuxième domaine dans lequel investir est **l'infrastructure de test automatisée**. Ne partez pas du principe que, parce qu'un certain type de requête s'est exécuté correctement une fois, ce sera toujours le cas. Il est acceptable d'avoir quelques tests unitaires dans lesquels ClickHouse est simulé, mais assurez-vous que votre produit dispose d'un ensemble raisonnable de tests automatisés exécutés sur un vrai ClickHouse et vérifiant que tous les cas d'usage importants fonctionnent toujours comme prévu.
Une étape supplémentaire pourrait consister à contribuer ces tests automatisés à [l'infrastructure de test open source de ClickHouse](https://github.com/ClickHouse/ClickHouse/tree/master/tests), utilisée en continu dans son développement au quotidien. Cela demandera certainement un peu plus de temps et d'efforts pour apprendre [comment l'exécuter](/fr/resources/develop-contribute/contribute/tests), puis comment adapter vos tests à ce framework, mais cet investissement sera rentable : les versions de ClickHouse seront déjà testées avec eux lorsqu'elles seront annoncées comme stables, au lieu de perdre régulièrement du temps à signaler un problème après coup, puis à attendre qu'un correctif soit implémenté, rétroporté et publié. Certaines entreprises ont même comme politique interne de contribuer ainsi à l'infrastructure de test qu'elles utilisent (ce que Google appelle la [Beyonce's Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well)).
Une fois votre environnement de préproduction et votre infrastructure de test en place, choisir la meilleure version devient simple :
1. Exécutez régulièrement vos tests automatisés sur les nouvelles versions de ClickHouse. Vous pouvez le faire même pour des versions de ClickHouse marquées comme `testing`, mais il n'est pas recommandé de passer aux étapes suivantes avec elles.
2. Déployez en préproduction la version de ClickHouse qui a passé les tests et vérifiez que tous les processus fonctionnent comme prévu.
3. Signalez tous les problèmes découverts dans [les issues GitHub de ClickHouse](https://github.com/ClickHouse/ClickHouse/issues).
4. S'il n'y a pas eu de problème majeur, vous pouvez commencer à déployer cette version de ClickHouse dans votre environnement de production en toute sécurité. Investir dans une automatisation des versions progressives mettant en œuvre une approche similaire aux [canary releases](https://martinfowler.com/bliki/CanaryRelease.html) ou aux [déploiements blue-green](https://martinfowler.com/bliki/BlueGreenDeployment.html) peut encore réduire le risque de problèmes en production.
Comme vous l'avez peut-être remarqué, il n'y a rien de spécifique à ClickHouse dans l'approche décrite ci-dessus : c'est ce que l'on fait pour tout élément d'infrastructure dont on dépend lorsque l'on prend son environnement de production au sérieux.
## Comment choisir entre les versions de ClickHouse ?
Si vous consultez le contenu du dépôt de paquets ClickHouse, vous verrez deux types de paquets :
1. `stable`
2. `lts` (support à long terme)
Voici quelques repères pour choisir entre les deux :
* `stable` est le type de paquet que nous recommandons par défaut. Une nouvelle version est publiée environ une fois par mois (et apporte donc de nouvelles fonctionnalités dans des délais raisonnables), et les trois dernières versions stables sont prises en charge en termes de diagnostic et de backport de correctifs.
* `lts` est publié deux fois par an et est pris en charge pendant un an après sa sortie initiale. Vous pouvez lui préférer `stable` dans les cas suivants :
* Votre entreprise applique des politiques internes qui n’autorisent pas les mises à niveau fréquentes ou l’utilisation de logiciels non LTS.
* Vous utilisez ClickHouse dans certains produits secondaires qui ne nécessitent pas de fonctionnalités ClickHouse avancées ou ne disposent pas de suffisamment de ressources pour le maintenir à jour.
De nombreuses équipes qui pensent au départ que `lts` est la meilleure option finissent malgré tout par passer à `stable` en raison d’une fonctionnalité récente importante pour leur produit.
Un autre point à garder à l’esprit lors de la mise à niveau de ClickHouse : nous veillons toujours à la compatibilité entre les versions, mais il n’est pas toujours raisonnable de tout conserver, et certains détails mineurs peuvent changer. Assurez-vous donc de consulter le [changelog](/fr/resources/changelogs/oss/2026) avant la mise à niveau afin de vérifier s’il contient des notes sur d’éventuelles modifications non rétrocompatibles.