Comment faire fonctionner une stack web découplée sans quatre tableaux de bord cloud

Découplage et orchestration : gérer des stacks d'applications multiples sur une seule plateforme

À un moment donné dans la vie de la plupart des projets web en pleine croissance, l’architecture se divise. Le frontend passe à un déploiement dédié. Un worker en arrière-plan se sépare pour devenir son propre processus. Une couche API est extraite. C’est généralement le bon choix d’un point de vue technique, mais la complexité opérationnelle qui en découle est rarement prise en compte à l’avance.

Six mois plus tard, on se retrouve avec quatre tableaux de bord cloud, trois comptes de facturation et une section README intitulée « Variables d’environnement » qui fait trois pages et qui est visiblement obsolète.

Comment la prolifération des fournisseurs se produit-elle réellement ?

Point clé : les architectures découplées ne commencent pas par une prolifération des fournisseurs. Elles l’accumulent progressivement, décision après décision, en choisissant « le meilleur outil pour cette tâche spécifique », jusqu’à ce que la surface opérationnelle devienne trop vaste pour être gérée proprement.

Personne ne part avec l’intention de faire tourner son front-end sur Vercel, son API sur Render, ses tâches en arrière-plan sur Railway et sa base de données sur Supabase. Ça se fait décision par décision, chacune étant raisonnable en soi.

Vercel est vraiment efficace pour déployer Next.js. Render permet d’exécuter facilement un backend Django ou FastAPI sans configurer de serveur. Railway propose une interface épurée pour Postgres géré. Chaque choix optimise la résolution d’un problème spécifique, et au moment où tu fais ce choix, le coût d’intégration est reporté.

Mais le coût d’intégration finit toujours par se faire sentir. Il se manifeste sous forme de variables d’environnement qui doivent rester synchronisées entre les quatre fournisseurs. Il se manifeste par le débogage d’une erreur CORS qui ne se produit que dans l’environnement de test, car le front-end y est sur un sous-domaine différent de celui de la production. Il se manifeste par une analyse post-incident qui remonte à une URL codée en dur pointant vers le backend de staging au lieu de celui de production.

Le problème sous-jacent, c’est que les composants de l’application ont été conçus comme un système unique, mais déployés comme des entités distinctes. Le modèle opérationnel ne correspond pas à l’architecture.

Le problème de réseau que personne ne prévoit

Point clé : lorsque les composants d’une application résident sur des plateformes différentes, la communication réseau entre eux est implicite, manuelle et non testée. Une communication réseau interne déterministe, où les adresses des services sont connues au moment de la compilation et ne changent pas d’un environnement à l’autre, élimine toute une catégorie de bugs spécifiques à l’environnement.

Quand un front-end Next.js appelle une API Django, il faut que quelque chose lui indique où se trouve cette API. En pratique, c’est généralement une variable d’environnement : NEXT_PUBLIC_API_URL=https://api.myapp.com. Cette variable a une valeur différente en développement local, dans l’environnement de test, en staging et en production. Garder ces valeurs correctes et synchronisées est un travail manuel qui se fait en dehors du contrôle de version, et ça plante de façons super pénibles à déboguer.

Le mode de défaillance n’est généralement pas dramatique. C’est subtil : un environnement de test qui appelle silencieusement l’API de production parce que quelqu’un a oublié de mettre à jour la variable. Un environnement de staging qui teste avec le backend de la semaine dernière parce que le déploiement ne s’est pas propagé. Une politique CORS qui fonctionne en production mais bloque les requêtes dans l’environnement de branche parce que le domaine d’origine est différent.

Le réseau déterministe contourne le problème en rendant les adresses internes cohérentes et connues. Lorsque deux applications cohabitent dans le même projet Upsun, elles peuvent se joindre via un nom d’hôte interne fixe qui ne change pas d’un environnement à l’autre. Le frontend sait toujours où se trouve le backend sans qu’il soit nécessaire de définir ou de synchroniser une variable d’environnement. L’adresse est déterminée par la configuration du projet, et non par la personne qui a mis à jour en dernier le tableau de bord des secrets.

À quoi pourrait ressembler une configuration multi-applications pour un seul projet

Point clé : définir une stack découplée dans un seul fichier de configuration signifie que les relations entre les applications sont explicites, soumises au contrôle de version et automatiquement reproduites dans chaque environnement, y compris les environnements de test pour chaque branche.

Upsun est une plateforme en tant que service (PaaS) qui gère la couche d’infrastructure de ta stack d’applications, pour que ton équipe n’ait pas à s’en occuper. Pour les projets multi-applications, cela signifie que l’ensemble de la stack — front-end, back-end et services — est défini dans un seul fichier .upsun/config.yaml. Voici un projet avec un front-end Next.js et un back-end Python FastAPI partageant une base de données Postgres :

applications:
  frontend:
    type: nodejs:22
    source:
      root: "frontend"          # path to this app within the repo
    relationships:
      api:                      # gives the frontend a fixed internal address for the backend
        service: "backend"
        endpoint: "http"
    web:
      commands:
        start: "npm run start"

  backend:
    type: python:3.12
    source:
      root: "backend"
    relationships:
      database:                 # wires the backend to the Postgres service below
        service: "db"
        endpoint: "postgresql"
    web:
      commands:
        start: "uvicorn main:app --host 0.0.0.0 --port $PORT"

