---
title: "La couche Web sur Vercel"
description: "Exécutez la couche Web de Quire sur Vercel avec un worker compagnon."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/fr/llms.txt
> Use this file to discover all available pages before exploring further.

# La couche Web sur Vercel

<span id="the-web-tier-on-vercel"></span>

La conception est décrite dans la section 5 de `docs/architecture/23-ops.md`. Vercel exécute uniquement la couche Web. Tout le reste fonctionne sur un hôte compagnon que vous gérez ; il est indispensable.

## État dans cette version <!--quire:status-in-this-release-->

La configuration est en place (`apps/web/vercel.json`, préréglage Nitro `vercel` et contrôles au démarrage). Vercel nécessite un stockage de fichiers partagé (`QUIRE_STORAGE_DRIVER=s3` ou `azure`), un moteur temps réel fonctionnant sur plusieurs instances de fonctions (`QUIRE_REALTIME_DRIVER=sse` ou `centrifugo`) et un fournisseur d’e-mails HTTP. Sans ces éléments, la couche Web refuse de démarrer et son journal nomme chaque paramètre manquant.

## Composants <!--quire:the-pieces-->

| Composant | Lieu d’exécution |
| --- | --- |
| `web` | Vercel Functions, environnement Node : pages, REST, MCP, LTI et réception des webhooks |
| `worker`, `scheduler`, `collab`, `content` | Hôte compagnon : Fly, Railway, ECS ou votre propre hôte Docker avec `docker/compose.yaml` |
| Postgres | Externe, derrière un répartiteur de connexions aux transactions : Neon, Supabase ou RDS avec PgBouncer |
| Fichiers | S3 ou R2. Aucun disque persistant n’est disponible |
| Travaux d’arrière-plan | Placés en file avec pg-boss dans la transaction de la requête, puis exécutés par le worker compagnon. Avec `QUIRE_QUEUE_DRIVER=vercel` sur celui-ci, les travaux légers (envois non ordonnés de notifications et de webhooks) passent par Vercel Queues (`VERCEL_QUEUE_REGION`, `VERCEL_QUEUE_TOKEN`) ; Postgres mutualisé n’est donc pas interrogé pour eux |
| Travaux récurrents | Scheduler compagnon. Il n’existe pas de route Vercel Cron, car une tâche effectuée dans une fonction dépasserait son délai maximal |
| Traçage | OpenTelemetry vers votre collecteur, `OTEL_EXPORTER_OTLP_ENDPOINT` |

## Limites de cette cible <!--quire:what-this-target-cannot-do-->

La couche Web vérifie les points suivants au démarrage et refuse de démarrer en nommant chaque problème, au lieu d’échouer plus tard lors du premier e-mail non envoyé :

- **Pas de SMTP.** Vercel bloque les connexions SMTP sortantes. Définissez `QUIRE_EMAIL_PROVIDER_CONFIG` avec un fournisseur HTTP (Postmark, SES, Mailgun, SendGrid ou Resend). `QUIRE_SMTP_URL` est refusé.
- **Pas de disque local.** `QUIRE_STORAGE_DRIVER=local` est refusé.
- **Pas de mémoire partagée entre les appels.** `QUIRE_REALTIME_DRIVER=inprocess` est refusé. Les événements envoyés par le serveur sont limités par le délai maximal de la fonction ; le client se reconnecte avec un curseur, donc aucun événement n’est perdu, mais la présence n’est pas disponible.
- **Le nombre de bases de données de locataires épinglées est limité** à environ huit, car chacune crée un autre pool de connexions dans un environnement où ces pools ne peuvent pas être partagés.

## Déploiement <!--quire:deploying-->

1. Créez un projet Vercel à partir du dépôt et définissez **Root Directory** sur `apps/web`. `apps/web/vercel.json` configure les commandes d’installation et de compilation (`NITRO_PRESET=vercel`) et sert `/sw.js` sans mise en cache.
2. Définissez les variables d’environnement. À partir de `docker/.env.example`, il faut au minimum : `QUIRE_DEPLOY_TARGET=vercel`, `QUIRE_APP_ORIGIN`, `QUIRE_CONTENT_ORIGIN`, `QUIRE_PLATFORM_DOMAINS`, `QUIRE_SECRET_KEY`, `QUIRE_MASTER_KEY`, `DATABASE_URL` (adresse du répartiteur), `QUIRE_REPORT_DATABASE_URL`, `QUIRE_AUDIT_DATABASE_URL`, `QUIRE_DATABASE_ID`, `QUIRE_EMAIL_PROVIDER_CONFIG`, `QUIRE_MAIL_FROM`, les paramètres de stockage, et `QUIRE_COLLAB_URL` et `QUIRE_COLLAB_SIGNING_KEY` pointant vers le service collab de l’hôte compagnon.
   `QUIRE_REPORT_DATABASE_URL` concerne la base de données physique nommée dans `DATABASE_URL`. Pour toute autre base enregistrée, ajoutez son URL de connexion `quire_report` aux environnements Web et worker, puis enregistrez le nom de sa variable d’environnement sous `env:NAME` dans la console de la plateforme. Si l’URL de rapport de cette base manque, Analytics échoue de façon sécurisée.
3. Sur l’hôte compagnon, exécutez `docker/compose.yaml` sans le service `web`, avec le même `docker/.env` :
   ```sh
   docker compose -f docker/compose.yaml up -d migrate init worker scheduler collab content
   ```
   Les migrations s’y exécutent avant l’activation de chaque déploiement Vercel.
4. Déployez. Si la configuration est refusée, le journal de la fonction commence par "The web tier did not start on vercel" et répertorie les paramètres à modifier.

## Mise à niveau <!--quire:upgrading-->

Commencez par migrer depuis l’hôte compagnon, activez ensuite le nouveau déploiement Vercel, puis mettez à jour les workers compagnons : respectez l’ordre indiqué dans [upgrade.md](/fr/ops/upgrade/). Le retour immédiat à un déploiement Vercel précédent constitue un retour à une version antérieure du code et reste toujours sûr au sein d’une version.

Source: https://docs.quirelms.com/fr/ops/vercel/index.mdx