OVHcloud augmente fortement le prix de ses VPS 2026 et IPv4
Moins j’augmente plus vite, plus j’augmente moins vite
À partir du 1ᵉʳ avril, OVHcloud va fortement augmenter le prix de ses VPS 2026. En cause, l’explosion du prix de la mémoire et du stockage… mais pourquoi cela concerne-t-il du matériel qui a déjà de nombreuses années ? OVHcloud veut « équilibrer » ses tarifs en limitant les hausses des nouveaux produits à venir et en augmentant ceux des anciennes gammes pour « compenser ».
En août dernier, OVHcloud lançait de nouveaux VPS avec un tarif agressif (lire notre test), à partir de 4,58 euros par mois pour 4 vCore, 8 Go de mémoire et 75 Go de stockage, mais seulement 400 Mb/s de bande passante.
Plus de 40 % sur les VPS 2026 d’entrée de gamme,+ 20 % sur les IPv4
Dans un message publié sur X vendredi, Octave Klaba (qui a repris les rênes de l’entreprise fin 2025) annonçait des hausses à venir : « On prévoit d’impacter légèrement les prix du Cloud déployé entre 2021 et 2025, en moyenne de + 2 % à+ 6 %, en fonction de l’ancienneté du hardware, et de faire évoluer légèrement les prix des IPv4 ». Des chiffres optimistes puisque la réalité est bien différente.
Des emails ont en effet été envoyés aux clients concernés, expliquant que la « gamme VPS 2026, de VPS 1 à VPS 6 et les VPS en Local Zones », ainsi que « les adresses Additional IPv4 » sont concernées par les hausses de prix. OVHcloud n‘y va pas avec le dos de la cuillère. La société est en effet bien loin des « + 2 % à+ 6 % » mis en avant par son PDG, puisque le VPS 1 passe de 5,39 à 7,79 euros (hors remise liée à un engagement de 6 ou 12 mois), soit environ 45 % de hausse !
Selon les retours sur X, c’est plus ou moins la même chose sur les autres offres de la gamme. Le VPS 2 passe ainsi de 8,39 à 11,99 euros par mois (hors remise), soit 43 % de hausse, explique #Kero. Si vous êtes touchés par les hausses, n’hésitez pas à nous laisser un commentaire avec les anciens et nouveaux tarifs des services concernés. OVHcloud n’a pour le moment pas communiqué officiellement sur l’ensemble des nouveaux tarifs à venir.
Une hausse (VPS) peut en cacher une autre (IP) : l’adresse IPv4 supplémentaire est actuellement facturée 2,39 euros par mois, mais elle passera prochainement à 2,87 euros, soit 20 % de hausse. Là encore, nous sommes loin de la « moyenne de + 2 % à+ 6 % » annoncée par Octave Klaba, sans parler de « faire évoluer légèrement le prix des IP v4 ».
Ces changements interviendront « à compter du mercredi 1 avril 2026 », selon l’email envoyé aux clients. Octave Klaba prévoyait de son côté « l’application des nouveaux tarifs au 1ᵉʳ avril 2026 ou au 1ᵉʳ mai 2026 ». D’ici là, il est possible de souscrire aux tarifs actuels ou de prolonger un abonnement existant, y compris sur des formules avec un engagement de six ou douze mois (il n’y a pas d’engagement de 24 mois sur les VPS 2026). Lors du renouvellement après le 1ᵉʳ avril par contre, les nouveaux tarifs seront appliqués.
« Cette évolution tarifaire ne s’applique pas aux gammes de serveurs Kimsufi et So you Start. Les performances des services concernés, leur disponibilité ainsi que les niveaux de support restent inchangés », explique l’hébergeur dans son email.
Réduire les augmentations en augmentant les tarifs
Comme nous l’avons expliqué dans notre test du VPS d’OVHcloud, l’hébergeur utilise des CPU d’anciennes générations pour au moins une partie de ses VPS. Dans notre cas (un VPS 1 avec 4 vCores), c’est la génération Haswell lancée il y a plus de 10 ans par Intel. Comme nous l’avons vu avec le test du VPS d’Ionos, un CPU récent change complètement la donne sur les performances.
L’amortissement du matériel est donc théoriquement déjà fait depuis longtemps. Pourquoi donc cette hausse, justifiée notamment par le fait que « le coût de composants matériels [mémoire et stockage, ndlr] a augmenté » ?
Octave Klaba y va de son explication sur les réseaux sociaux :
« Chez OVHcloud, nous voulons réduire l’impact de ces augmentations de composants pour éviter que notre Cloud (Public Cloud, Private Cloud, Bare Metal) ne devienne trop coûteux. C’est pourquoi, pour le Cloud que nous allons déployer en 2026 - 2028, nous avons décidé d’augmenter les prix de manière moins importante que les coûts réels de la RAM et des disques. Le prix de notre Cloud en 2026 - 2028 va ainsi évoluer, en moyenne, de + 9 % à+ 11 % seulement. Pour compenser, on prévoit d’impacter légèrement les prix du Cloud déployé entre 2021 et 2025 ».
OVHcloud veut « rendre acceptable le prix des gammes 2021 - 2028 »
L’hébergeur augmente donc le prix de ses anciennes offres pour limiter la hausse sur le prix des nouvelles. On attend maintenant de voir ce que les «+ 9 % à+ 11 % » donneront vraiment dans la pratique. L’idée est donc de « rendre acceptable le prix des gammes 2021 - 2028, avec une prévision de retour à la normale en 2029 ».
Pour le PDG d’OVHcloud, l’augmentation du prix de la RAM et des disques « va encore se poursuivre pour trouver un nouveau point d’équilibre entre l’offre et la demande probablement vers fin 2026 », mais « les prix resteront importants jusqu’à au moins 2028, le temps que de nouvelles capacités de production de mémoire voient le jour ».
Le prix n’est pour OVHcloud pas le seul problème, il y a également la question de la disponibilité : « même avec une telle augmentation de prix, la RAM et les disques ne sont pas disponibles si facilement sur le marché. Pour avoir la certitude d’être livré, il est nécessaire de passer les commandes 12 mois à l’avance, sans connaître le prix d’achat ! Les prix sont en effet communiqués 1 à 2 mois après livraison, en fonction de l’offre et de la demande dans le trimestre ».
Cette hausse de prix et cette pénurie de composants font au moins quelques heureux. Lors du salon IT Partners qui se tenait début février à La Défense Arena, nous avons discuté avec plusieurs entreprises spécialisées dans le reconditionnement et la revente de matériel informatique. Ils étaient unanimes : leur activité est en forte croissance durant cette période compliquée pour la disponibilité et le prix des composants.
Commentaires (82)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 23/02/2026 à 09h16
Par contre, proposer de l'IPv4, je vois vraiment pas l'utilité en 2026. La plupart des trucs qui me viennent en tête et qui ne supporteraient pas la v6 sont très généralement derrière une box qui le gère elle.
Modifié le 23/02/2026 à 09h38
Il faut un support ipv6 sur toute la chaîne pour que ça fonctionne.
Idem en face : pas mal de services ne fournissent que de l'ipv4. Tu n'as que de l'ipv6 ? Tu ne peux pas t'y connecter.
Modifié le 24/02/2026 à 11h50
Le 24/02/2026 à 12h27
Le 24/02/2026 à 12h48
Sur la lisibilité, qui a l'habitude de lire de l'hexadecimal mis à part les techos ?
En IPv4, ça va de 1 à 128 sur 4 positions pour le commun des mortels. Ils ne savent pas que c'est sur 4 octets et que 128 veut en réalité dire 11111111. Et que dire de la nomenclature /nombre pour déterminer le masque réseau.
En IPv6, qu'est-ce qui est globalement plus facile?
Modifié le 24/02/2026 à 13h55
128, c'est 10000000. 255 c'est 11111111
[edit]
Sur le fond, si on fait de l'IPv6 comme on fait de l'IPv4, rien n'est plus facile. On est d'accord.
Si on fait de lIPv6 comme il est prévu de faire de l'IPv6, alors on n'a pas de Nat, pas de MTU à gérer, et les différentes classes d'adresses sont continugues (contrairement l'IPv4, où, par exemple, pour vérifier si une adresse est locale, il faut vérifier qu'elle ne soit pas de classe A, B ou C, alors que c'est la simple vérification d'un prefix en IPv6)
Le 24/02/2026 à 18h04
J'entends les arguments technique
Pour faire du réseau local avec le matériel actuel, ça va être plus compliqué, surtout pour les novices. Très peu de particuliers vont monter en compétence sur la norme. En ipv4, tu gères juste une plage de 1 à 100 derrière du NAT. Si demain tu dois gérer des préfixes pour faire du "local", tu vas avoir une grosse gestion du changement à faire.
Après, si le NAT disparaît et que la fonction du routeur devient obsolète, on perd un peu le noeud qui gère le firewall. Du coup, comment qu'on fait? Firewall sur chaque appareil?
Le 24/02/2026 à 19h03
Le 24/02/2026 à 20h01
Modifié le 24/02/2026 à 20h16
Donc si, les box actuelles sont globalement nécessaires.
Cf la réponse de fred ci-dessous, j'oubliais l'essentiel : il faut un routeur
Le 24/02/2026 à 20h08
Tu ne vas pas balancer le trafic de ton réseau local sur le réseau du FAI vers un de ses routeurs pour que ça revienne ensuite chez toi.
Le 25/02/2026 à 10h25
Rappel que le NAT IPv4 « qui fait firewall » était un bug, pas une feature… (La plupart des box ne firewall de plus rien du tout, coucou UPnP…)
Et faire du réseau local IPv6 est pas plus compliqué que faire du réseau local IPv4, à config identique bien entendu.
Oui tu peux te mettre à faire du prefix delegation pour router des adresses publiques IPv6 sur des VM derrière une DMZ… Mais c’était DÉJÀ compliqué si tu voulais faire ça en IPv4 hein…
Modifié le 24/02/2026 à 14h25
Aussi, la délégation de préfixe est native ce qui est génial pour gérer des groupes logiques et donc la gestion de flux firewall qui va avec.
Quand on a goûté à ça on a juste envie de foutre ipv4 à la benne.
Ipv6 prévoit aussi un mécanisme de roaming mobile que je trouve assez cool mais qui vraisemblablement n'est jamais sorti des labos
Le 25/02/2026 à 21h20
En IPv4, tu NAT avec l'IP du FAI#1, si ca tombe, tu passes sur FAI#2 sans devoir tout reIP ton réseau local.
Le seul moyen de faire ca propre en IPv6, c'est d'avoir ton AS et ton prefix que tu peux annoncer en BGP. Autant dire que ca ne va pas être fréquent...
Sinon c'est du NATv6 (comme en IPv4...) ou du NPTv6 qui n'est quasiment pas implémenté et qui pose des problèmes car ton IP public n'est pas la même que l'IP "privée".
Donc non, IPv6 n'est pas la solution simple et magique à tous les problèmes.
Le 25/02/2026 à 21h35
Le 25/02/2026 à 21h56
Le cas est bien prévu en ipv6 : chaque routeur annonce son préfixe donc tes terminaux vont porter 2 préfixes différents et pour faire la différence de poids entre routes (si tu veux une topologie actif/passif), le champ router preference high/medium/low a été créé. Par défaut la plupart des implémentations émettent en medium mais c'est évidemment personnalisable. A ma connaissance les implémentations linux et freebsd respectent ce champ lors de la création des routes, pour les autres os je ne sais pas.
Le 25/02/2026 à 22h44
Bon et puis je viens de lire la RFC 4191 en travers, t'as déjà implémenté et testé ce que tu dis? Car la "pref" semble ne s'appliquer que sur les routes, pas sur les IP de l'interface.
Sachant que quelque soit le nombre de FAI derrière un routeur, au niveau du host, il n'y aura qu'une seule default vers la LL (la fe80::/10) du routeur, ca n'a aucun sens.
La RFC4191, c'est "router pref", en gros, c'est pour qu'un host sache basculer entre plusieurs routeurs sur un même subnet, pas switcher d'une GU (global unicast) à une autre qui serait configuré sur une même interface.
Modifié le 26/02/2026 à 06h52
-> En effet, dans la topologie où tu as un routeur par FAI, il y a effectivement une action manuelle à effectuer si le routeur perd le lien sauf s'il existe un moyen de l'automatiser ce que je ne connais pas.
Néanmoins je ne pense pas non plus que le cas dont on parle soit très répandu car dans un réseau critique type DC il y aurait un AS avec annonces pour automatiser (et surtout avoir une gestion des routes bien plus fine ainsi qu'une indépendance totale de l'adressage et pas un préfixe qui change si on change de fournisseur) mais vu que tu parlais de nat avant je pense qu'on ne parle pas de ce cas, tandis que dans le cas d'un réseau plus "modeste" d'entreprise la bascule (et donc les RA en cascade) serait effectuée par le routeur edge qui serait directement connecté aux 2 FAIs.
"Bon et puis je viens de lire la RFC 4191 en travers, t'as déjà implémenté et testé ce que tu dis? Car la "pref" semble ne s'appliquer que sur les routes, pas sur les IP de l'interface."
-> Oui testé sur routeurs linux et cisco tous deux avec hôtes linux avec succès. La préférence est utilisée par linux pour setter la priorité des routes annoncées (généralement la route par défaut).
"Sachant que quelque soit le nombre de FAI derrière un routeur, au niveau du host, il n'y aura qu'une seule default vers la LL (la fe80::/10) du routeur, ca n'a aucun sens."
Pas compris.
"La RFC4191, c'est "router pref", en gros, c'est pour qu'un host sache basculer entre plusieurs routeurs sur un même subnet, pas switcher d'une GU (global unicast) à une autre qui serait configuré sur une même interface."
-> C'est ton interprétation, je n'ai pas observé de telle limite dans mes tests et non seuleument je ne la vois pas indiquée dans la RFC mais surtout celle-ci décrit explicitement ce cas "multi-home" dans §5.2.
PS : cela dit je pars du principe que multi home veut dire multi préfixe mais c'est pas si évident en lisant ce paragraphe car l'exemple qu'ils donnent n'est pas exactement celui là
Le 26/02/2026 à 18h43
route != router
Les annonces de RA annoncent l’IP LL (link local). Donc si j’ai un routeur qui gère 2 FAI. Mes hosts finaux n’auront quand même qu’une default vers l’IP LL de mon routeur. Mais tu le dis que la stack Linux met une prio sur l’IP GU de sortie suivant la préf de l’annonce. Je te crois et j’essayerai dès que je peux. Mais c’est de la bidouille.
Sinon, moi je te parles d’un cas très simple. Je suis beaucoup en télétravail, je veux un accès Internet fiable. J’ai donc deux FAI: Free ftth et Sosh en 4G (via un routeur 4G avec un port ethernet).
La Freebox et le routeur 4G sont connecté en ethernet sur un Mikrotik.
Il n’y a pas de méthode simple de switcher l’IPv6 de Free à Sosh (et inversement) quand la connexion bascule.
Alors je peux essayer (pas encore fait) de faire compliqué avec la RFC 4191, mais ça ne marchera que pour les subnet dont la default route est géré par le Mikrotik. Mon lab, qui est encore un saut plus loin, géré par un autre routeur, n’a aucune idée si la ftth est up ou pas.
Bref, c’est quand même très compliqué de faire en IPv6 un truc très largement utilisé et qui était très simple en IPv4…
Bon et évidement, je te parle même pas des prefix delegation dynamique d’Orange (quand j’avais Sosh en ftth) qui qui ne respecte pas les RFc et t’annonce un lease de 1 semaine et qui change le prefix délégué au bout de 2j…
Le 26/02/2026 à 19h29
"Les annonces de RA annoncent l’IP LL (link local). Donc si j’ai un routeur qui gère 2 FAI. Mes hosts finaux n’auront quand même qu’une default vers l’IP LL de mon routeur"
Jusque là d'accord, néanmoins je parlais bien du cas où il y a 2 routeurs différents, chacun branché à un FAI différent ce qui fait que les terminaux du réseaux ont chacun 2 routes par défaut (une/routeur) puisqu'il reçoivent les 2 RA dont la priorité est réglable en fonction du router preference émis.
"J’ai donc deux FAI: Free ftth et Sosh en 4G (via un routeur 4G avec un port ethernet).
La Freebox et le routeur 4G sont connecté en ethernet sur un Mikrotik.
Il n’y a pas de méthode simple de switcher l’IPv6 de Free à Sosh (et inversement) quand la connexion bascule"
Dans le cas où il y a un routeur edge qui sort sur plus d'un réseau à la fois (qui est un cas d'usage courant), il revient au routeur de gérer la bascule et d'émettre immédiatement un nouveau RA qui va passer le lifetime de l'ancien préfixe à 0 et en même temps annoncer le nouveau préfixe. En tout cas à ma connaissance point de vue IPv6 il n'y a rien qui l'empêche toutefois je suis loin d'être un expert de ce type de topologie et il y a peut être des pièges, mais je sais que ça se fait.
Par contre attention, sur ce type de fonctionnement il faut des implémentations solides de routeurs professionnels et si possible interroger les fournisseurs à ce sujet en fonction de ton contrat. Attention aussi au matériel grand public/PME ou entrée de gamme.
"Alors je peux essayer (pas encore fait) de faire compliqué avec la RFC 4191, mais ça ne marchera que pour les subnet dont la default route est géré par le Mikrotik"
Donc dans le cas que tu décris ça ne marchera pas, enfin d'après ma connaissance ce n'est pas du tout prévu pour ça ne serait-ce que par l'absence d'invalidation de l'ancien préfixe.
"Bref, c’est quand même très compliqué de faire en IPv6 un truc très largement utilisé et qui était très simple en IPv4…"
Je perds un peu le fil mais tu parlais de quoi qui était simple en IPv4 ? Si tu parles des ULA natté, le principe est strictement identique en IPv6.
"Bon et évidement, je te parle même pas des prefix delegation dynamique d’Orange (quand j’avais Sosh en ftth) qui qui ne respecte pas les RFc et t’annonce un lease de 1 semaine et qui change le prefix délégué au bout de 2j…"
Il faut oublier ça, j'ai cuisiné la livebox, la freebox et la bbox et elles ont toutes des implémentations douteuses avec la palme des bizarreries pour la freebox. Clairement dès qu'on parle d'un truc aussi con que la délégation de préfixe il faut avoir du matos professionnel ou à la rigueur un Linux mais avec du matériel spécialisé pas du x86 qui consommerait trop. Même FreeBSD qui est réputé sa stack a qq bugs que j'ai remonté.
Le 26/02/2026 à 21h44
Je suis désolé mais le principe n’est pas strictement identique. En IPv6 on va faire du NAT stateless, en IPv4, du NAT+PAT dynamique.
Mais le NAT stateless, c’est pas juste une case à cocher. Il faut faire des règles de translations, faire matcher des tailles de subnet équivalentes. Et je te parle pas du bazar quand en plus le prefix délégué du FAI est dynamique…
Donc pour l’instant, j’ai que l’IPv6 de free. Quand ça bascule, seule l’IPv4 fonctionne, ça génère des timeout à chaque requêtes, je désactive la RA dans mon routeur et je reboot…
Avec le scripting Mikrotik, je pourrais automatiser un peu, mais on reste dans le bricolage, pour juste une pauvre bascule de connexion.
Modifié le 26/02/2026 à 22h20
Mais tu n'es pas du tout obligé de faire du nat stateless
En fait IPv6 ne fait qu'apporter des solutions supplémentaires mais tu peux tout à fait rester dans un mode de fonctionnement quasi iso à IPv4. D'ailleurs c'est la grande raison qui a poussé à DHCPv6 qui est une hérésie en soit : à l'époque il y avait une peur irrationnelle de plusieurs membres des groupes de travail à ne pas pouvoir reproduire la centralisation de l'adressage qui n'apporte finalement strictement rien en soi à part de la complexité supplémentaire (les VLAN sont déjà là pour ségréguer les flux, RA guard/ND inspection permettent de tracer les flux MAC-IP, et les RA peuvent envoyer à peu près les mêmes infos qu'un DHCP sauf rares exceptions) et ironiquement ce n'est que peu utilisé finalement.
Le 23/02/2026 à 09h40
Le 23/02/2026 à 09h51
@aeris22 Pareil, pour moi les box géraient nativement la translation.
Modifié le 23/02/2026 à 10h36
Modifié le 23/02/2026 à 10h42
Lire ceci.
Des liens ont été ajoutés dans le commentaire pendant que je peinais à mettre le mien. (il y a un bug si on met le lien directement pour avoir le bouton Wikipédia, même si on met bien le code de la parenthèse fermante : & #41 ; (sans les espaces))
Le 23/02/2026 à 18h04
Le 23/02/2026 à 21h07
C'est stable, éprouvé et les limites d'emplois sont parfaitement connues.
Pour la maison, je veut bien que cela puisse coincer sur les cas que tu as cité mais sur un serveur, pour couvrir ses besoins d'accès externes, c'est parfaitement fonctionnel et stable. Je l'ai mis en place sur mes serveurs et mes VM arrivent très bien à récupérer des choses depuis www.github.com entre autres.
Le DNSSEC n'est pas totalement bloqué car il reste utilisable entre le DNS64 et l'extérieur. Il n'est juste pas accessible aux client internes pour les adresses translatées.
Les opérateurs téléphonique ont un temps utilisé aussi NAT64/DNS64 et le 464XLAT utilisé massivement en est une variante.
Mon avis perso est que les appareils qui ne permettent pas de communiquer en IPv6 ne devraient peut être plus avoir le droit d'aller sur Internet car plus mis à jour et pas sécurisé. Mes TV connectées par exemple, sont interdites d'Internet depuis un bail.
Les liens directs IPv4 sont en train de disparaître, c'est le sens de l'histoire.
Le 23/02/2026 à 21h41
Le 24/02/2026 à 15h35
Le seul problème que cela pose potentiellement est que le reverse DNS ne peut donner qu'un seul nom de machine.
Le 23/02/2026 à 22h33
C’est juste que Denon / Marantz n’en a rien à battre de mettre de l’IPv6, ni quelconque sécurité sur la gestion via le réseau d’ailleurs… et ce ne sont pas les seuls
Et pour l’IPv6 chez Orange / Sosh, via la livebox, on doit obligatoirement utiliser les DNS d’orange en IPv6, j’ai remplacé la box par un OPNSense entre autre pour cette raison.
Le 23/02/2026 à 23h37
Le 24/02/2026 à 02h56
dns64 64:ff9b::/96 { clients { any; }; };
Le 24/02/2026 à 09h15
Le 24/02/2026 à 10h43
Modifié le 25/02/2026 à 19h08
Tu as raison, c'est le NAT64 qui fait la translation des paquets dont la source ou la destination IPv6 est le préfixe donné par le DNS64.
C'est donc le DNS64 qui marque en quelque sorte les paquets à translater via un préfixe spécial.
Modifié le 24/02/2026 à 10h53
en fait avec unbound ça a l'air assez facile aussi: https://fr-wiki.ikoula.com/fr/Configuration_de_dns64_(bind_et_unbound)
Modifié le 25/02/2026 à 19h23
Pour les clients, mettre any n'est pas considéré comme une bonne pratique. Il est pourtant facile de faire bien.
Dans l'exemple ci-dessous, l'adresse de service de bind est [préfixe donné par FAI]::53/64
Cette adresse doit être ajoutée en plus des adresses auto-configurées, ce qui est très courant en IPv6.
Dans cet exemple, bind n'écoute qu'en IPv6 et ne sert que les autres machines. Cela permet à systemd de faire sa résolution sur localhost.
A mettre dans /etc/bind/named.conf.options si utilisation de debian:
acl dns64-good-clients {
// Please list here the clients that should be allowed to query
// the DNS64 service.
[préfixe donné par FAI]::/64;
};
controls {
};
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
// DNS de free telecom
212.27.40.240;
212.27.40.241;
};
// configure recursive resolution
recursion yes;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation no;
listen-on { none; };
listen-on-v6 {
!::1;
[préfixe donné par FAI]::53;
};
dns64 64:ff9b::/96 {
clients { dns64-good-clients; };
};
};
Le 26/02/2026 à 00h14
Le 26/02/2026 à 08h13
Modifié le 25/02/2026 à 19h24
J'ai pas suivi ton lien mais il y a celui de google mais ce n'est pas recommandé.
La seule manière de le faire sous linux est avec bind9 mais c'est super simple et bien documenté.
Modifié le 25/02/2026 à 19h06
Il y a encore pas mal d'appareils en vente qui ne prennent pas en charge IPv6, pour de mauvaises raisons, tout comme il y a encore des ascensoristes qui installaient des modem 2G dans leurs installation il y a encore quelques mois. Tant que leurs ventes ne plongent pas, ils s'en foutent.
Le sujet de la news était le coût des adresses IPv4 publiques et le besoin d'accéder ou d'être accessible depuis Internet via une adresse dédiée, pour un serveur.
La question est: laisses-tu ton ampli accessible de l'extérieur ou ayant accès à l'extérieur ? J'imagine que non.
Si tu n'a pas besoin de faire communiquer ton appareil IPv4 only avec Internet, je ne vois pas où est le problème.
Le 25/02/2026 à 19h33
Le 25/02/2026 à 19h40
Une fois ces appareils en IP fixe, tu peux mettre en place NAT64/DNS64 puis couper le DHCP.
Tu te retrouve avec quasiment que de l'IPv6, mise à part les quelques appareils qui ne savent pas faire autrement, dont 0 en wifi pour ma part.
Le 25/02/2026 à 21h23
Modifié le 23/02/2026 à 10h21
Le 23/02/2026 à 21h09
Le 24/02/2026 à 11h33
Dans la majorité des cas je n'ai pas la main sur les zones DNS des clients.
Pouvoir déplacer l'IPv4 d'une machine à une autre est juste indispensable pour moi.
Le 25/02/2026 à 19h27
Le 26/02/2026 à 10h36
Tant q'OVH ne permet pas de déplacer les IPv6 des serveur en serveur je ne pourrait me servir d'IPv6.
Modifié le 26/02/2026 à 13h04
Edit: Je parle bien sûr d'un préfixe utilisable pour les adresses de service et non pour les adresses d'administration.
Modifié le 26/02/2026 à 14h24
mais tu ne peut les utiliser que sur ce serveur.
Tu peux ensuite commander d'autres IPv4 (ils appels ça des IPs FailOver) que tu peux attacher ensuite à presque tous le services OVH (baremetal, VPS, cloud).
Le 26/02/2026 à 23h26
Et, donc, je ne compte plus le nombre de situations ou des applis/stacks/produits ne fonctionnent pas ou pas bien parce que l'IPv6 est activé, ou mal configuré, ou ...
Bref maintenant : je désactive purement et simplement la stack IPv6 sur toutes mes machines. C'est la seule manière simple que j'ai trouvé de gérer le sujet :(
Le 23/02/2026 à 09h16
Le 23/02/2026 à 10h22
Le 23/02/2026 à 11h33
Ils ont des contrats pour livrer telle quantité, et ils connaissent le prix d'achat/vente à la réception du versement.
Le 23/02/2026 à 09h34
C'est loin d'être négligeable, mais en même temps cette gamme avait vraiment des tarifs hyper-attractifs, donc moi j'y voyais plus un prix d'appel qu'autre chose. Je suppose qu'ils avaient prévu de faire cette augmentation plus tard, mais que les frais de hardware les ont poussés à l'anticiper...
Le 23/02/2026 à 21h10
Le 23/02/2026 à 09h41
Le 23/02/2026 à 10h20
Je peux en revanche faire un parallèle avec les opérateurs grand public :
En revanche, je vois bientôt arriver toutes les offres tech grand public qui vont nous expliquer que leurs serveurs ont besoin de plus de hardware "afin d'améliorer notre qualité de service" : Stockage Cloud (Google Drive). Streaming (Netflix, Spotify,...), Cloud Gaming (Shadow, GeForce Now...), etc.
Bon, sauf l'IA puisqu'elle est toujours dans sa phase de dumping.
Le 23/02/2026 à 11h33
Après je suis d’accord que par exemple si je prends une Freebox révolution elle est ultra rentabilisée depuis 15 ans et le volume que fait Free est suffisant pour avoir la masse critique (par ex).
Le 23/02/2026 à 14h43
A titre perso, j'ai même plutôt diminué ma facture, mais ça s'est pas du tout fait naturellement ni sans mon intervention :
Bref, on me faisait payer plus pour de plus en plus obsolète, ce qui n'avait de sens ni dans une relation commerciale, ni dans un business model normal.
Dans le cas d'OVHcloud, c'est un peu différent, s'il y a des interventions liées à des pannes, ils vont devoir trouver le hardware de remplacement... donc ça engendre bien des dépenses supplémentaires à prévoir sur du hardware existant. A l'inverse, mon FAI se retrouve avec du reconditionné en pagaille quand il renouvelle son matériel, donc remplacer ma box est une formalité au fil du temps.
Le 23/02/2026 à 16h09
Donc ok oui passé un certain nombre d'année la box est + ou - amortie.. ca ne change pas forcement grand chose dans l’équation financière de votre "cher" FAI
Le 23/02/2026 à 17h12
Elle est là l'incohérence pour moi dans le modèle.
OVHcloud là fait la même chose. Pour pas être trop prohibitif sur le recrutement de ses clients Cloud Public/Private/etc., dont le matériel coûte un bras, ils augmentent AUSSI les clients existants qui sont déjà les plus rentables du lot et sur un coût de matériel déjà fixé et amorti.
C'est exactement ce que je lis, et c'est un peu spécial comme raisonnement. OVHcloud a au moins le mérite d'augmenter tout le monde, même les nouveaux arrivants... Faudra voir dans quelles proportions c'est fair
Le 24/02/2026 à 08h19
Pour ces opérateur la base de client installé est moins importante que l'acquisition de nouveaux clients, vu que c'est ça qui est mis en avant dans les présentations aux actionnaires.
=> Du coup sur un marché saturé , un client fidèle est vu comme un boulet et on cherche à le faire partir chez la concurrence... avant de le "re-capturer" 1 an plus tard avec les nouvelles offres, comme ça il est compté comme nouveau client.
Plus généralement, je trouve que le marché des opérateurs commerciaux est très atone comparé à celui des hébergeurs. Moi je ne trouve mon compte dans aucune offre commerciale actuelle par exemple - et les offres pro (or FTTE/FTTO) ne sont que des offres des 4 gros en marque blanche, donc sans intérêt majeur techniquement.
Le 23/02/2026 à 11h16
Les robots d'IA finiront par ne plus avoir de contenus à se mettre sous la dent vu que l'hébergement va coûter une blinde, les gens ne pourront plus remplacer leurs ordi / smartphone, et donc ne pourront plus utiliser de chatbots… Et là, toutes les boites d'IA qui ont été financées par de l'argent magique vont se casser la tronche (et le reste avec), j'ai bon ?
Le 23/02/2026 à 11h32
Le 23/02/2026 à 15h00
Il y a des tas d'intérêts politiques et commerciaux à investir lourdement dans des infrastructures. Ils permettront aux partis et aux entreprises de mettre à disposition leurs contenus objectifs via les plateformes IA qui seront nos seules sources d'information, puisqu'on aura plus que le nouveau pin's parlant de Google, le "AI Pin D8" (à prononcer "Hey pine d'huitre").
Le 23/02/2026 à 23h36
Le 23/02/2026 à 11h44
Et Hetzner vient aussi d’annoncer de belles hausses (+30/40%)
https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/
Le 23/02/2026 à 11h59
Petite coquille dans l'article, "l’adresse IPv4 supplémentaire est actuellement facturée 2,39 euros par mois, mais elle passera prochainement à 2,87 euros, soit 20 % de hausse".
Comme mis dans votre screen, ça passe de 1,99€ ttc/mois à 2,39€ ttc/mois ;)
Par contre, c'est à la tête du client suivant le produit qu'il a j'ai l'impression.
Le tarif de 1,99€ à 2,39€/mois c'est sur la partie VPS j'ai l'impression (en plus de votre article, j'avais vu cette augmentation pour quelqu'un qui avait un VPS).
Et de mon côté, ayant une IP additionnelle pour un Kimsufi, je passe de 1,80€ ttc/mois à 1,99€ ttc /mois
Entre 10 à 20% l'augmentation pour une ipv4 lol, se font plaisir les loulous
Heureusement pour la partie Kimsufi et SYS pas d'augmentation de ce qu'avais dit Octave Klaba sur la mailing list.
Le 23/02/2026 à 13h39
Le 23/02/2026 à 14h25
Le 23/02/2026 à 14h36
Modifié le 23/02/2026 à 16h40
3 serveurs d'occasions 2U (88vcpu (bi cpu Xeon 2 X 22coeurs) et 380Go RAM ECC par serveur, de marque, alim redondante platinium, stockage full SSD *24 emplacements, en cluster). Payé environ 3000€HT par serveur livré comme neuf avec les CPU et la RAM hors les SSD(120€HT/To pour du SSD pro neuf). Quand je vois combien ça coûte actuellement, je me dis que c'était une bonne idée.
J'ai fais racheter des SSD+RAM avant les augmentations au cas où et j'ai un serveur complet en plus pour les pièces.
Ceux qui ont des grosses config dans le cloud vont le sentir passer hélas.
Modifié le 23/02/2026 à 22h01
Le cloud ça permet d'avoir un PAAS/IAAS/SAAS professionnel, le tout en 2min pendant que tu es aux chiottes.
Le 23/02/2026 à 22h35
Le 23/02/2026 à 19h38
Le 24/02/2026 à 08h09
Modifié le 24/02/2026 à 00h23
Le 24/02/2026 à 09h17
Pour le moment, OVH reste le moins mauvais fournisseur (coté performance/prix) si l'on accepte le risque de brulure (tacle gratuit assumé)
Jusqu'où allons nous aller avec la merdification d'internet ? (Ploum a écrit un article à ce sujet il y a bien longtemps ... que cela donnerait-il avec la situation actuelle ?)
Le 24/02/2026 à 20h36
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?