Alternatives à Vercel après l'incident de sécurité d'avril 2026 : ce qu'il faut évaluer
Point clé : l'incident Vercel d'avril 2026 est une bonne occasion de réexaminer quatre propriétés structurelles de ta plateforme : où se trouve la piste d'audit de l'infrastructure, si les environnements de test incluent la couche de données, comment le périmètre de conformité est défini sur l'ensemble de l'application, et dans quelle mesure le déploiement est portable d'un cloud à l'autre. Ce sont là des questions auxquelles il vaut la peine de répondre, que tu restes sur Vercel ou que tu changes de plateforme.
TL;DRCe qui s'est passé : une intégration tierce connectée au Google Workspace d'un employé a été compromise, et l'accès s'est étendu aux systèmes internes de Vercel. Selon le bulletin publié par 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. La réponse de Vercel a été directe et professionnelle, et n'importe quelle plateforme peut être confrontée à un incident de ce type. Ce que cet incident met en lumière : toutes les plateformes SaaS multi-locataires partagées, y compris Upsun, intègrent une chaîne d'approvisionnement quelque part dans leur architecture. La question qu’il faut se poser après un incident n’est pas de savoir si Vercel est peu sûr. Il s’agit plutôt de déterminer où chaque plateforme trace ses limites, et dans quelle mesure un client peut voir et auditer l’état opérationnel de l’application depuis l’intérieur de ses propres systèmes. Les quatre questions à prendre en compte dans une évaluation :
Les réponses d'Upsun à ces quatre questions concernent les propriétés structurelles de la plateforme plutôt que des fonctionnalités superposées. La suite de cet article passe en revue chacune d'entre elles. |
1. Où se trouve la piste d'audit des modifications d'infrastructure ?
Vercel configure l'infrastructure principalement via le tableau de bord : routes, réécritures, paramètres de fonction, sélection de région, variables d'environnement et intégrations de la marketplace. L'historique indiquant qui a modifié quoi et quand est conservé dans les journaux propres à Vercel, accessibles via l'interface d'administration de Vercel.
Sur Upsun, l’infrastructure est définie dans un fichier `.upsun/config.yaml` situé dans le dépôt Git du client. Les routes, les définitions de services, les workers, les tâches cron, les règles de pare-feu, les relations entre services et les allocations de ressources sont déclarées dans le code. Chaque modification est un commit, revu via le processus de pull request du client, et visible dans le journal Git du client.
Ce que ça change, en cas d’incident de la chaîne d’approvisionnement : la piste d’audit des modifications d’infrastructure est visible depuis les systèmes du client lui-même, et pas seulement depuis ceux du fournisseur.
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'sensitiveion facultatif qui les masque de l'interface utilisateur et de la sortie CLI. La différence se situe un niveau plus haut, dans l'infrastructure qui utilise ces secrets, et non dans les secrets eux-mêmes.
2. Les environnements de test incluent-ils la couche de données ?
Les déploiements en prévisualisation de Vercel attribuent à chaque branche une URL et une version. Pour les modifications qui se trouvent dans le frontend, cela suffit pour livrer en toute confiance. Les services d’arrière-plan (bases de données, files d’attente, magasins d’objets) proviennent généralement de partenaires du Vercel Marketplace tels que Neon, Supabase ou Upstash, configurés par projet, et pointant vers des données de staging partagées ou des données par branche via les fonctionnalités de branchement du partenaire.
Le clonage d'environnement d'Upsun fournit une réplique octet par octet de la production sur chaque branche Git : code, services et données. Les réviseurs examinent l'application en exécution sur une copie complète et isolée de l'état réel de la production, généralement en une minute environ. Des hooks de nettoyage définis en YAML suppriment les informations personnelles identifiables (PII) lors du clonage, ce qui permet aux réviseurs de travailler avec des données réalistes sans toucher aux enregistrements sensibles.
Ce que cela change, dans le contexte de la vérification d'une application pendant ou après un incident : les ingénieurs peuvent inspecter l'état de la production dans un environnement isolé, effectuer des rotations d'identifiants ou des modifications d'intégration sur cet état, et vérifier le résultat avant de toucher à l'environnement de production.
3. Quel est le champ d'application des certifications de conformité de la plateforme ?
Vercel est certifié SOC 2 Type 2 et propose des accords de partenariat HIPAA (Business Associate Agreements) sur les plans Pro et Enterprise. Le champ d'application couvre la partie de la stack gérée par Vercel.
Pour les applications full-stack sur Vercel, les services avec état (bases de données, files d’attente, stockage d’objets) sont généralement fournis par des partenaires du marketplace. Ces partenaires disposent de leurs propres certifications, de leurs propres déclarations de portée et de leurs propres BAA. La posture de conformité d’un client pour l’ensemble de l’application se compose de la portée de Vercel et de celle de chaque partenaire du marketplace, reliées aux points de jonction créés par le client.
Les certifications SOC 2 Type 2 et ISO 27001 d'Upsun, avec les options PCI DSS et HIPAA, couvrent l'ensemble de la plateforme : calcul, bases de données, files d'attente, stockage d'objets, workers, crons et les pipelines qui les déploient. La déclaration de périmètre de conformité et le diagramme d'architecture de l'application constituent un seul et même document.
Pour les équipes du secteur de la santé, des services financiers, du secteur public ou de tout autre contexte B2B où la conformité fait partie des discussions d’approvisionnement, un périmètre sur une plateforme unique est nettement plus simple à défendre qu’un périmètre composite.
4. Dans quelle mesure le déploiement est-il portable entre les clouds ?
Vercel fonctionne sur une infrastructure mondiale gérée par Vercel. Le choix de la région au sein de cette infrastructure est disponible par fonction et par déploiement. Le choix du cloud n'est pas une question à laquelle la plateforme répond.
L'.upsun/config.yamlation d'Upsun est le même fichier, que le projet s'exécute sur AWS, Azure, Google Cloud ou OVH, dans des dizaines de régions. Tu choisis l'hyperscaler lors de la création du projet, et la configuration ne change pas lorsque tu changes d'hyperscaler. Upsun est également disponible sur les marketplaces AWS, Azure, Google et IBM, ce qui permet aux équipes ayant des contrats d'utilisation engagée sur l'un de ces clouds de 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ésormais d'un paramètre de projet plutôt que d'un projet d'ingénierie s'étalant sur un trimestre.
Devrais-tu quitter Vercel ?
Pas nécessairement. Un seul incident ne suffit pas à déterminer si une plateforme convient à une application. Ce qui vaut la peine, c’est de te poser les quatre questions ci-dessus concernant ta plateforme actuelle et toute alternative que tu évalues, et de t’assurer que les réponses correspondent aux besoins réels de ton entreprise.
Pour une application à forte composante front-end avec une surface back-end réduite et sans exigences de conformité réglementaire, Vercel est un bon choix, et une migration n’est probablement pas la bonne utilisation de ce trimestre. Pour une application full-stack avec des aperçus riches en données, des frictions de conformité entre plusieurs fournisseurs ou des exigences en matière de choix de cloud, les réponses sur une plateforme full-stack comme Upsun sont structurellement différentes d’une manière qui a tendance à compter au moment de l’achat.
À quoi ressemble la migration, si tu te lances
Pour la plupart des applications Next.js, la migration consiste principalement à rédiger un fichier .upsun/config.yaml qui décrit le runtime front-end, les services back-end, les bases de données et d’autres composants, ainsi qu’à déplacer les variables d’environnement et le DNS. Comme chaque branche Git sur Upsun dispose d’un environnement de test identique à l’original, les ingénieurs peuvent tester l’application migrée avec des données de production avant de basculer. L'équipe des services applicatifs d'Upsun t'accompagne activement dans les migrations lorsque c'est la bonne solution.
Foire aux questions
Upsun est-il plus sécurisé que Vercel ?
Les deux plateformes détiennent la certification SOC 2 Type 2 et hébergent des applications de production pour des équipes professionnelles. Les différences qui méritent d'être comparées sont d'ordre structurel. Où se trouve la piste d'audit de l'infrastructure : sur Upsun, dans le dépôt Git du client ; sur Vercel, dans l'interface d'administration et les journaux de la plateforme. Composition du périmètre de conformité : les certifications d'Upsun couvrent l'ensemble de la plateforme, y compris les bases de données, les files d'attente et les workers, tandis que celles de Vercel couvrent la couche gérée par Vercel, les partenaires du marketplace disposant de certifications pour les services avec état. Options disponibles : SOC 2 Type 2, ISO 27001, avec options PCI DSS et HIPAA sur Upsun ; SOC 2 Type 2 avec BAA HIPAA sur les plans Pro et Enterprise de Vercel.
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 tous les services sous-jacents dont elle dépend dans .upsun/config.yaml. Le déploiement est piloté par Git, les variables d'environnement sont gérées via la CLI ou la console avec un indicateur d'sensitivee optionnel (le même modèle que propose Vercel), et chaque branche bénéficie d'un environnement de test identique à l'original.
Comment les secrets sont-ils gérés ?
Les variables d'environnement sur Upsun et Vercel sont définies via la CLI ou la console web, et ne sont pas stockées dans le contrôle de version. Le fichier de configuration YAML d'Upsun est explicitement mentionné dans la documentation comme peu adapté aux valeurs de secrets, car il est validé dans Git. Les variables peuvent être marquées comme « sensitive », ce qui masque leurs valeurs dans l'interface utilisateur et la sortie CLI sur les deux plateformes. La différence structurelle entre les deux plateformes ne réside pas dans la manière dont les secrets sont stockés, mais dans l'infrastructure qui les entoure : sur Upsun, cette infrastructure est déclarée dans Git et peut être examinée en même temps que le code de l'application.
Combien de temps dure une migration ?
Pour la plupart des applications, le travail consiste principalement en un exercice de configuration : décrire la stack existante dans .upsun/config.yaml, déplacer les variables d’environnement, couper le DNS. Comme les environnements de test sur Upsun incluent la couche de données, l’application migrée peut être validée par rapport à des données de production avant la bascule. L’équipe des services applicatifs d’Upsun apporte un soutien pratique aux migrations lorsque cela s’avère utile.
Pour en savoir plus
Votre meilleur travail
est à l'horizon
Join our monthly newsletter
Compliant and validated