BYOC (Bring Your Own Cloud)
BYOC (Bring Your Own Cloud) est un modèle dans lequel un client connecte son compte existant chez un fournisseur cloud, plutôt que de migrer vers l'infrastructure propre d'un éditeur ou vers le compte d'un revendeur. Le compte, le contrat et la relation de facturation restent en permanence entre le client et le fournisseur ; l'éditeur gère les ressources à l'intérieur de ce compte sans jamais le posséder.
BYOC désigne qui possède légalement le compte cloud dans lequel tourne une infrastructure, pas qui l'exploite au quotidien. Dans un dispositif BYOC, une organisation conserve son propre compte chez un fournisseur cloud — Amazon Web Services, Google Cloud, Hetzner, ou tout autre — avec le contrat et la facturation qui l'accompagnent. Un éditeur tiers, qu'il s'agisse d'une plateforme de gestion, d'un outil de supervision ou d'un prestataire de services managés, se voit accorder un accès délimité pour opérer à l'intérieur de ce compte : provisionner des ressources, appliquer des configurations ou collecter de la télémétrie. Rien ne change côté calcul, stockage ou réseau sous-jacents. Le terme est né dans les contextes de bases de données managées et de SaaS, où « bring your own cloud » distingue un déploiement qui s'exécute dans le compte du client d'un déploiement hébergé entièrement sur l'infrastructure propre de l'éditeur.
L'alternative est un modèle entièrement managé ou de revente, où l'éditeur détient son propre compte chez le fournisseur sous-jacent et revend de la capacité aux clients, ou migre leurs charges de travail vers une infrastructure qu'il possède en propre. Ce modèle peut simplifier la facturation — un seul éditeur, une seule facture — mais il signifie aussi que l'infrastructure du client se trouve dans le compte de quelqu'un d'autre. Changer d'éditeur, négocier directement les tarifs du fournisseur, ou prouver à un auditeur quelle entité détient exactement le contrat sous-jacent, devient alors plus difficile. Le BYOC préserve cette frontière : le client peut révoquer l'accès de l'éditeur au niveau du fournisseur à tout moment, et le compte sous-jacent, son historique de facturation et sa posture de conformité ne changent jamais de mains.
En pratique, l'accès BYOC est accordé via des identifiants API ou un rôle attribué à l'éditeur dans le compte du client, délimité à ce dont il a réellement besoin et révocable indépendamment de la relation avec l'éditeur elle-même. Le compromis est opérationnel : c'est le client, et non l'éditeur, qui reste la partie contractante auprès de chaque fournisseur cloud — donc plusieurs fournisseurs signifient plusieurs contrats et factures, à moins qu'une couche au-dessus du compte ne les consolide. Les éditeurs qui prennent en charge le BYOC prennent généralement aussi en charge le modèle inverse — provisionner et facturer de la capacité sous leur propre compte pour le compte du client — ce qui permet à une organisation de combiner les deux selon les ressources qu'elle souhaite garder sous contrat direct avec le fournisseur et celles qu'elle est à l'aise de déléguer entièrement.
Pourquoi le BYOC compte
Le risque central auquel répond le BYOC est le verrouillage fournisseur (lock-in). Quand l'infrastructure se trouve dans le compte propre d'un éditeur, quitter cet éditeur signifie migrer les charges de travail — un projet qui se mesure en semaines ou en mois, pas en un simple ticket de support. Le BYOC réduit la sortie à un changement de permissions : révoquer les identifiants de l'éditeur, et l'infrastructure reste exactement là où elle était, sous le même contrat. Cela compte particulièrement là où c'est le compte sous-jacent, et pas seulement les données, qui a un poids en matière de conformité — dans les secteurs réglementés où une entité juridique précise doit rester la partie contractante directe du responsable de traitement auprès du fournisseur d'infrastructure, ou dans les règles de marchés publics qui exigent que l'organisation acheteuse détienne son propre contrat cloud plutôt qu'un contrat sous-traité. Cela préserve aussi toute tarification au volume ou tout accord entreprise déjà négocié directement par l'organisation avec son fournisseur cloud.
Comment Sencai gère le BYOC
Sencai prend en charge le BYOC comme l'un de deux modèles coexistant au sein d'une même organisation. Connectez un compte existant et rien ne bouge : les identifiants sont chiffrés au repos, vous pouvez révoquer l'accès chez le fournisseur à tout moment, et dès que le compte est connecté, Sencai fait l'inventaire de ce qui tourne déjà — instances, réseaux, stockage, DNS — sur chaque fournisseur connecté, avec une activation de la gestion active ressource par ressource. Le compte, le contrat et la facture restent en permanence chez votre fournisseur. Si vous préférez ne pas détenir de contrat direct avec le fournisseur, Sencai peut à la place provisionner et facturer la capacité sous son propre compte — une seule facture, le coût fournisseur plus une marge de 2 % indiquée séparément sur le relevé — et vous pouvez combiner les deux modèles selon l'évolution de vos besoins.
Voir comment fonctionnent l'inventaire et le provisionnement →