Administration de l’organisation

L’administration de l’organisation fremforge se trouve sur frem.sh/<your-org>/_admin. Une barre latérale en cinq groupes regroupe les pages d’administration ; la barre supérieure propose une palette Cmd-K (⌘K / Ctrl-K) qui recherche dans toutes les pages par libellé et par mot-clé. Pas de sous-menus enfouis, pas de fenêtres modales surprises.

Organisation : Vue d’ensemble, Dépôts, Membres, SSO, Facturation, Documentation publique, Export de données, Paramètres. Sécurité : Vue d’ensemble, Résultats, Composants, Prioriser, Corriger, Rapports, Politiques, Accès. Voir Sécurité ci-dessous. Build et déploiement : Environnements, Déploiements, Secrets, Mises à jour des dépendances (la même page que Sécurité › Corriger), Proxy de dépendances, frembench. Intégration : Intégrations IA, Accès programmatique, Webhooks, Transfert SIEM. Rapports : DORA, Journal d’audit (intégrité cryptographique dans Chaîne d’audit), Journal d’accès au registre, Conservation légale, Conservation des preuves, Avis juridiques.

Si la page que vous voulez ouvrir appartient à un tenant actuellement suspendu ou dans la période de 90 jours suivant une résiliation, l’interface d’administration est en lecture seule partout, sauf pour la Facturation et l’Export de données. Le bandeau en haut de chaque page le signale explicitement.

La barre d’onglets est identique sur toutes les pages d’administration ; vous pouvez passer d’un onglet à l’autre sans perdre votre place.

Qui peut accéder à l’administration

Toute personne ayant le rôle Propriétaire (Owner) dans l’organisation Forgejo. Ce rôle se définit sur la page <org>/-/teams/owners de Forgejo ; la vérification croisée a lieu côté serveur à chaque requête d’administration, si bien que retirer le rôle de propriétaire à un utilisateur invalide immédiatement sa session d’administration.

Les membres et les collaborateurs externes ne peuvent pas accéder à /admin. La route renvoie une erreur 403 avec un message « not an org owner ».

Onglets

Facturation

frem.sh/<org>/_admin/billing couvre tout ce qui touche à l’argent.

• Nombre actuel d’utilisateurs et estimation de la facture mensuelle
• État du moyen de paiement (avec un lien « Set up payment » s’il n’existe pas encore de mandat, ou un lien « Replace payment method » si le mandat existant est rompu)
• Historique des factures avec reçus téléchargeables
• Processus de résiliation de l’abonnement (protégé par la saisie du slug de l’organisation pour confirmer)

Le processus de résiliation définit l’état cancellation_scheduled avec un délai de 30 jours avant que la résiliation ne prenne effet. Pendant ce délai, le client peut annuler la résiliation depuis l’interface d’administration ou depuis le lien de l’e-mail envoyé au moment de la résiliation. À l’issue du délai, l’organisation passe à l’état cancelled (conservation en lecture seule pendant 60 jours supplémentaires), puis deleted (purge conformément au DPA §9).

SSO

frem.sh/<org>/_admin/sso : la fédération d’identité avec votre IdP.

• Domaines vérifiés : prouvez que vous contrôlez un domaine de messagerie par un enregistrement DNS TXT ou un fichier HTTP .well-known. Obligatoire avant d’activer toute source d’authentification qui utilise ce domaine.
• Sources d’authentification : enregistrez des fournisseurs OIDC.

Une fois le domaine vérifié et la source enregistrée, vos utilisateurs se connectent avec leur IdP sur frem.sh/<org>/login. Les PAT et les clés SSH restent valides en eux-mêmes ; lorsque Require SSO est activé, fremforge revalide la session IdP toutes les 15 minutes lors des opérations Git, de sorte qu’un utilisateur désactivé dans l’IdP perd l’accès Git dans ce délai, même si sa clé figure toujours sur le compte. Voir SSO OIDC pour le modèle d’application complet.

Voir migration → GitHub → Étape 7 : vérifier et décommissionner pour la vérification de la connexion SSO dans le cadre d’une migration complète, ou suivez directement les étapes de configuration d’une source d’authentification dans l’onglet SSO décrit ci-dessus.

Sécurité

frem.sh/<org>/_admin/security/overview. Le groupe Sécurité de la barre latérale comporte huit entrées, dans l’ordre où vous traitez un résultat : détecter, prioriser, corriger, rendre compte, plus les politiques qui décident de ce qui est autorisé et de qui peut entrer.

