Au-delà du front-end : choisir entre Vercel et Upsun pour les applications full-stack en 2026

Si tu développes une application web moderne en 2026, Vercel figure très certainement sur ta liste de favoris, et probablement en tête de celle-ci. L'expérience développeur que Vercel a mise en place pour Next.js et l'écosystème front-end qui l'entoure est une véritable réussite. Pousse une branche, obtiens une URL de prévisualisation, déploie. Ça marche, c'est rapide, et toute une génération d'équipes front-end a construit son processus autour de ça.

Cet article n’a pas pour but de contester tout cela.

Il est là parce que les applications que les équipes développent ont dépassé la partie de la stack autour de laquelle Vercel a été conçu, et que les questions auxquelles une équipe full-stack doit répondre au sujet d’une plateforme sont différentes de celles auxquelles une équipe front-end doit répondre. Où se trouvent les données. Ce que couvre la conformité. Sur quel cloud l’application tourne. Comment l’infrastructure est décrite et révisée. Si les services backend bénéficient du même traitement que le front-end.

Il s’agit d’une comparaison structurelle des deux plateformes sur les aspects qui ont tendance à compter dès lors qu’une application ne se limite plus à son front-end. L’objectif est de t’aider à prendre une décision en toute honnêteté, pas de te donner la réponse.

En quoi les deux plateformes divergent stratégiquement

Le centre de gravité de Vercel, c'est le runtime front-end et l'expérience développeur qui l'entoure. Les ajouts récents à la plateforme, Fluid Compute pour un serveur sans serveur JavaScript et Python efficace, Vercel Sandbox pour le calcul éphémère dans les microVM Firecracker, et l’intégration étroite avec Next.js, renforcent tous ce centre. La force de la plateforme réside dans l’excellence de la couche front-end et dans son extension vers l’extérieur via une place de marché d’intégrations pour les éléments qui l’entourent.

Upsun part d’un centre différent. La plateforme est conçue pour exécuter une application complète — front-end, services back-end, bases de données, files d’attente, workers, caches, tâches cron et tout ce qui les relie — sous une seule configuration déclarative, à l’intérieur d’une seule limite de gouvernance, sur le cloud de ton choix. L’accent est mis sur le traitement de l’application dans son ensemble comme une unité, plutôt que sur la superposition des éléments environnants autour d’un noyau front-end.

Les deux approches sont légitimes. Elles s’adaptent à différentes structures d’équipe et à différents types d’applications. C’est au niveau des capacités spécifiques ci-dessous qu’elles produisent des résultats différents.

L'application complète, pas seulement la couche front-end

La surface gérée par Vercel correspond au runtime front-end et aux fonctions serverless qui l’accompagnent. Les bases de données, le stockage d’objets et d’autres services avec état sont disponibles via les intégrations de la Marketplace de Vercel avec des fournisseurs partenaires tels que Neon, Supabase et Upstash. Ces intégrations sont vraiment pratiques pour les équipes dont le backend se résume à une base de données et à quelques fonctions.

En contrepartie, les parties de ton application intégrées via le Marketplace se trouvent dans l’environnement d’un autre fournisseur, avec un modèle opérationnel différent, un contrat d’assistance différent et une gouvernance différente. Pour un backend simple, ça va. Pour une application full-stack avec des workers à exécution longue, des files d’attente de messages, des environnements d’exécution multilingues ou des services de données qui doivent être colocalisés avec la partie calcul, les interfaces entre Vercel et les partenaires du Marketplace font partie intégrante de l’architecture.

Upsun exécute l'ensemble de l'application sur une seule plateforme. Un seul fichier `.upsun/config.yaml` dans ton dépôt Git décrit l'application front-end, les services backend Node, Python, PHP, Go ou Java, la base de données PostgreSQL ou MySQL, le cache Redis, la file d'attente RabbitMQ, les workers qui s'en servent, les tâches cron et le routage entre tous ces éléments. Ils se déploient ensemble, s'exécutent ensemble et sont gérés ensemble. Il n’y a pas de rupture de marché, car il n’y a pas de couche de marché.

C'est particulièrement important pour les applications comportant plusieurs services backend, des couches de données complexes ou des environnements d'exécution autres que JavaScript et Python.

Environnements de test : code contre octet par octet

Les déploiements en prévisualisation de Vercel sont au cœur de ce qui a fait la renommée de la plateforme. Chaque pull request reçoit une URL. Les réviseurs cliquent, voient la modification et l’approuvent ou la rejettent. C’est la fonctionnalité qui a le plus relevé la barre en matière d’expérience développeur dans l’ensemble du secteur.

Le compromis, c'est qu'un déploiement de prévisualisation dans Vercel est une prévisualisation au niveau du code. Le code est déployé, mais les services sous-jacents, les bases de données, les magasins d'objets, les files d'attente, sont ce vers quoi l'environnement a été configuré pour pointer. Les équipes connectent généralement les prévisualisations à une base de données de staging partagée ou à une base de données ramifiée par environnement via un partenaire du marketplace. L'URL de prévisualisation se charge, mais la question de savoir si les données sous-jacentes à la prévisualisation correspondent à la configuration de production est une autre histoire, avec une réponse distincte.

