← Retour au site

Cloud public : maîtriser la hausse d'octobre 2026

Publié le

Au 1er octobre 2026, le prix du calcul ne bouge pas, mais le stockage local et l'adresse IPv4 publique des instances de génération 3 deviennent payants à part. Pour une TPE ou une PME, cela se prépare par l'architecture réseau, le dimensionnement et le calendrier d'engagement.

Illustration en style plat et épuré : une facture cloud stylisée dont deux nouvelles lignes, un disque dur et une étiquette « IPv4 », sont mises en évidence, à côté d'un schéma réseau où une seule pas
Sommaire 10 parties

Une hausse discrète qui touche d'abord les petites infrastructures

Le billet « Public Cloud : nos tarifs évoluent au 1er octobre 2026 », publié sur le blog d'OVHcloud (auteur non précisé), détaille un changement de modèle tarifaire. Le principe tient en une phrase : le prix horaire du calcul reste identique, mais deux ressources jusqu'ici incluses dans les instances B3, C3 et R3 sortent du forfait. Ces deux ressources sont le stockage local et l'adresse IPv4 publique.

À configuration identique, l'éditeur annonce une hausse comprise entre 1,4 % et 21,9 % selon le gabarit. L'écart est large, et il ne joue pas en faveur des petites structures. Les instances les plus modestes, celles qu'une TPE ou une PME utilise pour son site, son CRM, son ERP ou ses outils internes, sont les plus touchées.

Chez comm.it, nous ne voyons pas cette annonce comme une simple ligne de plus sur une facture. Elle oblige à réexaminer trois sujets que nous traitons au quotidien avec nos clients :

  • l'architecture réseau ;
  • le dimensionnement des ressources ;
  • la stratégie d'engagement dans la durée.

Cet article explique comment ces trois sujets permettent de limiter l'impact du changement, et parfois d'en tirer un bénéfice en sécurité ou en lisibilité.

Ce qui change concrètement

Avant de parler de leviers, voici les faits tels que les présente la source.

  • Le compute ne change pas. Le prix horaire des instances est le même avant et après le 1er octobre 2026, sur toutes les gammes.
  • Le stockage local devient une classe à part entière, appelée Local Low Latency. Il est facturé 0,0001458 € HT par Go et par heure, soit environ 0,11 € par Go et par mois.
  • L'adresse IPv4 publique devient une ligne distincte, à 0,0027 € HT par heure, soit environ 1,97 € par mois.
  • Le Block Storage haute disponibilité, l'Object Storage et le File Storage restent au même tarif.
  • Les gammes précédentes (B2, C2, R2 et antérieures) conservent leur stockage local inclus.
  • Les Savings Plans sont simplifiés : il ne reste que deux durées, 12 mois à -15 % et 36 mois à -30 %. La remise porte uniquement sur le compute.

Le calendrier se déroule en trois étapes :

  1. Fin août 2026 : mise à jour des tarifs sur le site.
  2. 1er septembre 2026 : ouverture de la nouvelle grille des Savings Plans et information des clients concernés.
  3. 1er octobre 2026 : facturation séparée du stockage local et de l'IPv4.

Pourquoi les petits gabarits sont les plus exposés

Les analyses publiées par OVHcloud donnent elles-mêmes l'explication. La hausse est identique en euros pour toutes les instances qui ont la même capacité de stockage, puisque le stockage plafonne à 400 Go et que l'adresse IP coûte un montant fixe. Sur une petite instance, ces deux postes représentent une part importante de la facture. Sur une grosse machine, ils deviennent presque négligeables.

Les chiffres de la source le montrent bien :

  • une c3-4 passe de 33 € à 41 € par mois, soit +21,9 % ;
  • une b3-8 passe de 37 € à 45 €, soit +19,5 % ;
  • une b3-640 passe de 2 987 € à 3 032 €, soit seulement +1,5 %.

Pour une PME qui fait tourner quelques serveurs de taille modeste, le pourcentage de hausse sera donc nettement plus élevé que celui d'un grand compte. C'est précisément le profil de clientèle que nous accompagnons. Les leviers décrits ci-dessous comptent donc beaucoup.

Levier n° 1 : repenser l'exposition réseau

Une IPv4 publique par serveur n'est plus une évidence

Dans beaucoup d'infrastructures, chaque serveur a reçu une adresse IPv4 publique par défaut. C'était gratuit et pratique. Au 1er octobre, chacune de ces adresses aura un coût récurrent.

L'un des exemples de la source est très parlant. Une infrastructure composée d'une gateway exposée sur Internet et de dix instances privées coûterait 860,70 € par mois. Si les dix instances portaient chacune une IP publique au lieu de passer par la gateway, la facture monterait à 869,70 €. L'éditeur résume l'enjeu ainsi : ne pas attribuer d'IPv4 aux instances qui n'en ont pas besoin permet d'économiser environ 2 € par mois et par instance, tout en réduisant l'exposition publique des services.