Toutes les anciennes adresses de ces pages, comme _admin/security/policies/edge, _admin/code-security/…, _admin/compliance-evidence ou _admin/attestations, redirigent vers leur nouvel onglet. « Edge policies » n’existe plus : ses paramètres se trouvent sous Prioriser (Délai de correction (SLA), Vérifications des pull requests), Accès (Liste d’IP autorisées, Accès du support, Connecteurs IA, et les informations sur l’authentification à deux facteurs dans Politique d’authentification) et Rapports › Notifications (le résumé de sécurité).

Protection des push

frem.sh/<org>/_admin/security/policies/push-protection. L’analyse des secrets à chaque push est toujours active. Cet onglet contient la liste des dérogations et le mode de défaillance de l’analyseur.

• Rejets récents : chaque push bloqué parce que gitleaks a détecté un motif de secret à haut niveau de confiance. Cliquez sur « Approuver » pour le convertir en dérogation ponctuelle ou limitée à un motif.
• Dérogations actives : votre liste d’autorisations. Chaque dérogation porte un motif (consigné dans le journal d’audit) et une portée facultative par règle, motif de chemin, commit ou dépôt. Vous pouvez révoquer une dérogation à tout moment.

Si un résultat est un vrai secret, faites-le d’abord renouveler auprès du service émetteur, puis utilisez git filter-repo pour le retirer de l’historique, puis poussez. S’il s’agit d’un faux positif (fixture de test, identifiant public volontaire), ajoutez une dérogation limitée à un chemin. Voir Protection des push.

Résultats

frem.sh/<org>/_admin/security/findings/sast. Un onglet par analyseur : SAST, Dépendances, Licences, Images de conteneurs, Analyse des secrets, Logiciels malveillants (l’analyse antimalware des envois), plus Exceptions. Chaque onglet affiche d’abord ses résultats, avec une ligne indiquant si l’analyseur est actif et à partir de quelle gravité sa vérification de pull request échoue. Les paramètres eux-mêmes se trouvent sous Sécurité › Politiques › Analyseurs. Les règles selon lesquelles un résultat est évalué, comme les listes de licences et le contrôle des pulls d’images, se trouvent sous Sécurité › Politiques (voir Politiques de sécurité).

Mises à jour des dépendances

frem.sh/<org>/_admin/dependency-updates, sous Sécurité › Corriger (Build et déploiement conserve un lien vers la même page). Une page avec deux voies : Correctifs de sécurité, une pull request par paquet vulnérable pilotée par vos résultats, et Mises à jour de version par Renovate hébergé. Elle liste aussi les dépôts participants et l’activité récente.

• Activer : provisionne un utilisateur bot propre au tenant et lance une exécution nocturne sur les dépôts de l’organisation.
• Exécutions récentes : les 10 dernières exécutions de Renovate, avec le nombre de PR et les éventuelles erreurs.
• Exécuter maintenant : déclenchement hors cycle (limité à 1 par heure).
• Désactiver : révoque immédiatement le jeton du bot et le retire de l’organisation. Les PR déjà ouvertes par le bot restent ouvertes.

La configuration par dépôt se fait via renovate.json à la racine du dépôt. Voir Mises à jour des dépendances pour les deux voies, Mises à jour de version pour la référence Renovate, et Correctifs de sécurité pour les pull requests de correctifs pilotées par les résultats.

Secrets

frem.sh/<org>/_admin/secrets : les secrets Actions au niveau de l’organisation, injectés comme variables d’environnement dans chaque job de CI de l’organisation. Forgejo est la couche de stockage (chiffrement au repos) ; l’administration fremforge relaie les opérations de création, lecture, mise à jour et suppression, et émet des événements d’audit limités au nom du secret, à l’acteur et à l’horodatage (la valeur n’est jamais conservée dans la base de données ni dans le journal d’audit de fremforge).

• Nouveau secret / écraser un secret : nom (UPPER_SNAKE_CASE ; ne peut pas commencer par FORGEJO_ ou GITHUB_) et valeur. Soumettre un nom existant l’écrase ; ce même formulaire sert au renouvellement.
• Secrets actifs : liste des noms et de leur date de création. Les valeurs sont en écriture seule : fremforge ne relit ni ne réaffiche jamais une valeur après sa création.
• Supprimer : confirmation via une boîte de dialogue JS confirm(). Les workflows qui référencent le secret échoueront jusqu’à ce qu’il soit recréé.

