Skip to content
AMN Docs

Ordre de Priorité des Slices (Tranches Verticales) - Phase 0

Ordre de Priorité des Slices (Tranches Verticales) - Phase 0

Documentation technique

Date : 2026-09-04
Projet : Réarchitecture du Site Web (Vitrine, Blog, Portfolio, Documentation)
Version : 1.0

1. Principes d’ordonnancement

L’ordre des slices respecte les principes suivants :

  1. Dépendances techniques : Un slice ne peut commencer que si ses prérequis techniques sont implémentés
  2. Golden Path优先 : Les composants du parcours minimal viable sont priorisés
  3. Valeur business incrémentale : Chaque slice doit livrer une fonctionnalité utilisable par l’utilisateur
  4. Complexité croissante : Commencer par les flux simples, puis aborder les flux complexes

2. Ordre validé des 8 Slices1/2

Ordre Slice (Tranche Verticale) Priorité Golden Path Complexité Dépendances principales
1 Schéma Sanity “page” (vitrine) ✅ Critique Faible Infrastructure de base
2 Schéma Sanity “post” (blog) ✅ Critique Moyenne Slice 1
3 Schéma Sanity “project” (portfolio) ❌ Hors GP Moyenne Slice 1
4 Formulaire de contact ❌ Hors GP Moyenne Slice 1

2. Ordre validé des 8 Slices2/2

Ordre Slice (Tranche Verticale) Priorité Golden Path Complexité Dépendances principales
5 Upload de médias ❌ Hors GP Élevée Slice 1, 2, 3
6 Webhook Sanity ✅ Critique Moyenne Slice 1, 2
7 Backup & Cleanup ❌ Hors GP Élevée Slice 1, 2, 3, 5
8 Documentation & Recherche ❌ Hors GP Moyenne Infrastructure de base

3. Détail de chaque Slice

Slice 1 : Schéma Sanity “page” (vitrine)1/4

Composants impliqués :

  • L1 : Schéma page, blocs PageBuilder (hero, features, testimonials, cta, richText, imageGallery), objet seo
  • L2 : Route index.astro, Layout MainLayout.astro, utilitaire getSanityClient()
  • L3 : Middleware Cloudflare (pour preview)

Slice 1 : Schéma Sanity “page” (vitrine)2/4

Justification de la priorité :

  • C’est la page d’accueil, premier point d’entrée des utilisateurs
  • Établit le pattern de base pour toutes les autres pages Sanity
  • Requis pour le Golden Path

Prérequis :

  • Infrastructure Astro configurée (astro.config.mjs)
  • Projet Sanity créé avec les credentials
  • Middleware Cloudflare déployé (pour preview)

Slice 1 : Schéma Sanity “page” (vitrine)3/4

Livrables :

  • Schéma page avec PageBuilder
  • Schémas des 6 blocs PageBuilder
  • Objet seo utilitaire
  • Route index.astro (SSG)
  • Layout MainLayout.astro
  • Utilitaire getSanityClient() avec détection preview
  • Mode Preview fonctionnel

Slice 1 : Schéma Sanity “page” (vitrine)4/4

Critères d’acceptation :

  • La page d’accueil s’affiche correctement en production
  • Le mode Preview permet de voir les brouillons
  • Les blocs PageBuilder sont rendus correctement
  • Les métadonnées SEO sont injectées

Slice 2 : Schéma Sanity “post” (blog)1/4

Composants impliqués :

  • L1 : Schémas post, author, category, objet seo
  • L2 : Routes blog/index.astro, blog/[slug].astro, Layout BlogLayout.astro
  • L3 : Middleware Cloudflare (pour preview)

Slice 2 : Schéma Sanity “post” (blog)2/4

Justification de la priorité :

  • Deuxième composant du Golden Path
  • Démontre la gestion des contenus chronologiques et des références
  • Requis pour tester l’indexation Pagefind

Prérequis :

  • Slice 1 terminée (infrastructure de base, getSanityClient, layouts)
  • Schémas utilitaires author et category créés

Slice 2 : Schéma Sanity “post” (blog)3/4

Livrables :

  • Schéma author
  • Schéma category
  • Schéma post avec références vers author et category
  • Route blog/index.astro (listing)
  • Route blog/[slug].astro (détail)
  • Layout BlogLayout.astro
  • Génération de types TypeScript (sanity-typegen)

Slice 2 : Schéma Sanity “post” (blog)4/4

Critères d’acceptation :

  • La liste des articles s’affiche correctement
  • Un article individuel s’affiche avec son contenu Portable Text
  • Les références (auteur, catégories) sont résolues
  • Le mode Preview fonctionne pour les articles

Slice 3 : Schéma Sanity “project” (portfolio)1/3

