Une fois qu'une équipe admet qu'elle a besoin d'une intégrité des enregistrements vérifiable de façon indépendante, la question suivante est opérationnelle, non cryptographique : l'exécutons-nous nous-mêmes ou le fait-on exécuter pour nous ? Les deux modèles produisent la même preuve — une racine de Merkle ancrée à une chaîne publique que quiconque peut vérifier. Ce qui diffère : qui détient les clés, où résident les données et qui porte le bipeur. Ce guide expose les arbitrages pour que vous arriviez à la discussion d'achat en sachant déjà quel modèle convient.
Les deux modèles en un paragraphe chacun
Auto-hébergé signifie que la plateforme d'intégrité s'exécute dans votre propre infrastructure — votre cluster Kubernetes, votre compte cloud ou centre de données, votre service de gestion de clés. Vous l'exploitez ; le fournisseur licencie le logiciel et vous accompagne. Géré signifie que le fournisseur exploite la plateforme comme une instance dédiée mono-locataire sur son infrastructure, et vous intégrez via une API. Dans les deux cas, la cible d'ancrage est la même chaîne publique, et les preuves sont vérifiables par des tiers quel que soit le modèle.
L'intuition selon laquelle l'auto-hébergé est « plus sûr » et le géré « plus simple » est trop grossière pour décider. La vraie décision tient à quatre axes concrets, et pour la plupart des organisations, un ou deux d'entre eux dominent.
Les quatre axes qui décident vraiment
Évaluez votre situation sur chacun. Si l'un est une contrainte ferme, il tranche généralement la question à lui seul :
- Résidence des données — si une réglementation ou un contrat exige que les données d'enregistrement ne quittent jamais votre environnement ou une juridiction précise, l'auto-hébergé élimine la question. Le géré peut souvent satisfaire la résidence via des instances dédiées régionales, mais cela devient une clause à négocier plutôt qu'un fait architectural.
- Garde des clés — qui détient la clé de signature est la véritable frontière de sécurité. L'auto-hébergé la garde dans votre KMS sous votre IAM. Le géré la conserve dans un KMS isolé mono-locataire en votre nom. Si « nous devons être la seule partie à pouvoir détenir la clé » est non négociable, cela pointe vers l'auto-hébergé.
- Capacité opérationnelle — l'auto-hébergé implique d'exploiter un signataire en haute disponibilité, de gérer la rotation des clés et d'épingler les paquets de preuve. Sans équipe plateforme disposant de capacité, le géré transforme ces obligations en SLA d'un tiers.
Ce que reflète la différence de prix
Les deux modèles sont tarifés différemment parce que la structure de coûts diffère, non parce que l'un est une remise sur l'autre. Le géré inclut l'infrastructure, la disponibilité et la main-d'œuvre opérationnelle. L'auto-hébergé est une licence sur un logiciel que vous exécutez sur du matériel déjà payé.
L'auto-hébergé affiche un prix catalogue plus élevé précisément parce qu'il n'inclut pas l'exploitation que vous assumez vous-même — et parce que les acheteurs qui l'exigent sont généralement ceux aux mandats de résidence et de garde les plus stricts. Si votre moteur est purement le coût, le géré est presque toujours le plus faible coût total de possession une fois votre propre main-d'œuvre opérationnelle honnêtement chiffrée.
Comment la décision s'enchaîne en pratique
Pour la plupart des équipes, le chemin est court. Parcourez les axes dans l'ordre et arrêtez-vous à la première contrainte ferme :
Une banque régulée avec une politique « les données restent dans notre tenant » aboutit à l'auto-hébergé avant même que le coût n'entre en jeu. Une scale-up de santé qui veut la garantie d'intégrité sans monter un nouveau service HA aboutit au géré et négocie un BAA. La plupart des organisations sont l'un de ces deux cas ; les cas intermédiaires sont ceux où une vraie conversation aide.
Quel profil convient à quel modèle
À titre de carte approximative — pas une règle — les profils régulés tendent à se regrouper :
- L'auto-hébergé convient à — grandes banques, secteur public et toute entité aux mandats absolus de résidence ou de garde exclusive des clés, dotée d'une équipe plateforme compétente.
- Le géré convient à — scale-ups fintech et santé, équipes d'audit et de conformité, et quiconque veut la garantie sans exploiter un nouveau service avec état.
- L'un ou l'autre convient à — entreprises du mid-market aux exigences modérées — ici la décision est vraiment une question de coût et de préférence, et un pilote la tranche le plus vite.
Apportez la réponse, pas la question
Comme les deux modèles sont sur devis, la conversation la plus rapide est celle où vous connaissez déjà vos contraintes de résidence et de garde des clés ainsi que votre capacité opérationnelle. Avec ces trois réponses en main, le modèle de déploiement est généralement évident en une phrase, et il reste à discuter du volume et du calendrier, non de l'architecture. Si vous hésitez vraiment, un pilote cadré sur l'instance gérée est le moyen le moins cher d'apprendre ce dont vous avez réellement besoin avant de vous engager à l'exploiter vous-même.
Les deux modèles produisent la même preuve. La décision n'est pas cryptographique — elle porte sur qui détient la clé, où résident les données et qui porte le bipeur.