La refonte tarifaire de Render en avril 2026 : fini les frais par siège, beaucoup moins de bande passante incluse

Le 23 avril 2026, Render a remplacé sa tarification par siège par des frais fixes par espace de travail : 0 $ par mois pour Hobby, 25 $ par mois pour Pro, 499 $ par mois pour Scale, confirmé directement dans l’annonce officielle de tarification de Render. Les espaces de travail existants avaient jusqu’au 1er août 2026 pour migrer vers les nouveaux forfaits. Dans le même changement, Render a réduit substantiellement la bande passante incluse dans ces forfaits : l’allocation d’égress incluse de Hobby est passée de 100 Go à 5 Go, et les comptes rendus de ce changement décrivent une réduction comparable sur Pro, avec les dépassements maintenant facturés à un taux fixe de 0,15 $ le gigaoctet plutôt que l’ancienne pratique de facturer par blocs de 100 Go. L’annonce officielle de Render affirme que 75 % des clients payants verraient leur facture diminuer ou rester la même sous la nouvelle structure. Pour un type de charge de travail précis et courant, cependant, le calcul va dans l’autre sens, et ça vaut la peine de comprendre exactement pourquoi.

Ce qui a vraiment changé, dans les propres mots de Render

Le changement principal, c’est celui que Render a choisi de mettre en avant : plus de frais par siège. Sous l’ancien modèle, un espace de travail Pro payait quelque part entre 19 $ et 29 $ par membre d’équipe par mois, ce qui signifie que les seuls frais de base de plateforme d’une équipe de cinq personnes pouvaient atteindre 95 $ à 145 $ avant même qu’un seul service ne tourne. Sous le nouveau modèle, ça devient des frais fixes par espace de travail, 25 $ par mois pour Pro, peu importe si l’espace de travail compte une personne ou vingt. Pour toute équipe plus grande qu’un développeur seul, cette partie du changement est une amélioration nette, et c’est la partie qui justifie l’affirmation de Render selon laquelle la plupart des clients payants en sortent gagnants ou neutres.

Le deuxième changement a reçu beaucoup moins d’attention : la bande passante incluse par forfait a chuté fortement. L’allocation d’égress de Hobby est passée de 100 Go à 5 Go, une réduction de 20x. Les comptes rendus sur le forfait Pro décrivent une réduction tout aussi importante, jusqu’à 25 Go inclus, l’allocation précédente exacte étant rapportée de façon incohérente selon les sources couvrant ce changement (certains comptes rendus situent l’ancienne allocation Pro à 100 Go, d’autres plus haut), donc le chiffre précis « avant » vaut la peine d’être traité comme rapporté plutôt que confirmé de façon indépendante ici. Ce qui est cohérent à travers tous les comptes rendus, y compris les pages de forfaits actuelles de Render elles-mêmes, c’est le chiffre « après » : 25 Go inclus sur Pro, 1 To sur Scale, et un taux fixe de 0,15 $ le gigaoctet pour tout dépassement de l’allocation incluse.

Pourquoi Render a-t-il réduit la bande passante incluse et aboli les frais par siège?

Ces deux changements semblent indépendants, mais ils ne le sont pas. Des frais par siège sont une facture qui évolue selon le nombre de personnes qui utilisent le produit, ce qui n’a presque rien à voir avec ce qu’il en coûte réellement à Render pour faire tourner l’infrastructure d’un client. L’égress, les données qu’une application en fonctionnement renvoie à ses utilisateurs, est un vrai coût mesuré que Render paie lui-même à ses propres fournisseurs en amont, et il évolue selon exactement une chose : combien de trafic l’application d’un client sert réellement. Passer de « facturer par personne » à « facturer par gigaoctet réellement utilisé » est, mécaniquement, un rapprochement vers la facturation de la vraie structure de coûts de Render, et un éloignement d’un chiffre (le nombre de personnes dans l’équipe) qui n’était qu’une vague approximation de l’utilisation.

