> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ BYOC

> Questions fréquentes sur ClickHouse Bring Your Own Cloud (BYOC)

<div id="faq">
  ## FAQ
</div>

<div id="onboarding-and-provisioning">
  ### Intégration et provisionnement
</div>

<Accordion title="Comment démarrer avec BYOC ?">
  Contactez ClickHouse via le [formulaire de contact](https://clickhouse.com/cloud/bring-your-own-cloud) afin que l'équipe active BYOC pour votre organisation. Préparez ensuite un compte cloud dédié (compte AWS, projet GCP ou abonnement Azure) et suivez le [guide d’intégration standard](/fr/products/bring-your-own-cloud/onboarding/standard). Nous recommandons vivement d'utiliser un compte, projet ou abonnement exclusivement réservé à BYOC.
</Accordion>

<Accordion title="Combien de temps prend le provisionnement de l’infrastructure et quelles sont les causes courantes de blocage ?">
  Comptez environ 45 à 90 minutes de bout en bout. Cette fourchette est large, car la majeure partie de ce temps est consacrée au provisionnement des ressources par le fournisseur cloud (cluster Kubernetes, équilibreurs de charge, composants réseau), dont la durée varie d'une exécution à l'autre et échappe au contrôle de ClickHouse. Lorsque le provisionnement se bloque, les causes les plus fréquentes sont liées au compte :

  * Le modèle CloudFormation ou le module Terraform a été modifié avant d'être appliqué — par exemple, par l'ajout d'un `PermissionsBoundary` ou le renommage du rôle IAM pour respecter une convention de nommage (sur AWS, conservez le nom par défaut `ClickHouseManagementRole`, sauf si ClickHouse a explicitement approuvé un autre nom). Appliquez les artefacts tels qu'ils sont fournis — les personnalisations prises en charge sont disponibles sous forme de paramètres, et toute autre modification doit d'abord être approuvée par ClickHouse.
  * Des politiques au niveau de l'organisation (SCP AWS, politiques d'organisation GCP telles que `iam.allowedPolicyMemberDomains`, ou politiques Azure restreignant les attributions de rôles) empêchent l'assumption de rôles ou les liaisons IAM.
  * Une non-correspondance de l'ID externe du rôle d’intégration (voir la question sur l'ID externe ci-dessous).
  * Des quotas de compte atteints (par exemple, pour les Elastic IP ou les VPC sur AWS).

  Le provisionnement réessaie automatiquement et se rétablit une fois le problème sous-jacent résolu. Si votre infrastructure reste bloquée pendant plus de quelques heures, contactez l'assistance.
</Accordion>

