Tarification des PaaS : coûts à l’usage ou coûts fixes par instance

La tarification des PaaS peut sembler simple sur une fiche de forfait, puis devenir difficile à comprendre en production. Un abonnement peut inclure un crédit d’usage, une instance fixe peut facturer une taille réservée et une plateforme à l’usage peut mesurer le CPU, la RAM et le disque réellement consommés. Comparer uniquement le premier montant affiché conduit à une mauvaise décision.

Dockup sépare l’abonnement du forfait de la consommation mesurée. Free inclut un crédit de démarrage unique ; Pro inclut un crédit d'usage mensuel. L’utilisation du CPU, de la RAM et du disque est mesurée à la minute et déduite du solde.

Quelle est la différence entre la tarification à l’usage et la tarification fixe par instance ?

La tarification fixe par instance facture la machine ou la taille de service sélectionnée pendant la période de facturation, que l’application utilise ou non toute la capacité réservée. La tarification à l’usage repose sur la consommation mesurée, parfois avec des minimums ou des crédits inclus dans le forfait.

Modèle	Unité principale	Avantage	Risque
Instance fixe	Taille sélectionnée dans le temps	Poste prévisible	Payer une capacité inutilisée
Usage réel	CPU/RAM/disque consommés dans le temps	Facture alignée sur la consommation	Prévisions variables
Abonnement avec crédit	Frais du forfait et solde inclus	Combine accès et dépenses	Le crédit peut être mal compris
Requête serverless	Appels/durée	Mise à l’échelle jusqu’à zéro pour certains workloads	Pics de coûts en cas de volume élevé
Siège plus ressources	Accès de l’équipe plus compute	Fonctionnalités de collaboration	Croissance du coût par siège

Dockup utilise un abonnement avec crédit d’usage. Le nombre de ressources des forfaits payants est illimité, mais le compute et le disque ne sont pas gratuits. « Déploiements illimités » signifie qu’il n’existe aucune limite de quantité pour créer des déploiements ; les ressources qu’ils consomment utilisent néanmoins le solde du forfait.

La mesure à la minute est plus granulaire qu’une facturation mensuelle par instance fixe. Un service arrêté pendant une partie du mois peut consommer moins qu’un service exécuté en continu, tandis qu’un service toujours actif et très sollicité peut consommer régulièrement le solde disponible.

Quels sont les forfaits Dockup et les crédits inclus ?

Le tableau des forfaits est le suivant :

Forfait	Prix	Crédit inclus	Limites d’espaces de travail/bases de données/déploiements
Free	$0/mois	Crédit de départ de $10	1 espace de travail, 3 bases de données, 3 déploiements
Hobby	$5/mois	$0	Illimité dans les forfaits payants
Pro	$20/mois	Crédit d’usage mensuel de $20	Illimité ; recommandé

La consommation de CPU, de RAM et de disque est déduite du solde. Pour évaluer un forfait payant, considérez les frais comme donnant à la fois accès à un nombre illimité de ressources et à un solde d’usage prépayé du même montant.

Le forfait Pro est recommandé, car il fournit $20 de crédit mensuel tout en laissant de la marge pour plusieurs petits services ou un workload de production représentatif. Le forfait adapté dépend néanmoins de la consommation réelle.

Consultez le solde du compte et la consommation des services sur app.dockup.ai. Examinez ensemble le CPU, la mémoire, le disque et le solde actuel du forfait, au lieu de considérer le montant de l’abonnement comme l’intégralité de la facture.

Comment calculer un coût réaliste pour un PaaS ?

Construisez l’estimation à partir des heures de fonctionnement et des ressources mesurées.

Une formule conceptuelle simple est la suivante :

monthly cost =
  subscription
  + CPU consumption
  + RAM consumption
  + disk consumption
  + other metered services
  - included usage credit

Les tarifs unitaires exacts doivent être vérifiés dans la source tarifaire actuelle, et non dans une feuille de calcul copiée que personne ne met à jour. La méthodologie, elle, reste stable.

Pour chaque service, consignez :

• Le nombre d’heures d’exécution par jour.
• L’utilisation moyenne et maximale du CPU.
• La quantité moyenne de mémoire utilisée.
• La taille et la croissance du disque persistant.
• Les ressources des bases de données.
• La durée de vie des environnements de preview.
• Le nombre d’environnements.
• La saisonnalité du trafic.
• La fréquence prévue des builds et des déploiements.

