Il y a deux façons de laisser quelqu'un d'autre exploiter votre infrastructure. Dans la première, vous leur achetez du cloud : ils détiennent les comptes fournisseurs, ils reçoivent la facture, vous recevez une facture avec marge et une adresse de support. Dans la seconde - bring your own cloud, généralement abrégé BYOC - vous gardez vos propres comptes chez Hetzner, AWS ou OVHcloud, votre propre contrat, votre propre facture, et vous accordez à une plateforme de gestion des credentials scopés pour les exploiter en votre nom. Les deux modèles se ressemblent en démo et ne se comportent pas du tout de la même façon le jour où vous voulez partir.
Le modèle de revente n'est pas une arnaque ; c'est une activité légitime avec de vrais avantages, principalement une facture unique et un seul interlocuteur en cas de problème. Ce que vous perdez est moins visible. Votre relation contractuelle est avec le revendeur, pas avec le fournisseur, donc le SLA que vous pouvez réellement faire valoir est le sien. Les remises d'engagement d'usage, les crédits startup et les tarifs négociés passent tous par lui. Et l'identité de la ressource, le compte dans lequel vivent réellement les serveurs, appartient à quelqu'un d'autre, ce qui signifie que partir est une migration, pas une résiliation.
Ce que vous gardez quand vous gardez le contrat
Avec le BYOC, la relation fournisseur reste exactement là où un juriste s'attendrait à la trouver. Les instances sont dans votre compte. Les tickets de support sont les vôtres à ouvrir. La facture arrive dans le format que votre équipe finance rapproche déjà, en provenance d'une entreprise sur laquelle vous avez déjà fait votre due diligence, sous une juridiction que vous avez déjà évaluée. Si votre posture de conformité dépend de qui exploite légalement un service - ce qui, depuis Schrems II, est la question intéressante plutôt que l'emplacement physique des serveurs - vous n'avez pas ajouté un maillon à cette chaîne en adoptant un plan de contrôle.
Le test de sortie rend la différence concrète. Si la plateforme de gestion disparaissait du jour au lendemain, que se passe-t-il ? Avec la revente, vos serveurs sont dans un compte que vous ne contrôlez pas, et la réponse implique des avocats. Avec le BYOC, les serveurs continuent de tourner exactement comme avant ; vous avez perdu une console, un inventaire et un peu d'automatisation, ce qui est agaçant plutôt qu'existentiel. Cette asymétrie vaut plus que n'importe quelle liste de fonctionnalités, et c'est la première chose à vérifier avant de signer quoi que ce soit.
Ce que le BYOC exige de la plateforme
Le prix de ce modèle, c'est que la plateforme détient désormais de vrais credentials de production pour des comptes qu'elle ne possède pas. Cette obligation doit être prise au pied de la lettre. Les credentials sont chiffrés au repos avec AES-256-GCM, scopés à une seule organisation, jamais partagés entre tenants, et jamais renvoyés dans une réponse API - les champs sont privés à la sortie autant que chiffrés à l'entrée. Chacune de ces exigences est ennuyeuse jusqu'au jour où un simple endpoint de liste se retrouve à devoir sérialiser un enregistrement de credential.
Vient ensuite le mode de défaillance que personne n'anticipe. Un job de provisioning arrive sans credential attaché : un bug, une race condition, un message venu d'une ancienne version d'un service. Le comportement tentant est de retomber sur le token fournisseur propre à la plateforme pour que le job réussisse. Nous avons livré ce comportement une fois, et il a fait exactement ce qu'il allait toujours faire - créé une vraie machine sur le compte propre de la plateforme, facturée à la mauvaise partie, invisible dans l'inventaire du client. Le comportement par défaut est désormais fail-closed. Un job sans credential est refusé, et activer le fallback nécessite un flag d'environnement explicite.
Où le BYOC multi-fournisseur se complique
Un fournisseur, c'est une intégration ; onze, c'est un problème de taxonomie. Sencai pilote aujourd'hui Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode d'Akamai et Oracle Cloud, ainsi que les serveurs on-premise et bare metal via un agent hôte. Chacun a son propre modèle d'authentification, son propre système de quotas, son propre vocabulaire, et sa propre idée de savoir si un firewall appartient à une machine, un réseau ou un projet. Normaliser tout ça sans mentir dessus, c'est l'essentiel du travail d'ingénierie.
La ligne que nous tenons à respecter : le plan de contrôle opère le fournisseur, pas une copie de celui-ci. Quand vous créez un réseau, une règle de firewall ou une zone DNS dans Sencai, l'appel part vers l'API du fournisseur et l'objet existe là-bas - visible dans leur console, supprimable avec leur CLI, bien réel pour quiconque n'a jamais entendu parler de nous. Une plateforme qui se contente d'enregistrer une intention dans sa propre base de données produit un inventaire très convaincant de choses qui n'existent peut-être pas.
La facturation suit la même logique. Puisque la facture reste chez le fournisseur, le rôle de la plateforme n'est pas de vous facturer. C'est l'attribution et le contrôle. Les dépenses sont suivies par organisation et par projet sur tous les comptes connectés, avec les plafonds que vous définissez, si bien que la question « combien a coûté le pipeline batch le mois dernier » a une seule réponse au lieu de quatre exports dans quatre formats. C'est aussi la partie où le BYOC est réellement plus difficile que la revente, car il n'existe pas de registre unique à consulter : les chiffres doivent être extraits et réconciliés fournisseur par fournisseur.
À qui s'adresse le bring your own cloud
Le BYOC convient aux équipes qui ont déjà un parc existant et des contraintes déjà bien réelles : quelques centaines de machines accumulées en trois ans, une exigence de juridiction imposée par le service achats d'un client, un mix de fournisseurs qui s'est produit plutôt qu'il n'a été conçu. Il convient moins bien si vous partez de zéro, voulez exactement une seule facture, et n'avez aucune opinion sur l'endroit où tourne quoi que ce soit. Un revendeur ou un hyperscaler unique sera plus simple, et vous devriez prendre l'option la plus simple. Personne n'a besoin d'un plan de contrôle multi-cloud pour un compte et onze serveurs.
Deux points deviennent plus critiques sous BYOC et méritent une conception délibérée plutôt que de bonnes intentions. Le premier, c'est l'isolation : les identifiants appartiennent à une organisation, l'adhésion se fait sur invitation, et les rôles décident qui peut dépenser de l'argent ou toucher à un firewall - parce que le rayon d'impact ici est un vrai compte de production, pas un bac à sable. Le second, c'est le journal d'audit. Chaque action que la plateforme effectue en votre nom doit être enregistrée en append-only, avec l'acteur, la ressource et un ID de corrélation, dans un format que vous pouvez exporter. Vous déléguez des opérations, donc l'enregistrement de ces opérations est ce qu'il vous reste, à défaut de les avoir faites vous-même.
Voici donc les questions à poser à quiconque vous vend du bring your own cloud. À quel nom est le contrat avec le fournisseur ? Que peut exactement faire l'identifiant que vous avez remis, et pouvez-vous en réduire la portée ? Qu'advient-il de l'infrastructure en production si vous arrêtez de les payer demain ? Pouvez-vous exporter le journal de tout ce qu'ils ont fait dans vos comptes, et le vérifier vous-même ? De bonnes réponses à ces quatre questions, c'est ce qui distingue externaliser vos opérations d'externaliser votre infrastructure - et une seule des deux est réversible un mardi.