Les secrets d’organisation sont hérités par tous les dépôts de l’organisation. Pour une portée par dépôt, définissez le secret dans l’interface native de Forgejo, sous Dépôt → Paramètres → Actions → Secrets. Pour une portée par environnement, définissez-le sous Administration de l’organisation → Environnements → <env> → Secrets d’environnement (frem.sh/<org>/_admin/environments). La portée la plus spécifique l’emporte ; un secret d’environnement portant le même nom qu’un secret d’organisation masque ce dernier pour les jobs de cet environnement.

Voir Secrets pour la référence complète, y compris le chemin d’API et la procédure de renouvellement.

Paramètres par défaut des dépôts

frem.sh/<org>/_admin/repo-defaults redirige vers Sécurité › Politiques › Règles des dépôts (_admin/security/policies/repository-rules#org-baseline) : les paramètres par défaut de protection des branches pour les dépôts de l’organisation, comme les approbations requises, la revue CODEOWNERS et les commits signés. Voir Protection des branches.

Webhooks

frem.sh/<org>/_admin/webhooks : l’historique de livraison et la relivraison des webhooks pour les événements diffusés dans toute l’organisation. La création d’un webhook (événements auxquels s’abonner, URL cible, secret de signature) se configure dans l’interface native de Forgejo sous /<org>/-/settings/hooks (niveau organisation) ou /<org>/<repo>/settings/hooks (niveau dépôt). fremforge gère le tableau de bord de l’historique de livraison sous administration → Webhooks ; Forgejo gère l’enregistrement.

• Livraisons récentes : examinez chaque tentative de livraison, les codes de réponse et les charges utiles.
• Redeliver : redéclenchez n’importe quel événement depuis la vue de l’historique. Utile pour déboguer un bug côté récepteur après une correction.

Les webhooks d’organisation se déclenchent avec la même forme d’événement que les webhooks par dépôt. Voir webhooks pour la référence complète des types d’événements et le schéma des charges utiles.

Environnements

frem.sh/<org>/_admin/environments : des environnements de déploiement à la manière de GitHub pour les jobs de CI/CD. Chaque environnement porte un nom (référencé dans le YAML du workflow par jobs.<id>.environment: <name>), des motifs de protection de branches et de tags, des secrets et des variables qui lui sont propres.

• Branches et tags de déploiement : des motifs glob (main, release/*, v[0-9]*) qui limitent les références autorisées à déployer dans cet environnement. Les références qui ne correspondent pas sont refusées avant même que le runner ne récupère le workflow.
• Secrets d’environnement : des secrets chiffrés injectés dans les jobs exécutés avec environment: <name>. Ils masquent les secrets d’organisation portant la même clé. Utile pour les identifiants réservés à la production.
• Variables d’environnement : des variables non secrètes (région, URL de déploiement, etc.) liées à l’environnement.
• Fédération OIDC : chaque exécution de workflow porte un jeton OIDC dont la revendication sub contient le nom de l’environnement (repo:owner/repo:environment:prod). Faites-lui confiance dans l’IdP de votre cloud pour accorder des identifiants de déploiement de courte durée, sans secrets de longue durée.

Voir secrets de déploiement pour le guide complet de la fédération OIDC, y compris les politiques de confiance AWS, Azure, GCP et T Cloud Public.

Conservation des artefacts de build

frem.sh/<org>/_admin/artifact-retention : le paramètre de conservation de l’organisation pour les artefacts Forgejo Actions (résultats de build, rapports de test, paquets de débogage), en jours, de 1 à 90. La valeur par défaut est de 30 jours pour les nouvelles organisations, et les organisations qui ne l’avaient jamais modifiée sont passées de 90 à 30 jours le 2026-10-21. Une valeur que vous avez définie vous-même est conservée.

Ce qui supprime réellement un artefact aujourd’hui. Forgejo fait expirer un artefact après la durée retention-days indiquée lors de son envoi, ou après le plafond de la plateforme de 90 jours (le paramètre [actions].ARTIFACT_RETENTION_DAYS de l’instance Forgejo), selon ce qui est le plus court. Le paramètre d’organisation ci-dessus ne supprime encore rien : la tâche nocturne censée appliquer une valeur plus courte a besoin d’une API d’artefacts dont cette version de Forgejo ne dispose pas. Pour conserver des artefacts moins de 90 jours, définissez retention-days lors de l’envoi :

- uses: actions/upload-artifact@v3
  with:
    name: test-report
    path: report/
    retention-days: 7

Les artefacts expirés cessent d’être décomptés du quota d’artefacts de l’organisation.

Transfert SIEM

frem.sh/<org>/_admin/siem : transmettez le journal d’audit du tenant à votre SIEM en quasi temps réel. Prend en charge Splunk HEC, Sentinel HTTP Data Collector, Elastic Cloud et un webhook générique avec signature HMAC-SHA256. Splunk et Sentinel nécessitent un proxy léger de traduction HMAC (voir Transfert SIEM) ; Elastic Filebeat et le webhook générique sont directs. Chaque point de terminaison peut être testé avec un événement synthétique avant la mise en service ; les points de terminaison défaillants appliquent un délai d’attente progressif et leurs échecs remontent dans le portail opérateur.

Attestation fournisseur et preuves de contrôle

Les deux se trouvent sous Sécurité › Rapports : l’Attestation fournisseur (_admin/security/reports/vendor-attestation) est un document sur fremforge en tant que fournisseur, et les Preuves de contrôle (_admin/security/reports/control-evidence) mettent en correspondance les événements d’audit de votre organisation avec les contrôles SOC 2 et ISO 27001. La provenance de build SLSA se trouve sous Sécurité › Composants › Attestations de build ; voir Provenance SLSA.

Cycle de vie de l’organisation et des dépôts

Quelques opérations se situent en dehors de la grille d’onglets, car il s’agit d’actions ponctuelles plutôt que d’une configuration continue. Elles se trouvent à leur emplacement naturel (la page des paramètres du dépôt ou la page de renommage de l’organisation), mais il vaut la peine de les signaler ici pour qu’elles ne passent pas inaperçues.

Renommer une organisation

frem.sh/<org>/_admin/settings : modifiez le slug de l’organisation. Les URL de dépôt, URL de clonage, appels d’API et références dans les charges utiles des webhooks qui utilisent l’ancien slug continuent d’être redirigés pendant 90 jours après le renommage. Passé ce délai, l’ancien slug redevient disponible à l’enregistrement : planifiez la bascule, mettez à jour vos intégrations pendant la période de redirection et ne tardez pas.

Le renommage est une action de propriétaire de l’organisation, consignée dans le journal d’audit et confirmée par la saisie de l’ancien slug.

Transférer un dépôt vers une autre organisation

frem.sh/<org>/<repo>/settings → Changer de propriétaire. Un dépôt peut être transféré vers une autre organisation dont vous êtes propriétaire (ou vers le compte d’un autre utilisateur, qui doit accepter). Lors du transfert :

• Toutes les branches, tags, l’historique, les tickets, PR, versions, paquets, webhooks et exécutions de workflows de CI suivent le dépôt.
• Les forks du dépôt sur fremforge restent où ils sont ; ils mettent automatiquement à jour leur pointeur amont vers le nouvel emplacement.
• Les URL git clone, git fetch et d’API HTTP en cours qui visent l’ancien chemin <org>/<repo> sont redirigées pendant 90 jours, le même délai que pour un renommage d’organisation. Mettez à jour vos remotes au fil de l’eau ; la redirection est une marge opérationnelle, pas une garantie permanente.

Le transfert est soumis à la politique de l’organisation de destination : si celle-ci impose le SSO, les commits signés, etc., le dépôt transféré hérite de cette politique à son arrivée ; les règles de protection des branches existantes du dépôt sont conservées, sauf si les valeurs par défaut de l’organisation de destination sont plus strictes.

Résilier un abonnement

Action de propriétaire, protégée par la saisie du slug de l’organisation. Voir l’onglet Facturation ci-dessus pour le processus de résiliation, et la page Facturation pour les états du cycle de vie (résiliation programmée → résilié → supprimé).

Supprimer un compte personnel

Hors du périmètre de l’administration de l’organisation. La suppression d’un compte personnel (droit à l’effacement du RGPD) se trouve sous Paramètres utilisateur → Compte. Voir Votre compte fremforge pour le processus complet, y compris ce qui est conservé au titre de l’attribution historique.

Protection des branches : référence des concepts

La protection des branches suit une hiérarchie à trois niveaux : socle de la plateforme (défini par fremforge, non configurable) → valeur par défaut de l’organisation (définie par le propriétaire de l’organisation, s’applique à tous les dépôts) → règles par dépôt (peuvent renforcer les valeurs par défaut de l’organisation, sans pouvoir descendre en dessous du socle de l’organisation).

Protection par défaut de l’organisation : Sécurité › Politiques › Règles des dépôts, valeurs par défaut de protection des branches. Définissez des règles qui s’appliquent à tous les dépôts nouvellement créés et à tous les dépôts existants qui n’ont pas de règle plus stricte au niveau du dépôt.

Protection par dépôt : Dépôt → Paramètres → Branches → Ajouter une nouvelle règle. Saisissez un motif de nom de branche (par exemple main, release/*). Protections disponibles :

Socle de la plateforme : la plateforme impose ce qui suit : les commits signés sont autorisés (sans être obligatoires) au niveau de la plateforme ; l’analyse des secrets s’exécute quels que soient les paramètres de protection des branches ; le journal d’audit enregistre tous les force push, même si le force push n’est pas bloqué.

Héritage des politiques : si la valeur par défaut de l’organisation exige 1 revue de PR et qu’une règle de dépôt en exige 2, la règle la plus stricte (2) l’emporte. Les règles de dépôt ne peuvent que renforcer, jamais assouplir.

Export de données

frem.sh/<org>/_admin/data-export : un export complet en libre-service.

• Lancer un nouvel export : assemble un unique .tar.gz signé contenant un git bundle par dépôt, les tickets, pull requests, commentaires, étiquettes, jalons et versions de chaque dépôt, l’inventaire des paquets et un extrait d’audit de 90 jours. Voir Export de données pour le contenu exact.
• Tâches récentes : les 20 dernières tâches d’export, avec leur état et leurs liens de téléchargement (valables 7 jours après la mise à disposition).

Limité à un export par organisation toutes les 24 heures. Les archives de plus de 50 Go suivent une autre procédure. Contactez le support.

Voir export de données pour la structure de l’archive, les procédures de vérification et les points de terminaison de l’API.

Paramètres

frem.sh/<org>/_admin/settings : les métadonnées principales de l’organisation : visibilité (publique / limitée / privée), nom d’affichage, description, site web, localisation. Les modifications effectuées ici sont relayées à Forgejo via PATCH /api/v1/orgs/{org} et émettent un événement d’audit tenant.org.settings.updated.

Paramètres gérés ailleurs :

• Nom de l’organisation (slug) : renommer le slug est une action Forgejo assortie d’une période de redirection de 90 jours ; gérez-la dans l’interface native de Forgejo sous /<org>/-/settings.
• Avatar / image de profil : interface native de Forgejo sous /<org>/-/settings.
• Facturation, SSO, politique de sécurité, protection des push : voir les onglets dédiés ci-dessus.

La frontière : l’administration fremforge gère le nom de l’organisation (affichage), la visibilité, le site web, la description et la localisation, en plus des onglets dédiés à l’abonnement, aux politiques, à la sécurité et à l’audit. L’interface native de Forgejo sous /<org>/-/settings gère l’avatar / l’image de profil, le renommage du slug, les valeurs par défaut de création de dépôts internes à Forgejo et la configuration plus poussée propre à Forgejo. Les deux sont accessibles depuis les comptes propriétaires ; choisissez l’interface qui convient à la modification que vous effectuez.

Journal d’audit

frem.sh/<org>/_admin/audit-log : chaque action d’administration modifiant l’état de votre organisation, consultable en temps réel.

• Filtre par acteur : limitez l’affichage à un utilisateur Forgejo précis, aux actions des opérateurs (préfixées par operator:<email>) ou à un agent. Le filtre porte sur l’acteur, la personne pour laquelle un agent a agi et l’agent lui-même : le filtre d’un utilisateur inclut donc ce que des agents ont fait en son nom.
• Badge via un agent : une action qu’un agent a effectuée au nom d’une personne désigne cette personne comme acteur et porte la mention via un agent ; l’identifiant de l’agent figure dans le champ agent de l’événement.
• Filtre par action : limitez l’affichage à un espace de noms (par exemple push-protection ou billing.cancel).
• Filtre par date : limité dans le temps.
• Badge opérateur : les actions du personnel de fremverk effectuées au nom de votre organisation sont surlignées en orange et ne sont jamais silencieuses. Les mêmes données figurent dans l’extrait d’audit de votre archive d’export de données.

À l’écran, les événements plus anciens sont tronqués au-delà de 200 lignes. Pour un historique complet, utilisez l’Export de données. L’extrait du journal d’audit dans l’archive n’est pas limité.

Conservation. Conformément à l’annexe A.7 du DPA, les événements pertinents pour la sécurité (authentification, autorisation, actions d’administration) sont conservés dans un niveau chaud interrogeable, avec une durée de conservation par tenant que vous définissez sous Sécurité → Politique d’authentification → Conservation du journal d’audit : les préréglages sont 90 / 180 / 365 / 730 jours, avec 90 jours par défaut (offre standard) ou 365 jours (offres entreprise). Les journaux opérationnels (HTTP, runner, infrastructure) sont conservés au niveau chaud pendant 30 jours (non configurable). Les deux niveaux sont écrits dans une archive WORM immuable sur T Cloud Public OBS pendant 3 ans, avec un ancrage de chaîne de hachage toutes les 2 minutes pour rendre toute altération détectable ; après l’échéance du niveau chaud, le contenu (actor, fields_json) est expurgé, mais les hachages SHA-256 de la chaîne sont conservés pendant les 3 années complètes. La vue à l’écran et l’extrait d’audit de l’archive d’export couvrent tous deux la période configurée du niveau chaud. Pour récupérer des événements plus anciens dans l’archive WORM, contactez support@frem.sh.

Équivalence avec l’API

Chaque action d’administration est aussi un point de terminaison REST documenté. L’interface d’administration est elle-même un client de la même API que celle qu’utiliserait un agent IA. Voir l’API REST publique pour la spécification OpenAPI.

Deux espaces de noms, un seul hôte de base. Les routes sous /api/v1/... sont natives de Forgejo (même forme que l’API Forgejo amont, sans préfixe fremforge ; elles servent aux opérations sur les organisations, dépôts, utilisateurs, tickets et PR que Forgejo couvre déjà). Les routes sous /_app/api/v1/... sont des extensions fremforge (les ajouts du plan de contrôle que nous superposons : facturation, protection des push, export de données, Renovate hébergé, politique SSO, attestations). L’appel PATCH /api/v1/orgs/{org} cité dans §Paramètres ci-dessus est la forme native de Forgejo ; le même hôte réseau sert les deux préfixes grâce au routage de la plateforme. Choisissez le préfixe qui correspond au point de terminaison documenté et ne les mélangez pas.

Tout ce que vous faites dans l’interface d’administration peut donc aussi se faire par programme :

• POST /_app/api/v1/orgs/<org>/dependency-updates/enrol : équivaut à cliquer sur « Enable hosted Renovate » (extension fremforge)
• POST /_app/api/v1/orgs/<org>/exports : équivaut à cliquer sur « Lancer un nouvel export » (extension fremforge)
• GET /_app/api/v1/orgs/<org>/push-protection/overrides : liste les dérogations actives de protection des push (extension fremforge)
• PATCH /api/v1/orgs/<org> : met à jour le nom d’affichage, le site web, la localisation ou la visibilité (natif Forgejo)
• etc.

Authentification par jeton : un PAT émis depuis vos paramètres utilisateur Forgejo. L’OAuth 2.0 avec client credentials est prévu en même temps que le flux d’identité des agents.

Piste d’audit

Chaque action d’administration émet une ligne de journal structurée dans le flux d’audit de fremforge, avec les champs actor, action, tenant_id, ainsi que des champs propres à l’action. Le journal d’audit est inclus, limité à votre organisation, dans l’archive d’export de données.

Ce que vous voyez dans votre extrait d’audit :

• Toutes les actions POST/DELETE de l’interface d’administration (tout ce qui modifie l’état)
• Tous les appels d’API authentifiés en tant que membre de votre organisation
• Toutes les actions effectuées au nom de votre organisation par le personnel de fremverk (signalées par actor=operator:<email>, jamais silencieuses)

Ce que vous ne voyez pas (pour des raisons de confidentialité et de procédure judiciaire) :

• Les événements d’infrastructure internes à fremverk (ils vont dans un flux d’audit distinct)
• Les identifiants de corrélation entre tenants (expurgés avant l’export)

Références croisées

• Tarifs : ce qui est inclus dans l’offre à 30 € par utilisateur
• Confiance : sous-traitants, certifications, posture de souveraineté
• API REST publique : les équivalents programmatiques de chaque action d’administration
• Guides de migration : configuration pas à pas depuis GitHub / GitLab / Azure DevOps