Plan de contrôle cloud
Un plan de contrôle cloud est la couche d'interfaces, d'API et de services qui permet de provisionner, configurer et gérer l'infrastructure — distincte du plan de données, qui exécute réellement vos charges de travail et achemine votre trafic. Chaque fournisseur propose le sien ; le terme désigne aussi les systèmes qui gèrent plusieurs fournisseurs comme un plan unique.
Toute infrastructure comporte deux couches distinctes. Le plan de données, c'est l'infrastructure elle-même : les machines virtuelles qui exécutent votre application, le réseau qui achemine les paquets entre elles, le disque qui traite les lectures et les écritures. Le plan de contrôle, c'est tout ce que vous utilisez pour décider de la forme que doit prendre cette infrastructure et pour la modifier — l'API, la console, la CLI, le système de permissions qui détermine qui est autorisé à effectuer un changement. Quand vous créez une VM dans une console cloud, redimensionnez un disque ou ouvrez un port de pare-feu, vous opérez le plan de contrôle. L'instance qui démarre, les gigaoctets supplémentaires qui deviennent disponibles, le trafic qui se met à circuler — c'est le plan de données qui répond à ce que le plan de contrôle lui a demandé de faire.
Cette distinction devient plus utile dès qu'une équipe utilise plusieurs fournisseurs. AWS a son plan de contrôle. Google Cloud, Azure, Hetzner et tous les autres fournisseurs aussi — chacun avec sa propre console, sa propre forme d'API, ses propres identifiants, sa propre façon de nommer ce qu'est un « security group » ou une « règle de pare-feu ». Une équipe qui exploite trois clouds et vingt serveurs bare-metal opère en réalité trois ou quatre plans de contrôle distincts côte à côte, plus tout ce qu'elle utilise pour gérer les serveurs qui ne sont dans aucun cloud. Rien n'oblige ces plans de contrôle à se mettre d'accord entre eux, et rien en dehors de votre propre processus ne rend un changement effectué dans l'un d'eux visible à quelqu'un qui regarde un autre.
« Plan de contrôle cloud » s'emploie aussi dans un sens plus restreint — au sein de Kubernetes, le plan de contrôle désigne l'API server, le scheduler et le controller-manager qui décident où s'exécutent les pods, par opposition aux kubelets et aux conteneurs qui les font réellement tourner sur les nœuds. Un plan de contrôle « multi-cloud » ou « unifié » étend la même idée à travers les fournisseurs : un seul endroit pour voir et agir sur une infrastructure qui vit physiquement dans plusieurs comptes, régions et fournisseurs différents, au lieu d'une interface par fournisseur. Il ne remplace pas les plans de contrôle natifs sous-jacents — une requête finit toujours par un appel API vers AWS, vers Hetzner, ou vers l'agent de flotte sur une machine bare-metal — il se place devant eux pour que la personne qui effectue le changement n'ait qu'un seul système à apprendre.
Pourquoi cette distinction compte en pratique
La plupart des incidents d'infrastructure et des lacunes d'audit remontent à des problèmes de plan de contrôle, pas de plan de données : un changement que personne n'a journalisé, une permission que personne n'a révoquée, une règle de pare-feu ouverte dans la console d'un fournisseur qu'aucun autre membre de l'équipe ne peut voir. Quand chaque cloud a son propre plan de contrôle et sa propre piste d'audit, « qui a changé ceci, et quand » devient une question à laquelle on répond en se connectant à trois ou quatre consoles différentes et en comparant des horodatages à la main — ou en n'y répondant pas du tout. Pour les équipes soumises à des cadres de conformité comme NIS2, cette lacune n'est pas qu'un désagrément : l'historique des changements, le contrôle d'accès et les preuves d'incident sont exactement ce qu'un auditeur ou un régulateur demande en premier, et un plan de contrôle fragmenté explique pourquoi ces preuves n'existent souvent pas au même endroit.
Comment Sencai s'intègre
Sencai est un plan de contrôle qui se place au-dessus des plans natifs : il se connecte aux comptes de onze fournisseurs cloud ainsi qu'aux serveurs on-premise et bare-metal via un agent de flotte léger, et inventorie ce qui tourne déjà dès qu'un compte est connecté — sans migration nécessaire. À partir de là, provisionner, démarrer, arrêter, redimensionner et détruire des instances fonctionne de la même façon quel que soit le fournisseur. Vous pouvez connecter des comptes existants (rien ne bouge, les identifiants restent révocables chez le fournisseur) ou laisser Sencai provisionner et facturer la capacité directement, et combiner les deux au sein d'une même organisation. Chaque action, sur chaque fournisseur connecté, atterrit dans un journal d'audit unique, en ajout seul et chaîné par hachage, si bien que « qui a changé ceci, et quand » devient une requête, pas une enquête.
Voir l'inventaire et le provisionnement →