Équipes et accès

Donnez à chaque personne de votre équipe exactement l'accès dont elle a besoin

Quatre rôles clients, des sous-comptes qui reflètent la structure réelle de votre entreprise, des clés API par organisation, une authentification unique et un journal d'audit pour chaque action privilégiée. Le même modèle d'accès s'applique au tableau de bord, à l'API, à la CLI, à Terraform et à notre serveur MCP. Disponibilité : le fournisseur Terraform est en cours de développement actif et n'est pas encore disponible. Tout le reste est d'ores et déjà opérationnel.

  • 650 000+sites hébergés dans le monde entier
  • 4rôles clients, initialisés et prêts
  • 35clés de permissions granulaires
  • 14 joursessai gratuit de la carte

Quatre rôles, définis là où le travail se divise réellement

L'accès n'est pas un simple interrupteur marche/arrêt. Chaque organisation cliente dispose de quatre rôles, chacun étant un ensemble fixe d'autorisations granulaires module.action : ainsi, un contact financier ne touche jamais à un serveur et un développeur ne voit jamais de facture.

Propriétaire

Contrôle total de l'organisation et de ses sous-comptes : création d'organisations enfants, invitation et suppression de membres, modification des rôles, gestion des clés API, provisionnement, redémarrage, suspension et suppression de sites, gestion des factures et des moyens de paiement, ainsi que consultation du journal d'audit. Deux éléments en sont délibérément exclus : la fermeture d'une organisation et l'émission de remboursements relèvent du personnel et non d'un rôle client.

Gestionnaire de facturation

Tout ce qui concerne les finances et rien d'autre : factures, abonnements, modes de paiement et catalogue des offres, ainsi qu'une vue de l'organisation et de la liste des membres. Aucun accès au site — un responsable financier ou un comptable externe ne peut rien redémarrer, suspendre ou supprimer.

Développeur

Travaillez sur les sites sans toucher à l'argent : visualisez et configurez des sites, redémarrez des services, videz les caches, gérez les clés API, et créez ou répondez à des tickets de support. Pas de vue sur la facturation, pas de gestion des membres, pas de suspension et pas de suppression — les actions destructrices et commerciales restent réservées au propriétaire.

Lecture seule

Une vue complète sans possibilité de modifier quoi que ce soit : membres, sites, facturation, abonnements, tickets, statut de traduction et journal d'audit. Le rôle idéal pour un client partie prenante, un auditeur interne ou un nouveau collaborateur qui prend ses marques.

Sous-comptes qui correspondent à votre structure réelle

La gestion des comptes est une arborescence, et non une liste plate. Une organisation de revendeur se situe au-dessus de ses organisations clientes, et les sites se trouvent en dessous. Un membre d'équipe est une adhésion — un utilisateur, une organisation, un rôle —, de sorte que la même primitive alimente une équipe de deux personnes, une agence gérant une centaine de comptes clients et un revendeur gérant des sous-comptes sous sa propre marque.

Les rôles sont attribués par organisation, et leur application s'effectue également par organisation. Un rôle dans une organisation ne donne aucun accès dans une autre organisation distincte et sans lien : un prestataire peut être Développeur sur le compte d'un client et en Lecture seule sur un second, à partir du même identifiant. Cependant, l'accès se propage vers le bas dans votre propre hiérarchie : un rôle dans une organisation parente s'applique aux organisations qui y sont imbriquées, ce qui permet aux revendeurs et aux agences de gérer leurs clients.

L'isolation est garantie au niveau de la base de données, et pas seulement dans le code de l'application. La sécurité au niveau des lignes de Postgres limite chaque requête de locataire au sous-arbre de l'appelant, et tout élément situé en dehors de ce sous-arbre renvoie un résultat introuvable plutôt qu'une erreur de permission — de sorte que la plateforme ne confirme jamais l'existence de l'organisation ou du site d'un autre locataire.

Les mêmes autorisations sur toutes les surfaces

Les rôles ne sont pas de simples raccourcis d'interface. Chaque point d'accès à la plateforme repose sur les mêmes clés de permission, garantissant qu'aucune porte dérobée ne contourne vos règles d'accès.

Tableau de bord

Sites, facturation, tickets, avis, notifications, clés API et gestion d'équipe dans un même environnement. L'interface affiche uniquement ce que le rôle du membre connecté autorise, afin de masquer les commandes inutilisables.

API publique et CLI