Utilisez des valeurs mesurées après le lancement. La mémoire demandée n’est pas équivalente à la consommation réelle de mémoire dans un modèle à l’usage. À l’inverse, une facture par instance fixe peut refléter la taille demandée même lorsque l’utilisation réelle est faible.

Exemple de feuille de calcul du workload

Ressource	Quantité	Mode d’exécution	Niveau de confiance
Service web	1	24 h/24, 7 j/7	Élevé
Worker	1	8 heures/jour	Moyen
PostgreSQL	1	24 h/24, 7 j/7	Élevé
Redis	1	24 h/24, 7 j/7	Moyen
Service de preview	3 en moyenne	6 heures chacun	Faible
Volume	20 Go	Continu	Élevé

Ne transformez pas ce tableau en fausse référence tarifaire sans tarifs unitaires à jour ni utilisation réelle. Il s’agit d’un modèle de demande.

Quand la tarification à l’usage permet-elle de faire des économies ?

La facturation à l’usage est intéressante lorsque les workloads sont variables, peuvent s’arrêter lorsqu’ils sont inactifs ou présentent un écart important entre le plafond demandé et la consommation réelle.

Exemples :

• Environnements de développement utilisés pendant les heures de travail.
• Déploiements de preview qui n’existent que pendant une review.
• Workers batch actifs pendant une durée limitée.
• Produits en phase de lancement avec un faible trafic de base.
• Services pouvant être arrêtés entre deux campagnes.
• Petites API dont l’utilisation moyenne du CPU est faible.

Une instance fixe peut être compétitive lorsque le workload est constamment sollicité et prévisible. Dans ce cas, l’équipe peut préférer un prix réservé stable à une mesure granulaire de la consommation.

Les économies liées à l’usage supposent que le workload consomme effectivement moins de ressources. Définissez un cycle de vie pris en charge pour les environnements de développement réellement inactifs et vérifiez le comportement actuel de la plateforme au lieu de supposer qu’un service semblant inactif n’a aucun coût.

Le cycle de vie des previews compte également. Une équipe qui laisse des dizaines de previews fonctionner peut annuler l’avantage tarifaire des environnements éphémères. Définissez un responsable et une date d’expiration.

Comment les bases de données, les volumes et les previews influencent-ils la tarification des PaaS ?

Le compute applicatif ne représente qu’un seul poste de dépense.

Bases de données managées

PostgreSQL, MySQL, MongoDB et Redis consomment du CPU, de la RAM et du disque. Les workloads de base de données sont souvent actifs en permanence et le stockage augmente avec le temps. Intégrez les sauvegardes et les exigences de migration au modèle opérationnel, même lorsqu’elles ne constituent pas des limites distinctes du forfait.

Volumes persistants

Les volumes conservent les données entre les déploiements et consomment du disque en continu. Surveillez l’utilisation réelle :

dockup volume usage <volumeId> production/web --json

Une allocation de 20 Go dont 2 Go sont utilisés peut indiquer une marge de croissance ou du gaspillage. La décision dépend de la manière dont Dockup mesure le disque et de la croissance prévue de l’application à court terme.

Déploiements de preview

Chaque PR ou branche peut recevoir un environnement et une URL isolés. Une preview consomme des ressources tant qu’elle est active. Les previews sur réseau privé peuvent également interroger la base de données de production via un utilisateur automatique en lecture seule, ce qui peut accroître la charge de la base sans base de données distincte.

VM Windows et machines Linux

Le compute au niveau du système d’exploitation peut avoir une empreinte constante plus importante qu’un petit conteneur applicatif. Dimensionnez les ressources à partir des besoins logiciels mesurés et arrêtez ou supprimez les ressources temporaires lorsque leur tâche est terminée.

Le nombre de ressources est illimité dans les forfaits payants : la gouvernance doit donc remplacer les limites quantitatives strictes. Un agent ne doit pas créer dix services de test simplement parce que la plateforme l’y autorise.

Comment comparer les fournisseurs de PaaS sans se tromper ?

Commencez par normaliser le workload. Une comparaison équitable utilise les mêmes éléments :