Composants impliqués :

  • L1 : Schéma project, objet seo
  • L2 : Route portfolio/index.astro
  • L3 : Middleware Cloudflare (pour preview)

Justification de la priorité :

  • Hors Golden Path, mais suit le même pattern que Slice 2
  • Complexité similaire au blog (sans références croisées)
  • Peut être développé en parallèle de Slice 2 si ressources disponibles

Slice 3 : Schéma Sanity “project” (portfolio)2/3

Prérequis :

  • Slice 1 terminée (infrastructure de base)

Livrables :

  • Schéma project avec galerie d’images
  • Route portfolio/index.astro
  • Composants de galerie/carrousel si nécessaire

Slice 3 : Schéma Sanity “project” (portfolio)3/3

Critères d’acceptation :

  • La galerie de projets s’affiche correctement
  • Les projets mis en avant (featured) sont mis en évidence
  • Le mode Preview fonctionne

Slice 4 : Formulaire de contact1/4

Composants impliqués :

  • L2 : Route contact.astro (SSR)
  • L3 : Worker form-handler, Queue submissions-queue, Turnstile (anti-spam)

Justification de la priorité :

  • Hors Golden Path
  • Introduit la logique métier backend et la gestion des formulaires
  • Dépend de l’infrastructure SSR (Pages Functions)

Slice 4 : Formulaire de contact2/4

Prérequis :

  • Slice 1 terminée (MainLayout, infrastructure)
  • Cloudflare Turnstile configuré
  • CRM ou service d’emailing configuré

Slice 4 : Formulaire de contact3/4

Livrables :

  • Route contact.astro avec validation Zod côté client
  • Worker form-handler avec validation Turnstile
  • Queue submissions-queue pour résilience
  • Intégration CRM ou service d’emailing

Slice 4 : Formulaire de contact4/4

Critères d’acceptation :

  • Le formulaire soumet correctement les données
  • La protection anti-spam Turnstile fonctionne
  • Les soumissions sont enregistrées dans le CRM
  • Le fallback en Queue fonctionne en cas de panne CRM

Slice 5 : Upload de médias1/4

Composants impliqués :

  • L1 : Intégration Sanity Studio avec upload custom
  • L3 : Worker media-upload, Bucket R2 medias-r2, Cloudflare Stream (vidéos)

Justification de la priorité :

  • Hors Golden Path
  • Complexité élevée (URLs présignées, gestion R2/Stream)
  • Dépend de l’existence des schémas Sanity (post, project, page)

Slice 5 : Upload de médias2/4

Prérequis :

  • Slices 1, 2, 3 terminées (schémas Sanity créés)
  • Bucket R2 configuré
  • Cloudflare Stream configuré (pour vidéos)

Slice 5 : Upload de médias3/4

Livrables :

  • Worker media-upload (génération URLs présignées)
  • Intégration upload dans Sanity Studio
  • Bucket R2 medias-r2 avec organisation des dossiers
  • Support Cloudflare Stream pour les vidéos

Slice 5 : Upload de médias4/4

Critères d’acceptation :

  • L’upload d’images fonctionne depuis Sanity Studio
  • L’upload de vidéos fonctionne via Stream
  • Les fichiers sont stockés dans R2 avec la bonne structure
  • Sanity ne stocke que les métadonnées et URLs

Slice 6 : Webhook Sanity1/4

Composants impliqués :

  • L1 : Configuration webhooks dans Sanity Studio
  • L3 : Worker cms-webhook-receiver, KV webhook-lock-kv, Pipeline CI/CD

Justification de la priorité :

  • Critique pour le Golden Path : permet le rebuild automatique
  • Dépend des slices 1 et 2 (contenu à rebuild)
  • Complexité moyenne (validation HMAC, debounce)

Slice 6 : Webhook Sanity2/4

Prérequis :

  • Slices 1 et 2 terminées (contenu à publier)
  • Pipeline CI/CD configuré avec deploy hook
  • Sanity Studio configuré

Slice 6 : Webhook Sanity3/4

Livrables :

  • Worker cms-webhook-receiver avec validation HMAC-SHA256
  • KV webhook-lock-kv pour debounce (2 min)
  • Configuration webhook dans Sanity Studio
  • Intégration avec pipeline CI/CD (deploy hook)
  • Alerting en cas d’échec de rebuild

Slice 6 : Webhook Sanity4/4

Critères d’acceptation :

  • La publication d’un article déclenche automatiquement le rebuild
  • Le debounce évite les rebuilds multiples en cas d’éditions rapides
  • Les signatures webhook sont validées cryptographiquement
  • Les échecs de rebuild déclenchent une alerte

Slice 7 : Backup & Cleanup1/4

