Table des matières de l'article :
L'une des questions les plus absurdes que l'on a l'habitude de lire sur le net est : "Est-ce que quelqu'un me recommande un hébergement WordPress performant et pas cher ?", suite au festival des réponses des sociétés d'accueil, chacune élevée au gré d'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.
Alors voici ce qu'est un bon hébergement un bon ingénieur système devrait demander avant de référer un client ou un prospect à une solution d'hébergement, qu'il s'agisse d'un un hébergement mutualisé, un VPS, un Cloud ou 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.
Grâce à des outils en ligne tels que SimiliarWeb, Weppalizer et BuildWith en fait, nous pouvons connaître en quelques secondes le nombre de visites mensuelles qu'il effectue et les technologies côté serveur qui actuellement, ainsi que via SEOZoom comprendre la tendance à la croissance ou à la baisse et donc peser le choix non seulement dans le présent immédiat, mais également dans un avenir 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 signifie clarifier laarchitecture matérielle qui héberge actuellement le site Web ou l'infrastructure WebIl s’agit d’informations cruciales car elles nous permettent de comprendre immédiatement les limites, le potentiel et les problèmes critiques potentiels du système utilisé.
Si le client nous répond que le site est hébergé sur un hébergement partagé (hébergement mutualisé)Ces données à elles seules dressent un tableau assez clair : partage intensif des ressources, risques de survente, performances souvent instables et limitations opérationnelles dictées par un environnement rigide conçu pour des scénarios à faible coût 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é, mais souvent au détriment de la qualité technique réelle.
La situation est différente si le client utilise un VPS, environnement Cloud ou serveur dédiéDans ces cas-là, il est essentiel d'entrer dans les détails. Il faut 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 de évaluer correctement les performances réelles de l'environnement actuelPar exemple, il est courant de trouver des VPS avec de nombreux cœurs et beaucoup de RAM, mais pénalisés par des E/S disque extrêmement lentes, ou, à l'inverse, des environnements avec des disques NVMe ultra-rapides, mais des CPU sous-alimentés pour une utilisation réelle, comme dans le cas d'un site eCommerce WordPress avec un grand nombre de plugins et de trafic.
Cette analyse initiale nous permet non seulement de mettre en évidence d’éventuels goulots d’étranglement ou problèmes structurels, mais également de faites des choix plus intelligents lors de la conception de votre 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, obtenant ainsi des économies économiques sans sacrifier les performances.
Dans une approche technique rigoureuse, où Mesurer avant d'agir est essentielConnaître votre 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 ?
On a eu le cas d'un article de presse partagé sur le mur Facebook et Twitter de l'actuel Premier ministre Salvini, qui a conduit le site en question à bien marquer 5 millions de visites en une seule journée, dont les deux premiers millions en deux heures. Évidemment, un tel cas peut être considéré comme un cas exceptionnel, peu probable 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 d'une importance vitale surtout lorsqu'il s'agit de systèmes interactifs tels que les forums, le commerce électronique ou les zones restreintes. S'il est vrai que de pitoyables performances natives peuvent être habilement masquées par l'utilisation de caches statiques tels que Vernis SuperCache ou des solutions similaires, il est également vrai qu'un utilisateur connecté en tant que tel ne peut pas bénéficier de cet avantage car le cache est contourné pour des raisons évidentes.
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 sembler évidente puisque tout le monde répondrait à 100% bien sûr, mais en fait nous savons qu'un vrai 100% signifie en fait avoir une telle redondance géographique qui nécessite un double DNS, une double instance géographiquement redondante peut-être sur Amazon AWS qui n'est pas vraiment bon marché. La différence entre 99,9 % et 100 % alors qu'elle n'est que de 0,1 % en termes de disponibilité de l'infrastructure matérielle et logicielle signifie dépenser environ 10 fois plus.
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.
Avec l'aide de Calculateur de disponibilité en fait, nous pouvons déterminer combien de temps de disponibilité de 99,9% est mensuel, ou mieux encore un combien est le temps d'arrêt.
Comme on peut le voir sur le site, 99,9% correspond à 43 minutes d'indisponibilité mensuelle. Il faut dire que généralement avec une garantie de 99.9%, le double du temps des procédures de reprise après sinistre est toujours calculé en cas de problème.
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 l'activité que vous faites et de ce que rapporte votre site, soit en termes d'image, soit en termes de revenus ou de revenus. La réalité est également assez différente, dans le sens où les pannes sont encore rares (un couple par an) durant entre 5 à 15 minutes et en fait même dans les solutions redondantes avec 100% de disponibilité elles peuvent avoir des problèmes de nature logicielle qui conduisent toujours à problèmes. C'est également arrivé à de grands acteurs tels que Ebay, Amazon, Spotify, Netflix qui sont restés inactifs pendant plus de 4 heures. ( Le rapport d'échec original d'Amazon S3 ici ) et il est donc incontesté de dire qu'une baisse de quelques minutes par an peut être là.
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 elle l'est encore plus en Italie. 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 semble presque intrusif et insensible. Et pourtant, aussi provocateur ou prématuré que cela puisse paraître, c'est… l'une des questions les plus importantes à poser au début d'un projet, et pas à la fin.
Connaître le budget disponible ne signifie pas vouloir « presser » le client, mais au contraire cela permet de définir un périmètre réaliste dès le départ, en évitant les propositions trop ambitieuses ou, au contraire, excessivement restrictives. Sans ces informations, toute discussion sur le matériel, les logiciels, l'architecture et les performances risque d'être vague, théorique et souvent déconnectée de la réalité opérationnelle.
En outre, travailler « à moindre coût » alors que le budget permettrait une infrastructure plus performante C'est une erreur qui finit toujours par payer. Il est inutile (et contreproductif) de concevoir sur du matériel aux limites de ses capacités si l'on dispose des moyens financiers nécessaires pour opter pour des solutions plus stables, évolutives et durables. Un budget équilibré permet de mettre de côté les compromis inutiles, réduire les risques de goulots d’étranglement et assurer une plus grande tranquillité d’esprit dans la gestion quotidienne du projet.
En bref : la question budgétaire est non seulement légitime, mais fondamentale. Y répondre honnêtement permet à ceux qui conçoivent les infrastructures de construire quelque chose de cohérent, solide et durable, évitant ainsi le gaspillage et la frustration. C'est la première étape pour transformer une idée en une solution concrète et dimensionnée.
conclusion
En conclusion, nous pouvons dire que si vous ne savez pas comment choisir un hébergement ou comment choisir un serveur dédié vous devez au moins connaître ces données ci-dessus et être en mesure de répondre à ces sept questions. Si vous avez des doutes, vous souhaitez essayer de comprendre quelle est la solution la plus adaptée à 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.