Vercel vs Upsun : comparaison de l'architecture des plateformes après l'incident d'avril 2026

Point clé : L'incident Vercel d'avril 2026 est une bonne occasion de réexaminer où se trouve la piste d'audit des changements d'infrastructure, comment se compose le périmètre de conformité d'une application full-stack et dans quelle mesure le déploiement est portable d'un cloud à l'autre. La réponse structurelle d'Upsun est un modèle natif Git, défini en YAML, qui couvre l'ensemble de l'application.

I. L'architecture d'un compromis

Point clé : la surface d'exposition de toute plateforme hébergée inclut la chaîne d'approvisionnement du fournisseur lui-même. La visibilité de cette surface du point de vue du client varie d'une plateforme à l'autre.

L'incident de sécurité de Vercel en avril 2026 a pris naissance dans un outil tiers connecté au Google Workspace d'un employé et s'est propagé aux systèmes internes de Vercel. Selon le bulletin de Vercel, l'impact sur les clients a été limité, et Vercel a fait appel à des experts en réponse aux incidents et a averti les forces de l'ordre. N'importe quelle plateforme peut être confrontée à un incident, et la gestion de Vercel a été directe et professionnelle.

Ce que cet incident met en évidence, c'est une caractéristique du modèle SaaS multi-tenant partagé, et non un échec de Vercel en particulier. Chaque plateforme partagée, y compris Upsun, comporte une chaîne d'approvisionnement quelque part dans son architecture. La question qu'il convient de se poser est de savoir où chaque plateforme trace ses limites, et quelle partie de la surface opérationnelle de l'application un client peut voir et auditer de son côté.

La différence structurelle sur Upsun ne réside pas dans la manière dont les secrets sont stockés. Les variables d’environnement fonctionnent de manière similaire sur les deux plateformes : les valeurs sont définies via l’interface en ligne de commande (CLI) ou la console, avec un indicateur d’sensitive, activable, qui les masque de l’interface utilisateur. La différence se situe un niveau plus haut, dans la manière dont l’infrastructure elle-même est définie et révisée.

Sur les plateformes pilotées par un tableau de bord, la configuration des routes, des réécritures, des paramètres de fonction, de la sélection de région et du câblage d’intégration se trouve dans l’interface d’administration de l’opérateur de la plateforme. Les journaux d’audit de ces modifications se trouvent dans les journaux de la plateforme, derrière le modèle d’accès de celle-ci.

Sur Upsun, cette configuration se trouve dans un fichier d’.upsun/config.yaml au sein du dépôt Git du client. Chaque modification apportée à une définition de service, une route, une règle de pare-feu ou un profil de ressource est un commit, revu via le processus de pull request du client, et visible dans son journal Git. La piste d’audit des changements d’infrastructure est celle que l’équipe d’ingénierie gère déjà pour le code des applications.

II. Où se trouve la piste d'audit de l'infrastructure

Point clé : la piste d'audit des changements d'infrastructure doit être visible depuis les systèmes du client lui-même, et pas seulement depuis ceux du fournisseur.

Les équipes choisissent Vercel parce que l'expérience développeur autour du runtime front-end et du flux de prévisualisation est bonne. Pour les équipes dont le backend se compose d'une base de données gérée et d'une poignée de fonctions, cet atout est décuplé. Le compromis apparaît lorsque l'application dépasse ce stade, et que la surface opérationnelle en dehors du front-end nécessite le même niveau de visibilité et de révision que le code.

Upsun traite la définition de l'infrastructure comme du code, ce qui modifie ce qui est auditable du côté du client :

• L'infrastructure dans Git. Les routes, les services, les workers, les crons, les règles de pare-feu, les relations entre services et les allocations de ressources sont déclarés dans des fichiers d'.upsun/config.yamls dans ton dépôt. Chaque modification est un commit, révisé via ton processus de pull-request, visible dans ton journal Git. La piste d'audit des modifications d'infrastructure est la même que celle que l'équipe d'ingénierie gère déjà pour le code de l'application.
• Les secrets en dehors du fichier de configuration, avec une parité sur le drapeau lui-même. Les variables d’environnement sur Upsun et Vercel utilisent un drapeau d’sensitive optionnel qui masque les valeurs de l’interface utilisateur et de la sortie CLI. La différence structurelle ne réside pas dans le drapeau. C'est qu'sur Upsun, l'infrastructure qui utilise ces secrets (quels services existent, quelles relations ils ont, sous quelle configuration de pare-feu ils fonctionnent) est gérée par contrôle de version, donc les modifications apportées à cette infrastructure sont vérifiables en dehors des journaux du fournisseur.
• Relations explicites entre les services. Sur Upsun, un service ne reçoit les identifiants et les informations de connexion d’un autre service que par le biais d’une déclaration d’relationshipss en YAML. Le graphe de connexion entre tes services est déclaré dans le code, et non implicite dans les paramètres par défaut de la plateforme.
• Règles de pare-feu sortantes par service. La propriété « firewall » dans « .upsun/config.yaml » limite les hôtes externes auxquels chaque service peut accéder, et est déclarée en même temps que la définition du service. La configuration réseau sortante est examinée dans la même pull request que le code qui l'utilise.