<Accordion title="Quelle valeur utiliser pour l’ID externe dans le modèle d’intégration ?">
  La console ClickHouse Cloud génère un ID externe pour votre compte AWS lorsque vous démarrez l’intégration et le préremplit dans le lien CloudFormation (le paramètre `ExternalID`) ; si vous utilisez Terraform, transmettez la même valeur sous la forme `external_id`. Toutes les infrastructures BYOC d'un même compte AWS partagent le même ID externe. Ne choisissez pas votre propre valeur : elle doit correspondre à celle attendue par l'automatisation de ClickHouse, faute de quoi le rôle intercompte ne peut pas être assumé et le provisionnement échoue. Consultez [ID externe AWS](/fr/products/bring-your-own-cloud/onboarding/standard#aws-external-id) pour plus de détails.
</Accordion>

<Accordion title="Pourquoi mon ID externe est-il emptyid ?">
  Les infrastructures BYOC intégrées avant l'introduction des ID externes utilisent la valeur d'espace réservé `emptyid` afin d'assurer la compatibilité descendante. Lorsque vous ajoutez une nouvelle infrastructure à un compte AWS comportant un déploiement hérité, la console réutilise cet espace réservé afin que toutes les infrastructures du compte conservent une configuration de confiance cohérente. Si vous souhaitez passer à un ID externe unique, contactez ClickHouse Support.
</Accordion>

<Accordion title="BYOC peut-il utiliser un VPC existant ? Qu’en est-il des VPC partagés ?">
  Sur AWS et GCP, vous pouvez effectuer le déploiement dans un VPC existant appartenant au **même** compte ou projet que l'infrastructure BYOC. Consultez les guides de personnalisation pour [AWS](/fr/products/bring-your-own-cloud/onboarding/customization-aws) et [GCP](/fr/products/bring-your-own-cloud/onboarding/customization-gcp). Sur GCP, un **VPC partagé** d'un projet hôte distinct est également pris en charge : le [module d’intégration](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/gcp) accepte directement le projet hôte et le sous-réseau — consultez sa section « Shared VPC » pour connaître la configuration requise et les prérequis. La possibilité d'utiliser votre propre VNet sur Azure sera bientôt disponible.

  Sur AWS, les sous-réseaux partagés depuis un autre compte (AWS RAM) ne sont pas pris en charge — utilisez plutôt un compte dédié connecté à votre réseau existant via l'appairage VPC ou PrivateLink. Notez qu'avec un VPC géré par le client, seul l'équilibreur de charge privé est activé par défaut (voir [configuration](/fr/products/bring-your-own-cloud/configuration/configurations)).
</Accordion>

<Accordion title="BYOC peut-il être installé dans un cluster Kubernetes existant ?">
  Non. Le cluster Kubernetes (EKS, GKE ou AKS) est créé et entièrement géré par ClickHouse. Cela est nécessaire pour que ClickHouse puisse exploiter la plateforme de manière fiable et la maintenir à jour.
</Accordion>

<Accordion title="Pouvons-nous exécuter nos propres charges de travail dans le cluster BYOC ou le compte cloud ?">
  Dans le compte cloud : c'est possible, mais les ressources colocalisées relèvent toujours, dans une certaine mesure, du périmètre d'autorisations de ClickHouse — sur AWS, la plupart des autorisations d'écriture sont limitées par tag et préfixe (les ressources provisionnées par ClickHouse portent `clickhouse-byoc=true`), mais un petit nombre d'actions EC2 ne peuvent pas être limitées par tag ; sur GCP et Azure, les identités d'onboarding disposent d'autorisations limitées au projet ou à l'abonnement. Séparez vos ressources de celles provisionnées par ClickHouse et privilégiez un compte, un projet ou un abonnement dédié dans chaque cloud : cela reste vivement recommandé.

  Dans le cluster Kubernetes : c'est possible sous certaines contraintes — utilisez vos propres groupes de nœuds avec des taints et des tolerations, n'utilisez pas les espaces de noms gérés par ClickHouse et n'installez pas de contrôleurs d'admission ni de moteurs de politiques à l'échelle du cluster, car ils peuvent bloquer la réconciliation des composants ClickHouse. Décrivez votre projet au support afin que nous puissions confirmer qu'il n'y a pas de conflits.
</Accordion>

<div id="compute">
  ### Calcul et mise à l’échelle
</div>

<Accordion title="Puis-je créer plusieurs services dans une même infrastructure BYOC ?">
  Oui. L’infrastructure (y compris le cluster Kubernetes) ne doit être provisionnée qu’une seule fois pour chaque combinaison compte Cloud/projet/abonnement et région. Tous les services que vous créez dans cette région la partagent.
</Accordion>

<Accordion title="Quelles régions sont prises en charge pour BYOC ?">
  Toutes les **régions publiques** répertoriées dans notre documentation sur les [régions prises en charge](/fr/products/cloud/reference/supported-regions) sont disponibles pour les déploiements BYOC. BYOC est provisionné sur trois zones de disponibilité. Les régions comptant moins de trois zones ainsi que les AWS Local Zones ne sont donc pas prises en charge. Si la région dont vous avez besoin n’est pas répertoriée, contactez votre représentant ClickHouse pour discuter de sa disponibilité.
</Accordion>

<Accordion title="Y a-t-il une surcharge de ressources ? Quelles ressources sont nécessaires à l’exécution des services autres que les instances ClickHouse ?">
  Outre les instances ClickHouse elles-mêmes (les serveurs ClickHouse et ClickHouse Keeper), nous exécutons également des services de support tels que `clickhouse-operator`, le cluster autoscaler, Istio et la pile de supervision.

  La consommation de ressources de ces composants partagés est relativement stable et n’augmente pas linéairement avec le nombre ou la taille de vos services ClickHouse. À titre indicatif, le groupe de nœuds système dédié à ces charges de travail totalise environ 48 vCPU et 192 Go de mémoire — sur AWS, par exemple, environ six instances `2xlarge`. En outre, chaque entrepôt exécute un ensemble ClickHouse Keeper dédié de trois nœuds, partagé par tous les services de cet entrepôt. Consultez le [modèle de coûts](/fr/products/bring-your-own-cloud/reference/cost-model-aws) pour plus de détails.
</Accordion>

<Accordion title="BYOC prend-il en charge l’autoscaling ?">
  L’autoscaling vertical au niveau des services est prévu dans la feuille de route. Disponibles aujourd’hui : la mise à l’échelle verticale et horizontale manuelle via la Console, la mise à l’échelle planifiée pour les charges prévisibles, la mise en veille et le réveil automatiques pour les charges de travail intermittentes, ainsi que la mise à l’échelle automatique des groupes de nœuds au niveau de l’infrastructure — vous n’avez jamais à gérer les nœuds vous-même. ClickHouse Keeper est surveillé et mis à l’échelle par ClickHouse.
</Accordion>

<Accordion title="Sur quels types d’instances BYOC s’exécute-t-il ? Pouvons-nous changer de famille d’instances ?">
  BYOC s’exécute sur un ensemble sélectionné de groupes de nœuds plutôt que sur des types d’instances arbitraires. Les groupes de nœuds dédiés aux charges de travail (serveurs ClickHouse et Keeper) s’exécutent par défaut sur des instances ARM optimisées pour la mémoire (Graviton sur AWS), tandis que le groupe de nœuds système utilise généralement des instances x86. D’autres familles d’instances, ratios CPU/mémoire ou architectures peuvent être provisionnés sur demande via le support ; les instances Spot ne sont pas prises en charge. Consultez la [configuration](/fr/products/bring-your-own-cloud/configuration/configurations).
</Accordion>

<Accordion title="Pouvons-nous exécuter de très petites répliques pour réduire les coûts ?">
  Chaque réplique s’exécute sous la forme d’un pod sur son propre nœud — la taille du nœud est adaptée à celle de la réplique, les nœuds sont provisionnés à la demande et plusieurs répliques ne sont jamais regroupées sur un même nœud. Les très petites répliques sont donc inefficaces : une part plus importante du matériel est consacrée à la surcharge, et la bande passante réseau et disque évolue avec la taille de l’instance. Les tailles inférieures à celles proposées dans la Console nécessitent une demande personnalisée auprès du support.
</Accordion>

<Accordion title="Pouvons-nous séparer les charges de travail d’ingestion et de requête ?">
  Oui. Les entrepôts (séparation du calcul) sont pris en charge dans BYOC : plusieurs services partagent les mêmes données, ce qui vous permet de dédier certains services à l’ingestion et d’autres aux requêtes.
</Accordion>

<div id="network-and-security">
  ### Réseau et sécurité
</div>

<Accordion title="Pouvons-nous limiter ou révoquer les autorisations accordées lors de l’installation ?">
  Vous pouvez réduire les autorisations dès le départ sur AWS et GCP : les artefacts d’onboarding sont paramétrables, ce qui vous permet de ne pas accorder les autorisations de gestion de la topologie réseau de votre VPC lorsque vous utilisez votre propre VPC (`IncludeVPCWritePermissions` dans CloudFormation, `include_vpc_write_permissions` dans les modules Terraform). Sur GCP, cela limite uniquement la gestion de la topologie ; ClickHouse conserve un accès en écriture aux ressources réseau qu’il possède dans le VPC, telles que le sous-réseau NAT de Private Service Connect, l’attachement de service et les adresses d’entrée. Sur AWS, vous pouvez également — en aperçu privé, sur activation par le support — gérer vous-même les rôles IAM (`IncludeIAMWritePermissions=false`, voir [rôles IAM gérés par le client](/fr/products/bring-your-own-cloud/onboarding/customization-aws)). Les rôles intercomptes sont protégés par un ID externe contre les attaques de type « confused deputy ». Sur Azure, le module d’onboarding accorde actuellement un rôle fixe à l’échelle de l’abonnement, sans paramètres de restriction. Dans tous les clouds, certaines autorisations ne sont requises que pour des fonctionnalités spécifiques et peuvent être supprimées si vous n’utiliserez jamais ces fonctionnalités ; contactez le support si vous devez restreindre davantage les autorisations au-delà de ce que permettent les artefacts.

  Après le provisionnement, ne supprimez pas unilatéralement les autorisations de l’identité de gestion : ClickHouse réconcilie continuellement l’infrastructure, et l’absence d’autorisations bloque le provisionnement, les mises à niveau et le support. Pour modifier les autorisations accordées ou désactiver entièrement le service, coordonnez-vous avec le support (voir la question sur le déclassement ci-dessous).
</Accordion>

<Accordion title="Que peut exactement faire ClickHouse dans notre compte cloud ? Notre équipe de sécurité peut-elle examiner les autorisations ?">
  La [référence des privilèges](/fr/products/bring-your-own-cloud/reference/privilege) offre une vue d’ensemble de chaque rôle et identité, ainsi que de leur fonction, sur AWS, GCP et Azure. Pour l’identité d’onboarding (bootstrap), l’ensemble exact des politiques est défini par les artefacts publiés — le [modèle CloudFormation](https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/cf-templates/byoc_v2.yaml) et les [modules Terraform](https://github.com/ClickHouse/terraform-byoc-onboarding) — que votre équipe de sécurité peut auditer directement. Les identités supplémentaires créées par ClickHouse après l’onboarding (rôles de contrôleur, comptes de service et identités gérées) sont décrites pour chaque fournisseur dans la référence des privilèges. Comme elles résident dans votre compte, vous pouvez inspecter leurs politiques effectives dans votre console cloud et consulter leur création et leur utilisation dans CloudTrail ou les équivalents GCP/Azure. Sur AWS, la plupart des autorisations d’écriture du rôle de gestion sont limitées par des tags de ressources et des préfixes de nom tels que `clickhouse-cloud-*`, de sorte qu’il ne peut généralement pas modifier les ressources qu’il n’a pas créées (un petit nombre d’actions EC2 ne peuvent pas être limitées par tag). Il ne dispose **d’aucun accès aux objets de vos compartiments de données** : l’accès aux objets est limité aux identités du cluster, elles-mêmes limitées aux charges de travail ClickHouse. Sur GCP et Azure, les identités d’onboarding disposent plutôt d’autorisations à l’échelle du projet ou de l’abonnement, ce qui explique notamment pourquoi un projet ou un abonnement dédié est fortement recommandé. Les autorisations de lecture sont plus étendues, car elles sont nécessaires à la réconciliation continue.
</Accordion>

<Accordion title="De quels accès les employés de ClickHouse disposent-ils à notre environnement et à nos données ?">
  Par défaut, ils n’ont aucun accès à vos données. Pour le dépannage, les ingénieurs doivent passer par un processus interne d’escalade juste-à-temps ; l’accès est limité dans le temps, basé sur des certificats, restreint aux tables `system.*` (à l’exclusion des tables de données client), journalisé et audité par notre équipe de sécurité. Toute requête exécutée par un ingénieur ClickHouse est visible dans votre propre `system.query_log`. Pour les diagnostics d’infrastructure, cette même procédure d’escalade soumise à approbation peut également accorder un accès limité dans le temps au Kubernetes API server et à la pile de Monitoring du cluster via Tailscale. Consultez [ClickHouse data access](/fr/products/bring-your-own-cloud/reference/clickhouse-data-access) pour le modèle d’accès aux données et [sécurité réseau](/fr/products/bring-your-own-cloud/reference/network-security) pour le modèle de connexion.
</Accordion>

<Accordion title="Avez-vous envisagé de futurs contrôles de sécurité permettant aux ingénieurs ClickHouse d’accéder à l’infrastructure client pour le dépannage ?">
  Oui. La mise en œuvre d’un mécanisme contrôlé par le client permettant aux clients d’approuver l’accès des ingénieurs au cluster figure sur notre feuille de route. À l’heure actuelle, les ingénieurs doivent passer par notre processus interne d’escalade pour obtenir un accès juste-à-temps au cluster. Cet accès est journalisé et audité par notre équipe de sécurité.
</Accordion>

<Accordion title="Quelles données quittent notre compte ?">
  Uniquement des métadonnées opérationnelles : événements d’état du service et des sauvegardes, métriques d’utilisation à des fins de facturation et notifications d’alerte. Vos données, sauvegardes, logs et données de Monitoring restent dans votre compte. Consultez [sécurité réseau](/fr/products/bring-your-own-cloud/reference/network-security) pour obtenir la liste complète des flux sortants.
</Accordion>

<Accordion title="Comment le plan de contrôle ClickHouse accède-t-il à l'API Kubernetes de notre compte ? Tailscale est-il requis ?">
  Par défaut, l'endpoint de l'API Kubernetes est public, mais limité aux adresses IP NAT de ClickHouse. Tant que cette configuration par défaut est utilisée, ne supprimez pas les entrées de la liste d'autorisation ClickHouse, car le plan de contrôle en a besoin pour gérer le cluster. L'endpoint peut également être configuré pour un accès privé uniquement, en coordination avec l'équipe ClickHouse : via Tailscale (sortant uniquement, également utilisé pour l'accès de dépannage) ou, sur AWS, via VPC Lattice (aperçu privé) — consultez la [configuration](/fr/products/bring-your-own-cloud/configuration/configurations). Notez que cela s'applique uniquement à l'API Kubernetes : les appels aux API du fournisseur Cloud (par exemple EKS et EC2 sur AWS) proviennent du réseau de ClickHouse Cloud via l'assomption de rôle intercompte et ne peuvent jamais être acheminés via Tailscale — consultez [API du fournisseur Cloud et API Kubernetes](/fr/products/bring-your-own-cloud/reference/network-security#cloud-api-vs-kubernetes-api).
</Accordion>

<Accordion title="Comment les communications réseau fonctionnent-elles entre le réseau BYOC et le stockage d'objets ?">
  Sur AWS, le trafic entre votre Customer BYOC VPC et S3 utilise HTTPS (port 443) via l'API AWS S3 pour les données de tables, les sauvegardes et les journaux. Ce trafic passe par un endpoint VPC de type Gateway pour S3 : il reste donc au sein du réseau AWS, ne transite pas par Internet public et n'entraîne aucuns frais de passerelle NAT. Sur GCP, l'accès aux API Google utilise de même Private Google Access. Sur Azure, les données sont stockées dans des comptes Azure Blob Storage de votre abonnement.
</Accordion>

<Accordion title="Les données se trouvent dans notre propre bucket : pouvons-nous les lire ou les modifier directement ?">
  Non. Les blobs de données de tables sont stockés dans une disposition partagée, sans chemins par table. Les objets ne peuvent donc pas être attribués à des tables, et toute modification directe risque de corrompre vos services. Ne modifiez jamais directement le contenu du bucket ; si vous suspectez un problème, ouvrez un ticket de support.
</Accordion>

<Accordion title="Quels ports sont utilisés pour les communications client et cluster ?">
  Les connexions client aboutissent au équilibreur de charge sur les ports TLS suivants : **8443** (interface HTTPS) et **9440** (protocole natif sur TLS) ; le port 443 achemine également vers l'interface HTTPS. L'interface MySQL (port 3306) n'est actuellement pas exposée dans BYOC — elle figure sur la feuille de route (consultez l'[aperçu](/fr/products/cloud/guides/infrastructure/deployment-options/byoc/overview)).

  Au sein du réseau, les communications internes au cluster utilisent le protocole natif sur le port 9000, HTTP sur le port 8123, ainsi que la communication interserveur sur le port 9009 pour la réplication et les requêtes distribuées. Ces ports internes et les ports ClickHouse Keeper ne sont jamais exposés par un équilibreur de charge.
