Table des matières de l'article :
L'une des questions les plus absurdes que l'on rencontre habituellement en ligne est : « Quelqu'un pourrait-il me recommander un hébergement WordPress performant et économique ? » , suivie d'une multitude de réponses de sociétés d'hébergement, chacune s'appuyant sur des expériences personnelles directes ou indirectes.
Le problème est que nous parlons de cas et de situations absolument différents qu'il est impossible d'évaluer sans une analyse appropriée des exigences et des besoins.
Que répondriez-vous à ceux qui vous ont demandé :
Michael Jordan ou Diego Armando Maradona étaient-ils plus forts ?
Du point de vue de l'hébergement, la question sonne plus ou moins la même. Il n'a pas de réponse, mais il en mérite certainement une.
La raison est facile à dire, l'informatique est une science presque exact et donc il faut mesurer puis décider. Cette étape est vitale car une mauvaise évaluation fait perdre de l'argent au client.
Cela leur fait perdre essentiellement pour deux raisons, la première parce que le site risquerait d'être lent voire de planter sous le poids d'une charge importante, l'autre raison est qu'il pourrait être poussé à acheter un plan d'hébergement très surdimensionné pour des besoins réels et donc peut-être jeter des dizaines de milliers d'euros par an alors qu'il aurait suffi de simplement évaluer la situation avec calme et compétence puis de l'orienter vers la meilleure solution matérielle et logicielle afin de répondre aux besoins techniques sans aller surdimensionner le matériel et connexes des coûts qui dans certains cas avec certains de nos clients pourraient même atteindre 12 mille euros par mois.
Voici les questions qu'un bon hébergeur et un bon administrateur système devraient poser avant d'orienter un client ou un client potentiel vers une solution d'hébergement, qu'il s'agisse d'un plan d'hébergement mutualisé, d'un VPS, du Cloud ou d'un serveur dédié :
- Quel est le site ?
- Quel CMS utilisez-vous ?
- Quelle technologie matérielle utilisez-vous actuellement ?
- Quels sont les pics de trafic ?
- Les utilisateurs se contentent-ils de lire ou doivent-ils/peuvent-ils se connecter ?
- De quel type de continuité d'activité avez-vous besoin ?
- De quel budget disposez-vous ?
Essayons de comprendre l'importance de ces 8 questions et pourquoi tout bon ingénieur système, surtout si un ingénieur système Linux doit vous les poser.
1 - Qu'est-ce que le site ?
En connaissant simplement le nom du site, un ingénieur système expert est en mesure d'obtenir des données importantes pour dimensionner le matériel nécessaire et choisir le meilleur logiciel.
En effet, grâce à des outils en ligne tels que SimiliarWeb, Weppalizer et BuildWith, nous pouvons connaître en quelques secondes le nombre de visites mensuelles et les technologies côté serveur actuellement utilisées, et grâce à SeoZoom, nous pouvons comprendre la tendance à la croissance ou au déclin et ainsi peser le choix non seulement dans l'immédiat, mais aussi en tenant compte du futur proche.
Pour faire simple : cela nous permet d'avoir une vision approximative de notre futur client.
2 - Quel CMS utilisez-vous ?
Répondre à cette question nous fait immédiatement prendre conscience de la configuration côté logiciel que nous pourrions utiliser et des problèmes à résoudre. Utilisez-vous Joomla ? Utilisez-vous WordPress ? Utilisez-vous Magento, WooCommerce ou Prestashop ? Par exemple, on pourrait évaluer les marges d'amélioration et d'optimisation, sachant que normalement WooCommerce ne permet des améliorations décidément significatives qu'en intervenant sur la configuration logicielle alors que Prestashop fonctionne généralement déjà à son rythme et donc les marges d'amélioration que l'on peut obtenir à partir d'un bon les réglages sont minimes et vous devez nécessairement évaluer le matériel et le dimensionner de manière appropriée si les performances actuelles ne nous satisfont pas.
Mais surtout, utilisez-vous un CMS ou un site personnalisé ?
Prendre conscience de l'utilisation d'un système personnalisé peut-être écrit ad-hoc qui n'utilise aucun CMS nous prévient immédiatement d'un terrain inconnu, dont on ne sait pas quels peuvent être les points faibles, la possibilité d'utiliser un cache statique et dynamique sans bouleverser le code, d'éventuels problèmes d'inefficacité et de lenteur excessive sur la base de données, des requêtes lentes, l'utilisation d'index, les optimisations associées etc.
3 - Quelle technologie matérielle utilisez-vous actuellement ?
Répondre à cette question implique de clarifier l' architecture matérielle qui héberge actuellement le site web ou l'infrastructure web . Cette information est cruciale car elle nous permet de comprendre immédiatement les limitations, le potentiel et les éventuels problèmes critiques du système utilisé.
Si le client nous indique que son site est hébergé sur un serveur mutualisé , ce seul fait est révélateur : partage intensif des ressources, risques de survente, performances souvent instables et limitations opérationnelles dues à un environnement rigide, conçu pour des solutions économiques plutôt que pour la performance ou l’évolutivité. Les grands fournisseurs ont tendance à vendre ces services en mettant l’accent sur le prix et la simplicité d’utilisation, souvent au détriment de la qualité technique.
La situation est différente si le client utilise un VPS, un environnement cloud ou un serveur dédié : dans ces cas, il est essentiel d’entrer dans les détails. Nous devons savoir :
-
Nombre de cœurs de processeur réellement disponibles
-
Quantité et type de RAM installée
-
Vitesse de connexion réseau (liaison montante)
-
Type et vitesse du disque (HDD, SSD, NVMe, RAID si applicable)
-
Fournisseur d'hébergement ou d'infrastructure (par exemple, Hetzner, OVH, AWS, etc.)
Ces éléments nous permettent d' évaluer correctement les performances réelles de l'environnement actuel . Il est fréquent, par exemple, de trouver des VPS dotés de nombreux cœurs et d'une grande quantité de RAM, mais pénalisés par des E/S disque extrêmement lentes, ou, inversement, des environnements équipés de disques NVMe ultrarapides, mais de processeurs sous-dimensionnés pour une utilisation réelle, comme dans le cas d'un site e-commerce WordPress avec un grand nombre d'extensions et un trafic important.
Cette analyse initiale nous permet non seulement de mettre en évidence les éventuels goulots d'étranglement ou problèmes structurels, mais aussi de faire des choix plus judicieux lors de la conception du nouvel environnement : nous pourrions décider d'augmenter le nombre de cœurs ou de RAM, ou – si l'environnement actuel est surdimensionné par rapport à l'utilisation réelle – d'optimiser et de réduire les ressources, en réalisant des économies sans sacrifier les performances.
Dans une approche technique rigoureuse, où la mesure avant l'action est essentielle , la connaissance du matériel actuel nous permet de prendre des décisions éclairées et fiables, en construisant une nouvelle infrastructure sur des bases solides et sans conjectures inutiles.
4 - Quels sont les pics de trafic ?
Bien qu'en regardant le premier point de cette liste à travers les outils d'analyse susmentionnés, nous puissions connaître assez précisément le trafic mensuel, ce que nous ne pouvons pas connaître, ce sont les pics de trafic qu'un site peut recevoir.
Par exemple, si un journal publie la nouvelle d'un tremblement de terre, plutôt que celle d'un attentat à la bombe contre un bureau politique, combien de visiteurs peut-il faire ?
Nous avons eu le cas d'un communiqué de presse partagé sur les pages Facebook et Twitter du Premier ministre actuel, Salvini, qui a généré un nombre impressionnant de 5 millions de visites en une seule journée, dont les 2 premiers millions en seulement deux heures . Bien entendu, un tel cas peut être considéré comme exceptionnel, improbable, mais pas impossible.
Une réponse de mémoire
5 - Les utilisateurs se contentent-ils de lire ou doivent-ils/peuvent-ils se connecter ?
Cette question est particulièrement importante pour les systèmes interactifs tels que les forums, les sites de commerce électronique ou les espaces privés. S'il est vrai que les performances natives médiocres peuvent être habilement masquées par l'utilisation de caches statiques comme Varnish SuperCache ou des solutions similaires, il est tout aussi vrai qu'un utilisateur connecté ne peut pas bénéficier de cet avantage puisque le cache est évidemment contourné.
Dans ce cas, il est bon de connaître la nature de l'application et de prévoir le nombre d'utilisateurs connectés et non connectés et de mesurer la charge afin de dimensionner ultérieurement le matériel à choisir.
6 - De quel type de continuité d'activité avez-vous besoin ?
Cette question peut paraître évidente, car tout le monde répondrait sans doute 100 %. Cependant, nous savons qu'une disponibilité à 100 % implique une redondance géographique telle qu'il faut un double DNS et des instances redondantes géographiquement, par exemple sur Amazon AWS, ce qui n'est pas forcément rentable. La différence entre 99,9 % et 100 %, même si elle ne représente que 0,1 % de disponibilité au niveau de l'infrastructure matérielle et logicielle, implique des dépenses environ dix fois supérieures.
Pour être clair, dépensez-vous 300 euros par mois pour avoir 99,9% de disponibilité ? Soyez prêt à dépenser AU MOINS 3000 si vous voulez avoir 100% de disponibilité.
Est-ce que ça a du sens ? Ça dépend.
Grâce au calculateur de disponibilité, nous pouvons en effet déterminer à combien de temps de disponibilité de 99,9 % correspond un taux mensuel, ou mieux encore, à quel temps d'indisponibilité cela correspond.
Comme indiqué sur le site web, une disponibilité de 99,9 % correspond à 43 minutes d'indisponibilité par mois. Il convient de noter qu'une garantie de 99.9 % implique généralement un temps deux fois plus long pour les procédures de reprise après sinistre en cas de problème grave.
Par conséquent, imaginons que votre entreprise reste immobile pendant 2 heures deux fois par an, pour un total de 2 heures par an. Ces 4 heures d'arrêt peuvent-elles justifier une dépense hypothétique de 4 mille euros de plus par an pour atteindre un hypothétique 30%, contre une dépense de 100 euros par an pour avoir 3600% ?
Cela dépend de votre secteur d'activité et des performances de votre site, que ce soit en termes d'image ou de revenus. En réalité, les interruptions de service sont rares (quelques-unes par an) et durent entre 5 et 15 minutes. Même les solutions redondantes garantissant une disponibilité de 100 % peuvent rencontrer des problèmes logiciels susceptibles d'entraîner des dysfonctionnements. C'est ce qui est arrivé à des acteurs majeurs comme eBay, Amazon, Spotify et Netflix, dont les services ont été hors service pendant plus de 4 heures ( le rapport initial concernant la panne d'Amazon S3 est disponible ici ). On peut donc affirmer sans risque qu'une interruption de service de quelques minutes par an est normale.
Cet aspect doit donc être très bien évalué, en tenant compte en fait si vous préférez risquer d'avoir 1 heure d'arrêt mais une économie considérable sur les coûts d'infrastructure (une économie moyenne indicative de 500 % jusqu'à plus de 1000%) ou s'il est de importance vitale, atteindre 100 % et donc ne ménager aucune dépense.
Le choix dans ces cas dépend souvent d'une logique métier pas trop intelligente mais tout de même légitime surtout de la part des grands groupes d'édition et des grandes entreprises habitués à stipuler des contrats de service entre managers sans savoir le moins du monde de quoi ils parlent, exiger le meilleur du marché dans le seul but de protéger leur position de travail face à d'éventuels problèmes, en justifiant leur position comme celle de celui qui a fait le choix du marché.
7 - De quel budget disposez-vous ?
C'est peut-être la question la plus délicate à poser, et en Italie, c'est d'autant plus vrai. Parler ouvertement d'argent est souvent perçu comme de mauvais goût, presque comme un tabou culturel. Contrairement à d'autres pays où les discussions budgétaires font partie intégrante et transparente de toute négociation, dans notre contexte, cela paraît presque indiscret, voire déplacé. Pourtant, aussi provocateur ou prématuré que cela puisse paraître, c'est l'une des questions les plus importantes à se poser au début d'un projet , et non à la fin.
Connaître le budget disponible ne signifie pas chercher à « faire pression sur le client », mais permet plutôt de définir immédiatement un périmètre réaliste , évitant ainsi des propositions trop ambitieuses ou, à l'inverse, excessivement restrictives. Sans ces informations, toute discussion relative au matériel, aux logiciels, à l'architecture et aux performances risque d'être vague, théorique et souvent déconnectée de la réalité opérationnelle.
De plus, travailler à moindre coût alors que le budget permettrait une infrastructure plus performante est une erreur qui s'avère toujours payante à long terme. Il est inutile (et contre-productif) de concevoir un système sur du matériel aux limites de ses capacités si l'on dispose des moyens financiers pour opter pour des solutions plus stables, évolutives et durables. Un budget bien maîtrisé permet d' éviter les compromis inutiles , de réduire les risques de goulots d'étranglement et d'assurer une plus grande sérénité dans la gestion quotidienne du projet.
En résumé : la question budgétaire est non seulement légitime, mais essentielle. Y répondre honnêtement permet aux concepteurs d’infrastructures de bâtir un système cohérent, solide et durable , en évitant le gaspillage et les frustrations. C’est la première étape pour transformer une idée en une solution concrète et adaptée.
conclusion
En conclusion, si vous hésitez entre un hébergement et un serveur dédié, vous devriez au moins connaître les informations ci-dessus et être en mesure de répondre à ces sept questions. Si vous avez des doutes, souhaitez comprendre quelle solution correspond le mieux à vos besoins et connaître tous les avantages et inconvénients, n'hésitez pas à nous contacter.
Nous avons une expérience vraiment vaste avec de nombreuses études de cas allant de l'amateur aux portails et journaux et sites sectoriels avec plus de 50 millions de visiteurs mensuels par mois.
