11. Hébergement ‐ Déploiement - BlacF0X/owl GitHub Wiki

Rapport sur l'Architecture d'Hébergement et la Stratégie de Déploiement

Date : 22 octobre 2025

Synthèse

Ce document décrit l'architecture d'hébergement et la stratégie de déploiement continu (CI/CD) retenues pour l'application "Project OwL". L'approche adoptée vise à garantir la robustesse, la scalabilité et l'agilité du projet en s'appuyant sur des plateformes modernes et des pratiques de développement automatisées.

La stratégie repose sur trois piliers fondamentaux :

  1. Une architecture découplée (headless), avec une séparation nette entre le service frontend et les services backend.
  2. L'utilisation de plateformes spécialisées : Vercel pour le frontend Next.js et Render pour le backend et la base de données.
  3. Une pipeline de déploiement automatisée via GitHub Actions, gérant des environnements distincts de staging (pré-production) et de production.

1. Architecture d'Hébergement

L'hébergement de l'application est divisé en deux pôles distincts pour optimiser la performance, la sécurité et la maintenance de chaque partie du système.

1.1 Hébergement du Frontend (Application Next.js)

  • Plateforme choisie : Vercel

    • Justification : Vercel est la plateforme développée par les créateurs de Next.js, offrant une intégration native et des optimisations de performance inégalées (distribution via CDN global, optimisation des images, Serverless Functions). Son expérience développeur simplifie radicalement le processus de mise en ligne.

  • Configuration :

    • Le projet Vercel est directement lié au dépôt GitHub du projet.
    • Les commandes de build (next build) et les configurations de sortie sont gérées automatiquement par Vercel, qui détecte un projet Next.js.
    • Variables d'Environnement : La configuration la plus critique consiste à définir les variables d'environnement sur Vercel. Celles-ci permettent à l'application frontend de communiquer avec le backend. Une variable NEXT_PUBLIC_API_URL sera définie, dont la valeur pointera vers l'URL du service backend sur Render. Vercel permet de définir des valeurs différentes pour chaque environnement (Production, Staging/Preview).

  • Mise en place :

    1. Créer un compte Vercel et le lier au compte GitHub.
    2. Importer le dépôt du projet sur Vercel.
    3. Configurer les variables d'environnement pour les environnements de production et de staging.

1.2 Hébergement du Backend et de la Base de Données

  • Plateforme choisie : Render

    • Justification : Render offre une solution simple et puissante pour héberger des services web et des bases de données. Son principal avantage réside dans son réseau privé interne, qui permet au service backend et à la base de données de communiquer de manière sécurisée et à faible latence, sans exposer la base de données à l'internet public.

  • Composition des Services sur Render :

    1. Service Web (Backend) : Une instance de service web (ex: Node.js, Python, Go) qui exécute l'API de l'application. Render se charge de construire et de déployer le service à partir du code source du dépôt GitHub.
    2. Base de Données PostgreSQL : Une instance de base de données PostgreSQL gérée par Render, assurant la persistance des données.

  • Configuration :

    • La configuration peut être définie via l'interface de Render ou, de manière plus robuste, via un fichier render.yaml à la racine du projet (Infrastructure as Code).
    • Variables d'Environnement : Le service backend est configuré avec des variables d'environnement, notamment l'URL de connexion à la base de données (fournie par Render via le réseau privé) et d'autres secrets (clés d'API tierces, etc.).
    • Migrations de Base de Données : La commande de build du service backend sur Render sera configurée pour exécuter automatiquement les scripts de migration de la base de données avant de démarrer le serveur. Cela garantit que le schéma de la base est toujours synchronisé avec le code de l'application.

  • Mise en place :

    1. Créer un compte Render et le lier au compte GitHub.
    2. Définir les services via un fichier render.yaml ou l'interface web.
    3. Configurer les variables d'environnement et les secrets pour les environnements de production et de staging.

2. Stratégie de Déploiement

Le déploiement est entièrement automatisé à l'aide de GitHub Actions pour assurer un processus rapide, fiable et sans intervention manuelle.

2.1 Pipeline d'Intégration et de Déploiement Continus (CI/CD)

Le processus est orchestré par des workflows GitHub Actions définis dans le dépôt (.github/workflows/). Ces workflows sont déclenchés par des événements Git spécifiques, principalement la fusion de branches (merge).

2.2 Gestion des Environnements

La stratégie s'articule autour de deux environnements principaux, chacun associé à une branche Git :

  1. Environnement de Staging (Pré-production)

    • Branche associée : develop.
    • Objectif : Fournir un miroir de l'environnement de production pour effectuer des tests d'intégration, des démonstrations et valider les nouvelles fonctionnalités dans des conditions réelles avant leur mise en production.
    • Déclenchement : Un merge sur la branche develop.
    • Processus automatisé :
      1. Le workflow GitHub Actions se lance.
      2. Il exécute les tests automatisés (unitaires, intégration) et les vérifications de qualité de code (linting).
      3. Si les tests réussissent, le workflow déploie la dernière version du frontend sur l'environnement de staging de Vercel.
      4. En parallèle, il déploie la dernière version du backend sur le service de staging de Render (ce qui inclut l'exécution des migrations de base de données).

  2. Environnement de Production

    • Branche associée : main.
    • Objectif : L'application accessible aux utilisateurs finaux. Cet environnement doit être stable et performant.
    • Déclenchement : Un merge sur la branche main (généralement depuis la branche develop après validation en staging).
    • Processus automatisé :
      1. Un workflow GitHub Actions, similaire à celui de staging, se déclenche.
      2. Il exécute la même suite de tests pour une double vérification.
      3. Si tout est conforme, il déploie le frontend sur l'environnement de production de Vercel.
      4. Il déploie le backend sur le service de production de Render.

2.3 Gestion des Secrets avec Doppler

Pour centraliser et sécuriser la gestion des informations sensibles (clés d'API, tokens, URL de base de données), le projet utilise Doppler comme unique source de vérité. Cette approche remplace la gestion manuelle des secrets dans chaque environnement et service.

  • Principe : Doppler est une plateforme de gestion des secrets qui permet de stocker, gérer et synchroniser les variables d'environnement sur différentes plateformes. Pour ce projet, un projet Doppler est créé avec des configurations distinctes pour les environnements staging et production.

  • Intégration dans la pipeline CI/CD :

    1. Centralisation sur Doppler : Toutes les informations sensibles pour Vercel et Render sont définies dans les configurations correspondantes sur Doppler.
    2. Unique Secret sur GitHub : Le seul secret stocké dans les "Secrets GitHub" est un token de service Doppler (DOPPLER_TOKEN). Ce token accorde un accès en lecture seule aux secrets d'un environnement spécifique (staging ou production).
    3. Récupération à la volée : Au moment de l'exécution d'un workflow GitHub Actions (pour le staging ou la production), une étape dédiée utilise le CLI de Doppler pour récupérer les secrets pertinents.
    4. Injection dans l'environnement : Ces secrets sont ensuite injectés comme variables d'environnement dans les étapes de déploiement vers Vercel et Render, assurant que les applications disposent toujours de la configuration la plus à jour sans jamais exposer les secrets dans les logs ou le code source.

Cette méthode renforce la sécurité en limitant la dissémination des secrets, simplifie leur rotation et garantit une configuration cohérente entre tous les environnements.