Vercel + OVH : la souveraineté pragmatique vs la souveraineté religieuse

Cette semaine, nous avons migré l'architecture de Capitole Tech. Pas en aveugle, pas en suivant un dogme : en séparant proprement deux usages que beaucoup de cabinets MSSP confondent. La vitrine marketing, et l'infrastructure de production qui héberge les données clients. Voici comment nous décidons — et pourquoi mélanger les deux est l'erreur la plus chère en cybersécurité française.

Le piège de la souveraineté religieuse

Le discours dominant chez les MSSP français en 2026 ressemble à ça : « 100 % cloud souverain, 100 % France, 100 % OVH ou Outscale ». L'intention est bonne. La traduction technique est souvent désastreuse. Parce que tout ce qui n'a pas de données clients dedans — la vitrine marketing, les images, les fonts, les fichiers statiques — n'a aucune raison d'être hébergé dans un datacenter souverain. Le datacenter souverain coûte plus cher, sert moins de visiteurs, et donne une moins bonne perception d'expertise au RSSI qui audite votre site.

Notre architecture pratique

Nous séparons strictement deux périmètres. Premier périmètre : capitole.tech (vitrine, blog, lead magnets, agents de démonstration). Tourne sur Vercel, CDN mondial Cloudflare, Lighthouse 100/100, zéro donnée client manipulée. Deuxième périmètre : prod cliente (portails sécurité, dashboards SOC, données vos audits). Tourne sur OVHcloud Public Cloud (SecNumCloud-ready) dans nos datacenters Gravelines et Strasbourg, isolé, audité, conforme HDS/NIS2.

Périmètre 1 — la vitrine : pourquoi Vercel reste le bon choix

Vercel n'héberge aucune donnée nominative. Il sert du HTML, des fonts, des images Next.js optimisées. Son CDN edge — environ 90 PoPs dans le monde — délivre la première page en moins de 50 ms à un visiteur n'importe où. Pour un site marketing qui doit convertir, c'est imbattable. Et le coût Hobby est de zéro pour 100 GB de bande passante mensuelle, ce qui couvre largement les besoins d'une vitrine cabinet.

Périmètre 2 — la prod : pourquoi OVH est non-négociable

À la seconde où nous touchons une donnée client — un cyberscore audit, un log SOC, un rapport NIS2 — nous bascule sur OVHcloud. Datacenter français, propriétaire français, droit français, opérateur d'importance vitale au sens LPM. Pas de Cloud Act. Pas de FISA. Pas de juridiction US qui pourrait demander un accès. C'est notre argument boardroom face à un RSSI : le datacenter qui hosts vos données est connu, auditable, contraint par le seul droit français.

Notre stack OVH technique de A à Z

Sur un VPS OVH Essential (4 Go RAM, 12 €/mo, Debian 12), nous déployons une stack Docker composée de trois services : l'application Next.js en build standalone (le mode qui ne ship que les dépendances effectivement utilisées, et non l'intégralité de node_modules), un proxy LiteLLM qui expose une API OpenAI-compatible vers Anthropic/OpenAI/Mistral, et un reverse proxy Caddy qui obtient automatiquement un certificat TLS Let's Encrypt en moins de 30 secondes après que les DNS soient propagés.

dockerfile
# Build minimal Next.js 16 — image finale ~150 Mo au lieu de 1.5 Go
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
USER node
CMD ["node", "server.js"]

Le piège du build standalone

Sans la directive output: "standalone" dans next.config.ts, ce Dockerfile produit une image qui démarre, écoute sur le port 3000, mais ne sert que des erreurs 500. Le mode standalone est ce qui permet à Next.js de tracer chaque import utilisé au runtime et de ne packager qu'eux. Un projet Capitole Tech typique passe de 1,5 Go (avec node_modules complet) à 150 Mo (standalone). C'est aussi ce qui rend le redéploiement rapide : Docker pull devient 30 secondes au lieu de 4 minutes.

Une erreur qui nous a coûté deux builds

Pendant cette migration, Next.js 16 nous a retourné une erreur RSC stricte que nous n'avons jamais croisée auparavant : « Functions cannot be passed directly to Client Components ». Notre composant Timeline (animations Framer Motion, donc "use client") recevait en prop une référence d'icône lucide-react — un objet forwardRef. Next.js 16 refuse désormais de sérialiser ce type d'objet à travers la boundary Server→Client. La règle nouvelle : on passe des éléments JSX déjà rendus (ReactNode), pas des références de composant.

tsx
// ❌ KO en Next.js 16
const steps = [{ Icon: Search, ... }];
<Timeline steps={steps} />

// ✅ OK
const steps = [{ icon: <Search size={20} />, ... }];
<Timeline steps={steps} />

Critères de bascule : quand migrer 100 % sur OVH ?

Trois conditions doivent être réunies avant d'abandonner Vercel pour la vitrine :

1. 1Le site collecte des données nominatives directement (formulaires consentement RGPD avec stockage long terme, pas juste un mailto)
2. 2Le trafic dépasse 100 GB/mois et le coût Vercel commence à exploser
3. 3L'argument souveraineté est le critère #1 du pitch (cabinets sous contrôle Bâtonnier, OIV, opérateurs santé)

Tant que ces trois conditions ne sont pas réunies, l'hybride Vercel-vitrine + OVH-prod reste défendable, mesurable et économiquement optimal. Le jour où elles le sont, nous migrons en cinq minutes (modification DNS : remplacer 76.76.21.21 par l'IP du VPS OVH). Le code applicatif ne change pas d'une ligne.

L'argument de pitch boardroom

Notre vitrine tourne sur Vercel — CDN mondial, performance 100 sur 100, zéro donnée client. Notre infrastructure de production cliente, elle, est sur OVHcloud souverain France, droit français, opérateur d'importance vitale. Deux usages, deux choix techniques rigoureux. Pas un dogme, une architecture.— Capitole Tech, méthode publique

Cette nuance — la séparation propre entre vitrine et production — démontre quelque chose qu'aucun discours marketing ne peut faire : la maîtrise des trade-offs techniques. Un RSSI qui entend ça reconnaît un interlocuteur qui ne récite pas un manifeste, mais qui pense en architecte.