Rôles et sécurité
FortressFlag est livré avec quatre rôles et un ensemble de protections de la production conçus autour d’une idée : aller vite hors production doit être sans effort, et changer la production doit demander soit le bon rôle, soit une seconde personne.
Les quatre rôles
Section intitulée « Les quatre rôles »| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| Voir les flags et l’équipe | ✓ | ✓ | ✓ | ✓ |
| Modifier les environnements hors production | ✓ | ✓ | ✓ | |
| Proposer et approuver des changements en production | ✓ | ✓ | ✓ | |
| Modifier la production directement | ✓ | ✓ | ||
| Voir les clés SDK | ✓ | ✓ | ✓ | |
| Créer et révoquer des clés SDK | ✓ | ✓ | ||
| Gérer l’équipe, les projets et les environnements | ✓ | ✓ | ||
| Lire et exporter le journal d’audit | ✓ | ✓ | ||
| Facturation, utilisation et politique de l’organisation | ✓ |
Quelques notes que le tableau ne peut pas porter :
- Les Viewers et les Developers ne voient que les projets qui leur ont été accordés.
- Personne n’accorde un rôle supérieur au sien. Un Admin peut inviter des Developers, pas des Owners.
- La matrice complète est publiée dans l’app, de sorte que ce que vous voyez dans le tableau de bord reflète toujours ce que le serveur applique réellement.
Les changements en production : une seconde paire d’yeux
Section intitulée « Les changements en production : une seconde paire d’yeux »Les Developers ne peuvent pas écrire directement dans les environnements de classe production — mais ils n’ont pas non plus à attendre un Admin. Un Developer propose un changement (une bascule, une modification de règles), et n’importe quelle seconde personne — un autre Developer ou au-dessus — le relit et l’approuve, ce qui l’applique.
La forme de ce mécanisme est délibérée, et vaut la peine d’être comprise en tant qu’acheteur :
- C’est une revue par les pairs, pas une revue hiérarchique. Deux Developers ensemble peuvent changer la production. Le but est qu’aucune personne seule ne la change en dessous du niveau Admin.
- L’auto-approbation est refusée, point — par personne, pas par rôle. Même un Admin ne peut pas approuver sa propre proposition.
- Le journal d’audit nomme les deux parties sur chaque proposition appliquée — qui a proposé, qui a approuvé.
Les Admins et les Owners peuvent toujours écrire directement en production ; le chemin de la proposition est là pour que le reste de l’équipe ait une voie d’entrée sûre.
Les changements planifiés
Section intitulée « Les changements planifiés »L’état d’un flag booléen peut être planifié : activer holiday-banner vendredi à 09:00
UTC. Le changement prend effet exactement à l’heure choisie pour chaque lecteur, et
planifier un environnement demande la même permission que d’y écrire maintenant — une
planification n’est qu’une écriture avec un horodatage, et elle est tenue à la même
exigence.
Le journal d’audit
Section intitulée « Le journal d’audit »Chaque changement d’état atterrit dans un journal d’audit en ajout seul : qui, quoi, quand, d’où, et les valeurs avant/après. Les Admins et les Owners peuvent le parcourir dans l’app avec des filtres et l’exporter en CSV — pour une revue d’incident, une demande de conformité ou un auditeur. Voir Exportez le journal d’audit pour le pas à pas.
Où aller ensuite
Section intitulée « Où aller ensuite »- Exigez une approbation pour les changements en production — le flux, étape par étape
- Planifiez un changement — programmez une bascule pour plus tard
- Invitez votre équipe — les rôles s’attribuent sur l’invitation