Le moteur de clonage d'environnement d'Upsun crée une réplique octet par octet de la production sur chaque branche. Pas seulement le code. Les bases de données, les fichiers dans le stockage d'objets, les services, les index de recherche, les caches. Un réviseur qui ouvre une URL de prévisualisation sur Upsun examine l'application s'exécutant sur une copie complète et isolée de l'état réel de la production. Des hooks de nettoyage définis en YAML peuvent supprimer 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.

Pour les équipes où les bugs les plus tenaces se trouvent dans l’interaction entre le code et les données, c’est un processus de révision différent. Les bugs qui survivaient jusqu’à la phase de staging disparaissent désormais lors de la révision des pull requests.

Le choix du cloud comme fonctionnalité de premier plan

Vercel fonctionne sur l’infrastructure mondiale de Vercel. C’est en partie ce qui donne à la plateforme son côté magique : tu n’as pas à te soucier des régions, des instances ou des fournisseurs de cloud, car Vercel s’occupe de tout ça. La configuration régionale de Vercel te permet de choisir où les fonctions s’exécutent, et le réseau périphérique met l’application en avant à l’échelle mondiale.

En contrepartie, la plateforme ne répond pas à la question « quel cloud ? ». Si un régulateur exige un traitement au sein de l’infrastructure d’une juridiction spécifique, si l’équipe d’approvisionnement d’un client refuse d’approuver des fournisseurs utilisant un hyperscaler particulier, ou si un directeur financier souhaite que les dépenses cloud soient imputées à un accord d’utilisation engagée existant avec AWS, Azure, Google ou IBM, la réponse sur Vercel est celle que la plateforme te donne.

Upsun déploie la même application, décrite par le même fichier .upsun/config.yaml, sur AWS, Azure, Google Cloud ou OVH, dans des dizaines de régions. La configuration ne change pas lorsque le cloud change. Déplacer un projet d’un hyperscaler à un autre est un paramètre au niveau du projet, pas un changement de plateforme. Et Upsun est disponible sur les marketplaces AWS, Azure, Google et IBM, ce qui permet aux équipes ayant un engagement de dépenses sur un cloud donné d’appliquer cet engagement à leur utilisation d’Upsun. Pour les équipes dont le parcours de développement commercial inclut des secteurs réglementés, des exigences de régions souveraines ou des clients d’entreprise ayant des préférences cloud spécifiques, cette flexibilité fait souvent la différence entre un « oui » et un projet d’ingénierie de 90 jours.

Conformité : uniforme sur toute la plateforme, pas d’option d’activation par fonctionnalité

C'est la différence qui compte le plus pour les équipes dont les exigences de conformité ne sont pas facultatives, et c'est celle qui est le plus souvent sous-estimée lors des évaluations.

Vercel est certifié SOC 2 Type 2 et propose des accords de partenariat HIPAA (BAA) sur les plans Pro et Enterprise. La conformité HIPAA nécessite de souscrire à un plan éligible et de signer le BAA. Pour les équipes disposant du plan adéquat et ayant signé le BAA, la couverture s'applique comme prévu.

Le compromis est que la conformité de Vercel est définie par équipe et par niveau de forfait. Tu adhères à la norme HIPAA en passant au forfait Pro ou Enterprise et en signant le BAA. Tu bénéficies de la portée SOC 2 de Vercel pour les parties de l’application gérées par Vercel, et tes partenaires du marketplace (pour les bases de données, les files d’attente, le stockage d’objets et d’autres services avec état) ont leurs propres certifications, portées et BAA pour les parties qu’ils gèrent. Le diagramme de conformité qui en résulte est une composition des politiques de plusieurs plateformes, reliées aux points de jonction que tu as créés.

Les options SOC 2 Type 2, ISO 27001, PCI DSS et HIPAA d'Upsun s'appliquent à chaque fonctionnalité et à chaque environnement de la plateforme, ainsi qu'à chaque service géré que tu y exécutes. La limite de conformité est la même en environnement de test qu’en production, la même pour le frontend que pour le worker de file d’attente, la même pour le service PostgreSQL que pour le conteneur d’application, et la même quel que soit l’hyperscaler sous-jacent sur lequel ton projet s’exécute. Lorsque ton périmètre d’audit doit inclure l’application dans son ensemble, la déclaration de périmètre correspond au diagramme d’architecture car les certifications couvrent l’ensemble de la plateforme d’un seul tenant.

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, une approche uniforme est nettement plus simple à défendre qu’une approche composite.

Configuration et expérience développeur

Le modèle de configuration de Vercel repose principalement sur le tableau de bord et l’interface CLI, complétés par un fichier d’vercel.jsons pour les paramètres propres à chaque projet. Les variables d’environnement, les intégrations, les régions et les paramètres d’équipe sont gérés via l’interface utilisateur de Vercel, qui est bien conçue et rapide à prendre en main. L’expérience est optimisée pour le développeur solo et les petites équipes qui souhaitent que la plupart des décisions soient prises à leur place.

