Hébergement géré et maintenance de sites web

Une décision d’hébergement devrait partir de ce qui est hébergé : quel trafic, quelles données, quelles intégrations, quelle indisponibilité l’entreprise peut vraiment absorber, et quel budget. Un site vitrine de cinq pages et une application utilisée toute la journée par vos équipes n’ont pas besoin de la même architecture, et prétendre le contraire, c’est ainsi qu’une PME finit par payer un cluster Kubernetes pour servir un formulaire de contact.

Nous choisissons donc la plateforme la plus simple qui réponde aux besoins réels, et n’ajoutons des services que là où l’un d’eux supprime un risque précis. Quand les données doivent rester en Europe, cela réduit la liste, et nous le disons dès le départ plutôt qu’après la migration. Quand plusieurs environnements sont nécessaires, la production est tenue à l’écart de l’endroit où l’on essaie des choses.

Le nom de domaine et les comptes principaux sont enregistrés à votre nom partout où le fournisseur le permet. Ce seul détail fait la différence entre changer de prestataire et négocier avec lui.

Un déploiement qui dépend de quelqu’un qui se souvient du bon ordre est un déploiement qui finira mal un vendredi. Le code et la configuration passent chaque fois par le même processus défini, les secrets vivent en dehors du dépôt, et les différences entre environnements sont écrites là où quelqu’un peut les trouver.

Les migrations de base de données, les changements de cache et tout ce qui laisse une trace demandent plus de soin que le code applicatif, parce que revenir en arrière sur le code ne les annule pas. Le niveau de cérémonie d’une mise en production suit ce qu’une erreur coûterait : une mise à jour de contenu peut simplement partir, tandis qu’une application dont on dépend toute la journée mérite une fenêtre, un déploiement progressif et un retour arrière répété. L’objectif : que les changements ordinaires cessent d’être des événements.

Un test de disponibilité qui interroge la page d’accueil vous dit que la page d’accueil répond. Il ne vous dit pas que le formulaire de contact échoue en silence depuis une semaine, que la tâche nocturne ne tourne plus depuis mars, qu’un certificat expire dimanche, ou que le disque sera plein jeudi. Ce qui mérite d’être surveillé dépend du système, et le déterminer fait partie du travail.

Les alertes vont à quelqu’un qui peut agir, avec assez de contexte pour distinguer un vrai incident du bruit. Cela compte plus qu’il n’y paraît : un canal saturé d’alertes que personne ne traite apprend à tout le monde à ignorer celle qui compte. Les journaux sont conservés assez longtemps pour être utiles et assez peu pour rester responsables, en laissant de côté les champs sensibles partout où c’est possible.

La plupart des sites compromis n’ont jamais été visés. Ils tournaient avec une extension dont la faille était connue et corrigée onze mois plus tôt. Les mises à jour de l’application, du runtime et de tout ce qu’il y a en dessous suivent un rythme, testées à la hauteur de leur risque. Rien n’est appliqué à l’aveugle, et rien n’attend qu’un incident tranche.

Les accès suivent la même logique. Les comptes sont limités à ce dont la personne a besoin, protégés par une authentification forte quand le fournisseur le permet, et supprimés quand quelqu’un s’en va. Certificats, en-têtes de sécurité et autres contrôles sans gloire sont simplement maintenus. Rien de tout cela n’est malin. C’est le métier.

Une sauvegarde que personne n’a restaurée est une croyance, pas un plan. Nous définissons ce qui est sauvegardé, à quelle fréquence, combien de temps les copies sont gardées et où elles vivent, y compris dans un endroit qu’une erreur sur la plateforme principale ne peut pas atteindre. Les restaurations sont ensuite testées, à un rythme proportionnel à la valeur des données.

Deux chiffres pilotent la conception, et ils méritent d’être posés à voix haute : combien de données vous pourriez vous permettre de perdre, et combien de temps vous pourriez rester à l’arrêt. La plupart des entreprises ne se sont jamais posé la question, et les réponses surprennent. Une fois qu’ils existent, ces chiffres décident de la fréquence des sauvegardes, de l’architecture et de la procédure de reprise, au lieu que chacun espère que la question ne se posera jamais.

Quand quelque chose casse, ce qui aide, c’est une personne capable de regarder l’application, le déploiement et l’infrastructure le même après-midi, plutôt qu’un client qui fait passer des messages entre un hébergeur, un développeur et une agence qui se soupçonnent mutuellement. Le premier travail est de remettre le service en route sans casse. La cause vient ensuite, avec ce qui empêche que cela se reproduise.

Vous apprenez ce qui s’est passé en langage clair, y compris quand le diagnostic prend plus de temps que la réparation. Fournisseurs, architecture, accès et procédure de reprise sont documentés, et cette documentation est à vous. Si une autre équipe reprend un jour, elle le peut : tout ce qui est spécifique à un fournisseur est nommé plutôt que découvert. L’hébergement doit être quelque chose qu’on garde parce que c’est utile, pas parce que partir est compliqué.

L’hébergement géré n’est pas un forfait de développement illimité. Garder la plateforme en bonne santé, appliquer les mises à jour, surveiller les indicateurs et intervenir quand quelque chose casse : voilà le service. Nouvelles fonctionnalités, refontes et intégrations sont du travail de projet, chiffré à part. Nous préférons tracer cette ligne clairement au départ plutôt que la voir surgir dans une discussion sur une facture.

Ce n’est pas non plus la promesse que rien ne tombera jamais. Les fournisseurs ont des pannes, les autorités de certification ont de mauvais jours, et une dépendance que vous n’avez pas choisie peut sortir une mauvaise version. Ce qui peut être promis : que quelqu’un surveille, que le chemin de reprise a été testé, et que vous l’apprendrez par nous avant de l’apprendre par un client.