L'API publiée est le même moteur d'API que celui utilisé par le tableau de bord. Les clés d'API sont émises par organisation avec des portées granulaires liées aux autorisations RBAC, et des modes bac à sable et production séparés vous permettent de tester les intégrations sans toucher à la facturation ou au provisionnement réels.

Fournisseur Terraform

Gérez les sites, les domaines, le DNS, les boîtes aux lettres et les abonnements sous forme d'infrastructure en tant que code et exécutez terraform apply pour provisionner l'hébergement, le tout régi par les mêmes portées que le reste.

Serveur MCP

Connectez Claude Code, Cursor, ChatGPT, Claude Desktop ou tout autre outil compatible MCP. Les jetons sont limités à une organisation et à ses autorisations RBAC, révocables par outil, avec confirmation des actions destructrices, plafonds de dépenses et piste d'audit complète.

Gestion des clés

Seul un hachage de chaque clé d'API est stocké, et jamais la clé brute. Les clés comportent un nom et un préfixe visible pour vous permettre de les différencier, d'enregistrer leur dernière utilisation et de les révoquer individuellement sans perturber le reste.

Une seule connexion, basée sur des standards, pour tout

L'identité repose sur Keycloak, ce qui garantit une authentification native en OIDC et SAML plutôt qu'un formulaire de connexion personnalisé rattaché à un panneau d'hébergement.

  • Connexion par e-mail avec lien magique par défaut, avec l'e-mail et le mot de passe en solution de repli pour les utilisateurs qui le préfèrent.
  • Passkeys et WebAuthn pour une connexion résistante au phishing, plus une authentification à deux facteurs TOTP imposée à tous par la politique de sécurité.
  • Connexion sociale via Google, Microsoft, GitHub et d'autres fournisseurs d'identité.
  • Connexion unique SAML pour les clients entreprises et agences, afin que l'accès de l'équipe suive votre répertoire existant.
  • Une seule session sur le tableau de bord, la console d'administration, le site public, la base de connaissances et les tickets de support : connectez-vous une seule fois, et non cinq.
  • Chaque e-mail d'inscription est validé avant qu'un compte ne soit créé, de sorte que les adresses non distribuables et invalides n'atteignent jamais votre équipe.
  • Puisqu'il repose sur des standards, le fournisseur d'identité lui-même peut être remplacé sans avoir à réarchitecturer quoi que ce soit autour — la même règle de non-enfermement que nous appliquons à tous les autres fournisseurs.

De la responsabilité que vous pouvez confier à un auditeur

Chaque action privilégiée génère un enregistrement d'audit non modifiable : qui l'a effectuée, ce qui a été fait, sur quoi, les éléments justificatifs et l'adresse IP d'origine. Le journal est non modifiable — les événements sont ajoutés et ne peuvent pas être modifiés sur place — et en production, il est partitionné par temps pour rester rapide à mesure qu'il grandit.

La lecture de ce journal constitue en soi une autorisation. Les propriétaires et les membres en lecture seule y ont accès, de sorte que le responsable du compte et la personne qui l'audite peuvent tous deux consulter l'historique complet sans avoir besoin de privilèges élevés pour le faire.

Autour de cela se trouvent les contrôles que demandent les grandes équipes : politiques de session, listes d'autorisations IP facultatives par organisation, et authentification renforcée sur les actions sensibles pour qu'une session active ne suffise pas à elle seule à commettre un acte critique.

Comment les autorisations évoluent avec vous

Le catalogue des autorisations est constitué de données, et non de logique figée dans le code — c'est pourquoi il peut être étendu sans avoir à repenser l'architecture de la plateforme.

  • 35 clés module.action granulaires aujourd'hui, couvrant les organisations, les membres, les clés API, les sites, la facturation, les abonnements, le parc, les tickets, les clients, les abus, les campagnes, les traductions et l'audit.
  • Le catalogue est alimenté de manière idempotente à chaque déploiement, et la validation échoue bruyamment si un rôle référence une permission qui n'existe pas — une faute de frappe ne peut pas accorder silencieusement le néant.
  • Les nouvelles fonctionnalités de produits ajoutent leurs clés de permission au catalogue avant le déploiement de l'endpoint, de sorte que le contrôle d'accès n'est jamais ajouté rétroactivement après la mise en service d'une fonctionnalité.
  • Restreindre un abonnement unique à des sites spécifiques ou à une région précise est une amélioration planifiée, et non une fonctionnalité disponible dès aujourd'hui. Le schéma actuel consiste à placer ces sites dans une organisation enfant et à y attribuer un rôle à la personne, ce qui permet d'obtenir la même séparation grâce à l'arborescence des tenants.
  • Les clés d'API sont émises au niveau de l'organisation plutôt que par personne ; traitez-les donc comme des identifiants de service pour les intégrations et utilisez les adhésions pour l'accès humain.