1. Besoins en CPU et en mémoire.
2. Heures d’exécution.
3. Moteur de base de données et stockage.
4. Disque persistant.
5. Nombre et durée de vie des previews.
6. Sièges de l’équipe lorsqu’ils sont facturés.
7. Hypothèses de transfert réseau.
8. Besoins en sauvegarde et en support.
9. Régions et modèle de disponibilité.
10. Charge opérationnelle.

Classez ensuite chaque poste comme fixe, mesuré, crédité ou incertain.

Poste de coût	Fournisseur A	Fournisseur B	Dockup
Abonnement	Vérifier les tarifs actuels	Vérifier les tarifs actuels	$0/$5/$20
Usage inclus	Vérifier les tarifs actuels	Vérifier les tarifs actuels	$10 au démarrage ou crédit mensuel correspondant au forfait
CPU	Fixe ou mesuré	Fixe ou mesuré	Mesuré à la minute
RAM	Fixe ou mesurée	Fixe ou mesurée	Mesurée à la minute
Disque	Vérifier les tarifs actuels	Vérifier les tarifs actuels	Mesuré à la minute
Base de données	Séparée ou incluse	Séparée ou incluse	Consommation des ressources managées
Previews	Modéliser la durée de vie	Modéliser la durée de vie	Consommation des ressources pendant l’activité
Sièges	Vérifier les tarifs actuels	Vérifier les tarifs actuels	Vérifier les conditions actuelles des forfaits d’équipe

Évitez trois erreurs courantes :

• Comparer un service de production sur une plateforme avec un service gratuit en veille sur une autre.
• Soustraire deux fois le crédit inclus.
• Assimiler un nombre illimité de ressources à un usage illimité.

L’article Dockup vs Render vs Fly.io applique cette méthode sans figer les tarifs des concurrents.

Comment les équipes doivent-elles surveiller et maîtriser leurs dépenses de PaaS ?

La maîtrise des coûts repose sur une boucle opérationnelle. Consultez la consommation des services et le solde du compte sur app.dockup.ai, puis reliez les changements aux déploiements, au trafic et à la croissance des ressources.

Attribuez un responsable à chaque ressource. Chaque service, base de données, volume, VM Windows, machine Linux et preview doit avoir une finalité et un responsable. Supprimez ou arrêtez les ressources inutilisées selon un processus approuvé.

Un agent d’IA peut aider à répertorier les ressources, résumer l’utilisation et proposer des actions. Il ne doit pas détruire automatiquement des ressources en se basant uniquement sur une faible activité. Une base de données de reprise après incident arrêtée ou un service administratif rarement utilisé peut être volontairement inactif.

Seuils budgétaires

Définissez :

• La fourchette mensuelle attendue.
• Le seuil d’alerte.
• Le seuil d’investigation.
• L’approbation requise pour les nouvelles ressources toujours actives.
• La durée de vie maximale des previews.
• Le seuil de croissance des volumes.
• Le responsable des dépenses inexpliquées.

Une prévision est une fourchette, pas une promesse. Utilisez des scénarios bas, attendu et haut pour le trafic et l’activité des previews.

Économie unitaire

Reliez les dépenses d’infrastructure à une unité produit : client actif, job traité, requête API ou artefact généré. Le coût total peut augmenter tandis que le coût unitaire diminue. Un abonnement fixe de $20 peut également sembler peu coûteux alors que des services inutilisés créent de la complexité opérationnelle.

Coût du temps d’ingénierie

Une facture plus faible peut être une moins bonne décision si l’équipe doit créer et maintenir des wrappers de déploiement, du monitoring, l’orchestration des previews, des sauvegardes ou des mécanismes de sécurité pour les agents. Intégrez la charge opérationnelle et le risque d’incident.

La proposition de valeur de Dockup ne se limite pas au tableau des tarifs. Elle associe la couche de déploiement pour les agents d’IA à des services managés et à des opérations via une seule CLI.

Plan de validation sur 30 jours

1. Commencez par le plus petit forfait adapté au test.
2. Déployez un service et une base de données représentatifs.
3. Générez un trafic ou un workload réaliste.
4. Ne conservez les previews que pendant la durée normale d’une review.
5. Suivez l’utilisation chaque semaine.
6. Examinez la croissance des volumes et des bases de données.
7. Comparez la projection aux dépenses réelles en fin de mois.
8. Ne changez de forfait qu’à partir de données concrètes.