Composants impliqués :

  • L3 : Workers media-cleanup (cron), sanity-backup (cron), Buckets R2

Justification de la priorité :

  • Hors Golden Path
  • Fonctionnalités de maintenance et résilience
  • Complexité élevée (safety locks, streaming, cron triggers)

Slice 7 : Backup & Cleanup2/4

Prérequis :

  • Slices 1, 2, 3 terminées (schémas Sanity pour requêtes GROQ)
  • Slice 5 terminée (bucket R2 avec médias)
  • Buckets R2 configurés

Slice 7 : Backup & Cleanup3/4

Livrables :

  • Worker sanity-backup (cron quotidien, streaming HTTP)
  • Worker media-cleanup (cron hebdomadaire, safety locks)
  • Bucket R2 backups-r2 avec lifecycle rules
  • Alerting en cas d’échec des jobs cron

Slice 7 : Backup & Cleanup4/4

Critères d’acceptation :

  • Le backup Sanity s’exécute quotidiennement sans erreur
  • Les backups sont stockés dans R2 avec rétention 30 jours
  • Le cleanup des médias orphelins s’exécute hebdomadairement
  • Les safety locks empêchent les suppressions massives accidentelles
  • Les échecs de jobs déclenchent des alertes

Slice 8 : Documentation & Recherche1/4

Composants impliqués :

  • L1 : Content Collection starlight-docs (fichiers Markdown/MDX)
  • L2 : Intégration Starlight, Pagefind (indexation unifiée)

Justification de la priorité :

  • Hors Golden Path
  • Dernier slice car indépendant des autres (fichiers locaux)
  • Requiert une configuration Starlight spécifique

Slice 8 : Documentation & Recherche2/4

Prérequis :

  • Infrastructure Astro configurée
  • Slices 1 et 2 terminées (pour indexation Pagefind unifiée)

Slice 8 : Documentation & Recherche3/4

Livrables :

  • Configuration Starlight dans Astro
  • Structure de documentation Markdown/MDX
  • Intégration Pagefind unifiée (indexe Sanity + Starlight)
  • Interface de recherche globale avec badges par type
  • Overrides CSS Starlight pour cohérence visuelle

Slice 8 : Documentation & Recherche4/4

Critères d’acceptation :

  • La documentation Starlight s’affiche correctement
  • La recherche Pagefind indexe le contenu Sanity et Starlight
  • Les résultats de recherche sont distingués par type (Doc, Blog, Portfolio, Page)
  • La cohérence visuelle est maintenue entre Starlight et le reste du site

4. Mapping avec le Golden Path1/2

Le Golden Path (parcours minimal viable) est composé des éléments suivants :

Composant Golden Path Slice associé Statut
Page d’accueil (vitrine SSG + Sanity) Slice 1 ✅ Critique
Article de blog (SSG + Sanity + Portable Text) Slice 2 ✅ Critique
Recherche Pagefind (indexant ces 2 pages) Slice 2 + Slice 8 ✅ Critique
Mode Preview (pour les contributeurs) Slice 1 + Slice 2 ✅ Critique
Webhook de rebuild (déclenchement automatique) Slice 6 ✅ Critique

4. Mapping avec le Golden Path2/2

Stratégie recommandée :

  1. Implémenter les Slices 1, 2, et 6 en priorité absolue
  2. Stabiliser le Golden Path (tests E2E complets)
  3. Une fois le Golden Path validé, poursuivre avec les Slices 3, 4, 5, 7, 8
  4. Slice 8 peut être avancé si la documentation est prioritaire business

5. Templates de Fiches d’Objet

Pour chaque slice, les fiches d’objets doivent être créées en utilisant les templates spécifiques situés dans la structure docs/L[x]/[platforme]/[resource_type]/ :

Templates par type de ressource1/4

Type de ressource Template (.template.md) ObjectData (.objectData.md)
Sanity (L1)
Schéma Sanity docs/L1_Contenu/sanity/schemas/schemas.template.md docs/L1_Contenu/sanity/schemas/schemas.objectData.md
Configuration API Sanity docs/L1_Contenu/sanity/api/api.template.md docs/L1_Contenu/sanity/api/api.objectData.md
Configuration Studio docs/L1_Contenu/sanity/studio/studio.template.md docs/L1_Contenu/sanity/studio/studio.objectData.md
Visual Editing / Preview docs/L1_Contenu/sanity/visual-editing/visual-editing.template.md docs/L1_Contenu/sanity/visual-editing/visual-editing.objectData.md
Webhook Sanity docs/L1_Contenu/sanity/webhooks/webhook.template.md docs/L1_Contenu/sanity/webhooks/webhook.objectData.md

Templates par type de ressource2/4

