Accès délégué
Faites appel à un développeur, confiez la facturation à votre comptable, donnez à un client un accès en lecture seule à ses propres sites ou permettez à notre équipe d’assistance d’examiner un problème. Chaque attribution est un rôle doté d’autorisations définies, circonscrit à une organisation, appliqué dans la base de données et consigné dans un journal d’audit en ajout seul.
Partager un identifiant unique est la cause des problèmes d’accès aux comptes. Sur Zinn Digital®, chaque personne dispose de sa propre identité, et l’accès est une adhésion — un utilisateur, une organisation et un rôle — que vous pouvez accorder, modifier ou révoquer de manière indépendante.
Chaque collaborateur se connecte sous sa propre identité via Keycloak, notre couche de gestion des identités. Personne ne saisit votre mot de passe, personne ne partage de session de navigation, et supprimer quelqu’un se fait en une seule action plutôt que par une rotation de mot de passe et une course pour savoir qui d’autre le connaissait.
Les comptes sont hiérarchiques — une organisation de revendeur contient des organisations de clients, et les organisations de clients contiennent des sites. Une adhésion s’applique à une organisation et à tout ce qui se trouve en dessous, ce qui vous permet de donner à un client d’agence le contrôle de sa propre organisation sans jamais divulguer vos autres clients.
La séparation des locataires n’est pas un simple filtre dans le code applicatif qu’un bogue pourrait ignorer. La sécurité au niveau des lignes (Row-Level Security) de Postgres limite chaque requête au sous-arbre de l’organisation de l’appelant, de sorte qu’une requête en dehors de votre périmètre n’a rien à renvoyer.
Si vous demandez une organisation ou un site hors de votre périmètre, l’API renvoie une simple erreur « introuvable » plutôt qu’une erreur d’autorisation. Une erreur d’autorisation confirmerait l’existence de l’enregistrement ; « introuvable » n’indique absolument rien à une personne externe.
Les autorisations sont des clés granulaires — module plus action, comme sites.restart ou billing.refund — et les rôles les regroupent. Quatre rôles couvrent les structures dont les équipes réelles ont besoin, et chacun constitue des données que nous injectons, et non une logique enfouie dans le code.
Contrôle total : créez des organisations enfants, invitez et supprimez des membres, modifiez les rôles, gérez les clés d’API, créez, redémarrez, purgez, suspendez et supprimez des sites, gérez la facturation et les factures, ouvrez des tickets et consultez le journal d’audit. Le rôle que vous conservez pour vous-même.
Voit l’organisation, ses membres et le catalogue des forfaits, et gère les factures, les moyens de paiement et les frais. Aucun accès pour créer, modifier ou supprimer le moindre site — exactement le profil que devrait avoir un comptable externe.
Consulte et crée des sites, redémarre les services, vide le cache, gère les clés d’API et traite les tickets. Délibérément exclus : la facturation, les factures, les moyens de paiement, la gestion des membres, la suspension de sites et la suppression de sites. Un prestataire peut développer sans pouvoir vous facturer ni détruire quoi que ce soit.
Consulte l’organisation, ses membres, ses sites, sa facturation, le catalogue des forfaits, les tickets, l’état de la traduction et le journal d’audit — et ne peut rien modifier. L’autorisation idéale pour un client souhaitant de la visibilité, un auditeur ou une partie prenante qui a uniquement besoin de consulter.
Déléguer l’accès n’est sécurisé que si les comptes auxquels vous le déléguez sont difficiles à pirater. L’authentification s’effectue via Keycloak pour chaque personne du compte, sur chaque interface.
Le travail d’assistance implique parfois d’examiner l’intérieur de votre compte. Cet accès est régi par le même modèle d’autorisations que tout le reste : le personnel fait simplement partie d’une organisation interne, structurée en départements disposant d’autorisations restreintes.
Le personnel est réparti entre les équipes Support, Facturation et Finances, Abus et Confiance et Sécurité, Ventes, Intégration, Ingénierie et Opérations, Marketing et Direction. Chaque rôle accorde des modules et des actions spécifiques, de sorte qu’un agent ne voit que la partie de la console d’administration requise par son travail, et non le reste.
Le rôle d’agent d’assistance accorde exactement ceci : afficher les clients, afficher les tickets et y répondre, afficher les sites, redémarrer un site et purger son cache. Il ne comporte aucune configuration de facturation, aucun remboursement, aucune modification de forfait et aucune gestion de parc. Les mesures correctives qu’un agent peut effectuer sont limitées par son rôle, et non par ses bonnes intentions.
L’autorisation customer.impersonate ne fait pas partie du rôle Manager — elle est détenue uniquement par Super Admin. Lorsqu’une session est exécutée en votre nom, le tableau de bord affiche une bannière d’emprunt d’identité persistante afin qu’il n’y ait jamais d’ambiguïté sur l’auteur de l’action.
Chaque action privilégiée et administrative est ajoutée à un journal d’audit en ajout seul qui consigne l’auteur, l’action, la cible, les métadonnées associées, l’adresse IP et l’horodatage — partitionné dans le temps en production. Les propriétaires et les membres en lecture seule peuvent consulter eux-mêmes le journal de leur organisation.
Les actions sensibles et destructrices du personnel peuvent nécessiter une authentification renforcée ou l’approbation de deux personnes avant d’être exécutées, et les nouveaux services ainsi que les nouveaux rôles relèvent de la configuration plutôt que d’une modification du code.
Les scripts, les pipelines CI, la CLI, le fournisseur Terraform et les agents IA s’authentifient tous via le même modèle d’autorisation que les personnes — aucun identifiant humain partagé, aucun secret à longue durée de vie collé dans un build.
Les clés appartiennent à une organisation et comportent des portées granulaires liées aux mêmes autorisations RBAC — lecture seule, facturation, provisionnement. Accordez à un pipeline la portée restreinte dont il a besoin plutôt que l’ensemble du compte d’un membre.
Les clés du mode test et du mode réel sont distinctes, de sorte qu’une intégration en cours de développement ne peut pas accéder aux données de production par accident ou par une variable d’environnement copiée.
Nous stockons un hachage SHA-256 du secret et un préfixe de recherche — jamais la clé brute. Vous ne voyez la clé qu’une seule fois, lors de sa création. Chaque clé enregistre la date de sa dernière utilisation et peut être révoquée indépendamment sans affecter le reste.
Notre serveur MCP permet à tout agent compatible MCP de gérer votre hébergement en langage naturel, avec une authentification OAuth 2.1 et une portée limitée à votre organisation et à votre rôle RBAC, des jetons révocables par outil, une confirmation pour les actions destructives, des limites de dépenses et une journalisation d’audit complète.
L’accès au compte et l’accès au serveur sont des problématiques différentes. Les identifiants au niveau du site sont gérés dans le tableau de bord, délivrés avec le moindre privilège et confinés afin que le shell d’un collaborateur soit strictement celui d’un seul site.
Un opérateur individuel conserve une seule organisation et une seule adhésion de propriétaire, et ajoute un rôle de Développeur lorsqu’un prestataire intervient sur un projet. Lorsque le projet prend fin, l’adhésion est supprimée et sa connexion cesse immédiatement de fonctionner — il ne reste aucun identifiant partagé à renouveler.
Une agence utilise l’arborescence de l’organisation. Chaque client dispose de sa propre organisation enfant, qui héberge ses sites, et les collaborateurs du client y obtiennent des adhésions — en lecture seule pour une partie prenante souhaitant de la visibilité, propriétaire pour un client souhaitant être autonome. Vos collaborateurs détiennent des adhésions plus haut dans l’arborescence et visualisent le portefeuille ; un client ne voit que sa propre branche, et Row-Level Security permet d’en faire une réalité plutôt qu’une promesse.
Un revendeur fonctionne de la même manière, un niveau plus haut : une organisation de revendeur regroupe des organisations de clients, chacune disposant de ses propres membres, de sa vue de facturation et de ses sites. Le même élément fondamental gère les sous-comptes, les équipes d’agences et les hiérarchies de revendeurs — il n’existe aucun mécanisme distinct et moins performant pour l’un d’entre eux.
Tout est accessible pendant l’essai de 14 jours sans carte bancaire. Inscrivez-vous sans coordonnées de paiement, invitez un collègue, observez ce à quoi chaque rôle a accès ou non, et consultez votre propre journal d’audit.
Actuellement, une adhésion attribue son rôle à l’ensemble d’une organisation et à tous les éléments situés sous elle dans l’arborescence. Par conséquent, pour séparer des ensembles de sites, il convient de séparer les organisations : placez ces sites dans leur propre organisation enfant et attribuez-y l’adhésion. Il s’agit d’un modèle clair pour les agences et les revendeurs, où chaque client souhaite déjà disposer de son propre périmètre. La définition de la portée des ressources par adhésion, consistant à associer une adhésion unique à des sites désignés au sein d’une même organisation, est une amélioration planifiée et n’est pas disponible pour le moment.
Le rôle Developer n’inclut pas la suppression ou la suspension de sites — ces prérogatives appartiennent au rôle Owner. Il permet d’afficher et de créer des sites, de redémarrer des services, de purger le cache, de gérer les clés API et de traiter les tickets. Les autorisations de déploiement et de push-to-live ne font pas non plus partie des attributions du rôle Developer, la mise en production reste donc du ressort du propriétaire du compte. Associez cela à un environnement de staging afin que les travaux de développement s’effectuent d’emblée en dehors du site en ligne.
Cela dépend entièrement du rôle du collaborateur, chaque rôle correspondant à un ensemble restreint de clés d’autorisation. Un agent du support peut, par exemple, consulter votre compte et vos sites, consulter vos tickets et y répondre, redémarrer un site et vider son cache — sans pouvoir toucher à la configuration de la facturation, aux remboursements, aux forfaits ou au parc. La connexion en tant que client est une autorisation distincte réservée au Super Admin, et lorsqu’elle a lieu, le tableau de bord affiche une bannière d’usurpation persistante. Chaque action privilégiée est consignée dans le journal d’audit avec l’auteur, l’action, la cible, l’adresse IP et l’horodatage, et vous pouvez consulter vous-même le journal de votre organisation.
Supprimez l’adhésion et leur accès à cette organisation prend fin — ils conservent leur propre identité, mais n’ont plus aucun rôle et donc aucune autorisation sur votre compte. Les clés API sont révoquées individuellement, ce qui permet de supprimer une clé de pipeline sans perturber le reste. Si vous utilisez l’authentification unique SAML, le déprovisionnement auprès de votre fournisseur d’identité gère les connexions de manière centralisée. Les identifiants au niveau du site, tels que les clés SSH, sont révoqués dans le tableau de bord, et la suppression elle-même est consignée dans le journal d’audit.
Non — mais il convient d’en préciser la raison. Les clés API appartiennent à l’organisation et non à un membre individuel, et elles disposent de leurs propres portées granulaires liées au même catalogue d’autorisations. Ainsi, plutôt que de confier une clé à une personne, vous créez une clé pour la tâche à accomplir avec la portée la plus restreinte nécessaire, puis vous révoquez cette clé une fois la tâche terminée. Seul un hachage du secret est conservé, et chaque clé enregistre la date de sa dernière utilisation, ce qui permet d’identifier et de désactiver facilement les clés inutilisées.
Oui. Notre serveur MCP authentifie les agents avec OAuth 2.1 et limite leur portée à votre organisation et à votre rôle RBAC, avec des jetons révocables par outil, de sorte que vous accordez une capacité spécifique plutôt qu’un accès général. Les actions destructrices nécessitent une confirmation, des plafonds de dépenses s’appliquent et chaque action est consignée dans le même journal d’audit que l’activité humaine.
La sécurité au niveau des lignes de Postgres limite les requêtes au sous-arbre de l’organisation de l’appelant au sein même de la base de données, le filtre au niveau de l’application servant de défense en profondeur plutôt que d’unique ligne. Les requêtes pour des enregistrements hors de portée renvoient une erreur « introuvable » plutôt qu’une erreur de permission, afin de ne rien révéler sur ce qui existe. Côté serveur, l’isolation par site via CageFS confine le shell et les fichiers de chaque locataire à son propre site.
Oui. L’essai de 14 jours s’effectue sans carte — sans coordonnées de paiement ni engagement — et inclut l’hébergement Footprint-Free pour un maximum de cinq sites. C’est suffisant pour inviter un collègue, lui attribuer un rôle et confirmer que le cloisonnement répond à vos attentes avant de vous engager.
Commencez votre essai de 14 jours sans carte bancaire, invitez un utilisateur et observez le modèle de permissions faire son travail — des rôles que vous pouvez nommer, des périmètres que vous pouvez révoquer, et un journal d’audit indiquant exactement qui a fait quoi.
Commencer gratuitement