C’est une raison d’affaires cohérente pour faire ce changement, et c’est en phase avec la trajectoire plus large de l’entreprise : Render a levé 100 millions de dollars en février 2026 à une évaluation rapportée de 1,5 milliard de dollars sur une croissance annuelle de plus de 100 %, ce qui est un contexte de financement qui dépend d’une structure de coûts qui évolue de façon prévisible avec l’utilisation plutôt que d’une structure où une poignée de clients à fort trafic se subventionnent discrètement sur un forfait fixe basé sur les sièges, tarifé pour un autre type de charge de travail. Rien de tout ça ne rend le changement mauvais sur le fond. Ça veut dire que les clients les plus exposés au désavantage sont un groupe spécifique et identifiable : des charges de travail avec une vraie bande passante soutenue, vidéo, téléchargements de fichiers, réponses d’API avec de grosses charges utiles, webhooks déclenchés en volume, qui tenaient auparavant confortablement dans une allocation fixe généreuse et qui tombent maintenant sur un compteur.

Ce que ça coûte pour une charge de travail réelle

Prenez une configuration Pro assez ordinaire : un service web, une tâche de fond, les deux sur une taille d’instance standard, plus une petite base de données Postgres gérée. Avant même de compter l’égress, c’est environ 95 $ par mois sous la nouvelle tarification, frais d’espace de travail inclus. À faible trafic, sous l’allocation incluse de 25 Go, c’est toute la facture, et c’est une vraie amélioration par rapport à l’ancienne tarification Pro par siège pour une équipe de plus d’une ou deux personnes.

Le chiffre bouge vite passé ce point. À 500 Go d’égress mensuel, un chiffre raisonnable pour une application qui sert des images, des miniatures vidéo, ou une quantité modeste de trafic d’API à quelques milliers d’utilisateurs, le dépassement est de 475 Go au-delà de l’allocation incluse, à 0,15 $ le gigaoctet ça représente environ 71 $ ajoutés à la base, pour un total près de 166 $ par mois. À 1 To d’égress mensuel, le dépassement grimpe à environ 150 $, poussant le total au-delà de 245 $. À 2 To, une charge de travail qui n’est pas inhabituelle pour une application grand public riche en contenu multimédia, la ligne d’égress à elle seule approche 300 $, plus du triple des frais de base de plateforme. Le motif est clair : la bande passante, pas le calcul ni les frais d’espace de travail, devient la ligne dominante de la facture pour tout ce qui dépasse une application à faible trafic, et elle continue de grimper sans plafond jusqu’à ce qu’un client passe au forfait Scale à 499 $ et son allocation de 1 To.

La partie qui vaut la peine de retenir, c’est que rien de tout ça n’exige qu’une équipe fasse un choix inhabituel. Servir de la vidéo, des images, de grosses charges utiles JSON, ou simplement avoir une application populaire, n’est pas un comportement exotique; c’est une grande part de ce que les applications web font réellement. Un modèle de tarification qui est plus favorable aux petites équipes sur le plan du nombre de personnes, et nettement moins favorable à quiconque a un vrai trafic soutenu, est un compromis précis et intentionnel, pas une amélioration universelle, et le cadrage de Render lui-même à « 75 % des clients » est cohérent avec ça : ça décrit le client médian, pas la frange de clients dont les charges de travail sont justement le genre qui génère de la vraie bande passante.

Ce qu’un prix fixe sans compteur de bande passante fait différemment

La tarification de Railyard n’a aucune ligne de bande passante, mesurée ou non. Le forfait Pro à 19 $ par mois et le forfait Team à 49 $ par mois sont fixes par équipe, peu importe combien de trafic les applications sur ces serveurs servent réellement. C’est possible pour une raison structurelle, pas une raison de générosité : les serveurs eux-mêmes se trouvent dans le propre compte infonuagique du client, et la bande passante est facturée par le fournisseur infonuagique (DigitalOcean, Hetzner, Vultr) directement au client, au propre tarif de ce fournisseur, qui pour la plupart des fournisseurs inclut une allocation de bande passante nettement plus grande groupée dans le prix du serveur lui-même, et ne comporte historiquement rien près d’un taux marginal de 0,15 $ le gigaoctet une fois l’allocation propre d’un serveur épuisée. Railyard ne touche jamais à cette facture, n’applique aucune majoration dessus, et n’a rien à mesurer, parce que le trafic ne passe jamais par une infrastructure que Railyard possède en premier lieu.

