Le jour où il s’arrête, vous ne facturez plus

Ce n’est pas un site, et ça ne s’exploite pas pareil

Un site vitrine indisponible une heure fait mauvais effet. Un ERP indisponible une heure arrête les devis, les bons de livraison et les factures — et il l’arrête pendant les heures ouvrées, précisément quand tout le monde s’en sert.

Trois différences en découlent. La charge est interne et concentrée : peu de visiteurs, mais des écrans lourds sollicités en continu de 9 h à 18 h. Les données sont celles de l’entreprise, pas du contenu public. Et la disponibilité se mesure sur les heures de travail, pas sur un total mensuel qui noie une panne d’un après-midi.

La plateforme, et ce qu’elle accueille

Nos serveurs mutualisés hébergent déjà ce type d’applications : les CRM comme Dolibarr ou SugarCRM, les ERP, et tout développement sur mesure — Symfony, Zend, Django. Toutes les versions de PHP sous Linux y sont disponibles, de PHP 4 à PHP 8, avec MariaDB ou PostgreSQL.

C’est un point qui compte pour un logiciel de gestion, dont la version supportée n’est pas toujours la plus récente : une installation ancienne peut être reprise telle quelle, puis mise à niveau ensuite, plutôt que d’imposer une migration en préalable à l’hébergement.

Le certificat SSL Let’s Encrypt est inclus et automatique, et l’administration se fait par Plesk ou cPanel selon la plateforme. Dolibarr ayant besoin de PHP et d’une base de données, la première formule qui convient est celle à 96 € HT par an — celle d’entrée de gamme, à 72 €, ne sert que des fichiers. Une installation utilisée par toute une équipe demande davantage, et parfois une machine à elle.

Restreindre l’accès, parce que c’est un outil interne

C’est la mesure la plus efficace, et la plus souvent négligée. Un ERP est utilisé par vos salariés, pas par le public : rien n’oblige sa page de connexion à être joignable depuis n’importe quel réseau du monde.

Nous restreignons donc l’accès — filtrage par adresse, accès distant pour ceux qui en ont besoin, second facteur d’authentification. S’y ajoute ce que la plateforme applique déjà : sondes d’intrusion, pare-feu matériels et applicatifs, dont les règles sont mises à jour très régulièrement. Une faille publiée est corrigée au niveau du pare-feu en attendant que la mise à jour de l’application soit appliquée — ce qui laisse le temps de la préparer au lieu de la subir.

La sauvegarde, et le fait de l’avoir restaurée

Sauvegarde quotidienne, conservée 30 jours, répliquée hors du serveur qu’elle protège. Sur un ERP, elle couvre deux risques bien distincts : l’incident technique, et la fausse manœuvre — un import qui écrase un fichier client, une suppression en masse faite de bonne foi. Le second est de loin le plus fréquent.

Une sauvegarde qui n’a jamais été restaurée n’est qu’une intention. Nous vérifions qu’elle se restaure, et nous savons en combien de temps — c’est cette durée-là qui vous intéresse le jour où vous en avez besoin, pas la fréquence de la copie.

Quand le mutualisé ne suffit plus

Il suffit longtemps, et plus souvent qu’on ne le croit. Trois signaux indiquent qu’il faut passer à une machine dédiée : des traitements lourds qui tournent longtemps — inventaires, éditions de masse, exports comptables ; un besoin de configuration que la plateforme partagée ne permet pas ; ou des échanges permanents avec d’autres logiciels.

Dans ce cas, un serveur privé infogéré prend le relais, avec la même exploitation : mises à jour du système, supervision, sauvegarde, astreinte. Vous ne changez pas d’interlocuteur, et vous ne devenez pas administrateur système.