Le forfait Free fournit un crédit de départ de $10 pour une première validation. Le forfait Pro fournit un solde mensuel de $20 pour un test de production plus large.

Décision finale concernant la tarification des PaaS

La tarification des PaaS devient compréhensible lorsque chaque poste possède une unité, une période et une règle de responsabilité. La mesure à l’usage favorise les workloads efficaces et intermittents ; les instances fixes favorisent la prévisibilité lorsque la capacité est requise en continu.

Le modèle de Dockup, qui mesure le CPU, la RAM et le disque à la minute, doit être évalué à partir de l’utilisation réelle des services. Choisissez le forfait qui fournit le solde inclus et les fonctionnalités de compte adaptés, puis continuez à mesurer au lieu de supposer que les frais d’abonnement plafonnent toute la consommation.

Consultez la référence de la CLI Dockup pour connaître les commandes d’utilisation actuelles. Comparez les plateformes voisines dans Dockup vs Railway et Dockup vs Heroku, en vérifiant leurs tarifs officiels actuels avant publication.

Distinguer les flux de trésorerie du coût économique

Le crédit inclus modifie le moment où l’argent quitte le compte, mais il ne rend pas le workload gratuit. Suivez la consommation brute des ressources et le montant net dû. L’usage brut révèle l’efficacité ; les dépenses nettes montrent l’impact sur la trésorerie.

Par exemple, un abonnement Pro fournit $20 de crédit mensuel. Si les ressources mesurées consomment moins que le solde, le prélèvement peut rester limité aux $20 de l’abonnement. Si la consommation dépasse le solde, l’excédent devient une dépense supplémentaire. Le résultat exact dépend des règles de mesure et du solde actuels du compte.

Utilisez des rapports de tarification des PaaS qui affichent les deux montants afin que les équipes n’optimisent pas uniquement une fois le crédit épuisé.

Modéliser explicitement l’incertitude

Les premières prévisions doivent présenter trois scénarios :

Variable	Bas	Attendu	Haut
Trafic	50 % du forfait	Prévision	200 % du forfait
Durée de vie des previews	2 heures	8 heures	3 jours
Croissance de la base de données	1 Go/mois	5 Go/mois	20 Go/mois
Activité du worker	2 h/jour	8 h/jour	24 h/jour
Surcharge liée aux incidents	Aucune	Une reprise	Débogage répété

Appliquez les tarifs unitaires actuels à chaque scénario. L’objectif n’est pas d’atteindre une précision au centime près, mais d’identifier l’hypothèse susceptible de modifier la décision.

Une instance fixe comporte elle aussi une part d’incertitude : l’équipe peut dépasser la taille sélectionnée et passer au niveau supérieur. Intégrez ces changements de palier.

Intégrer la multiplication des environnements

Une architecture de production ne se résume presque jamais à un seul service. Comptez le staging, les previews, les workers, les bases de données, Redis, les volumes, les VM Windows, les machines Linux et les ressources temporaires de migration.

Un petit service peut facilement tenir dans un crédit de départ. Le même service réparti entre la production, le staging et cinq previews persistantes constitue un tout autre problème de tarification des PaaS.

Définissez les environnements qui fonctionnent en continu :

• Production : normalement toujours active.
• Staging : toujours actif uniquement lorsque nécessaire.
• Preview : liée à une PR ou une branche ouverte.
• Test de charge : créée pour une période planifiée.
• Migration : supprimée après validation.
• Reprise après sinistre : chiffrée selon l’objectif de disponibilité.

Le nombre illimité de ressources dans un forfait payant rend cette gouvernance plus importante, et non moins.

Comparer les choix d’optimisation avec leurs risques

Réduire la mémoire, arrêter un worker, raccourcir la rétention ou supprimer un volume peut diminuer les dépenses, mais chaque action modifie la fiabilité. Notez la conséquence sur le service à côté de l’économie estimée.

Une proposition d’optimisation utile contient :

1. La ressource et son responsable.
2. Sa consommation mesurée actuelle.
3. La modification proposée.
4. La fourchette mensuelle attendue.
5. Le risque pour les performances ou la reprise.
6. La méthode de rollback.
7. La période d’observation.

Un agent peut résumer la consommation mesurée affichée par la plateforme, mais un humain doit approuver les changements susceptibles d’affecter la disponibilité ou la conservation des données.

