Coût du cloud : chiffrer une application, ses dépendances et sa croissance

Deux serveurs et une base de données ne constituent pas encore le budget d’une application cloud. Le réseau, les sauvegardes, les journaux, les environnements de test, les services externes et l’exploitation peuvent modifier fortement l’addition. Un chiffrage sérieux relie une architecture à un volume d’activité, puis rend visibles les hypothèses qui feront varier la dépense.

Ce dossier utilise des tarifs fictifs et des scénarios de calcul.

Ils ne représentent les prix d’aucun fournisseur et ne doivent pas servir à comparer des offres sans consulter leur grille réelle, leur région, leurs unités et leurs conditions.

Décrire une application avant de compter ses machines

Commencez par le trajet d’une demande. Un utilisateur se connecte, consulte une donnée, charge un document ou lance un traitement. Chaque étape mobilise éventuellement un service : résolution de nom, répartition du trafic, calcul, base, stockage, messagerie ou analyse.

Dessinez aussi les tâches invisibles pour l’utilisateur : sauvegardes, collecte des journaux, déploiements, contrôles de sécurité et traitements périodiques. Une facture cloud peut contenir des ressources qui ne correspondent à aucun écran de l’application.

Pour chaque service, notez son propriétaire, son environnement et sa raison d’être. Les ressources de développement, de test et de production doivent être distinguées. Une machine de démonstration oubliée peut continuer de consommer après la fin du projet.

Une architecture distribuée n’est pas automatiquement plus économique. Elle peut répartir la charge avec finesse, mais ajoute des échanges, des outils et des compétences. Notre dossier sur les architectures applicatives expose les conséquences opérationnelles des dépendances entre logiciels.

La première décision porte donc sur les besoins : volume, disponibilité, délai de réponse, localisation, sécurité et reprise. Le choix des composants vient ensuite.

Transformer chaque composant en unité mesurable

Le calcul peut être facturé par durée de fonctionnement, quantité de mémoire et temps d’exécution, ou requêtes selon le service. Le stockage peut dépendre de la capacité conservée, des opérations effectuées et des récupérations. Les flux réseau suivent leurs propres règles.

Lisez les unités. Un gigaoctet décimal contient un milliard d’octets ; un gibioctet contient 1 073 741 824 octets. Un tarif exprimé par Go et une mesure en Gio ne s’additionnent pas sans conversion. La même vigilance s’applique aux milliers ou millions de requêtes.

Une machine facturée à l’heure et maintenue en permanence pendant trente jours représente 720 heures. Un mois de trente et un jours représente 744 heures. La convention de 730 heures utilisée dans certaines estimations correspond à une moyenne, pas à chaque mois réel.

Examinez aussi les minimums de facturation, les classes de stockage, les durées minimales de conservation et les arrondis. Une suppression rapide ne signifie pas toujours une disparition immédiate de tous les coûts associés.

Conservez la grille consultée, la date, la région, la devise, les remises et les taxes applicables. Sans ce contexte, un montant calculé aujourd’hui devient difficile à expliquer quelques mois plus tard. Un devis doit pouvoir être recalculé, pas seulement reproduit.

Une simulation mensuelle complète

Imaginons une petite application disponible en permanence durant un mois de trente jours. Deux instances coûtent chacune 0,08 euro par heure. Une base gérée coûte 0,20 euro par heure. Les autres montants suivants sont également hypothétiques.

Le total de ces ressources atteint 581,70 euros. Il ne contient pas encore le travail humain. Huit heures d’exploitation à un coût complet de 50 euros ajoutent 400 euros : le coût mensuel du périmètre étudié atteint 981,70 euros.

Avec 20 000 opérations métier réussies dans le mois, cela représente environ 0,0491 euro par opération. Sur la seule consommation cloud, le ratio est de 0,0291 euro. Ces deux indicateurs répondent à des questions différentes ; leur nom doit préciser leur périmètre.

Le tableau n’inclut pas tous les postes possibles. Une offre réelle peut ajouter support, sécurité, réseau privé, licences, moteurs de recherche ou services d’IA. La bonne méthode consiste à retrouver chaque composant de l’architecture dans le chiffrage.