Ce que comm.it met en place

Le networking est l'un de nos métiers historiques. Nous aidons nos clients à passer d'une logique « chaque machine est joignable depuis Internet » à une architecture segmentée :

  • un point d'entrée unique, comme une gateway, un reverse proxy ou un répartiteur de charge, qui seul porte une adresse publique ;
  • un réseau privé pour les échanges entre serveurs applicatifs, bases de données et services internes ;
  • un accès d'administration sécurisé par VPN ou bastion, au lieu d'ouvrir SSH ou RDP sur chaque machine ;
  • une politique de filtrage documentée, qui précise quels flux sont autorisés, entre quelles zones et pour quels usages.

L'économie par adresse reste modeste prise isolément. Le vrai bénéfice est ailleurs : une surface d'attaque réduite, une supervision plus simple et une architecture plus lisible. La hausse tarifaire devient alors l'occasion d'un chantier de sécurité qui aurait de toute façon été utile.

Le cas d'une application web classique

La source prend aussi l'exemple de trois instances applicatives C3-8, exposées chacune avec leur propre IPv4, et de deux bases de données b3-16 en réseau privé. Le coût passe de 351 € à 408,30 € par mois, soit +16,3 %. Avec un quatrième serveur front, il passe de 418 € à 487,30 €.

Pour ce type d'architecture, nous étudions systématiquement la possibilité de placer les serveurs front derrière un répartiteur de charge ou une gateway. Les instances applicatives n'ont alors plus besoin d'adresse publique individuelle. Chaque montée en charge cesse aussi d'ajouter mécaniquement une IPv4 à la facture.

Levier n° 2 : dimensionner le stockage au besoin réel

Le problème du disque imposé par le gabarit

Aujourd'hui, la capacité de stockage local reste fixée par gabarit. La source cite l'exemple d'une b3-64, livrée avec 400 Go quelle que soit l'utilisation réelle. Désormais, ces 400 Go seront facturés, même si l'application n'en utilise qu'une fraction. OVHcloud indique travailler sur une évolution qui permettra de choisir cette capacité indépendamment du gabarit, voire de démarrer sans disque local. Cette option n'est cependant pas encore disponible.

Les instances flex, une alternative à étudier

En attendant, les instances flex répondent en partie à ce besoin. Leur disque local est fixé à 50 Go, quel que soit le gabarit. La ligne ajoutée au 1er octobre reste donc la même en euros (50 Go plus une IPv4, soit environ 7 € par mois), quelle que soit la puissance de l'instance. Selon la source, une b3-64 flex n'augmente que de +2,3 %, contre +14,9 % pour la b3-64 standard.

L'autre atout des instances flex est leur souplesse. On peut redimensionner l'instance d'un gabarit à l'autre, à la hausse comme à la baisse, sans changer de disque local. Si une application a besoin de plus d'espace, on peut ajouter du Block Storage distant, dont le tarif ne change pas.

Notre méthode : mesurer avant de migrer

Passer en flex n'est pas pertinent pour toutes les charges. Une base de données très sollicitée peut profiter d'un stockage local à faible latence. Un serveur applicatif sans état n'a généralement besoin que de peu d'espace disque. Nous procédons en trois étapes :

  1. Inventaire : liste des instances, gabarits, adresses publiques et volumes associés.
  2. Mesure de l'usage réel : espace disque effectivement occupé, profil des entrées-sorties, besoins de performance.
  3. Recommandation par charge de travail : maintien en standard, bascule en flex, ajout de Block Storage ou séparation des données vers l'Object Storage.

Cette approche évite deux écueils. Le premier consiste à payer des centaines de gigaoctets inutilisés. Le second consiste à dégrader la performance d'une application métier critique pour quelques euros.

Levier n° 3 : piloter les engagements avec méthode

Une grille simplifiée, mais un périmètre réduit

La nouvelle grille des Savings Plans s'applique au 1er septembre 2026. Les durées de 1, 6 et 24 mois ne sont plus proposées à la souscription. Il reste deux options : 12 mois à -15 % et 36 mois à -30 %. Surtout, la remise ne porte plus que sur le compute. Le stockage local et l'IPv4 sont facturés hors remise, à leur prix réel.

Les engagements en cours

Les clients qui détiennent déjà un Savings Plan conservent leur prix et leur taux jusqu'au terme de leur engagement. La source précise toutefois un point important : à partir du 1er octobre 2026, le stockage local et l'IPv4 sortent du périmètre de la remise, même pendant un engagement en cours. L'exemple donné est celui d'un plan de 12 mois sur une C3-8, souscrit le 1er juillet 2026 aux anciennes conditions avec une remise de -35 %. Le prix du compute reste garanti, mais une ligne supplémentaire apparaît dès octobre. Au renouvellement, le client bascule sur la nouvelle grille.

Comment nous aidons à décider

