Vault Community Edition (CE) couvre 90% des cas d'usage en gestion de secrets. Avant de considérer Enterprise, évaluez objectivement vos besoins réels : la plupart des équipes n'ont pas besoin des fonctionnalités avancées.
Cette page détaille les différences entre les éditions et vous aide à faire un choix éclairé.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les fonctionnalités incluses dans chaque édition
- Les vrais besoins Enterprise vs les besoins perçus
- L'option HCP Vault (Vault managé)
- Une grille de décision objective
Vue d'ensemble des éditions
Section intitulée « Vue d'ensemble des éditions »Une précision qui évite une mauvaise surprise en fin de projet : les deux
éditions sont distribuées sous forme de binaires distincts. Le catalogue de
publication HashiCorp expose, pour une même version, une variante CE et des
variantes suffixées +ent, +ent.hsm et +ent.fips1403. Passer à Enterprise
suppose donc de remplacer le binaire ou l'image de conteneur, pas seulement de
déposer un fichier de licence.
Lisez ensuite la colonne « Licence » avant la colonne « Prix » : depuis Vault
1.15, le code n'est plus sous MPL 2.0 mais sous BUSL 1.1, et le
licencier inscrit dans le fichier LICENSE du dépôt est désormais IBM, qui a
racheté HashiCorp. Cette contrainte pèse sur votre choix bien avant la question
du budget, en particulier si vous revendez un service bâti sur Vault.
| Édition | Licence | Prix | Cas d'usage |
|---|---|---|---|
| Community (CE) | BSL 1.1 | Gratuit | La plupart des organisations |
| Enterprise | Commercial | $$$ | Multi-région, compliance stricte |
| HCP Vault | SaaS | $/heure | Vault managé par HashiCorp |
Tableau comparatif complet
Section intitulée « Tableau comparatif complet »Les trois tableaux qui suivent sont découpés selon le moment où la question se pose : ce que vous stockez (moteurs de secrets, méthodes d'authentification), ce que vous exploitez (stockage, haute disponibilité, descellement), puis ce que vous gouvernez (cloisonnement, politiques, audit). Une croix ne signifie pas « impossible en CE » : elle signifie « pas fourni par Vault, à assembler autrement ». Les alternatives correspondantes sont détaillées plus bas.
Fonctionnalités de base
Section intitulée « Fonctionnalités de base »Ce premier tableau porte sur la surface fonctionnelle du produit, celle que les développeurs consomment au quotidien. C'est aussi la moins discriminante : les moteurs qui couvrent l'immense majorité des usages, à savoir KV, Transit, PKI et les secrets dynamiques de base de données, sont dans les deux éditions. Les deux lignes qui basculent en Enterprise, KMIP et Transform, répondent à des besoins précis : parler le protocole de gestion de clés des baies de stockage et des HSM pour le premier, tokeniser des numéros de carte ou de sécurité sociale pour le second.
| Fonctionnalité | CE | Enterprise |
|---|---|---|
| Secrets Engines | ||
| KV (Key-Value) | ✅ | ✅ |
| Transit (chiffrement) | ✅ | ✅ |
| PKI (certificats) | ✅ | ✅ |
| Database (secrets dynamiques) | ✅ | ✅ |
| SSH (OTP, CA) | ✅ | ✅ |
| AWS, Azure, GCP secrets | ✅ | ✅ |
| KMIP | ❌ | ✅ |
| Transform (tokenisation) | ❌ | ✅ |
| Auth Methods | ||
| AppRole, UserPass | ✅ | ✅ |
| Kubernetes, LDAP | ✅ | ✅ |
| OIDC, JWT | ✅ | ✅ |
| AWS, Azure, GCP auth | ✅ | ✅ |
| Login MFA (TOTP, Duo, Okta, PingID) | ✅ | ✅ |
| SAML, Step-up MFA | ❌ | ✅ |
Fonctionnalités opérationnelles
Section intitulée « Fonctionnalités opérationnelles »C'est ici que se joue la vraie différence de prix. Regardez d'abord le bloc Haute disponibilité : un cluster CE fait déjà du Raft avec bascule automatique du leader sur un site unique, ce qui couvre la panne d'un nœud. Ce que CE ne fait pas, c'est répliquer vers un second cluster sur un autre site. Le bloc Unseal se lit de la même façon : l'auto-unseal par KMS cloud, que beaucoup croient réservé à Enterprise, est disponible en CE depuis Vault 1.0. Ne restent en Enterprise que le scellement par HSM PKCS#11 et le Seal Wrap, tous deux motivés par une certification FIPS, pas par un besoin d'exploitation.
| Fonctionnalité | CE | Enterprise |
|---|---|---|
| Stockage | ||
| Integrated Storage (Raft) | ✅ | ✅ |
| Consul, etcd, etc. | ✅ | ✅ |
| Haute disponibilité | ||
| Cluster HA (single site) | ✅ | ✅ |
| Replication DR | ❌ | ✅ |
| Replication Performance | ❌ | ✅ |
| Autopilot | ✅ (basique) | ✅ (avancé) |
| Unseal | ||
| Shamir | ✅ | ✅ |
| Auto-unseal (KMS, Transit) | ✅ | ✅ |
| HSM PKCS#11 | ❌ | ✅ |
| Seal Wrap | ❌ | ✅ |
Fonctionnalités de gouvernance
Section intitulée « Fonctionnalités de gouvernance »Ce troisième tableau concerne les organisations, pas les machines. La seule ligne qui déclenche réellement des achats de licence est Namespaces : sans elle, isoler plusieurs équipes revient à multiplier les clusters ou à discipliner les préfixes de chemins. Sentinel et Control Groups répondent à des exigences de conformité écrites, jamais à un confort d'exploitation. Notez que les journaux d'audit sont bien en CE : c'est le point que les auditeurs vérifient en premier, et il ne coûte rien.
| Fonctionnalité | CE | Enterprise |
|---|---|---|
| Multi-tenancy | ||
| Namespaces | ❌ | ✅ |
| Policies avancées | ||
| ACL Policies | ✅ | ✅ |
| Sentinel (policy-as-code) | ❌ | ✅ |
| Control Groups | ❌ | ✅ |
| Audit | ||
| Audit logs | ✅ | ✅ |
| Entropy augmentation | ❌ | ✅ |
Analyse des fonctionnalités Enterprise
Section intitulée « Analyse des fonctionnalités Enterprise »Chacune des six sections qui suivent est bâtie de la même façon : ce que fait la fonction, le profil d'organisation qui la justifie vraiment, puis le montage équivalent en CE. Lisez surtout la troisième partie. Dans la plupart des dossiers de décision, ce n'est pas la fonction Enterprise qui manque, c'est le travail d'exploitation que son équivalent CE demande, et ce travail a lui aussi un coût.
Replication DR et Performance
Section intitulée « Replication DR et Performance »La réplication Vault agit au niveau du coffre entier, pas d'un secret : un cluster primaire pousse en continu son journal vers un ou plusieurs clusters secondaires. Le point qui coince en CE n'est pas la disponibilité mais le RPO, c'est-à-dire la quantité de données que vous acceptez de perdre. Avec des snapshots Raft toutes les heures, vous perdez au pire une heure d'écritures ; avec la réplication, la perte se compte en secondes. Chiffrez cette différence avant d'ouvrir une discussion commerciale.
Ce que c'est :
- DR Replication : cluster secondaire en standby pour reprise après sinistre
- Performance Replication : clusters secondaires actifs pour distribuer la charge
Qui en a vraiment besoin :
- Organisations avec SLA très stricts (99.99%+)
- Infrastructures multi-régions avec latence critique
- Exigences réglementaires de DR géographique
Alternatives CE :
- Snapshots Raft réguliers + procédure de restore testée
- Cluster HA single-site (déjà très résilient)
- Architecture multi-cluster indépendants
Namespaces
Section intitulée « Namespaces »Un namespace est un Vault dans le Vault : il possède son propre arbre de montages, ses propres policies et ses propres tokens, et un administrateur de namespace ne voit rien des autres. C'est la fonction Enterprise la plus réclamée, parce que son absence se paie en prolifération de clusters : sans namespaces, chaque équipe autonome finit par exiger son propre cluster Raft à trois nœuds, à sauvegarder et à mettre à jour séparément. Comptez ce coût d'exploitation avant de conclure que CE est gratuit.
Ce que c'est : Isolation complète de tenants au sein d'un même cluster. Chaque namespace a ses propres secrets, auth methods, policies.
Qui en a vraiment besoin :
- Fournisseurs de services managés
- Grandes organisations avec équipes autonomes
- Environnements multi-clients
Alternatives CE :
- Clusters séparés par équipe/environnement
- Préfixes de paths stricts avec policies ACL
- OpenBao : namespaces inclus gratuitement
MFA : Login MFA en CE, Step-up en Enterprise
Section intitulée « MFA : Login MFA en CE, Step-up en Enterprise »C'est le point sur lequel la plupart des comparatifs se trompent, y compris des
pages officielles de revendeurs. Le MFA à la connexion existe bien en
Community Edition, et depuis longtemps : la documentation HashiCorp indique
« Starting with Vault version 1.10, Vault Community Edition provides MFA on login
only », avec les quatre méthodes TOTP, Okta, Duo et PingID. La
configuration passe par les points d'API identity/mfa/method/:type et
identity/mfa/login_enforcement.
Ce que réserve Enterprise, c'est le Step-up MFA : redemander un second
facteur non plus à la connexion, mais au moment d'atteindre un chemin sensible
précis, par exemple pki/root/sign-intermediate. Il se configure via
sys/mfa/method/:type/:name et exige des policies Sentinel. Enterprise ajoute
aussi l'auto-enrôlement TOTP et la déclinaison par namespace.
Qui a vraiment besoin du Step-up :
- Opérations à effet large et irréversible (signature d'une CA racine, rekey)
- Exigence réglementaire de réauthentification par action, pas par session
- Comptes d'administration partagés qu'on ne peut pas supprimer à court terme
Alternatives CE :
- Login MFA natif sur les méthodes locales comme
userpass, sans licence - MFA imposée par l'IdP en amont, pour les connexions OIDC ou LDAP
- Réduction de la durée de vie des tokens, pour forcer une reconnexion fréquente
Ne confondez pas les deux points d'API, c'est la source d'erreur la plus
fréquente : sys/mfa/method/* est l'API Step-up Enterprise, alors que
identity/mfa/method/* est l'API Login MFA de l'édition Community. Sur un
Vault CE, un vault write sys/mfa/method/totp/… renvoie un code 404 tandis
que vault write identity/mfa/method/totp issuer=… period=30 retourne bien un
method_id. Un 404 sur le premier chemin ne signale donc pas un binaire cassé,
seulement une API Enterprise appelée sans licence.
Sentinel (Policy-as-Code)
Section intitulée « Sentinel (Policy-as-Code) »Une policy ACL classique répond à une seule question : ce token a-t-il le droit sur ce chemin ? Sentinel ajoute le contexte de la requête, ce qu'une ACL ne sait pas exprimer : l'heure, l'adresse source, la méthode d'authentification utilisée, ou la valeur d'un paramètre de la requête. Le critère de décision est donc simple à formuler : si vos règles s'écrivent toujours sous la forme « qui accède à quoi », les ACL suffisent ; si elles contiennent un « sauf si » ou un « seulement quand », Sentinel devient pertinent.
Ce que c'est : Langage de policy avancé permettant des règles complexes basées sur l'identité, le temps, les propriétés des requêtes.
Qui en a vraiment besoin :
- Organisations avec compliance stricte
- Besoins de policies contextuelles complexes
- Audit de conformité automatisé
Alternatives CE :
- ACL Policies (couvrent 95% des besoins)
- Validation dans les applications
- Processus d'approbation manuels
Control Groups
Section intitulée « Control Groups »Un Control Group intercepte la lecture d'un secret et la met en attente : le demandeur reçoit un identifiant de requête au lieu de la valeur, et le secret n'est délivré qu'une fois le nombre d'approbations requis atteint. La différence avec une validation par ticket est que le contrôle est appliqué par Vault, pas seulement documenté : personne ne peut le contourner en se connectant directement. C'est précisément cette non-contournabilité que les auditeurs demandent quand ils exigent une séparation des tâches.
Ce que c'est : Requiert plusieurs approbations pour certaines opérations sensibles.
Qui en a vraiment besoin :
- Exigences réglementaires "four eyes principle"
- Opérations financières à haut risque
- Environnements très réglementés (PCI-DSS, SOC2 strict)
Alternatives CE :
- Procédures manuelles documentées
- Workflow d'approbation externe (tickets, chat)
- Root token fragmenté (Shamir) = contrôle multi-personnes
HSM et Seal Wrap
Section intitulée « HSM et Seal Wrap »La distinction entre ces deux fonctions échappe souvent, et elle change tout. Le HSM Seal ne concerne que la clé de descellement : le HSM déchiffre la clé racine au démarrage, puis Vault travaille en mémoire comme d'habitude. Le Seal Wrap va plus loin et fait passer chaque écriture de donnée marquée sensible par le HSM, ce qui coûte un aller-retour matériel à chaque opération et se paie en latence. On n'active le second que si une certification l'impose, jamais par précaution.
Ce que c'est :
- HSM Seal : clé master stockée dans un HSM matériel
- Seal Wrap : chiffrement additionnel des données sensibles par HSM
Qui en a vraiment besoin :
- Exigences FIPS 140-2/140-3 Level 3+
- Secteurs très réglementés (défense, finance critique)
- Protection contre les menaces internes avancées
Alternatives CE :
- Auto-unseal KMS (AWS KMS, GCP KMS, Azure Key Vault)
- Transit seal (autre cluster Vault/OpenBao)
- Shamir avec procédures strictes
Besoins réels vs besoins perçus
Section intitulée « Besoins réels vs besoins perçus »Les deux onglets ci-dessous servent à préparer une réunion d'arbitrage. Le premier recense les arguments entendus qui ne résistent pas à l'examen ; le second, les situations où la licence se justifie sans discussion. La ligne de partage est toujours la même : un besoin Enterprise réel s'appuie sur une contrainte externe vérifiable, une clause de contrat, un référentiel de conformité, un engagement de SLA signé. Un besoin perçu s'appuie sur une intuition de robustesse. Si vous ne pouvez pas citer le document qui impose la fonction, vous êtes dans le premier onglet.
| Besoin perçu | Réalité |
|---|---|
| "On a besoin de DR" | Un cluster HA + snapshots automatisés + procédure testée suffit pour 95% des cas |
| "On veut la MFA" | L'IdP gère souvent déjà la MFA, pas besoin de la dupliquer dans Vault |
| "Il nous faut les namespaces" | Des paths séparés avec policies strictes ou OpenBao peuvent suffire |
| "Enterprise = plus sécurisé" | CE est tout aussi sécurisé, Enterprise ajoute des features opérationnelles |
| Besoin validé | Pourquoi Enterprise |
|---|---|
| Multi-région avec latence critique | Replication Performance réduit la latence |
| SLA 99.99%+ avec DR automatique | DR Replication avec failover automatique |
| Multi-tenant commercial | Namespaces isolent complètement les clients |
| Compliance FIPS 140-2 Level 3 | HSM Seal obligatoire |
| Four-eyes principle réglementaire | Control Groups natifs |
L'option HCP Vault
Section intitulée « L'option HCP Vault »HCP Vault Dedicated (HashiCorp Cloud Platform) est un cluster Vault Enterprise déployé et exploité par HashiCorp dans votre région cloud. La documentation officielle décrit trois paliers : Development, mononœud et explicitement réservé au hors-production ; Essentials, en haute disponibilité ; et Standard, qui ajoute la réplication Performance et Sentinel. Point à retenir avant de lire les deux listes suivantes : les namespaces sont inclus dès le palier Development, ce qui fait d'HCP le chemin le plus court vers cette fonction si vous ne voulez ni licence Enterprise ni OpenBao.
Avantages
Section intitulée « Avantages »Ces avantages tiennent tous à la même chose : c'est HashiCorp qui porte l'astreinte. La ligne la plus sous-estimée est celle des mises à jour : sur un cluster autogéré, la montée de version d'un Raft à trois nœuds est l'opération que les équipes repoussent le plus longtemps, et c'est ainsi qu'on se retrouve avec un Vault non corrigé face à une CVE publiée.
- Pas d'infrastructure à gérer
- Mises à jour automatiques
- Backups intégrés
- Disponible en minutes
- Certaines features Enterprise incluses
Inconvénients
Section intitulée « Inconvénients »Le point à examiner en premier n'est pas la latence mais le couplage : vos clusters Kubernetes, vos runners de CI et vos machines s'authentifient désormais auprès d'un service tiers, et une indisponibilité de celui-ci gèle vos déploiements. Deuxième point, la facturation par client authentifié des paliers Essentials et Standard : un cluster peu coûteux à l'heure peut voir sa note s'envoler dès que chaque pod, chaque runner et chaque machine virtuelle compte pour un client distinct.
- Coût récurrent (facturation à l'heure)
- Latence réseau (pas on-premise)
- Dépendance cloud HashiCorp
- Moins de contrôle sur la configuration
Quand considérer HCP Vault
Section intitulée « Quand considérer HCP Vault »Le tableau ci-dessous se lit par la contrainte la plus rigide de votre contexte, pas par la moyenne. Une seule ligne rouge, typiquement la souveraineté des données ou une obligation d'hébergement sur site, disqualifie l'option quels que soient les autres avantages. La ligne « équipe ops expérimentée » est la seule qui demande un vrai calcul : comparez le coût annuel HCP au temps réellement passé par vos équipes sur l'exploitation de Vault, astreinte et montées de version comprises.
| Situation | HCP Vault pertinent ? |
|---|---|
| Startup sans équipe infra | ✅ Oui |
| POC/prototype rapide | ✅ Oui |
| Infrastructure critique on-premise | ❌ Non |
| Équipe ops expérimentée | ⚠️ À évaluer (coût vs temps) |
| Contraintes de souveraineté | ❌ Non |
Grille de décision finale
Section intitulée « Grille de décision finale »Les quatre listes suivantes ne sont pas exclusives et ne se lisent pas dans l'ordre. Traitez-les comme des critères d'entrée : commencez par la liste Enterprise, car c'est la seule dont les critères sont imposés de l'extérieur et donc non négociables. Si aucun ne s'applique à vous, redescendez vers CE, OpenBao ou HCP selon la ressource qui vous manque le plus, du temps d'équipe ou du budget de licence.
Commencez par CE si...
Section intitulée « Commencez par CE si... »Ces critères décrivent une organisation dont les contraintes restent internes : vous choisissez votre niveau de service au lieu de le subir. Le dernier point est le plus discriminant, et c'est aussi celui que les équipes formulent le moins souvent à voix haute. Posez la question à l'envers pour y répondre honnêtement : combien coûte une demi-heure d'indisponibilité de vos déploiements et de vos rotations de secrets ?
- C'est votre premier Vault
- Vous êtes une équipe de moins de 50 personnes
- Vous n'avez pas d'exigences réglementaires strictes
- Votre infrastructure est mono-région
- Vous pouvez tolérer 15-30 min de downtime en cas de sinistre
Considérez Enterprise si...
Section intitulée « Considérez Enterprise si... »À l'inverse de la liste précédente, chacun de ces critères doit pouvoir s'adosser à un document opposable : un contrat client, un référentiel de conformité, un engagement de niveau de service signé. C'est ce document, et non l'appréciation d'une équipe, qui justifiera la dépense devant une direction financière. Un seul critère rempli suffit à ouvrir le dossier ; les quatre autres ne le renforcent pas davantage.
- Multi-région avec SLA 99.99%+
- Compliance FIPS, PCI-DSS strict, SOC2 Type II
- Business multi-tenant (namespaces obligatoires)
- Four-eyes principle réglementaire
- Budget IT conséquent
Considérez OpenBao si...
Section intitulée « Considérez OpenBao si... »OpenBao est le fork de Vault porté par la Linux Foundation, sous licence MPL 2.0. Le premier critère est le plus concret : les namespaces y sont intégrés depuis la version 2.3.0, publiée le 25 juin 2025, avec une API annoncée comme compatible avec celle de l'implémentation amont. Les deux autres critères relèvent de la stratégie, pas de la fonctionnalité, et méritent d'être tranchés au niveau de la direction technique plutôt que dans un comparatif de tableaux.
- Besoin de namespaces sans budget Enterprise
- Politique open source OSI stricte
- Indépendance vis-à-vis d'HashiCorp/IBM
Considérez HCP Vault si...
Section intitulée « Considérez HCP Vault si... »Le dénominateur commun de ces quatre situations n'est pas le budget mais la rareté du temps d'exploitation. HCP achète du temps d'équipe, pas de la sécurité : un cluster managé mal cloisonné reste mal cloisonné. Gardez aussi en tête que le palier Development est explicitement hors production dans la documentation HashiCorp, ce qui en fait un bon support de maquette mais interdit de le laisser glisser vers un usage réel.
- Pas d'équipe ops dédiée
- POC rapide nécessaire
- Startup early-stage
- Budget temps limité
Estimation des coûts
Section intitulée « Estimation des coûts »Le tableau ci-dessous compare quatre postes, et c'est la colonne Coût humain qui décide dans la pratique. Les trois solutions autogérées y sont à égalité sur le papier, mais la charge réelle dépend surtout du nombre de clusters que vous finirez par exploiter : sans namespaces, l'isolation par équipe se paie en clusters supplémentaires, donc en sauvegardes, en montées de version et en astreintes multipliées. Traitez les montants indiqués comme des ordres de grandeur à confirmer, HashiCorp ne publiant pas de tarif Enterprise et les tarifs HCP évoluant par palier.
| Solution | Coût infrastructure | Coût licence | Coût humain |
|---|---|---|---|
| Vault CE | Serveurs/cloud | 0 € | Ops interne |
| Vault Enterprise | Serveurs/cloud | $$$ (contact commercial) | Ops interne |
| HCP Vault | 0 € | ~$0.50-1.50/h (selon tier) | Minimal |
| OpenBao | Serveurs/cloud | 0 € | Ops interne |
Parcours de migration CE → Enterprise
Section intitulée « Parcours de migration CE → Enterprise »Bonne nouvelle pour ceux qui hésitent à s'engager : commencer en CE ne vous enferme pas. Les données restent dans le même stockage Raft et l'API ne change pas, donc vos applications, vos policies et vos rôles AppRole survivent à la bascule sans modification. Le travail se concentre sur le remplacement du binaire et l'activation de la licence.
- Bascule du binaire : remplacer la version CE par une variante
+entde la même version de Vault, nœud par nœud - Ajout de licence : déposer le fichier de licence, puis vérifier avec
vault read sys/license/status - Configuration additionnelle : namespaces, réplication, Sentinel
Deux réserves pour ne pas se croire à l'abri. La bascule reste une montée de version d'un cluster stateful : snapshot Raft avant de commencer, restauration testée, et fenêtre de maintenance. Surtout, le chemin inverse n'existe pas proprement : une fois que vous avez créé des namespaces ou activé la réplication, revenir en CE impose de démonter cette organisation. Ne franchissez ce pas que pour un besoin identifié.
À retenir
Section intitulée « À retenir »- CE couvre 90% des besoins : ne présumez pas que vous avez besoin d'Enterprise
- Namespaces : le besoin le plus courant, inclus dans OpenBao depuis la 2.3.0
- Replication : évaluez votre RPO réel, pas votre confort
- MFA : le Login MFA est en CE depuis Vault 1.10 ; seul le Step-up MFA par requête est Enterprise
- HSM et Seal Wrap : uniquement pour une exigence FIPS écrite
- HCP Vault Dedicated : trois paliers, namespaces inclus, mais facturation par client authentifié
- Binaires distincts : Enterprise se distribue en variantes
+ent, la bascule n'est pas qu'un fichier de licence