Stack technique et architecture d’exécution de la présence digitale
Comment lire ce dossier
Ce dossier transforme le cahier des charges et le plan d’action en architecture exécutable. Il privilégie une base statique, performante et portable, puis réserve le CMS, le backend et le commerce propriétaire aux besoins réellement démontrés.
Version : 1.0
Date : 11 août 2026
Marché prioritaire : Allemagne
Périmètre : présence digitale B2C
Produit héros : Carthania Farm Gold
Statut : document d’architecture technique
1. Objet du document
Ce document définit la stack technique retenue pour construire la nouvelle présence digitale B2C de Carthania Farm en Allemagne.
Le choix technique doit répondre à un objectif précis :
exécuter rapidement un site de marque performant, orienté contenu, SEO et conversion vers une marketplace, tout en conservant une architecture suffisamment souple pour accueillir ultérieurement un CMS, de nouvelles références ou un véritable checkout sans reconstruction complète.
La stack ne doit donc pas être choisie comme si Carthania Farm lançait immédiatement une plateforme e-commerce complexe.
Le besoin actuel est principalement :
- présenter Carthania Farm Gold ;
- développer le storytelling autour de la Tunisie ;
- publier des pages éditoriales, recettes et articles ;
- travailler le SEO allemand ;
- mesurer les interactions ;
- diriger le visiteur vers un canal transactionnel externe ;
- permettre une évolution progressive lorsque des besoins réels apparaissent.
2. Principes de décision technique
Six principes structurent le choix de la stack.
2.1 Rapidité d’exécution
Le projet doit pouvoir être développé, testé et publié avec peu de dépendances et peu d’administration système.
2.2 Performance par défaut
Le site repose essentiellement sur des contenus et des pages marketing. Il ne doit pas envoyer une application JavaScript complète au navigateur lorsqu’une grande partie de l’interface peut être rendue en HTML.
2.3 SEO comme fonction native
Le référencement naturel est un canal stratégique. L’architecture doit faciliter le rendu HTML, les métadonnées, les données structurées, les URLs propres, le sitemap et les performances.
2.4 Source de vérité produit unique
Les informations de Gold doivent être structurées et validées à un seul endroit afin d’éviter les contradictions déjà observées dans l’existant.
2.5 Complexité progressive
Le projet ne doit pas intégrer aujourd’hui un CMS, un panier, un serveur applicatif ou un back-office e-commerce uniquement parce qu’ils pourraient éventuellement devenir utiles.
2.6 Portabilité
Les couches métier et contenu ne doivent pas dépendre fortement d’un hébergeur, d’une marketplace ou d’un fournisseur e-commerce.
3. Stack retenue pour la version initiale
La stack recommandée est :
Astro
+
TypeScript
+
Tailwind CSS
+
Astro Content Collections / Markdown / MDX
+
React islands lorsque nécessaire
+
GitHub
+
Netlify
+
Google Tag Manager / GA4 / Search ConsoleCette architecture correspond au besoin réel du projet sans introduire de couche applicative superflue.
4. Astro comme framework principal
Astro est retenu comme framework du frontend.
Il est particulièrement adapté aux sites orientés contenu, marketing et SEO, ce qui correspond au rôle défini pour Carthania Farm.
Le projet contient principalement :
- homepage ;
- page Gold ;
- pages d’origine et de storytelling ;
- recettes ;
- articles ;
- contenus SEO ;
- pages légales ;
- CTA marketplace.
La majorité de ces pages ne nécessite aucune application JavaScript permanente côté navigateur.
Astro permet donc de générer principalement du HTML et d’ajouter de l’interactivité seulement aux composants qui en ont réellement besoin.
Conséquence
Une page éditoriale reste une page éditoriale.
Une recette reste essentiellement du HTML.
Une fiche Gold ne nécessite pas une application React complète pour afficher une bouteille, un texte et un bouton d’achat.
Cette approche favorise :
- performance ;
- simplicité ;
- stabilité ;
- SEO ;
- maintenance réduite.
Source officielle : Astro Documentation — https://docs.astro.build/
5. TypeScript
TypeScript est retenu dès le départ.
Son rôle est particulièrement important pour la structuration des données produit.
Il permet de détecter plus facilement :
- champs manquants ;
- valeurs invalides ;
- erreurs de structure ;
- incohérences lors de l’évolution du modèle de données.
Pour un site contenant peu de produits mais où la cohérence de l’information constitue une priorité, cette sécurité est plus utile qu’un système de données libre et non typé.
6. Tailwind CSS
Tailwind CSS est retenu pour la couche de styles.
Le choix répond principalement à un besoin de rapidité et de cohérence d’exécution.
Il permet de construire directement dans les composants :
- grilles ;
- espacements ;
- typographie ;
- responsive ;
- états interactifs ;
- système de composants.
Le projet doit toutefois éviter de transformer Tailwind en accumulation anarchique de classes.
Un petit design system devra définir :
- typographies ;
- tailles ;
- espacements ;
- largeurs ;
- boutons ;
- containers ;
- cartes ;
- traitement des images ;
- règles responsive.
Le but est d’obtenir la vitesse de Tailwind tout en gardant une direction visuelle stable.
Source officielle : Tailwind CSS — guide Astro — https://tailwindcss.com/docs/installation/framework-guides/astro
7. React uniquement sous forme d’islands
React n’est pas retenu comme framework principal du site.
Il reste disponible là où une interaction client réelle le justifie.
Exemples possibles :
- sélecteur de format ;
- comparateur léger ;
- filtre de recettes ;
- sélecteur de marketplace ;
- composant interactif futur ;
- panier futur si la stratégie évolue.
Architecture :
Astro
├── Header → Astro
├── Homepage → Astro
├── Gold → Astro
├── Origin → Astro
├── Recipes → Astro
├── Journal → Astro
│
├── Interactive UI → React island si nécessaire
└── Future cart → React island éventuelLe principe est :
pas de React par défaut ; React lorsqu’il apporte réellement une interaction.
Astro dispose d’une intégration officielle permettant le rendu et l’hydratation de composants React lorsque nécessaire.
Source officielle : Astro React Integration — https://docs.astro.build/en/guides/integrations-guide/react/
8. Content Collections comme couche de données initiale
Les Astro Content Collections sont retenues pour gérer les données structurées du projet.
Elles conviennent notamment à :
- produits ;
- recettes ;
- articles ;
- contenus éditoriaux.
Astro permet de définir des collections et de valider leur structure.
Cette fonction est particulièrement importante pour Carthania Farm car le nouveau dispositif doit éviter les incohérences constatées dans l’ancien catalogue.
Structure possible :
src/content/
├── products/
│ └── gold.md
├── recipes/
│ ├── recipe-01.md
│ ├── recipe-02.md
│ └── recipe-03.md
└── journal/
├── tunesisches-olivenoel.md
├── natives-olivenoel-extra.md
└── olivenoel-richtig-lagern.mdAstro présente les Content Collections comme une solution adaptée aux ensembles de contenu structurés tels que les articles, descriptions produit et recettes.
Source officielle : Astro Content Collections — https://docs.astro.build/en/guides/content-collections/
9. Modèle de données Gold
Gold doit avoir une seule source de vérité.
Exemple conceptuel :
name: Gold
slug: gold
category: Natives Olivenöl Extra
origin: Tunesien
region: null
volumes:
- 500
gtin:
500: "..."
marketplace:
provider: amazon
url: ""
claims:
extraVirgin: confirmed
tunisia: confirmed
mahdia: pending
earlyHarvest: pending
organic: excludedLes pages ne doivent pas recopier manuellement les caractéristiques du produit.
Elles doivent interroger ce référentiel.
Cela permet notamment de modifier une information à un seul endroit.
10. Gestion des claims
Le modèle de contenu doit intégrer la distinction définie dans les documents stratégiques :
confirmed
pending
excludedExemple :
claims:
originTunisia:
status: confirmed
originMahdia:
status: pending
earlyHarvest:
status: pending
organic:
status: excludedLes templates ne doivent jamais publier automatiquement un claim non validé.
Cette logique permet de transformer une contrainte éditoriale en règle technique.
11. Pourquoi aucun CMS au lancement
Le MVP doit gérer approximativement :
- un produit héros ;
- quelques pages de marque ;
- quelques recettes ;
- quelques articles.
Dans ce contexte, un CMS introduirait immédiatement :
- un service supplémentaire ;
- authentification ;
- modèle de permissions ;
- maintenance ;
- API ;
- dépendance externe ;
- coûts ou limites éventuels.
Pour le volume initial, Markdown/MDX et les Content Collections sont plus simples.
Le contenu reste :
- versionné dans Git ;
- facilement auditable ;
- facile à modifier ;
- facile à manipuler avec les outils de développement et d’IA ;
- portable.
12. Évolution CMS possible
L’absence de CMS initial n’interdit pas son ajout futur.
Si Carthania Farm doit un jour publier elle-même régulièrement :
- recettes ;
- actualités ;
- nouveaux produits ;
- campagnes ;
une couche CMS pourra être ajoutée.
Le frontend Astro pourra conserver sa structure.
L’objectif est de considérer le CMS comme une source de contenu interchangeable, et non comme le cœur du site.
Architecture possible :
Aujourd’hui
Markdown / MDX
↓
Content Collections
↓
Astropuis :
Évolution
CMS
↓
Astro Content Layer / API
↓
AstroAstro permet également de charger du contenu local ou distant via sa couche de contenu.
13. Netlify comme plateforme de déploiement
Netlify est retenu pour l’hébergement et le déploiement de la version initiale.
Le choix est pragmatique :
- environnement déjà disponible ;
- workflow Git simple ;
- excellent support des sites statiques ;
- intégration officielle avec Astro ;
- déploiements automatiques ;
- Deploy Previews ;
- possibilité de fonctions serveur si un besoin apparaît ultérieurement.
Le workflow cible est :
GitHub
↓
Pull Request / Push
↓
Netlify Build
↓
Deploy Preview
↓
Validation
↓
ProductionCe workflow est particulièrement adapté à une exécution dans laquelle les contenus, la direction visuelle ou certaines pages doivent pouvoir être validés avant publication.
Netlify documente officiellement le déploiement d’Astro et prend également en charge le rendu serveur d’Astro via Netlify Functions lorsqu’il est nécessaire.
Source officielle : Netlify — Astro on Netlify — https://docs.netlify.com/build/frameworks/framework-setup-guides/astro/
14. Pourquoi Netlify plutôt qu’une infrastructure VPS
Un VPS impliquerait inutilement :
- maintenance du système ;
- mises à jour ;
- serveur web ;
- runtime Node ;
- certificats ;
- monitoring ;
- sécurité ;
- déploiement ;
- sauvegardes selon architecture.
Pour un site essentiellement généré statiquement, cette infrastructure ne produit aucun avantage métier suffisant.
Netlify permet d’éviter cette couche opérationnelle.
15. Pourquoi Netlify plutôt que Cloudflare pour cette première version
Cloudflare constitue également une excellente cible technique et Astro peut y être déployé.
Cependant, les principaux avantages avancés de Cloudflare — Workers, KV, D1, R2 ou architectures edge plus poussées — ne correspondent pas à un besoin immédiat du projet.
Le besoin actuel est surtout :
développer
↓
prévisualiser
↓
valider
↓
publierNetlify répond directement à ce workflow avec très peu de configuration.
Le choix ne signifie pas que Cloudflare serait techniquement inférieur.
Il signifie simplement que l’écosystème supplémentaire de Cloudflare n’est pas nécessaire pour atteindre les objectifs de Carthania Farm aujourd’hui.
16. Netlify comme couche interchangeable
Le projet ne doit pas utiliser des fonctionnalités propriétaires de Netlify sans nécessité.
La majorité du site doit rester :
- Astro ;
- HTML ;
- CSS ;
- TypeScript ;
- contenu local.
Ainsi, l’architecture reste conceptuellement :
Git repository
↓
Astro project
↓
Hosting adapter
↓
Netlify aujourd’hui
Cloudflare ou autre demain si nécessaireLe choix d’hébergement ne doit pas devenir un choix métier irréversible.
17. Stratégie de rendu
Le rendu recommandé pour la première version est majoritairement statique.
Statique
Pour :
- homepage ;
- Gold ;
- origine ;
- recettes ;
- journal ;
- pages éditoriales ;
- pages légales.
Dynamique seulement lorsque nécessaire
Pour d’éventuels besoins futurs :
- API ;
- formulaire avec logique spécifique ;
- personnalisation ;
- session ;
- intégration commerce dynamique.
Astro permet d’ajouter du rendu serveur à certaines parties sans transformer automatiquement tout le site en application serveur.
Netlify peut exécuter ce rendu via ses Functions.
18. Commerce V1 : marketplace externe
Le site ne possède pas de panier dans la première version.
Le canal transactionnel est externe.
Architecture :
Carthaniafarm.com
↓
Gold
↓
CTA Acheter
↓
MarketplaceCette décision réduit immédiatement :
- code ;
- paiement ;
- sécurité transactionnelle ;
- emails transactionnels ;
- gestion des commandes ;
- comptes clients ;
- logique de panier.
19. Abstraction du canal commerce
La marketplace ne doit pas être encodée directement dans toutes les pages.
Créer une couche simple :
Product
↓
purchase provider
↓
BuyButtonPar exemple :
marketplace:
provider: amazon
url: https://...Le bouton utilise la donnée et non une URL écrite manuellement dans chaque template.
20. Route de sortie recommandée
Une route interne peut centraliser les redirections :
/go/goldElle peut ensuite rediriger vers :
Amazon aujourd’huipuis éventuellement :
Marketplace B demainsans modifier toutes les pages.
Cette route facilite également le tracking du clic sortant.
21. Commerce V2 : possibilité Shopify
Si un véritable DTC devient un besoin réel, Shopify constitue une évolution possible sans imposer une reconstruction du frontend.
Architecture future :
Astro frontend
↓
commerce adapter
↓
Shopify
↓
cart / checkout / ordersLe site peut conserver :
- design ;
- SEO ;
- storytelling ;
- articles ;
- recettes ;
- pages produit.
Le moteur commerce est alors remplacé ou complété derrière l’interface.
Cette évolution ne doit toutefois être développée qu’après validation d’un besoin opérationnel réel.
22. Pourquoi ne pas utiliser Shopify dès maintenant
Shopify serait pertinent si le projet avait immédiatement besoin de :
- panier ;
- checkout ;
- stock ;
- commandes ;
- promotions ;
- livraison ;
- clients ;
- paiements.
Ces fonctionnalités ne font pas partie du MVP retenu.
L’ajouter immédiatement ferait du moteur transactionnel le centre d’un projet dont le cœur actuel est la marque, le contenu et l’acquisition.
23. Pourquoi ne pas utiliser WordPress / WooCommerce
WordPress et WooCommerce permettent évidemment de créer un e-commerce.
Ils ne sont toutefois pas retenus pour ce projet pour plusieurs raisons :
- le site actuel repose déjà sur une logique WooCommerce qui n’a pas produit la cohérence recherchée ;
- la première version n’a pas besoin d’un moteur e-commerce ;
- dépendance aux plugins ;
- surface de maintenance plus large ;
- couche serveur et base de données inutiles pour le MVP ;
- risque de reproduire une architecture catalogue avant de construire la marque.
Le changement de stack accompagne donc également un changement de logique produit.
24. Pourquoi ne pas utiliser Next.js
Next.js est un framework très capable.
Il n’est pas retenu parce qu’il répond à une classe de besoins plus large que celle du MVP.
Carthania Farm n’a pas besoin actuellement :
- d’une application React full-stack ;
- d’une hydratation généralisée ;
- d’une architecture serveur complexe ;
- d’une logique applicative importante.
Astro permet d’utiliser React lorsqu’il est nécessaire sans faire de React le runtime général du site.
Le choix d’Astro correspond donc mieux à la nature éditoriale du projet.
25. Pourquoi ne pas utiliser Strapi
Strapi introduirait :
- service backend ;
- base de données ;
- API ;
- authentification administrative ;
- mises à jour ;
- sauvegardes ;
- maintenance.
Pour un produit et quelques contenus, cette infrastructure serait disproportionnée.
Un CMS de ce type ne devra être envisagé que si la quantité de contenu, les rôles éditoriaux ou les intégrations futures créent un besoin réel.
26. Images
Les images constituent une part importante du positionnement.
La stack doit donc permettre :
- formats modernes ;
- dimensions adaptées ;
- responsive images ;
- lazy loading ;
- optimisation des poids.
Priorité :
- AVIF lorsque pertinent ;
- WebP ;
- fallback adapté.
Les fichiers sources haute définition doivent être conservés séparément des versions générées pour le site.
27. Fonts
Le nombre de fontes doit rester limité.
Règles :
- privilégier WOFF2 ;
- limiter les graisses ;
- preload uniquement lorsque nécessaire ;
- self-hosting lorsque les licences le permettent ;
- éviter les dépendances externes inutiles.
Le choix typographique final appartient au design system, mais son implémentation doit respecter les objectifs de performance.
28. SEO technique
Le socle doit intégrer dès le départ :
- titles ;
- meta descriptions ;
- canonical ;
- sitemap ;
- robots.txt ;
- Open Graph ;
- structured data ;
- breadcrumbs ;
- alt images ;
- URLs propres.
Les structured data pertinents seront principalement :
- Organization ;
- Product ;
- Article ;
- Recipe ;
- BreadcrumbList.
29. Analytics
Stack analytics :
Google Tag Manager
+
GA4
+
Google Search ConsoleÉvénements principaux :
view_gold
click_buy
click_marketplace
view_origin
view_recipe
click_recipe_product
contact_submitLa conversion principale du MVP est le clic vers la marketplace.
30. Consentement
Le site devra intégrer une gestion adaptée du consentement pour les technologies qui le nécessitent.
Le tracking marketing ou analytics ne doit pas être déclenché indépendamment des règles de consentement applicables.
Le choix de la CMP pourra être réalisé lors de l’implémentation en fonction des outils réellement activés.
31. GitHub et workflow de développement
Le repository Git constitue la source du projet.
Workflow recommandé :
main
↑
pull request
↑
feature branchChaque pull request peut produire une Deploy Preview Netlify.
Cela permet de vérifier :
- mobile ;
- design ;
- contenus ;
- SEO ;
- tracking ;
- nouveaux composants ;
avant fusion en production.
32. Environnements
Minimum :
Local
Preview
ProductionLocal
Développement.
Preview
Validation via Netlify Deploy Preview.
Production
Domaine public.
Aucun environnement staging permanent n’est nécessaire au lancement sauf besoin particulier.
33. Variables d’environnement
Les informations sensibles ou dépendantes d’un environnement doivent rester hors du repository.
Exemples futurs :
- tokens API ;
- CMS credentials ;
- clés de services ;
- configuration commerce.
Les données publiques produit ne doivent pas être cachées inutilement dans des variables d’environnement.
34. Tests
Le projet n’a pas besoin d’une suite de tests d’application extrêmement lourde.
Priorités :
Build
Le site doit compiler sans erreur.
Validation de contenu
Les collections doivent refuser les structures invalides.
Tests fonctionnels clés
- navigation ;
- page Gold ;
- CTA marketplace ;
- formulaire ;
- routes principales.
Tests responsive
- mobile ;
- tablette ;
- desktop.
Des tests E2E ciblés peuvent être ajoutés pour les parcours critiques si le projet évolue.
35. Linting et formatage
Recommandations :
- ESLint selon besoins du projet ;
- Prettier ;
- plugin Tailwind approprié si utilisé ;
- TypeScript strict raisonnable.
L’objectif est surtout d’obtenir un repository facile à maintenir et à reprendre.
36. Architecture de répertoire proposée
src/
├── assets/
├── components/
│ ├── layout/
│ ├── marketing/
│ ├── product/
│ └── ui/
│
├── content/
│ ├── products/
│ ├── recipes/
│ └── journal/
│
├── layouts/
├── pages/
├── styles/
├── lib/
│ ├── commerce/
│ ├── analytics/
│ └── seo/
│
└── content.config.tsLe dossier lib/commerce joue un rôle important dans la portabilité future du canal transactionnel.
37. Architecture logique
┌─────────────────────┐
│ Content Layer │
│ │
│ Gold │
│ Recipes │
│ Journal │
└──────────┬──────────┘
│
Content Collections
│
┌──────────▼──────────┐
│ │
│ ASTRO │
│ │
│ Pages │
│ SEO │
│ Components │
│ React Islands │
│ │
└─────┬────────┬──────┘
│ │
┌───────────┘ └───────────────┐
│ │
Analytics Commerce
GTM / GA4 / GSC adapter
│
┌───────────┴───────────┐
│ │
Marketplace Future DTC
today optional
│
Shopify38. Future-proof : ce que cela signifie réellement
Future-proof ne signifie pas installer dès maintenant toutes les technologies qui pourraient être utilisées un jour.
Cela signifie éviter les choix qui rendraient les évolutions coûteuses.
Pour ce projet, cela se traduit par :
- contenu séparé des templates ;
- produit centralisé ;
- commerce abstrait ;
- hébergement interchangeable ;
- React facultatif ;
- CMS facultatif ;
- rendu dynamique facultatif ;
- analytics indépendant du moteur commerce.
Le projet peut donc devenir plus complexe sans avoir besoin d’être entièrement remplacé.
39. Trajectoire technique possible
V1 — Présence digitale
Astro
Tailwind
Content Collections
Netlify
MarketplaceV2 — Édition métier
Astro
Tailwind
CMS
Netlify
MarketplaceV3 — DTC éventuel
Astro
Tailwind
CMS éventuel
Netlify
Commerce adapter
Shopify / autre moteurLa progression correspond aux besoins, et non à une architecture imposée dès le départ.
40. Stack synthétique
| Couche | Choix initial | Évolution possible |
|---|---|---|
| Framework | Astro | Astro conservé |
| Langage | TypeScript | TypeScript |
| CSS | Tailwind CSS | Conservé |
| Interactivité | React islands | React si besoin |
| Produit | Content Collection | CMS/API possible |
| Articles | Markdown/MDX | CMS possible |
| Recettes | Markdown/MDX | CMS possible |
| Hébergement | Netlify | Interchangeable |
| Déploiement | GitHub → Netlify | Conservé ou autre CI |
| Commerce | Marketplace | Shopify/autre |
| Panier | Aucun | Éventuel |
| Backend | Aucun | Functions/API si besoin |
| Base de données | Aucune | Seulement si besoin futur |
| Analytics | GTM + GA4 | Conservé |
| SEO | Astro + GSC | Conservé |
41. Technologies explicitement non retenues au lancement
| Technologie / approche | Décision | Motif principal |
|---|---|---|
| WordPress + WooCommerce | Non | moteur e-commerce et maintenance inutiles au MVP |
| Shopify theme | Non | commerce trop central par rapport au besoin actuel |
| Shopify headless | Pas encore | à ajouter uniquement si DTC réel |
| Next.js | Non | complexité full-stack React non nécessaire |
| Strapi | Non | infrastructure CMS disproportionnée |
| Base SQL | Non | aucune donnée applicative nécessitant une base |
| VPS | Non | administration serveur sans bénéfice suffisant |
| Authentification | Non | aucun compte utilisateur requis |
| Panier | Non | transaction externalisée |
42. Critères de validation de l’architecture
La stack est considérée adaptée si elle permet :
- un build rapide et fiable ;
- des pages rapides ;
- une bonne indexabilité ;
- une source produit unique ;
- des previews simples ;
- des déploiements reproductibles ;
- peu de maintenance ;
- l’ajout simple de contenus ;
- le remplacement du lien marketplace ;
- l’ajout futur d’un CMS sans refonte du frontend ;
- l’ajout futur d’un moteur commerce sans réécriture de l’identité digitale.
43. Décision finale
La stack initiale retenue est :
Astro + TypeScript + Tailwind CSS + Astro Content Collections/MDX + React islands si nécessaire + GitHub + Netlify + GTM/GA4/Search Console.
La transaction reste externalisée vers une marketplace.
Aucun CMS, panier, serveur applicatif ou moteur e-commerce n’est ajouté au MVP sans nécessité démontrée.
Netlify est retenu comme plateforme de déploiement actuelle pour sa simplicité de workflow avec Git et Astro, ses previews et sa capacité à évoluer vers des fonctions serveur si nécessaire.
Ce choix reste volontairement découplé du cœur du projet afin que l’hébergement puisse être remplacé ultérieurement sans remettre en cause l’architecture métier.
44. Conclusion
La stack de Carthania Farm doit refléter la stratégie du projet : simplicité maximale aujourd’hui, possibilités d’évolution demain.
Le site n’est pas une plateforme e-commerce lourde.
C’est d’abord un outil de marque, de contenu, de SEO et de conversion.
Astro fournit une base adaptée à cette nature éditoriale.
Tailwind accélère l’exécution visuelle.
TypeScript et les Content Collections sécurisent les données.
React reste disponible sans devenir une dépendance générale.
Netlify simplifie le cycle développement → preview → validation → production.
La marketplace prend en charge la transaction initiale.
Les couches CMS et DTC restent optionnelles et pourront être ajoutées uniquement lorsque des besoins réels les justifieront.
L’architecture peut ainsi évoluer sans devoir être reconstruite simplement parce que le modèle commercial de Carthania Farm évolue.
Sources techniques officielles consultées
- Astro Documentation — https://docs.astro.build/
- Astro Content Collections — https://docs.astro.build/en/guides/content-collections/
- Astro React Integration — https://docs.astro.build/en/guides/integrations-guide/react/
- Tailwind CSS — Astro installation guide — https://tailwindcss.com/docs/installation/framework-guides/astro
- Netlify — Astro on Netlify — https://docs.netlify.com/build/frameworks/framework-setup-guides/astro/
- Netlify — Deploy overview — https://docs.netlify.com/deploy/deploy-overview/