Dans un billet de blog signé par Octave Klaba et Michel Paulin, l’hébergeur pointe du doigt le coupable : l’inflation. « Avec un taux annuel qui atteint +8,9 % en juillet 2022 en Europe, dont +39,7 % pour les coûts d’énergie, l’inflation a un impact important touchant tous les secteurs d’activité, dont le secteur du numérique ».
Les couvertures d’achat arrivent à leur terme et OVHcloud va devoir « acheter l’énergie au prix fort ». Cette augmentation significative va être répercutée et « impacter les services nouvellement souscrits, mais aussi les services existants ».
Ainsi, au 1er décembre 2022, la société va « procéder à une augmentation maîtrisée de [ses] tarifs de l’ordre de 10 % sur Baremetal (Serveurs, Eco, VPS), Hosted Private Cloud, Public Cloud et les hébergements Web ». De plus amples détails seront donnés dans les prochaines semaines.
Hasard du calendrier, une autre annonce vient de tomber : Yann Leca, vice-président exécutif et directeur financier d’OVHcloud, démissionne et quittera la société fin octobre. Le communiqué indique simplement qu’il souhaite donner une « nouvelle orientation à sa carrière professionnelle ». Le recrutement d’un remplaçant est en cours.
La nouvelle ne ravit pas particulièrement la bourse. L’action baisse légèrement pour atteindre 13,5 euros seulement… loin des 18,50 euros lors de son introduction et des 22 euros une semaine plus tard.
Commentaires (33)
#1
Après Sony qui a augmenté le tarif de la playstation … ça commence à se voir que l’économie n’est pas au top de sa forme
#1.1
On n’est plus trop habitués à l’inflation, mais il y a 30 ans, c’était la routine.
#1.2
C’était plutôt il y a 40⁄50 ans : 1973 à 1983, https://france-inflation.com/inflation-depuis-1901.php
Et la différence, c’est que les salaires ont fortement progressés dans les années 70 : https://www.ofce.sciences-po.fr/pdf/ebook/ebook121.pdf (+35% pour le salaire médian entre 1970 et 1980)
Le chômage avait également augmenté : https://www.observatoire-des-territoires.gouv.fr/kiosque/2016-rapport-1b-05-la-hausse-du-chomage-depuis-les-annees-1970-des-impacts-differencies-sur
#2
Moi je vois le bon côté, on va peut être arrêter le gaspillage de resources informatique et demander aux développeurs de faire du code efficient.
Quand je vois les requêtes SQL qui arrivent de framework où les développeurs ne manipule que des objets « magique »… y a largement moyen d’optimiser par 10 ou 100 l’efficacité…
#2.1
Ou alors on va rien demander aux développeurs et on va augmenter les tarifs, comme c’est le cas.
L’énergie coutait déjà de l’argent avant et ca n’a jamais empêché tous les excès…
#2.2
C’est beau de rêver
A moins de contractualiser ça avec le développeur, aucune chance si c’est de la prestation “pissage de code” standard des SSII.
A ma connaissance pas de news, mais j’ai des clients utilisant aussi OVHCloud qui commencent à anticiper ça chez les autres providers qu’ils consomment.
#3
Voir bien plus. Mon record perso est à 37000 et des brouettes
#3.1
Franchement, ca ne m’étonne même pas. J’ai vu des trucs immondes dans ma vie, genre des requêtes lancées à chaque event applicatif qui faisaient des seqential scan d’une base d’1To… merci le framework…
Mais bon, de nos jours, tout doit aller vite en terme de features, sauf que le premier truc qui saute, c’est l’optimisation, donc on met des machines surdimensionnées alors que ca pourrait tourner sur un raspberry pi, et j’exagère à peine.
#3.2
héhéhé, c’est satisfaisant quand on arrive a des trucs du genre, j’ai plus les chiffres, mais j’avais réussi à faire tomber un traitement qui devait prendre 1h ou 2, et qui passait réellement en quelques secondes (même pas 10 peut-être, je sais plus), j’avais passé du temps ensuite à vérifier que le résultat était bon, un tel écart me semblait suspect, mais en fait non et j’avais réussi a encore améliorer le truc après il me semble :p
#4
Malheureusement d’accord…
C’est que ce n’est pas encore assez cher alors.
#5
Le problème est souvent pire que ça. C’est rarement un problème d’optimisation en tant que tel. C’est très souvent un problème de conception foireuse et d’usage d’outils inappropriés.
Mais c’est pas grave, le matériel ne coûte pas cher… contrairement à un dev (même mauvais, alors ne parlons pas des bons !)
#6
Heureusement que j’ai pas investi une grosse somme sur leurs actions vu comme elles chutent depuis l’introduction
Je souhaitais soutenir une acteur européen. Bon bah là, financièrement, je m’en mords un peu les doigts pour le moment… Mais faudra voir à long terme, comme tout investissement de ce type.
#7
Mon ancien directeur technique ne mettait pas d’index sur des (grosses) bases de données. Je vous laisse imaginer le waouh quand je l’ai fait…
#8
le DF qui demissionne sent quand même le poussage vers la porte pour avoir ‘oublier’ de prendre des couverture sur l’energie un peu plus chère et plus longtemps
ca va faire 9⁄8 mois que ca monte bien, leur couverture a ce niveau ne fait même pas 1 an
petite pensé a fessenheim qui depuis sa femeture presque à 30 jours prés le marché de l’électricité a pris son envol, et permet pour certain acteur de super bien margé
#9
Ah ça, je l’ai vécu aussi …
J’ai aussi eu le cas des requêtes avec une clause where ne comportant pas les champs prévus dans l’index, qui du coup ne sert à rien …
T’as aussi le coup de l’interface qui te ramène une liste de 4000 tuples avec 20 colonnes, pour au final n’afficher que 2 infos de 5 tuples …
Temps d’exécution pas cool, charge réseau énorme (vu que les données étaient retournées dans un fichier xml ultra verbeux …)
Bref, un
select champ1 champ2
au lieu de select *
un where qui va bien
et le fichier à transférer passe de 3 Mo (à chaque appel pour chaque user) à 150 ko …
#9.1
Ca, c’est en faisant l’impasse sur les requêtes dans des boucles, en omettant les contraintes d’intégrités (ça sert à rien, ça nous gène, on fait attention, …), les noms de colonnes farfelues ou trompeuses, le code-spaghetti (dans un programme ou une fonction SQL hein), …
Bordel, maintenant que je suis développeur, PEBKAC.fr me manque …
#10
Clair qu’investir sur OVH n’est pas une stratégie sur du court terme, mais globalement c’est une boîte qui tient la route, ça devrait finir par remonter. Heureusement, mes actions ne sont que virtuelles sur abcbourse
De toute façon faut pas rêver, ça sera pas les seuls, c’est juste les premiers (ou les premiers dont on parle). N’importe quelle entreprise se tape actuellement des hausses à un endroit ou à un autre.
Tu peux faire un effort sur ta marge pendant un temps, mais tu finis forcément par devoir le répercuter quelque part.
#11
Qu’en est-il des concurrents ? Ils augmentent aussi leurs tarifs ?
#11.1
Hetzner (en allemagne) a augmenté ses tarifs. j’ai un serveur chez eux, j’ai déjà eu 5% d’augmentation en janvier dernier et là j’ai eu un mail pour m’informar d’une hausse d’environ 10% à la fin de l’année :/
#11.2
En effet j’ai lu ça quelques messages au dessus. Je suis aussi chez Hetzner, pas très satisfait des perfs donc ça sera l’occasion de ne pas renouveler (j’attends l’e-mail officiel pour résilier).
#12
Si seulement.
Mais j’ai dans l’idée qu’on va continuer sur la stratégie “vite fait, vite vendu” afin de vite remplir les caisses et montrer à tous la bonne santé financière de l’entreprise.
#13
Ah, j’ai fait ça une fois, passer d’un tableau JSON de 150 Mo (cas extrême) à un booléen. C’était récupéré sur une page pour savoir si on activait un bouton pour aller sur la page suivante (un array.length > 0 était fait coté JavaScript, plutôt que de le faire coté bdd)
#14
Si mon salaire augmentait lui aussi de 10%, il n’y aurait pas de problème. Cette année, j’ai eu généreusement 3%, et uniquement car mon supérieur c’est impliqué, sinon, on était plutôt à 2%. C’est basé sur le pourcentage gouvernemental de l’inflation de l’année précédente. Déjà que ce pourcentage est un dogme et pas la réalité.
Pour les ressources, si on arrêtait Angular/NodeJS et ces milliers de fichiers et dépendances, et si en plus on y ajoute Docker, on se retrouve avec 300Mo d’image docker pour un “Bonjour le monde”
#14.1
J’ai réussi a gratter un petit 7% car en dessous du marché et justement en sortant l’inflation et quand je vois derrière le prix de l’énergie etc qui va doubler voir tripler en 2023, ça n’annonce rien de bon toussa … Mon augmente est déjà bouffer par inflation + prix de l’energie. Sachant qu’on est déjà en train de nous mettre dans le crâne que l’année prochaine c’est the crise … On peut oublier les augment de salaire comme à la dernière crise inflationniste.
Concernant la lenteur des applications, je me suis battu récemment avec un éditeur de solution EPM (que ne citerais pas pour pas avoir de pbm
. Juste que ce n’est pas big red 
). On a mis Microsoft sur le coup car c’est une base SQL Server et même eux ont dit que les appels base n’était pas opti mais l’éditeur a préféré dire que Microsoft était incompétent 
. Donc bon l’optimisation de la conso on part de loin. Beaucoup de DEV ont accès à une puissance tellement folle que bon pourquoi s’emmerder à optimiser. Suffit de monter le CPU et la RAM pour compenser
#15
C’est économiquement parlant la meilleure des alternatives.
Certains ici qui pensent que la finalité d’un dev est la ‘beauté du code’ (et se persuadent à peu de frais au passage de “savoir - eux - mieux coder que le reste de la plèbe”).
Reste que ceux qui ont un tant soit peu les pieds sur terre ont compris qu’un soft a pour but premier une efficience au niveau économique: on fait de l’info pour baisser le coût d’un traitement automatisable, en le faisant exécuter par une machine moins coûteuse et plus rapide que la même tâche exécutée par un être humain).
Si un dev coûte 500 balles par jour, pas besoin de gros calculs pour comprendre que le code ‘non optimisé’ a souvent vite fait d’etre plus rentable, malgré le surcoût en matos, que le code aux p’tits oignons plus cher à produire.
#15.1
Et au bout de 40 ans l’ERP est devenu un monstre de rustines et de xénogreffes qui font que la moindre modification coûte 20 jours de dev alors qu’un code propre et bien documenté dès le départ fluidifierait les développement successifs qui coûteraient donc moins cher (sans compter les économies d’énergies qui ne sont pas à négliger sur 40 ans).
#15.2
a 1600€ le MWH au lieu de 80€ (voir jusqu’a 4000€ cet hiver), qui ne sont pas a négliger sur 1 mois
#16
Non, la finalité d’un dev, c’est d’écrire du code.
Quand on parle d’optimisation dans le langage courant, c’est améliorer les performances. Mais il faut connaitre les sources des problèmes de performances pour comprendre qu’il se cache en réalité, derrière ce concept plus choses.
La première (et la plus grosse), c’est une application mal codée et/ou mal structurée. Là, il ne s’agit pas de faire un “code aux petits oignons”, simplement savoir coder. Tout le monde est capable de poser un parpaing. Faire un mur complet, droit et sans défaut, c’est autre chose. C’est exactement pareil pour le code. Ecrire une ligne de code est à la portée d’un grand nombre de personnes, écrire un code efficace et fonctionnel non.
Et un logiciel bien fait ne coute pas forcément plus cher. C’est même bien souvent le contraire sur le long terme. Mais c’est un art, qui nécessite compétence et expérience.
Le deuxième type d’optimisation, c’est l’optimisation en tant que telle. Pas pour avoir un code “plus performant”, mais bien pour obtenir “les meilleures performances possibles”, car cela représente un réel avantage (par rapport à la concurrence, sur le traitement des données, moteur de jeux vidéos, etc…). Utiliser un algorithme plus performant, utiliser des astuces pour consommer moins de RAM ou de CPU, utiliser des caches, etc… Ca oui, ça coute du temps de dev (et donc de l’argent). Mais contrairement à beaucoup d’idées reçues, ce type d’optimisation est très rarement nécessaire.
#17
La finalité d’un dev c’est d’offrir un service qui offre une valeur ajoutée à celui pour lequel il code (ce qui lui vaut en échange une rémunération). La valeur ajoutée reste celle que j’ai mentionnée dans mon post précédent.
Tu te contredis en deux paragraphes. Si c’est une compétence (un ‘art’ même, soyons fous), c’est plus rare donc plus cher.
Il y a des endroits où les perfs et l’efficience en terme de conso de ressources est critique pour le business visé (l’exemple parlant, ce sont les jeux vidéos). Parce que si tu n’atteint pas la perf, tu ‘e rends tout simplement pas le service visé. Sauf que ça représente une goutte d’eau, disons <10% dans l’océan des besoins en code globaux (qu’on pourrait qualifier essentiellement d”‘informatique de gestion”).
En tant que product owner d’une app non perf critical, j’ai le choix entre 5 devs à 1k€ par jour et 10 devs à 500€ par jour (quitte à ce que les seconds nécessitent les ressources d’un ou deux serveurs supp à 4k€ amortis sur trois ans). Ben sauf a être suicidaire, je prends la seconde option sans la moindre hésitation.
Je livrerai plus de valeur avec les 10 devs, disons ‘mediocres’, la valeur de mon produit étant concentrée non pas dans ses perfs intrinsèques mais dans l’éventail de fonctionnalités implémentées.
Et si un jour j’ai un vrai besoin/blocage relatif aux perfs ou a l’optimisation, je prendrai un dev expert pendant un mois pour résoudre le problème avéré.
#18
Depuis le début d’année les prix ont augmenté chez certains hébergeurs allemands.
hetzner augmente encore ses tarifs début septembre
https://docs.hetzner.com/general/others/price-adjustment/
Il y a aussi des projets de datacenter qui changent de pays car le pays en question. Ne produit pas assez d’électricité. Le cas de Microsoft et amazon amen Irlande.
Chez l’autre gros acteur français Scalaway qui communique de temps en temps via son directeur sur les difficultés d’approvisionnement à venir cet hiver ou les groupes électrogènes vont fonctionner plus souvent que d’habitude du au délestage du réseau.
La situation va être difficile pour le secteur sur les 2 ans à venir. Ce qui est une bonne chose pour arrêter de prendre des instances aws ou azure comme ça, à l’arrache qui gonflent les factures inutilement.
#19
Absolument aucune contradiction. Si tu t’arrêtes au TJM, oui, c’est sûr, un expert coûtera plus cher qu’un débutant.
Si tu regardes sur le coût du projet, tu verras qu’un expert mettra moins de temps et fera un meilleur travail sur du long terme qu’un débutant.
Je suis suicidaire alors. Le TJM ne fait pas tout. Il vaut mieux 5 dev experts qui iront 10x plus vite que tes 10 dev débutants. Tu seras gagnant car :
J’ai pu le constater à de nombreuses reprises, notamment au niveau des startups, mais pas que. Bien sûr, ce n’est basé que sur mon expérience personnelle et je me targuerais bien d’en faire une généralité. Mais même de grands groupes peuvent rencontrer ce genre de problème. Exemple de témoignage chez Amazon, où une équipe, composée de jeunes recrues a littéralement échouée pendant 3 mois à mettre au point un algorithme de détection de fraude efficace. Un nouvel arrivant analyse le problème, passe quelques heures et pond un algorithme très efficace en moins d’une journée.
Un expert coûte cher, mais un incompétent (dans son sens le plus littéral “ne sachant pas” et sans connotation négative) encore plus. Alors plusieurs…
#20
J’ai fait exactement ça chez un client, résolu en une semaine un problème sur lequel avaient planché 2 novices pendant 2 mois, et où ils n’avaient aucune chance d’aboutir dans la voie qu’ils avaient choisi.
Après ça reste un exemple extrême, et avec les fourchettes de tarif dont vous parlez, c’est plus difficile car il n’y a pas de dev débutant dans ces prix. Vous auriez dit “choisir entre 15 devs à 200 € ou 5 devs à 600 €” , le deuxième choix me paraît bien meilleur, pour les raisons que tu as citées. Mais entre 500 € et 1000 € c’est plus compliqué, à ces tarifs il y a certainement des spécificités du secteur d’activité à prendre en compte pour faire le bon choix. Des fois ça peut être aussi prendre 1 dev à 1000 € expert du secteur pour le faire gérer une équipe de devs à 500 €.
Dis “novice” ou “débutant” si tu veux éviter la connotation.
#21
De mon expérience je ne ferais pas non plus une généralité de l’augmentation de l’infra pour compenser une appli mal optimisée. C’était la stratégie adoptée sur un précédent projet où j’ai bossé qui intégrait un ERP très consommateur en infra (du genre 50 à 80 clusters par instances) et les problèmes de perf se sont fait sentir évidemment. Au début on est en mode “ok c’est la montée en charge du déploiement on pouvait s’y attendre”, mais pour ceux qui étaient en run depuis bientôt un an l’excuse passait difficilement.
Seule réponse de l’éditeur : augmenter l’infra (ils nous sortaient des précos délirantes à coup d’iOPS stratosphériques et des cargos de CPU/RAM).
Le projet a finalement pris l’initiative de faire auditer par un consultant DBA l’appli pour analyser les lenteurs (qui provenaient de la base, les serveurs d’application se touchaient la nouille), et ne serait-ce que la première journée il avait trouvé des optim pour 5 des requêtes les plus jouées et fait des propositions qu’on a testé et qui ont fait gagner du temps de travail loin d’être négligeable (du genre divisé par 2 certains traitements qui duraient plusieurs heures).
Claqué dans la gueule à l’éditeur en mode “nez dans le caca” pour qu’il optimise son bousin plutôt que de ramener des pelleteuses de silicium pour compenser. Pour le coup, ce fut un bon investissement.