Au-delà de Vercel et Netlify : trouver des alternatives d'hébergement frontend plus intelligentes

Il n'y a pas si longtemps, déployer un site web était une affaire complexe. Vous louiez un VPS, installiez Nginx, configuriez des certificats SSL, vous vous souciiez des ports et des permissions, tout en espérant ne pas faire planter le serveur lors du déploiement d'une nouvelle version. Puis Netlify et Vercel sont arrivés. Soudain, il suffisait de connecter son dépôt GitHub, de pousser son code, et le site était en ligne. Pour les développeurs frontend, c'était magique.

L'idée était simple mais puissante : faire abstraction de l'infrastructure pour permettre aux développeurs de se concentrer sur le code. Vercel et Netlify ne se contentaient pas d'héberger des fichiers statiques ; ils offraient le déploiement continu, des prévisualisations automatiques, des CDN mondiaux et même des fonctions serverless. Ils sont devenus la réponse par défaut à la question : « où dois-je héberger mon frontend ? »

Mais comme beaucoup de révolutions, l'étape suivante a apporté son lot de compromis. Ce qui rendait ces plateformes si pratiques les rendait aussi rigides. Et à mesure que les équipes et les projets grandissaient, certains de ces compromis ont commencé à poser problème.

Ce que Vercel et Netlify ont résolu

Les deux plateformes ont éliminé un point de friction majeur dans les workflows frontend. Avant elles, le déploiement était une réflexion après coup, souvent géré par le seul ingénieur backend qui comprenait le serveur. Soudain, chaque développeur frontend pouvait déployer en toute confiance. À chaque git push, votre code était construit, déployé et servi mondialement en quelques secondes. Vous n'aviez plus à vous soucier des CDN, du SSL ou du cache.

Elles ont également facilité la collaboration. Les URL de prévisualisation pour les pull requests ont changé la façon dont les équipes révisent le code. Les fonctions serverless ont permis d'exécuter une logique backend sans gérer d'API séparée. Et comme elles étaient construites autour des workflows Git, les développeurs n'avaient pas de nouveaux outils à apprendre.

Pour les petites équipes, les projets personnels ou les startups, c'était parfait. Rapide, propre, moderne.

Les premières fissures apparaissent

Les problèmes surgissent lors du passage à l'échelle. Pas forcément en termes de trafic, mais dans la complexité de votre équipe ou de votre stack.

Le premier problème est le verrouillage propriétaire (vendor lock-in). Ces plateformes reposent sur des configurations et des systèmes de déploiement propriétaires. Une fois que vous utilisez les edge functions de Vercel ou les formulaires de Netlify, vous ne déployez plus seulement du code : vous déployez leur version spécifique du code. En partir plus tard peut signifier réécrire des fonctionnalités ou reconfigurer l'ensemble de votre CI/CD.

Le deuxième problème est le support limité des stacks. Elles excellent avec Next.js, Gatsby ou les sites statiques SvelteKit, mais si votre projet comporte un backend, une API personnalisée ou une intégration de base de données, la simplicité s'effondre. De nombreuses équipes finissent par déployer des parties de leur application ailleurs de toute façon.

Ensuite, il y a la tarification. C'est bon marché au début, mais dès que votre équipe s'agrandit, vous payez par utilisateur, par minute de build, par invocation de fonction. Ce modèle punit la collaboration.
Les agences, en particulier, se heurtent vite à ce mur : soudain, chaque développeur coûte un supplément, même s'il ne travaille que sur un seul projet pour un client.

Et la plus grande frustration est peut-être le manque de contrôle. Vous ne pouvez pas décider du comportement de votre CDN, de la région où les fonctions s'exécutent, ou de la manière dont les règles de mise à l'échelle s'appliquent. La simplicité qui les rendait idéales pour les individus devient limitante pour les équipes qui ont besoin de flexibilité.

Pourquoi nous avons cherché des alternatives

Chez We Do Dev Work, nous évoluons dans un environnement d'agence. Plusieurs développeurs, plusieurs projets, différents frameworks, différents clients. Nous avons besoin d'une configuration capable de grandir avec nous et de s'adapter à notre façon de travailler, et non l'inverse.

Nous ne voulons pas payer par utilisateur. Nous ne voulons pas qu'on nous dicte la stack à utiliser. Et nous avons besoin d'un système cohérent d'un projet à l'autre : pour que lorsqu'un développeur termine un projet, un autre puisse prendre le relais sans une courbe d'apprentissage abrupte.

C'est pourquoi nous avons commencé à regarder au-delà de Vercel et Netlify. Nous voulions quelque chose qui s'intègre proprement à notre écosystème : TypeScript, .NET, PostgreSQL, SvelteKit et Supabase. Quelque chose qui nous donne le contrôle sur l'infrastructure, les coûts et les accès.

Cela nous a menés à AWS Amplify.

Pourquoi nous aimons AWS Amplify

Amplify n'est pas aussi tape-à-l'œil que Vercel. Il ne se vend pas avec des animations sophistiquées ou des mots magiques comme « déploiement instantané ». Mais sous le capot, il offre le bon équilibre entre commodité et contrôle.