III. Portabilité entre les clouds, définie dans le code

Point clé : un modèle de déploiement auprès d’un seul fournisseur facilite beaucoup de décisions, mais rend ces décisions plus difficiles à revoir par la suite. La portabilité entre les clouds est une propriété structurelle qui réduit ce coût.

Lorsqu’un incident, une exigence d’approvisionnement ou un changement de périmètre de conformité soulève la question « pouvons-nous faire tourner ça ailleurs ? », la réponse dépend du degré d’enracinement de l’application dans l’environnement d’exécution d’un fournisseur. Si la logique de déploiement est spécifique à une seule plateforme, le transfert implique une réécriture. Si la logique de déploiement est générique, le transfert se résume à un changement de configuration.

L'.upsun/config.yamlation d'Upsun est le même fichier, que le projet tourne sur AWS, Azure, Google Cloud ou OVH, dans des dizaines de régions. Tu choisis l'hyperscaler quand tu crées le projet, et la configuration ne change pas quand tu changes d'hyperscaler. Upsun est également disponible sur les marketplaces AWS, Azure, Google et IBM, donc les équipes ayant déjà des contrats d'engagement d'utilisation sur l'un de ces clouds peuvent les appliquer à leur utilisation d'Upsun.

Ton application s'exécute dans des environnements gérés par Upsun sur l'hyperscaler de ton choix. La portabilité réside dans la configuration, et non dans l'emplacement physique de l'infrastructure. Ce qui change, c'est le coût lié à la réévaluation du choix du cloud : il s'agit d'un paramètre de projet plutôt que d'un projet d'ingénierie s'étalant sur un trimestre.

Pour les équipes dont la feuille de route inclut des clients soumis à une réglementation, des exigences de région souveraine ou des achats d'entreprise qui posent des questions sur les préférences en matière d'hyperscaler, cette flexibilité fait souvent la différence entre un « oui » et un changement de plateforme.

Foire aux questions

Upsun est-il plus sécurisé que Vercel ?

Les deux plateformes détiennent des certifications SOC 2 Type 2 et sont utilisées en production par des équipes sérieuses. Les différences qui méritent d'être comparées sont d'ordre structurel. Où se trouve la piste d'audit des changements d'infrastructure : sur Upsun, dans le dépôt Git du client ; sur Vercel, dans l'interface d'administration et les journaux de la plateforme. Comment se compose le périmètre de conformité pour une application full-stack : les certifications d’Upsun couvrent l’ensemble de la plateforme, y compris les bases de données, les files d’attente, le stockage d’objets et les workers, tandis que le périmètre SOC 2 de Vercel couvre la couche Vercel et que les BAA HIPAA sont disponibles sur les plans Pro et Enterprise, les partenaires du marketplace disposant de leurs propres certifications pour les services avec état. Quelles sont les options disponibles : Upsun propose SOC 2 Type 2, ISO 27001, avec des options PCI DSS et HIPAA sur l'ensemble de la plateforme.

Est-ce qu'Upsun prend en charge Next.js ?

Oui. Next.js est un runtime de premier choix sur Upsun. Tu définis l'application et ses services sous-jacents (bases de données, caches, recherche, files d'attente) dans .upsun/config.yaml. Les variables d'environnement sont définies via la CLI ou la console Upsun et peuvent être marquées comme sensibles afin que leurs valeurs soient masquées dans l'interface utilisateur et la sortie de la CLI, selon le même modèle d'opt-in que propose Vercel. Chaque branche Git reçoit un clone identique à l'environnement de production (code, données et services), ce qui est utile pour valider l'application avant de basculer depuis une autre plateforme.

Combien de temps faut-il pour migrer depuis Vercel ?

Pour la plupart des applications Next.js, la migration consiste principalement à rédiger un fichier `.upsun/config.yaml` qui décrit l'application et ses services, puis à déplacer les variables d'environnement et le DNS. Comme chaque branche sur Upsun reçoit un environnement de test cloné octet par octet depuis la production (code, données et services), tu peux exécuter l'application entièrement migrée sur des données conformes à la production avant de basculer. L'équipe des services applicatifs d'Upsun t'accompagne activement dans les migrations lorsque c'est la meilleure solution.