Aller au contenu
API Delivery
Avant de compter sur une fonctionnalité, consultez l'état des capacités.

Confiance

Architectures de référence

Comment différents types d'organisations peuvent configurer Atlas, d'un site d'entreprise unique à un groupe multimarque ou une agence.

Cette page a été traduite de l'anglais. En cas de divergence, la version anglaise fait foi. Lire en anglais

Ce sont des configurations recommandées, pas des témoignages clients. Choisissez le modèle le plus proche du vôtre et adaptez-le.

Une société holding avec plusieurs sites de marque, chacun avec sa propre équipe.

Organization: Group
├── Site: brand-a (Development, Production) editors: Brand A team
├── Site: brand-b (Development, Production) editors: Brand B team
└── Site: brand-c (Development, Production) editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand
  • Une organisation, un site par marque. Le contenu, les médias, les tokens et les personnes ne sont jamais partagés entre sites.
  • Chaque marque conserve son propre code de site web et son propre contrat, avec ses propres composants et design tokens. Atlas n’impose jamais un design commun.
  • Les éditeurs d’une marque ne reçoivent des rôles que sur leur site. L’équipe digitale du groupe approuve les releases Production.
  • Chaque site web a ses propres jetons de diffusion et webhooks, de sorte que le déploiement ou la panne d’une marque n’affecte pas les autres.

2. Entreprise réglementée ou soumise à de nombreuses approbations

Section intitulée « 2. Entreprise réglementée ou soumise à de nombreuses approbations »

Équipes de la finance, de la santé, de l’énergie ou proches du secteur public, où chaque modification publique nécessite une validation.

  • Les éditeurs et les équipes marketing rédigent ; un relecteur/publicateur publie dans Development ; un groupe plus restreint approuve les releases Production.
  • Activez l’approbation par téléphone pour les actions sensibles.
  • Chaque release est vérifiée (contrat synchronisé, aucun problème de publication, santé du site, sauvegarde récente) et signée. Le retour arrière est une seule action.
  • Exportez le journal d’audit pour vos dossiers de conformité.
  • Convenez des règles de conservation des leads avant la mise en production, et notez qu’aujourd’hui la conservation et l’envoi vers un CRM ne couvrent que les leads Development.
  • Confirmez avec nous l’emplacement d’hébergement et la rétention des données avant de signer (voir Sécurité).

Une agence construit et maintient des sites pour plusieurs clients.

  • Privilégiez une organisation par client, afin que chaque client possède ses données, ses personnes et son offre. Le personnel de l’agence est invité en tant que membre.
  • Constituez une bibliothèque de vos propres composants dans le code et réutilisez-la d’un contrat client à l’autre, avec des design tokens propres à chaque client.
  • Utilisez un agent de code IA via MCP pour la migration du contenu ; c’est le relecteur du client qui publie.
  • La remise au client est sûre : ses éditeurs ne peuvent modifier que des champs typés, jamais le code.

Un site d’entreprise, une petite équipe marketing et un développeur externe.

  • Une organisation, un site. Le développeur connecte le site web et écrit le contrat une seule fois.
  • L’équipe marketing modifie les pages, les actualités et les traductions ; le responsable marketing approuve les releases Production.
  • Le développeur n’est nécessaire que pour de nouveaux composants ou types de pages.
  • Le code, l’hébergement et les déploiements de votre site web restent chez vous.
  • Development d’abord ; Production uniquement via une release approuvée.
  • Un contenu de repli intégré pour que le site reste en ligne si Atlas est injoignable.
  • Des jetons de diffusion côté serveur, renouvelés avant leur expiration.