Croissance : distinguer ce qui double de ce qui ne double pas

Doubler le nombre d’utilisateurs ne double pas nécessairement toutes les ressources. Une base peu chargée peut absorber une hausse sans changement. Un seuil de capacité peut, au contraire, imposer un palier coûteux. Le stockage historique peut croître même si le nombre d’utilisateurs reste stable.

Dans notre simulation, supposons que le trafic sortant, les opérations de stockage et les journaux doublent, sans modification immédiate des autres postes. Le total cloud augmente de 72 + 1 + 20 euros, soit 93 euros. Il passe à 674,70 euros.

Si les opérations métier réussies doublent aussi à 40 000, le coût cloud unitaire tombe à environ 0,0169 euro. La dépense totale monte tandis que le coût par opération diminue. Observer uniquement la facture peut donc conduire à une mauvaise lecture.

Ce résultat dépend fortement des hypothèses. Si la base doit changer de capacité ou si les traitements nécessitent des instances supplémentaires, ajoutez ces paliers. Un modèle linéaire qui ignore les seuils donne une précision trompeuse.

Préparez trois scénarios : activité attendue, activité basse et pointe plausible. Pour chacun, indiquez ce qui varie, les limites atteintes et l’action prévue. Une campagne exceptionnelle peut générer beaucoup de requêtes sans produire autant de ventes : utilisez un indicateur métier en parallèle.

Les flux entrants, sortants, entre zones ou entre services ne sont pas nécessairement facturés de la même façon.

Les règles dépendent du fournisseur, du service et du trajet. Une architecture doit donc documenter ses échanges au lieu d’appliquer un tarif unique à tout le réseau.

Prenons un document moyen de 5 Mo téléchargé 100 000 fois. Le volume brut atteint 500 000 Mo, soit 500 Go en unités décimales, avant les autres échanges. Modifier le poids moyen ou la fréquence change directement cette estimation.

Un cache peut réduire certaines sollicitations à l’origine, mais il possède ses propres coûts et règles. Vérifiez les résultats observés : taux de réponse depuis le cache, volume sortant de chaque composant et taille des objets. Un taux de cache favorable ne prouve pas à lui seul que la facture globale diminue.

Les transferts de reprise et de sortie doivent également être chiffrés. Récupérer une grande quantité de données vers un autre environnement peut entraîner consommation réseau, opérations et travail humain. La réversibilité n’est pas seulement un format d’export.

Évitez une optimisation qui rendrait le système opaque ou fragile pour une faible économie. Le coût d’un connecteur supplémentaire et sa surveillance peuvent absorber le gain attendu sur les transferts.

Surdimensionnement et engagements : optimiser dans le bon ordre

Mesurez d’abord l’utilisation réelle et les besoins de performance. Une instance peu sollicitée peut être réduite, mais une moyenne faible peut cacher des pointes critiques. Observez la mémoire, le processeur, les temps d’attente, les entrées-sorties et le comportement aux heures chargées.

Les environnements qui n’ont pas besoin de fonctionner en permanence peuvent parfois être arrêtés ou réduits hors usage. Vérifiez toutefois les dépendances, les traitements nocturnes et le temps de remise en route. Un arrêt automatique sans propriétaire peut interrompre un test important.

Les engagements de consommation et les réservations peuvent réduire certains tarifs en échange de contraintes. Leur valeur dépend de la stabilité du besoin et des modalités contractuelles. Réserver une capacité inutilisée ne crée pas une économie simplement parce que son prix unitaire est inférieur.

Dans un scénario simplifié, un engagement mensuel de 300 euros utilisé seulement à moitié reste une dépense de 300 euros. Comparez son coût effectif avec l’alternative réellement consommée. Les taux de couverture et d’utilisation doivent être suivis séparément.

Optimisez donc la quantité nécessaire avant de négocier son prix. Puis vérifiez régulièrement que l’engagement reste adapté à l’architecture. Une migration ou un changement d’activité peut rendre une ancienne décision moins pertinente.