C’est la même bifurcation architecturale qui apparaît dans chaque comparaison entre une plateforme gérée et une plateforme à serveur apporté par le client : une plateforme qui fait tourner le calcul doit tarifer les ressources qu’elle paie réellement, ce qui pour une charge de travail riche en bande passante finit par signifier mesurer la bande passante, parce que c’est un vrai coût variable que la plateforme absorbe au nom du client. Une plateforme qui ne fait pas tourner le calcul n’a aucun coût de ce genre à récupérer, donc il n’y a rien à mesurer. Aucune des deux approches n’est un tour de passe-passe. Le coût d’égress de Render est de l’argent réel que Render paie quelque part en amont, et en récupérer une partie auprès des clients qui génèrent ce trafic est une décision de tarification défendable, possiblement plus honnête que de le cacher dans des frais fixes que d’autres clients finissent par subventionner. Le cadrage honnête, c’est que les deux modèles sont optimisés pour des charges de travail différentes : une plateforme avec de l’égress mesuré est un choix correct et juste pour une équipe avec un trafic modeste et prévisible qui profite du coût plus bas basé sur les sièges; un prix fixe par équipe avec la bande passante facturée directement par le fournisseur infonuagique est le meilleur ajustement une fois que le trafic est assez important pour qu’un compteur par gigaoctet domine la facture.

La vraie leçon

Render n’a rien fait de malhonnête ici. L’entreprise a publié le changement, a donné une vraie période de transition, et a mis en avant la partie du changement qui est un gain sans ambiguïté pour la plupart des clients. La partie qui vaut la peine de connaître avant de s’inscrire, ou avant de budgéter un renouvellement, c’est la partie qui n’a pas fait les manchettes : une charge de travail avec une vraie bande passante soutenue est maintenant facturée par gigaoctet sans plafond autre que le prochain palier de forfait, remplaçant une allocation qui, pour la majeure partie de l’histoire de Render, était assez généreuse pour qu’on n’ait pas à y penser. Quiconque fait tourner une application riche en bande passante sur Render a intérêt à faire le calcul pour son trafic réel avant de supposer que le nouveau prix de base, d’allure plus accueillante, raconte toute l’histoire.

FAQ

Quand Render a-t-il changé sa tarification? Render est passé à un modèle de frais fixes par espace de travail le 23 avril 2026, avec une obligation pour les espaces de travail existants de migrer d’ici le 1er août 2026.

Combien de bande passante Render inclut-il maintenant? Les nouveaux forfaits incluent 5 Go sur Hobby, 25 Go sur Pro, et 1 To sur Scale, une forte baisse par rapport aux allocations en place avant avril 2026, avec les dépassements facturés à 0,15 $ le gigaoctet.

Les prix de Render ont-ils augmenté ou diminué? Les deux, selon la charge de travail. Abolir les frais par siège réduit la facture pour la plupart des équipes, surtout les plus grandes. Réduire la bande passante incluse augmente la facture pour toute charge de travail avec un vrai trafic soutenu, puisque l’égress est maintenant mesuré au-delà d’une allocation beaucoup plus petite.

Railyard facture-t-il la bande passante? Non. Les serveurs de Railyard tournent dans le propre compte infonuagique du client, donc la bande passante est facturée directement par le fournisseur infonuagique à son propre tarif, pas mesurée ou majorée par Railyard.

Sources

• Render : « Better pricing for fast-growing teams », annonce officielle de Render, consultée en octobre 2026, confirmant les paliers d’espace de travail à 0 $/25 $/499 $, la bande passante incluse de 5 Go/25 Go/1 To, le taux de dépassement de 0,15 $/Go, et l’affirmation de 75 % des clients
• Comptes rendus sur la réduction de bande passante Hobby d’avril 2026, incluant Render’s April 2026 Egress Cut From 100GB to 5GB on Hobby
• Comptes rendus sur le contexte d’affaires derrière le changement, incluant la ronde de financement de Render en février 2026, dans Render’s $1.5B Valuation Hides a $0.15/GB Question
• La page de tarification de Railyard pour les détails actuels des forfaits fixes par équipe

Voyez comment les modèles se comparent directement : Comparer Railyard à Render, ou voyez comment fonctionne le prix fixe de Railyard sur des serveurs que vous possédez déjà.