Telaria Admin

Telaria Admin est le backoffice global de Codexia. Il fournit une interface d'administration unique pour gérer les fonctionnalités transverses (utilisateurs, rôles, traductions, recherche, CMS, paramètres applicatifs) et pour administrer les plugins via un CRUD générique. Sources : Architecture, Design, Bootstrap.

Positionnement

• Backoffice fonctionnel, distinct de l'éditeur de documentation.
• Administration du site via un sous-domaine dédié.
• V1 orientée gestion et cohérence, sans surcharge visuelle. Sources : Branding, Design.

Accès et URLs

Sous-domaine :

• admin.telaria.fr

Réécriture Apache :

• Les URLs publiques du backoffice sont exposées en /controller/action.
• Apache réécrit en interne vers /admin/controller/action. Source : Apache mod_rewrite.

Exemple Apache (VirtualHost) :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^admin\.telaria\.fr$ [NC]
RewriteRule ^/(.*)$ /admin/$1 [L]

Source : Apache mod_rewrite.

Routage Symfony

Les contrôleurs d'administration restent sous /admin/* et sont mappés par les routes Symfony standard. Source : Symfony Routing.

Périmètre V1

Modules gérés dans l'admin :

• Utilisateurs
• Rôles
• Traductions
• Recherche
• CMS
• Paramètres applicatifs

CRUD générique pour plugins

Objectif :

• Éviter des vues dédiées par plugin.
• Déclarer un plugin via configuration et alimenter un CRUD automatique.

Configuration minimale (exemple) :

# config/packages/Telaria_admin.yaml
Telaria_admin:
  bundles:
    telaria-cms:
      label: "CMS"
      list: "App\\Controller\\Admin\\CmsContentController::index"
      create: "App\\Controller\\Admin\\CmsContentController::new"
      edit: "App\\Controller\\Admin\\CmsContentController::edit"
      delete: "App\\Controller\\Admin\\CmsContentController::delete"

Règles :

• Le backoffice appelle les actions déclarées.
• Chaque bundle fournit ses services et ses formulaires.
• Le CRUD générique se limite à l'orchestration et à l'UI standard.

UI et ergonomie

Principes :

• Lisibilité et densité maîtrisée.
• Actions principales mises en avant.
• Erreurs explicites et proches des champs. Sources : Branding, Design, Bootstrap.

Sécurité et rôles

L'accès est régi par le système d'authentification existant et des rôles dédiés. Rôles réellement implémentés (develop, v0.5.0) :

• ROLE_USER (lecteur)
• ROLE_ADMIN

Rôles conceptuels — non encore implémentés (domaine CMS, parqué sur la branche wip-cms-before-ia-landing, hors develop) :

• ROLE_CMS_ADMIN
• ROLE_CMS_EDITOR
• ROLE_CMS_REVIEWER

Les contrôleurs appliquent des Voters pour centraliser les droits. Source : Symfony Voters.

Pilotage de la consommation API (/admin/metrics, v0.5.0 — implémenté)

Surface réellement livrée en prod sur telaria v0.5.0 (à distinguer du périmètre conceptuel ci-dessus). Source : rétro-doc Lead dev (#30). Le canon décrit le comportement ; le runbook opérationnel (clé Admin Anthropic, déploiement) reste côté codexia.

Le back-office expose /admin/metrics, alimenté par l'Admin API Anthropic, qui présente :

• Usage et coût par modèle (jetons in/out, coût associé).
• Analytics : taux de cache, coût $/Mtok, projection de dépense.
• Ventilation des jetons par clé API / tier.
• Alertes de coût par e-mail, administrables (seuils gérés en BO, CRUD).

Limite assumée : le coût n'est pas ventilable par clé côté Admin API Anthropic (seuls les jetons le sont). Documenté pour ne pas re-tenter une ventilation coût/clé impossible.

Runbook (hors canon, côté codexia) : la clé Admin (sk-ant-admin) vit en .env.local sur le VPS ; modalités de déploiement et de rotation = responsabilité de l'exécutant codexia.

Cette surface est l'une des cartes du tableau de bord modulaire (cf. guides/pattern-dashboard-modulaire.md).

Liens internes

• Architecture technique
• Design
• Bootstrap
• Telaria CMS
• Pattern dashboard modulaire

Implémentation

Historique des décisions