Command Palette

Search for a command to run...

Unlumen
Web

Architecture technique

Choisir le bon mode de rendu selon le contexte.

Architecture technique

Il n'y a pas d'architecture universelle. Le bon choix dépend de votre contenu, de vos besoins d'édition et de vos contraintes SEO. On vous aide à faire le bon arbitrage.


Modes de rendu

Avec Next.js, on a trois options principales. Chacune a ses forces :

SSG (Static Site Generation)

Les pages sont générées au build. Parfait pour le contenu qui ne change pas souvent.

Quand l'utiliser :

  • Sites vitrines, blogs, documentation
  • Contenu mis à jour occasionnellement
  • Maximum de performance

Avantages :

  • Ultra-rapide (fichiers servis depuis un CDN)
  • Excellent pour le SEO
  • Coût d'hébergement minimal

SSR (Server-Side Rendering)

Les pages sont générées à chaque requête. Pour le contenu dynamique ou personnalisé.

Quand l'utiliser :

  • Données qui changent en temps réel
  • Contenu personnalisé par utilisateur
  • Applications avec authentification

Avantages :

  • Données toujours fraîches
  • Personnalisation possible
  • SEO préservé

ISR (Incremental Static Regeneration)

Le meilleur des deux mondes : pages statiques qui se mettent à jour en arrière-plan.

Quand l'utiliser :

  • Blogs avec beaucoup de contenu
  • E-commerce avec catalogue qui évolue
  • Sites avec beaucoup de pages

Avantages :

  • Performance du statique
  • Fraîcheur du dynamique
  • Pas de rebuild complet

Comment on structure le code

Composants petits et réutilisables

Un composant = une responsabilité. Si un composant fait plus de 100 lignes, il faut le découper.

Séparation des responsabilités

  • UI — composants d'affichage, sans logique métier
  • Hooks — logique réutilisable (fetching, state)
  • Utils — fonctions pures, helpers
  • Types — définitions TypeScript centralisées

Conventions documentées

Chaque projet a un README qui explique :

  • La structure des dossiers
  • Les conventions de nommage
  • Comment lancer le projet en local
  • Comment déployer

Intégrations courantes

CMS headless

Pour les équipes qui éditent du contenu régulièrement. On configure Sanity, Strapi ou Contentful selon vos besoins et on documente l'utilisation.

APIs tierces

Paiement (Stripe), emailing (Resend), analytics (GA4, Plausible), CRM... On intègre proprement avec gestion d'erreurs et fallbacks.

Webhooks

Pour synchroniser les données entre services (CMS → rebuild, formulaire → CRM, etc.).


Sécurité

On ne néglige jamais la sécurité :

  • Headers de sécurité — CSP, HSTS, X-Frame-Options configurés
  • Validation côté serveur — on ne fait jamais confiance aux données front
  • Variables d'environnement — secrets jamais dans le code
  • Rate limiting — protection contre les abus sur les APIs
  • RGPD — collecte minimale, consentement géré