services:
  db:
    type: postgresql:16         # platform manages patching within this version

routes:
  "https://{default}/":
    type: upstream
    upstream: "frontend:http"   # only the frontend is public; the backend stays internal-only

C’est dans le bloc `relationships` que la configuration réseau est définie. Le frontend a une relation avec le backend appelée « api », ce qui signifie qu’il peut accéder au backend via une adresse interne prévisible. Le backend a une relation avec la base de données. Aucune de ces relations ne nécessite d’URL codée en dur ni de variable d’environnement gérée manuellement en dehors du fichier de configuration.

Lorsqu’un développeur ouvre une branche, la plateforme lance à la fois les applications et la base de données, les relie entre elles selon la même structure de relations et attribue à chacune une adresse interne cohérente. Le frontend de l’environnement de test appelle le backend de l’environnement de test, et non le backend de production.

C’est justement ce que la configuration multi-fournisseurs ne peut pas t’offrir facilement : un isolement des environnements qui s’étend sur l’ensemble du réseau, et pas seulement aux conteneurs d’applications.

Ce qui change sur le plan opérationnel

Point clé : un projet unique pour l’ensemble du stack, ça veut dire un pipeline de déploiement unique, un seul endroit pour consulter les logs, une seule facture et une parité des environnements qui inclut le réseau. La charge opérationnelle liée à l’exploitation d’une architecture découplée diminue considérablement.

Les différences pratiques immédiates sont évidentes. Un seul pipeline de déploiement couvre toute la stack. Les logs du front-end et du back-end se trouvent au même endroit. La facture mensuelle provient d’un seul et même endroit.

La différence la moins évidente concerne l’intégration des nouveaux développeurs et le débogage.

Avec une configuration multi-fournisseurs, un nouveau développeur qui rejoint l’équipe a besoin de comptes sur quatre plateformes, d’un accès à quatre tableaux de bord et d’une bonne compréhension de la façon dont les éléments s’articulent entre eux. La section « Variables d’environnement » du fichier README existe parce qu’il n’y a pas d’autre moyen de documenter une topologie réseau qui se trouve dans les panneaux de configuration de quatre fournisseurs distincts.

Avec une configuration à projet unique, la topologie se trouve dans le fichier de configuration. Un nouveau développeur clone le dépôt, et la configuration lui indique exactement en quoi consiste le stack, comment les composants s’articulent entre eux et quelle version de chaque élément est en cours d’exécution. La section du README consacrée aux variables d’environnement est alors bien plus courte.

Il en va de même pour le débogage. Quand un problème survient à la frontière entre le front-end et le back-end, les logs concernés se trouvent au même endroit. Le réseau qui les relie est défini dans le même fichier que tout le reste. Pas besoin de passer d’un tableau de bord à l’autre ni de recouper les horodatages entre quatre interfaces de logging distinctes.

Tu utilises déjà plusieurs fournisseurs ?

La migration ne nécessite pas de tout déplacer d’un seul coup. Le fichier de configuration décrit l’état cible du stack ; une approche pratique consiste donc à commencer par un seul composant, généralement le backend et sa base de données, à le définir dans Upsun, puis à mettre en place le réseau interne à partir de là. Le problème du README multi-fournisseurs commence à s’atténuer dès le premier service migré.

Foire aux questions (FAQ)

Les applications d’un projet peuvent-elles utiliser des langages et des environnements d’exécution complètement différents ?

Oui. Un projet peut contenir un front-end Node.js, un back-end Python et un processus de travail Java, chacun s’exécutant dans son propre conteneur isolé. La plateforme gère la communication entre eux, peu importe avec quoi ils ont été développés.

Comment le front-end connaît-il l’adresse interne du back-end ?

Upsun injecte les informations de relation sous forme de variables d’environnement au moment de l’exécution. Le front-end reçoit un ensemble de variables décrivant comment atteindre le back-end : hôte, port et schéma. Celles-ci sont cohérentes d’un environnement à l’autre, ce qui permet au même code d’application de fonctionner dans toutes les branches sans modification.

Comment ça se passe pour la communication réseau dans les environnements de test ?

Chaque environnement de branche dispose de sa propre instance isolée de chaque application du projet, reliées entre elles selon la même structure de relations qu’en production. Le frontend d’un environnement de branche appelle le backend de ce même environnement de branche. Les liaisons de relations dans un environnement de branche pointent vers les services propres à cet environnement, et non vers ceux de la production.

Est-ce que ça veut dire que tous les services doivent être définis dans un seul dépôt ?

Pas forcément. Upsun prend en charge les opérations sur le code source et les intégrations externes qui permettent aux composants de résider dans des dépôts séparés tout en étant orchestrés comme un seul projet. Pour la plupart des équipes qui débutent, un seul dépôt est plus simple, mais la plateforme ne l’impose pas.

En quoi est-ce différent de Docker Compose ?

Docker Compose gère l’orchestration du développement local. Il ne gère pas les déploiements, la parité des environnements, la mise à l’échelle ni la mise en réseau entre plusieurs environnements de production. Un seul fichier de configuration de projet Upsun couvre tout ça, de l’environnement de branche du développeur jusqu’à la production, avec la même configuration.