FAQ

Que peut réellement faire chaque rôle ?

Le Propriétaire a le contrôle total de l'organisation et de ses sous-comptes, y compris les membres, les clés API, les sites et les moyens de paiement. Le Gestionnaire de facturation voit les factures, les abonnements, les moyens de paiement et les forfaits, sans accès aux sites. Le Développeur gère les sites et les clés API et traite les tickets, sans contrôle de la facturation ni des membres. L'utilisateur en lecture seule peut consulter les membres, les sites, la facturation, les forfaits, les tickets et le journal d'audit sans rien modifier.

Puis-je donner à quelqu'un l'accès à un seul site ?

Pas encore disponible en tant que paramètre par site — restreindre un abonnement unique à des sites spécifiques est une amélioration prévue. Aujourd'hui, vous obtenez la même séparation avec l'arborescence des locataires : placez ces sites dans une organisation enfant et attribuez-y un rôle à la personne. Les rôles étant accordés par organisation, cet accès ne s'étend pas au reste de votre compte.

Les clés API sont-elles associées à des membres d'équipe individuels ?

Non — les clés API sont émises par organisation, avec des portées granulaires liées aux mêmes autorisations RBAC, et des modes bac à sable et production distincts. Utilisez-les comme identifiants de service pour les intégrations, l'intégration continue ou Terraform, et utilisez les adhésions pour les personnes. Seul un hachage de chaque clé est stocké, chaque clé enregistre sa dernière utilisation et toute clé peut être révoquée individuellement.

Un développeur peut-il envoyer des modifications vers un site en direct ?

Le rôle de développeur couvre la consultation et le provisionnement de sites, le redémarrage de services, le vidage des caches, la gestion des clés API et le traitement des tickets. Il ne confère pas de droits de publication sur un site en direct. Par conséquent, si vous souhaitez qu'une personne puisse promouvoir des modifications, cet accès doit être confié à un propriétaire. Les rôles sont attribués par organisation, ce qui vous permet d'en détenir un différent sur un autre compte.

Prenez-vous en charge l'authentification unique (SSO) pour l'annuaire de notre entreprise ?

Oui. L'identité fonctionne avec Keycloak et OIDC ainsi que SAML, de sorte que l'authentification unique (SSO) SAML est disponible pour les clients des offres entreprise et agence, aux côtés de la connexion par lien magique (magic-link), de l'e-mail et du mot de passe, des fournisseurs sociaux, des passkeys et de l'authentification à deux facteurs TOTP, qui est imposée par la politique de sécurité. Une seule session couvre le tableau de bord, le site public, la base de connaissances et les tickets de support.

Comment puis-je savoir qui a modifié quelque chose ?

Chaque action privilégiée est consignée dans un journal d'audit non modifiable qui enregistre l'auteur, l'action, la cible, les éléments justificatifs et l'adresse IP. Sa consultation constitue une autorisation à part entière, détenue à la fois par les rôles Propriétaire et Lecture seule, permettant ainsi au propriétaire d'un compte et à un auditeur de consulter le même historique.

L'ajout de membres à l'équipe modifie-t-il mon tarif ?

Les plans sont tarifés en fonction de la capacité d'hébergement plutôt que par nombre d'utilisateurs. Sur la gamme Footprint-Free, par exemple, les 42 niveaux partagent exactement le même ensemble de droits et ne diffèrent que par le nombre de sites qu'ils autorisent. La tarification est toujours affichée à partir du catalogue en direct, dans votre devise, de sorte que ce que vous voyez sur la page des tarifs correspond exactement au montant facturé.

Puis-je essayer ceci avant de m'engager ?

Oui. L'essai Footprint-Free dure 14 jours, ne nécessite aucune carte bancaire et couvre jusqu'à 5 sites, ce qui vous permet de configurer votre organisation, d'inviter votre équipe et de tester les rôles sur des cas réels avant de payer quoi que ce soit. Une garantie de remboursement de 30 jours s'applique aux abonnements payants.

Configurez votre équipe en quelques minutes, pas en quelques tickets

Commencez un essai de 14 jours sans carte sur la ligne Footprint-Free, invitez votre équipe et testez les rôles sur de vrais sites avant de payer quoi que ce soit.

Commencer gratuitement