S'engager sur 12 ou 36 mois est une décision qui dépasse la technique. Elle dépend de la stabilité de votre activité, de vos projets de croissance et des migrations prévues. Nous aidons nos clients à :

  • distinguer les charges stables, comme l'ERP, le CRM ou la messagerie, qui justifient un engagement, des charges variables ou expérimentales ;
  • finir l'optimisation avant de s'engager, car il serait dommage de bloquer pour 36 mois un gabarit surdimensionné ;
  • anticiper les dates de renouvellement des plans en cours, pour les aborder avec une infrastructure déjà rationalisée.

Levier n° 4 : automatiser le suivi des coûts

Une hausse tarifaire ponctuelle se gère une fois. Une dérive de coûts se gère en continu. C'est ici que notre savoir-faire en automatisation des processus entre en jeu.

Rendre la facture lisible

Avec deux nouvelles lignes de facturation, la lecture des factures cloud devient plus fine. Nous mettons en place des tableaux de bord qui ventilent les coûts par projet, par environnement (production, recette, développement) et par type de ressource. Une direction peut ainsi voir d'un coup d'œil ce que coûte réellement chaque application.

Détecter les ressources orphelines

Une adresse IPv4 attachée à une instance arrêtée, un environnement de test oublié, un serveur dimensionné pour un pic passé : ces petites dérives coûtent désormais plus cher. Des scripts d'inventaire planifiés et des alertes automatiques permettent de les repérer avant qu'elles ne s'accumulent.

Décrire l'infrastructure sous forme de code

L'infrastructure as code consiste à décrire serveurs, réseaux et règles de filtrage dans des fichiers versionnés. Elle permet d'appliquer des règles par défaut, par exemple « aucune IPv4 publique sauf exception justifiée » ou « instances flex pour les serveurs sans état ». Les bonnes pratiques ne dépendent plus alors de la vigilance individuelle de chaque intervenant.

L'IA comme assistant d'analyse

Pour les clients qui le souhaitent, nous intégrons des assistants IA capables d'interroger les données de consommation en langage naturel. Une question comme « quelles instances ont une IP publique sans trafic entrant ? » ou « quel projet a le plus augmenté ce trimestre ? » obtient une réponse directe. L'objectif n'est pas de remplacer l'expertise humaine. Il s'agit de rendre le pilotage accessible à des dirigeants qui n'ont pas le temps de décortiquer une facture technique.

Et pour vos applications métier ?

Nous développons aussi des logiciels cœur de métier, comme des CRM, des ERP ou des outils sur mesure. Ce changement tarifaire influence donc la façon dont nous concevons leur hébergement. Quelques principes guident nos choix :

  • séparer l'applicatif et les données, pour dimensionner chaque brique selon son besoin réel ;
  • ne jamais exposer directement une base de données, une bonne pratique de sécurité qui devient aussi une économie ;
  • concevoir des services sans état lorsque c'est possible, pour profiter de gabarits flexibles et redimensionnables ;
  • stocker les fichiers volumineux (documents, pièces jointes, sauvegardes) dans un stockage objet plutôt que sur le disque local des instances.

Une application pensée ainsi dès sa conception résiste mieux aux évolutions tarifaires des fournisseurs. Elle reste aussi plus facile à faire évoluer et à faire migrer si besoin.

Un plan d'action avant le 1er octobre 2026

Pour les entreprises qui utilisent des instances de génération 3, voici une feuille de route réaliste en suivant le calendrier annoncé par OVHcloud :

  1. Dès maintenant : inventaire des instances B3, C3 et R3, des adresses IPv4 publiques et des Savings Plans en cours, avec leurs dates d'échéance.
  2. Fin août 2026 : vérification des nouveaux tarifs publiés et simulation de la facture post-bascule.
  3. Avant le 1er septembre 2026 : arbitrage sur les instances à basculer en flex, sur les IP à retirer et sur les architectures à réorganiser derrière une gateway.
  4. À partir du 1er septembre 2026 : décision sur les engagements à souscrire sur la nouvelle grille, une fois l'infrastructure optimisée.
  5. Au 1er octobre 2026 et après : suivi automatisé des coûts et revue régulière des ressources.

En résumé

Le changement annoncé ne relève pas le prix du calcul. Il rend payantes deux ressources que beaucoup d'entreprises utilisaient sans y penser. Les petites infrastructures sont les plus touchées en proportion, mais ce sont aussi celles où quelques décisions bien placées font la plus grande différence :

  • réduire l'exposition réseau grâce à une gateway et au réseau privé ;
  • aligner le stockage sur l'usage réel, notamment avec les instances flex ;
  • s'engager au bon moment, sur les bonnes charges ;
  • automatiser la surveillance des coûts pour que les gains durent.

Chez comm.it, nous combinons réseau, automatisation, IA et développement logiciel pour transformer ce type de contrainte en une infrastructure plus sobre, plus sûre et mieux maîtrisée.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.


Source : Public Cloud : nos tarifs évoluent au 1er octobre 2026