Type de ressource Template (.template.md) ObjectData (.objectData.md)
Astro (L1)
Content Collection docs/L1_Contenu/astro/content-collections/content-collections.template.md docs/L1_Contenu/astro/content-collections/content-collections.objectData.md
Cloudflare (L1)
Stockage R2/Stream docs/L1_Contenu/cloudflare/storage/storage.template.md docs/L1_Contenu/cloudflare/storage/storage.objectData.md
Configuration Stream docs/L1_Contenu/cloudflare/stream/stream.template.md docs/L1_Contenu/cloudflare/stream/stream.objectData.md
Astro (L2)

Templates par type de ressource3/4

Type de ressource Template (.template.md) ObjectData (.objectData.md)
Configuration Astro docs/L2_Presentation/astro/config/config.template.md docs/L2_Presentation/astro/config/config.objectData.md
Route Astro docs/L2_Presentation/astro/routes/routes.template.md docs/L2_Presentation/astro/routes/routes.objectData.md
Layout Astro docs/L2_Presentation/astro/layouts/layouts.template.md docs/L2_Presentation/astro/layouts/layouts.objectData.md
Composant Astro docs/L2_Presentation/astro/components/components.template.md docs/L2_Presentation/astro/components/components.objectData.md
Pagefind (L2)
Indexation Pagefind docs/L2_Presentation/pagefind/indexing/indexing.template.md docs/L2_Presentation/pagefind/indexing/indexing.objectData.md
API Pagefind docs/L2_Presentation/pagefind/search-api/search-api.template.md docs/L2_Presentation/pagefind/search-api/search-api.objectData.md

Templates par type de ressource4/4

Type de ressource Template (.template.md) ObjectData (.objectData.md)
UI Pagefind docs/L2_Presentation/pagefind/search-ui/search-ui.template.md docs/L2_Presentation/pagefind/search-ui/search-ui.objectData.md
Cloudflare (L3)
Worker Cloudflare docs/L3_Backend/cloudflare/workers/workers.template.md docs/L3_Backend/cloudflare/workers/workers.objectData.md
Binding Cloudflare docs/L3_Backend/cloudflare/bindings/bindings.template.md docs/L3_Backend/cloudflare/bindings/bindings.objectData.md
Configuration Wrangler docs/L3_Backend/cloudflare/config/config.template.md docs/L3_Backend/cloudflare/config/config.objectData.md
Pages Function docs/L3_Backend/cloudflare/functions/functions.template.md docs/L3_Backend/cloudflare/functions/functions.objectData.md

Cycle de développement

Pour chaque objet d’un slice, suivre le cycle strict :

  1. DOC : Remplir les sections “Vue d’ensemble” et “Architecture” du template
  2. SPEC : Remplir les sections “Contrats d’Entrée/Sortie”
  3. CODE : Remplir les sections “Implémentation” avec le code réel
  4. TEST : Remplir les sections “Tests attendus” et exécuter les tests
  5. INTÉG : Remplir les sections “Intégration” et vérifier la cohérence

6. Estimation de durée par Slice1/2

Slice Estimation (1 développeur) Notes
Slice 1 2-3 jours Infrastructure + PageBuilder
Slice 2 2-3 jours Références + Portable Text
Slice 3 1-2 jours Similaire à Slice 2, sans références
Slice 4 2-3 jours Backend + Turnstile + CRM
Slice 5 3-4 jours R2 + Stream + URLs présignées

6. Estimation de durée par Slice2/2

Slice Estimation (1 développeur) Notes
Slice 6 1-2 jours Webhook + HMAC + Debounce
Slice 7 2-3 jours Cron + Safety locks + Streaming
Slice 8 2-3 jours Starlight + Pagefind unifié
Total 15-23 jours Sans tests E2E et documentation

Note : Ces estimations incluent le cycle complet DOC → SPEC → CODE → TEST → INTÉG pour chaque slice.

7. Possibilités de parallélisation1/2

Si plusieurs ressources sont disponibles, certains slices peuvent être développés en parallèle :

Groupe de parallélisation Slices Condition
Groupe A Slice 1, Slice 3 Infrastructure de base partagée
Groupe B Slice 2, Slice 4 Slice 1 terminée
Groupe C Slice 5, Slice 6 Slices 1, 2, 3 terminées
Groupe D Slice 7, Slice 8 Slices 1, 2, 3, 5 terminées

Attention : La parallélisation nécessite une coordination rigoureuse pour éviter les conflits de merge et assurer la cohérence de l’architecture.

7. Possibilités de parallélisation2/2

Historique des modifications

Date Version Description Auteur
2026-09-04 1.0 Création initiale de l’ordre des slices AMN
Switch to normal mode

Contents

Built with StarlightPowered by Cloudflare