Il supporte les frameworks modernes comme React, Vue et SvelteKit sans en imposer un en particulier. Vous connectez votre dépôt, et il construit à chaque push. Comme les autres. Mais parce qu'il fait partie d'AWS, il s'intègre naturellement avec le reste de l'écosystème. Besoin d'une base de données ? Vous pouvez lancer RDS ou connecter Supabase. Besoin d'héberger des images ? Utilisez S3. Besoin de mise en cache edge ? CloudFront est là.

Nous apprécions le fait que tout soit transparent. Vous voyez ce que vous payez, région par région. Vous n'êtes pas facturé pour les membres de l'équipe. Vous n'avez pas de coûts de fonction cachés ou de limites de minutes de build. Si un projet grandit, nous le mettons à l'échelle de la même manière que nous mettons à l'échelle notre backend.

Autre point fort : la cohérence. Chaque projet que nous déployons suit la même configuration Amplify. Cela signifie que nos développeurs peuvent passer d'un projet client à l'autre sans avoir à apprendre de nouveaux pipelines ou des workflows propriétaires. Cela permet également de garder tous les environnements sous notre contrôle. Pas besoin de dépendre d'un fournisseur qui pourrait changer ses tarifs ou ses fonctionnalités demain.

Alternatives valant le détour

Amplify fonctionne bien pour nous, mais ce n'est pas la seule voie. Selon la taille et l'orientation de votre projet, il existe d'autres excellentes options :

• Cloudflare Pages est excellent pour les sites statiques et JAMStack. Une distribution mondiale rapide, des edge functions intégrées et une intégration Git simple. C'est aussi l'une des options les plus abordables pour les frontends simples.

• Render offre un équilibre intéressant entre simplicité et flexibilité full-stack. Il supporte les services web, les cron jobs, PostgreSQL et les background workers. Le tout avec un tableau de bord relativement facile à utiliser.

• Fly.io se concentre sur la performance et la proximité. Vous pouvez exécuter des applications conteneurisées (Docker) au plus près de vos utilisateurs, idéal pour les projets où la latence est cruciale.

• DigitalOcean App Platform ressemble à une version plus conviviale d'AWS. Elle supporte la plupart des frameworks, propose des bases de données managées et convient parfaitement aux petites entreprises. Pourtant, pour une raison inconnue, DigitalOcean n'est pas l'option favorite de beaucoup.

• Google Cloud Run offre une scalabilité sérieuse, bien qu'il soit plus technique. Il peut héberger n'importe quoi de conteneurisé, mais nécessite plus de configuration et de connaissances DevOps.

Chacun de ces outils a ses propres compromis. La clé est de faire correspondre l'outil à l'équipe.

Quand le serverless n'est pas la solution

L'hébergement serverless ressemble à l'avenir — et c'est souvent le cas — mais pas pour tout. Nous avons vu des projets où le serverless finit par être plus coûteux et complexe qu'une installation VPS classique.

Les problèmes se résument généralement à l'échelle et à la cohérence. Pour des tâches de longue durée ou un trafic intense, les coûts du serverless peuvent s'envoler. Les « cold starts » peuvent nuire à l'expérience utilisateur, et le débogage à travers de multiples invocations lambda peut être pénible. Et parce que chaque fonction s'exécute de manière isolée, la mise en cache et la gestion de l'état sont plus difficiles.

Une configuration classique basée sur des conteneurs peut être moins chère, plus facile à déboguer et tout aussi évolutive. Avec la bonne configuration DevOps (pipelines CI/CD, autoscaling et équilibrage de charge), vous obtenez des coûts et des performances prévisibles. Ce n'est pas « moderne » au sens marketing du terme, mais c'est ainsi que fonctionnent avec succès de nombreuses applications à grande échelle.

En d'autres termes, la bonne architecture est celle qui s'adapte au problème, pas à la tendance.

Notre approche chez We Do Dev Work

Pour nous, c'est la flexibilité qui gagne. Nous utilisons Amplify quand nous avons besoin de déploiements frontend rapides, intégrés à Supabase pour les données et l'authentification. Quand nous avons besoin de plus de contrôle, nous optons pour des déploiements de conteneurs classiques sur AWS ECS ou même des configurations VPS managées.

Notre objectif est toujours le même : un hébergement rapide, fiable et maintenable avec des coûts transparents. Il ne s'agit pas de courir après le dernier outil à la mode. Il s'agit de choisir le bon outil pour la mission.

Et de maîtriser l'ensemble du processus, du code à la production.

Nous admirons toujours ce que Vercel et Netlify ont apporté à l'écosystème. Ils ont rendu le développement frontend moderne accessible et agréable. Mais la commodité a ses limites. Pour une agence qui gère plusieurs stacks, équipes et clients, posséder son propre pipeline compte plus que les déploiements en un clic.

Dernières réflexions

Le déploiement frontend a parcouru un long chemin : des téléchargements FTP manuels aux CDN serverless avec prévisualisations et fonctions. Mais l'histoire n'est pas finie. Nous entrons dans une phase où les équipes veulent à la fois la commodité et le contrôle. Où les coûts doivent être prévisibles, les environnements reproductibles et les outils ouverts.

Pour nous, chez We Do Dev Work, AWS Amplify trouve cet équilibre. C'est fiable, flexible et s'intègre naturellement dans notre stack. Mais la véritable leçon est celle-ci : ne laissez pas l'hébergement définir votre architecture.

Choisissez une plateforme qui sert votre workflow, et non l'inverse.
C'est ainsi que l'on construit des systèmes évolutifs — et une agence durable.