Les journaux peuvent devenir un poste important

Les journaux servent à comprendre les incidents et les comportements. Leur coût dépend notamment du volume ingéré, de la durée de conservation, du stockage et des recherches selon les services. Une application très bavarde peut produire davantage de texte que prévu.

Définissez les informations nécessaires, leur sensibilité et leur durée utile. Les données de diagnostic n’ont pas toutes besoin d’être conservées aussi longtemps. Des journaux applicatifs, de sécurité et financiers répondent à des finalités différentes.

Une réduction du volume doit être testée : supprimer toutes les erreurs fréquentes peut cacher une dégradation. À l’inverse, enregistrer systématiquement des contenus complets peut augmenter les coûts et exposer des données sensibles. Réservez les détails aux cas justifiés et protégez l’accès.

Instrumentez les changements. Si une nouvelle version multiplie le volume de journaux par quatre, le tableau de bord doit permettre de relier cette hausse au déploiement. Sans ventilation par service et environnement, l’équipe voit seulement une facture plus élevée en fin de mois.

Haute disponibilité, sauvegarde et responsabilité ne sont pas interchangeables

Deux instances peuvent aider à supporter certaines pannes, à condition que les autres dépendances suivent.

Une base unique, un secret inaccessible ou un service de stockage indisponible peut conserver un point de défaillance. La redondance doit être évaluée sur le parcours complet.

La sauvegarde répond à un autre problème : revenir à un état de données exploitable. Notre dossier sur la restauration d’entreprise explique pourquoi la réplication seule ne suffit pas face à une suppression propagée.

Le partage de responsabilités dépend du type de service. Dans son modèle, AWS distingue ce que le fournisseur gère et ce qui reste à la charge du client ; ces obligations changent entre infrastructure et services gérés. Aucun label « cloud » ne remplace la lecture des responsabilités concrètes.

Pour chiffrer la reprise, comptez les ressources de secours, leur maintien, les données à transférer et les exercices. Si un environnement est créé uniquement en cas d’incident, vérifiez que cette création reste possible lorsque les accès ou une région sont affectés.

Une économie acceptable conserve les objectifs convenus de sécurité, de disponibilité et de restauration. Réduire silencieusement un de ces objectifs pour faire baisser la facture fausse la comparaison.

Faire vivre le budget dans l’exploitation

Associez les ressources à des projets et propriétaires, par des étiquettes ou un mécanisme équivalent. Les coûts partagés nécessitent une règle d’allocation : volume, usage mesuré ou clé documentée. Gardez une catégorie pour les dépenses encore non attribuées, plutôt que de les répartir artificiellement.

Fixez des alertes de montant et d’anomalie. Vérifiez leur destinataire et le délai de remontée. Une alerte budgétaire ne constitue pas nécessairement un plafond bloquant : certaines consommations continuent jusqu’à une intervention ou une règle explicitement configurée.

Définissez les actions possibles : examiner un service, limiter une tâche non essentielle ou arrêter un environnement identifié. Ne déclenchez pas une coupure générale de production au seul dépassement d’un chiffre sans avoir traité les conséquences métier.

Chaque revue doit comparer budget, dépense, volumes et qualité de service. La démarche FinOps encourage notamment à rapprocher la consommation technologique de la valeur produite ; un coût par transaction réussie peut éclairer ce lien, si sa définition reste stable.

Terminez par une prévision révisée et des décisions attribuées. Le dossier de coût devient utile lorsqu’un responsable peut expliquer l’écart, proposer un changement et mesurer son effet sur la facture comme sur le service.

Une application cloud économique est une application dont les moyens sont compris et proportionnés. Le montant le plus bas n’est pas toujours le meilleur choix ; le meilleur budget est celui qui rend les engagements, les risques et la croissance vérifiables.

Avant de retirer une ressource, vérifiez enfin ses dépendances et la procédure de retour. Un disque apparemment inutilisé peut contenir un export encore nécessaire à une migration. L’inventaire, le propriétaire et la date de dernière utilisation doivent être examinés ensemble. Cette précaution évite de convertir une économie marginale en incident coûteux.