</Accordion>

<Accordion title="Nos endpoints de service sont-ils exposés sur Internet public ? Pouvons-nous passer à un accès privé uniquement ?">
  Avec un VPC géré par ClickHouse, chaque service dispose par défaut d'un équilibreur de charge public protégé par une liste d'accès IP ; un équilibreur de charge privé, accessible depuis votre réseau et les réseaux appairés, peut également être activé dans la ClickHouse Cloud console (consultez [Load Balancers](/fr/products/bring-your-own-cloud/configuration/configurations#load-balancers)). Avec un VPC géré par le client, les paramètres par défaut sont inversés et seul l'équilibreur de charge privé est activé. Le filtrage IP est appliqué au niveau du proxy d'entrée ; les ports de l'équilibreur de charge peuvent donc sembler ouverts lors d'analyses, mais les connexions provenant de sources non répertoriées sont rejetées. L'endpoint public peut être entièrement désactivé dès lors que plus rien n'en dépend. Le [sélecteur de connexion](/fr/products/bring-your-own-cloud/configuration/connect#connection-via) de la console affiche les endpoints associés à chaque chemin de connexion activé pour votre service. Consultez la [connectivité](/fr/products/bring-your-own-cloud/configuration/connect).
</Accordion>

<Accordion title="Pouvons-nous utiliser notre propre domaine DNS ou fournir nos propres certificats TLS ?">
  Pas encore. Les endpoints de service sont provisionnés sous `clickhouse-byoc.com` avec des certificats gérés par ClickHouse.
</Accordion>

<Accordion title="Comment configurer AWS PrivateLink, GCP Private Service Connect ou Azure Private Link ?">
  Suivez les guides de configuration réseau pour [AWS](/fr/products/bring-your-own-cloud/onboarding/network-aws), [GCP](/fr/products/bring-your-own-cloud/onboarding/network-gcp) et [Azure](/fr/products/bring-your-own-cloud/onboarding/network-azure). Deux points sont fréquemment oubliés : la liste d'autorisation des endpoints est **par service**, les endpoints doivent donc être enregistrés de nouveau pour chaque nouveau service, et la résolution DNS des noms d'endpoints privés doit être configurée de votre côté si vous utilisez votre propre DNS. Une fois la configuration effectuée, utilisez le [sélecteur de connexion](/fr/products/bring-your-own-cloud/configuration/connect#connection-via) de la console pour copier le nom d'hôte correct de l'endpoint privé.
</Accordion>

<Accordion title="Pouvons-nous nous connecter via PrivateLink depuis une autre région AWS ?">
  Oui, mais le bouton bascule **Enable private link** de la console ne couvre que les consommateurs situés dans la même région : AWS désactive par défaut l’accès interrégional aux services d’endpoint, et la console ClickHouse ne le gère pas. Comme le service d’endpoint se trouve dans votre compte BYOC, vous devez l’activer vous-même : ajoutez les régions consommatrices à la liste **Supported regions** du service d’endpoint dans votre console AWS, puis créez l’endpoint avec l’option interrégionale côté consommateur. ClickHouse ne modifiera ni ne réinitialisera ces valeurs. Consultez le [guide de configuration de PrivateLink](/fr/products/bring-your-own-cloud/onboarding/network-aws#setup-privatelink) ; les tarifs AWS de transfert de données interrégional s’appliquent.
</Accordion>

<Accordion title="Existe-t-il une liste d’endpoints à autoriser dans notre pare-feu ou nos règles d’egress ?">
  Il n’existe pas de liste unique d’endpoints publiée. Le cluster nécessite un accès Internet sortant fonctionnel (directement ou via NAT), ainsi qu’un accès privé aux API du fournisseur Cloud ; consultez les [exigences de connectivité réseau](/fr/products/bring-your-own-cloud/onboarding/customization-aws#ensure-network-connectivity). Si votre politique réseau exige un inventaire explicite, contactez l’assistance afin d’examiner votre configuration.
</Accordion>

<Accordion title="Nos outils de sécurité ont signalé des conteneurs privilégiés ou des montages hôte dans le cluster BYOC : est-ce attendu ?">
  Certains composants de la plateforme nécessitent légitimement des privilèges élevés ou un accès au système de fichiers hôte, notamment le pilote EBS CSI, les tâches de configuration des nœuds et l’exporter de nœud Prometheus (qui lit `/proc` et `/sys`). Si votre scanner signale des problèmes, transmettez-les à l’assistance : nous confirmerons si chacun est prévu ou nécessite une action.
</Accordion>

<Accordion title="Prenez-vous en charge les clés de chiffrement gérées par le client (CMEK) ?">
  Pas actuellement pour BYOC. Les données au repos sont chiffrées à l’aide de clés gérées par le fournisseur Cloud. Consultez la [vue d’ensemble](/fr/products/cloud/guides/infrastructure/deployment-options/byoc/overview) pour obtenir la liste actuelle des fonctionnalités prévues.
</Accordion>

<div id="upgrades-and-maintenance">
  ### Mises à niveau et maintenance
</div>

<Accordion title="Comment fonctionnent les mises à niveau de version de ClickHouse ? Puis-je définir la fréquence de maintenance ?">
  Les mises à niveau fonctionnent de la même manière que dans ClickHouse Cloud : les services sont inscrits à des canaux de publication (rapide, régulier, lent) et respectent les fenêtres de maintenance planifiées. Contactez le support pour les configurer. Prévoyez au minimum une mise à jour par semaine. Les mises à niveau sont effectuées de manière progressive, réplique par réplique (make before break), de sorte que l’ensemble du service ne connaît aucune indisponibilité. Consultez les [opérations](/fr/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<Accordion title="Qui est responsable des mises à niveau de Kubernetes et à quel impact faut-il s’attendre ?">
  ClickHouse prend en charge et effectue les mises à niveau de Kubernetes de manière proactive, avant les dates de fin de support du fournisseur, et coordonne la fenêtre avec vous via le support. Les mises à niveau du plan de contrôle sont transparentes ; les mises à niveau des groupes de nœuds s’effectuent nœud par nœud selon une stratégie make before break. Vous pourrez donc observer de brèves réinitialisations de connexion lors du redémarrage des pods, mais aucune perte de données. Consultez les [opérations](/fr/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<div id="backups-and-disaster-recovery">
  ### Sauvegardes et reprise après sinistre
</div>

<Accordion title="Où les sauvegardes sont-elles stockées ?">
  Dans le stockage d’objets de votre propre compte cloud : les sauvegardes ne quittent jamais votre environnement. La planification et la rétention des sauvegardes sont configurables ; contactez le support pour les modifier.
</Accordion>

<Accordion title="Que comprend une sauvegarde ? Les tables système sont-elles sauvegardées ?">
  Toutes les bases de données, tables et objets créés par les utilisateurs, ainsi que les entités d’accès (utilisateurs, rôles, profils de paramètres, politiques de lignes, quotas) et les fonctions définies par l’utilisateur. Les tables de journaux système telles que `system.query_log` ne sont pas incluses.
</Accordion>

<Accordion title="Pourquoi les sauvegardes antérieures à ma période de rétention me sont-elles facturées ?">
  Les sauvegardes forment des chaînes : une sauvegarde complète suivie de sauvegardes incrémentielles qui en dépendent. La sauvegarde complète de base est nécessaire pour restaurer toute sauvegarde incrémentielle de sa chaîne ; elle est donc conservée (et stockée) jusqu’à ce que chaque sauvegarde incrémentielle dépendante ait dépassé sa période de rétention.
</Accordion>

<Accordion title="Comment surveiller nous-mêmes l’état des sauvegardes ?">
  Deux options : les endpoints de sauvegarde de l’API ClickHouse Cloud et les métriques de sauvegarde (compteurs de démarrage, de fin et d’échec) exposées par la pile de monitoring du cluster. Nous vous recommandons de configurer des alertes sur les échecs dans votre propre système de monitoring. Consultez [l’observabilité](/fr/products/bring-your-own-cloud/reference/observability-aws).
</Accordion>

<Accordion title="Comment répondre aux exigences de reprise après sinistre (RPO/RTO) ?">
  BYOC est déployé sur trois zones de disponibilité et les écritures ne sont confirmées qu’une fois validées par le stockage d’objets. La réplication inter-régions n’est pas disponible actuellement ; la reprise après sinistre à l’échelle régionale repose donc sur les sauvegardes, et le RPO atteignable est limité par leur fréquence. La fréquence et la destination des sauvegardes peuvent être configurées pour répondre à vos objectifs, notamment en effectuant les sauvegardes dans un bucket situé dans une autre région : contactez le support pour mettre cela en place.
</Accordion>

<div id="observability">
  ### Observabilité
</div>

<Accordion title="Comment intégrer BYOC à notre propre solution de monitoring et d’alerte ?">
  La stack de monitoring (Prometheus, Grafana, AlertManager) s’exécute dans votre compte et vous pouvez l’utiliser directement via une connectivité privée : interrogez-la via l’API PromQL, fédérez-la dans votre propre instance Prometheus ou récupérez les métriques de l’endpoint ClickHouse `/metrics_all` pour chaque service. Il n’existe actuellement aucune intégration clé en main avec des plateformes tierces telles que Datadog ; utilisez leur ingestion compatible Prometheus. Consultez [l’observabilité](/fr/products/bring-your-own-cloud/reference/observability-aws) pour connaître les endpoints et la configuration.
</Accordion>

<div id="cost">
  ### Coût
</div>

<Accordion title="Que payons-nous avec BYOC ?">
  Deux factures distinctes : ClickHouse Cloud facture la mémoire allouée à vos services, tandis que votre fournisseur cloud vous facture directement l’infrastructure sous-jacente au prix coûtant, sans majoration. Les pages de référence détaillées sur les coûts couvrent actuellement AWS : consultez le [modèle de coûts](/fr/products/bring-your-own-cloud/reference/cost-model-aws), les [services AWS facturables](/fr/products/bring-your-own-cloud/reference/billable-aws-services) et les [limites de service AWS](/fr/products/bring-your-own-cloud/reference/aws-service-limits).
</Accordion>

<div id="availability-and-lifecycle">
  ### Disponibilité et cycle de vie
</div>

<Accordion title="Chez quels fournisseurs cloud BYOC est-il disponible ?">
  AWS, GCP et Azure sont tous disponibles en disponibilité générale. Consultez la [vue d’ensemble](/fr/products/cloud/guides/infrastructure/deployment-options/byoc/overview) pour connaître les fonctionnalités et les régions prises en charge sur chaque cloud.
</Accordion>

<Accordion title="Comment mettre hors service un environnement BYOC ?">
  Résiliez vos services et l’infrastructure BYOC depuis la console ClickHouse — ne commencez pas par supprimer des ressources ou révoquer des autorisations dans la console de votre fournisseur cloud, car cela interrompt la connexion au plan de contrôle en cours d’opération et impose un nettoyage manuel. Une fois la résiliation depuis la console terminée, supprimez la pile d’onboarding (pile CloudFormation ou module Terraform) ainsi que les ressources restantes. Sur AWS, toutes les ressources créées par ClickHouse portent le tag `clickhouse-byoc=true`, ce qui vous permet de les répertorier ensuite afin de vérifier qu’il ne reste rien ; sur GCP et Azure, le projet ou l’abonnement dédié utilisé lors de l’onboarding délimite les éléments à examiner.
</Accordion>

<div id="uptime-sla">
  ### SLA de disponibilité
</div>

<Accordion title="ClickHouse propose-t-il un SLA de disponibilité pour BYOC ?">
  Non. Comme le plan de données est hébergé dans l’environnement cloud du client, la disponibilité du service dépend de ressources qui ne sont pas sous le contrôle de ClickHouse. Par conséquent, ClickHouse n’offre pas de SLA de disponibilité formel pour les déploiements BYOC. Notez que les services en cours d’exécution fonctionnent indépendamment du plan de contrôle ClickHouse : une panne du plan de contrôle n’interrompt pas les services exécutés dans votre compte. Si vous avez d’autres questions, veuillez contacter le support à l’adresse [support@clickhouse.com](mailto:support@clickhouse.com).
</Accordion>