Le compromis est que la configuration de la plateforme réside dans l'interface d'administration de la plateforme elle-même plutôt que dans ton dépôt. Pour les équipes de sécurité qui souhaitent que chaque modification de l'infrastructure sous contrôle de version soit soumise au même processus de révision que le code de l'application, le modèle Vercel nécessite une couche d'audit supplémentaire pour reconstituer ce qui a changé et quand.

Le modèle d'Upsun est natif Git. Le fichier `.upsun/config.yaml` de ton dépôt constitue l'intégralité de la définition de l'infrastructure. Chaque version de base de données, chaque règle de pare-feu, chaque service, chaque route, chaque cron, chaque allocation de ressources : tout cela est un commit dans ta branche principale. Les changements passent par des pull requests. Les audits examinent le `git log`. Les rollbacks sont des `git revert`. Le même processus de révision qui régit le code de l'application régit l'infrastructure.

Ce n'est pas un jugement de valeur sur les tableaux de bord. Les tableaux de bord sont plus rapides pour les individus. Le YAML dans Git est plus justifiable pour les équipes ayant des exigences de révision.

Comparaison en un coup d'œil

Quand Vercel est probablement le bon choix

Une équipe axée sur le frontend qui développe une application Next.js avec un backend restreint et aucune exigence réglementaire imminente sera probablement plus rapide sur Vercel que sur n'importe quelle autre plateforme. Si ton application est essentiellement front-end, si ton équipe est orientée JavaScript, si ton backend se compose d’une base de données gérée et de quelques fonctions serverless, et si tes besoins en matière de conformité correspondent à ce que Vercel et ses partenaires certifient collectivement, les atouts de la plateforme jouent en ta faveur. C’est pour ce type de cas qu’elle a été conçue et qu’elle continue de bien fonctionner.

Quand Upsun est probablement le bon choix

Une équipe dont l’application comporte plusieurs services backend, des workers à exécution longue, des couches de données qui doivent coexister avec le calcul, des environnements d’exécution au-delà de JavaScript et Python, ou des exigences de conformité qui doivent couvrir l’ensemble de l’application, trouvera que les propriétés structurelles d’Upsun correspondent mieux à la nature du problème. Les clients des secteurs de la santé, des services financiers, du gouvernement, les agences développant pour des clients soumis à une réglementation, et les équipes produit qui ont dépassé le stade où l’application est un frontend avec une base de données, ont tendance à se tourner vers cette solution. Les capacités qui comptent le plus dans ces contextes — une infrastructure définie en YAML dans Git, le clonage d’environnement octet par octet, le déploiement multicloud sans modification de configuration et une conformité uniforme pour toutes les fonctionnalités et tous les environnements — sont des choix structurels sur lesquels la plateforme a été construite, plutôt que des fonctionnalités ajoutées après coup.

Passer de Vercel à Upsun, si c’est là que tu atterris

Les équipes qui migrent le font généralement une application à la fois. Le code de l’application lui-même nécessite généralement des ajustements mineurs. La majeure partie du travail consiste à traduire la configuration spécifique à Vercel (réécritures, redirections, variables d’environnement, paramètres de fonctions serverless) en déclarations YAML équivalentes dans .upsun/config.yaml, et à intégrer les services backend qui étaient intégrés via le Vercel Marketplace dans les définitions de services natives d’Upsun.

L'équipe des services applicatifs d'Upsun travaille directement avec les équipes d'ingénierie tout au long des migrations lorsque c'est la voie à suivre. L'objectif de ces collaborations n'est pas tant de vendre une migration que de dresser un tableau clair de ce que le changement implique réellement, afin que l'équipe puisse prendre sa décision en s'appuyant sur des chiffres concrets plutôt que sur des estimations.

Le résumé honnête

Vercel et Upsun sont toutes deux de bonnes plateformes. Elles s’adressent à des problèmes différents, et la bonne réponse dépend du problème que tu rencontres réellement.

Si ton application est essentiellement un frontend, Vercel est probablement un bon choix, et la richesse d'une plateforme full-stack risquerait d'être gaspillée pour une équipe qui n'en a pas besoin.

Si ton application comporte un backend important, des exigences de conformité couvrant l’ensemble de la stack, une flexibilité cloud pour l’avenir, ou si ton équipe souhaite gérer l’infrastructure dans Git en même temps que le code de l’application, les fonctionnalités full-stack d’Upsun sont exactement ce qu’il te faut.

L'erreur n'est pas de choisir l'une plutôt que l'autre. L'erreur est de choisir la plateforme qui correspond à ce qu'est l'application aujourd'hui et de découvrir, au bout de douze mois, que c'est à cause de cette plateforme que l'application ne peut pas devenir ce que l'équipe voulait qu'elle soit.

Choisis la plateforme qui correspond à l'évolution future de l'application.

Pour en savoir plus

• Présentation de la plateforme Upsun
• Environnements Upsun et clonage octet par octet
• Conseils de conformité Upsun
• Documentation de la plateforme Vercel
• Vercel Fluid Compute
• Sandbox Vercel
• Déploiements en préversion Vercel
• Sécurité et conformité Vercel