Réévaluer la tarification des PaaS après les changements d’architecture

Un nouveau cache peut réduire le CPU de la base de données tout en ajoutant le coût de Redis. Un worker en arrière-plan peut améliorer la latence de l’API tout en fonctionnant davantage d’heures. Le réseau privé peut modifier l’architecture sans changer les mêmes unités fondamentales de CPU, de RAM et de disque. Un Dockerfile peut réduire la taille de l’image, mais mobiliser du temps d’ingénierie.

Refaites vos prévisions après :

• L’ajout d’une base de données managée.
• L’activation de nombreuses previews.
• L’ajout d’un volume volumineux.
• Le passage à l’autoscaling Kubernetes.
• La création d’une VM Windows ou d’une machine Linux.
• La modification de la rétention.
• Le lancement d’une nouvelle région ou d’un nouveau niveau client.

La tarification des PaaS est un modèle vivant, lié à l’architecture, et non une feuille de calcul d’achat ponctuelle.

Modèle de revue mensuelle

Consignez le forfait, le solde initial, la consommation brute, le solde restant, les cinq principales ressources, les changements inattendus, les ressources arrêtées, le nombre de previews, la croissance du disque et les scénarios du mois suivant.

Comparez le résultat au mois précédent et annotez les déploiements ou les événements de trafic qui expliquent l’écart. La revue des coûts devient ainsi utile aux équipes d’ingénierie au lieu de constituer une surprise pour la finance.

Le même modèle peut servir à comparer des fournisseurs d’instances fixes : remplacez les lignes de ressources mesurées par les frais des instances sélectionnées et incluez leur utilisation afin que la capacité inutilisée reste visible.

Publier les hypothèses avec chaque estimation

Un montant de tarification des PaaS sans hypothèses ne peut pas être vérifié. Ajoutez les heures d’exécution, l’utilisation des ressources, la croissance du disque, la durée de vie des previews, le nombre de bases de données et la date des tarifs unitaires actuels. Indiquez les valeurs mesurées, estimées ou inconnues.

Mettez à jour le modèle après la première semaine et le premier mois complet. L’écart entre les prévisions et la réalité renseigne sur le workload ; ce n’est pas simplement une erreur comptable.

Cette discipline permet de maintenir la validité des comparaisons de tarification des PaaS lorsque les fournisseurs modifient leurs tarifs ou que l’architecture évolue.

Conserver le modèle sous contrôle de version

Validez les hypothèses et la date de revue à côté des notes d’architecture. Un modèle de tarification des PaaS versionné montre pourquoi l’équipe a changé de forfait et évite qu’une ancienne feuille de calcul ne devienne une cible budgétaire inexpliquée.

Commencer par un déploiement vérifiable

Déployez un workload représentatif, observez-le pendant 30 jours, puis comparez la consommation mesurée du service, de la base de données, des previews et du disque au solde du forfait.

Commencez gratuitement sur app.dockup.ai. Le forfait Free coûte $0 par mois, inclut un crédit de départ de $10 et prend en charge un espace de travail, trois bases de données et trois déploiements.

FAQ

Combien coûte Dockup ?

Free coûte $0 et inclut $10 de crédit de démarrage. Hobby coûte $5 par mois, l'usage étant facturé en supplément, et Pro coûte $20 par mois avec les $20 premiers d'usage inclus.

Qu’est-ce qui est illimité dans les forfaits payants Dockup ?

Les forfaits payants autorisent un nombre illimité d’espaces de travail, de bases de données et de déploiements. La consommation de CPU, de RAM et de disque utilise toutefois le solde du forfait.

Comment la consommation Dockup est-elle mesurée ?

La consommation de CPU, de RAM et de disque est mesurée à la minute et déduite du solde inclus ou rechargé du compte.

La tarification à l’usage est-elle toujours moins chère qu’une instance fixe ?

Non. Elle peut réduire les coûts pour les workloads variables ou inactifs, tandis qu’un workload prévisible et constamment sollicité peut être compétitif avec une instance fixe. Modélisez une demande identique.

Comment comparer les tarifs de deux PaaS ?

Normalisez les heures d’exécution, le CPU, la mémoire, le disque, les bases de données, les previews, le transfert, les sièges et le support, puis identifiez les frais fixes, l’usage mesuré, les crédits inclus et les incertitudes.