Un site peut être livré un vendredi et commencer à se dégrader le lundi. Certificats, dépendances, contenus, sauvegardes, formulaires et services tiers évoluent sans attendre le prochain projet de refonte.
1. La réponse utile : héberger n’est pas exploiter
L’hébergement web fournit les ressources qui rendent le service accessible : calcul, stockage, réseau, base de données, diffusion, certificats et parfois services managés. La maintenance maintient le service dans un état acceptable : mises à jour, supervision, sauvegarde, correction, assistance, capacité, sécurité et évolution contrôlée.
Payer un serveur ne signifie donc pas que quelqu’un surveille les formulaires, restaure les données, teste les extensions, renouvelle les domaines ou répond à une vulnérabilité. Un contrat sain transforme ces verbes en responsabilités, délais, preuves et limites.
L’objectif n’est pas l’absence absolue d’incident. C’est une exploitation capable de prévenir les défaillances prévisibles, détecter rapidement les autres, restaurer le service et apprendre sans rendre chaque incident héroïque.
2. Chiffres clés : chaque promesse de disponibilité a un coût
| Chiffre | Source et périmètre | Lecture opérationnelle | Question à poser au contrat |
|---|---|---|---|
| 52,7 % | Entreprises de l’UE achetant du cloud en 2025, Eurostat. | Le cloud est largement adopté, avec une hausse de 7,4 points depuis 2023. | Quel service managé est utilisé, dans quelle région et avec quel plan de sortie ? |
| 65,5 % | Entreprises utilisatrices du cloud achetant des applications de sécurité, Eurostat. | L’hébergeur ne supprime pas le besoin de protection et de configuration. | Qui configure, surveille et recertifie les contrôles ? |
| 45,5 % | Utilisateurs du cloud y hébergeant la base de données de l’entreprise, Eurostat. | Les données critiques passent souvent dans des services managés. | Qui possède sauvegarde logique, restauration, chiffrement et export ? |
| 7,2 h/mois | Indisponibilité théorique à 99 % de disponibilité, Google SRE. | « 99 % » paraît élevé mais autorise presque une journée ouvrée d’arrêt chaque mois. | Cette cible est-elle compatible avec la perte métier maximale ? |
| 43,2 min/mois | Indisponibilité théorique à 99,9 %, Google SRE. | Un neuf supplémentaire divise le budget d’erreur par dix. | L’architecture, l’astreinte et les fournisseurs permettent-ils réellement cette cible ? |
| 4,32 min/mois | Indisponibilité théorique à 99,99 %, Google SRE. | Une promesse très élevée exige redondance, tests de bascule et opérations matures. | Le prix couvre-t-il une ingénierie autre qu’un simple SLA fournisseur ? |
| 2,6 Mo | Poids médian d’une page d’accueil mobile en 2025, HTTP Archive. | La capacité et le CDN n’effacent pas le coût CPU et réseau chez l’utilisateur. | Le contrat inclut-il une surveillance de performance terrain ? |
| 72 % | Pages d’accueil mobiles appliquant correctement la compression de texte, HTTP Archive. | Plus d’un quart échoue encore à une optimisation d’infrastructure élémentaire. | Qui contrôle cache, compression, images et règles CDN après chaque changement ? |
| 63 % | Pages d’accueil mobiles passant le test de minification JavaScript, HTTP Archive. | Le pipeline de livraison influence directement le poids et le rendu. | L’équipe maintient-elle la chaîne de build et ses dépendances ? |
| 4 groupes | Pratiques du NIST SSDF : préparer, protéger, produire, répondre. | La réponse aux vulnérabilités fait partie du cycle logiciel, au même titre que la production. | Le contrat définit-il veille, qualification, correction et communication ? |
Eurostat mesure l’achat de services, pas leur qualité. Google fournit une conversion mathématique de cibles, pas la disponibilité d’un prestataire particulier. HTTP Archive observe des millions de pages, pas votre pile. Leur utilité consiste à rendre les promesses testables.
3. Le contrat d’exploitation : douze clauses qui changent réellement le service
3.1. Périmètre des actifs
Le contrat doit inventorier domaines, DNS, certificats, hébergement, bases, stockage, CDN, CMS, dépôts, environnements, comptes, formulaires, outils d’analytics, intégrations et services tiers. Pour chacun : propriétaire légal, administrateur, facturation, région, criticité et procédure de sortie.
Les incidents les plus coûteux naissent souvent hors du serveur principal : domaine renouvelé sur une carte expirée, clé API appartenant à un ancien salarié, formulaire envoyé vers une boîte supprimée ou plugin abandonné.
Preuve : registre des actifs révisé chaque trimestre et exportable par le client.
3.2. Responsabilités partagées
Un fournisseur cloud sécurise une partie de l’infrastructure. Le client et son prestataire restent responsables de configurations, identités, application, données, contenus et usages selon le service acheté.
Écrivez un RACI sans cases « tout le monde ». Qui approuve un accès administrateur ? Qui applique un correctif critique ? Qui confirme la restauration ? Qui contacte les utilisateurs ? Une responsabilité sans nom se transforme en discussion pendant l’incident.
Preuve : matrice signée, contacts principaux et remplaçants, scénario de crise testé.
3.3. SLO, SLA et budget d’erreur
Le SLA est un engagement contractuel ; le SLO est une cible opérationnelle ; l’indicateur mesure l’expérience. Ils ne sont pas interchangeables. Un fournisseur peut respecter son SLA global tandis qu’un parcours essentiel échoue à cause d’une intégration.
Définissez la disponibilité à partir d’actions réelles : page consultable, recherche répondant, formulaire accepté, paiement autorisé. Le Google SRE Book propose le budget d’erreur — 1 moins le SLO — comme mécanisme d’arbitrage entre changement et fiabilité.
Preuve : indicateurs par parcours, fenêtres de calcul, exclusions limitées et revue du budget d’erreur.
3.4. Supervision et alertes
La supervision doit combiner disponibilité externe, métriques système, erreurs applicatives, journaux, performance terrain et tests synthétiques. Un ping réussi ne prouve pas qu’un utilisateur peut soumettre le formulaire.
Chaque alerte doit avoir un propriétaire, un seuil, une sévérité et une action. Une boîte contenant mille alertes ignorées est un décor. Supprimez ou corrigez ce qui ne déclenche aucune décision.
Preuve : tableau de bord partagé, test d’alerte, historique d’incidents et runbooks associés.
3.5. Sauvegarde et restauration
Une sauvegarde est une hypothèse jusqu’à sa restauration. Définissez RPO — quantité de données que l’on accepte de perdre — et RTO — temps cible pour restaurer le service. Adaptez fréquence, rétention, immutabilité et copies séparées à ces objectifs.
Sauvegardez aussi configurations, médias, données du CMS, secrets selon une procédure adaptée, DNS, règles CDN et documentation. Les données enfermées dans un SaaS méritent un export séparé si leur perte bloque l’activité.
Preuve : restauration périodique dans un environnement isolé, résultat chronométré et écarts corrigés.
3.6. Mises à jour et vulnérabilités
Classez les composants : système, runtime, framework, bibliothèques, plugins, thèmes, images de conteneur et services tiers. Définissez une fenêtre normale et une procédure accélérée pour une faille critique exploitée ou exposée.
Le correctif ne s’arrête pas au bouton « mettre à jour ». Il faut analyser l’exposition, tester, sauvegarder, déployer progressivement, surveiller et pouvoir revenir. Le NIST SSDF place explicitement la réponse aux vulnérabilités dans le développement sécurisé.
Preuve : inventaire des versions, scans, tickets liés, délai de remédiation et exception approuvée.
3.7. Changements et retour arrière
Tout changement significatif reçoit une description, un propriétaire, des critères, une revue, un test et une stratégie de rollback. Séparez environnements et droits. Protégez la branche de production et gardez la trace de ce qui a été publié.
Le but n’est pas une bureaucratie lourde. De petits changements, automatisés et observables réduisent la surface d’échec. Les mesures DORA suivent fréquence de déploiement, délai, échecs et temps de restauration, au lieu de valoriser le volume de tickets.
Preuve : journal de déploiement, tests automatisés, validation et exercice de retour arrière.
3.8. Performance et capacité
Fixez des budgets : poids, JavaScript, images, requêtes tierces, LCP, INP, CLS et temps de réponse backend. Mesurez au 75e percentile et segmentez mobile, appareil, pays et type de page.
La capacité inclut trafic normal, campagne, import, robot, pic saisonnier et défaillance d’un service tiers. Prévoir un mécanisme de limitation ou une file vaut souvent mieux que surdimensionner toute l’année.
Preuve : données terrain, tests de charge proportionnés, seuils d’alerte et revue avant campagne.
3.9. Sécurité, accès et secrets
Imposez MFA aux comptes sensibles, moindre privilège, comptes nominatifs, rotation et retrait rapide. Les clés ne doivent pas vivre dans le code ou un document partagé. Journalisez les actions administratives et revoyez les droits.
La sécurité du site comprend aussi WAF/CDN, en-têtes, dépendances, formulaires, API, stockage, emails et protection des comptes éditeurs. Elle n’est jamais « incluse » sans liste de contrôles.
Preuve : revue d’accès trimestrielle, registre de secrets, tests et plan de réponse.
3.10. Support et sévérité
Définissez quatre niveaux compréhensibles : service indisponible ou données en danger ; fonction critique dégradée ; anomalie contournable ; demande d’évolution. Pour chacun : canal, heures de couverture, délai de prise en charge, fréquence de communication et cible de restauration.
Ne promettez pas « réponse en une heure » si cette réponse peut être un accusé sans diagnostic. Séparez prise en compte, qualification, contournement, correction et clôture.
Preuve : tickets horodatés, respect des étapes et analyse des réouvertures.
3.11. Incidents et apprentissage
Le runbook précise commandement, diagnostic, communication, préservation des preuves, décisions et restauration. Après un incident significatif, rédigez une analyse sans blâme : chronologie, impact, détection, facteurs contributifs et actions avec propriétaires.
Une « erreur humaine » n’est pas une cause suffisante. Demandez pourquoi une action était possible, invisible ou irréversible.
Preuve : compte rendu, actions suivies jusqu’à vérification et exercice annuel.
3.12. Réversibilité et fin de service
Le client doit récupérer données, code, médias, configurations, domaines, journaux utiles et documentation dans un format exploitable. Le contrat précise délai, coût, assistance, suppression et confirmation.
Testez un export avant d’en avoir besoin. La clause de réversibilité la mieux écrite ne corrige pas un format propriétaire inutilisable ou un compte racine détenu par le prestataire.
Preuve : paquet de sortie annuel ou à chaque changement majeur, restauré sur un environnement de test.
4. Comparer quatre modèles d’hébergement
| Modèle | Contexte adapté | Ce que l’équipe possède encore | Risque à surveiller |
|---|---|---|---|
| SaaS / plateforme de site | Site marketing standard, équipe technique limitée. | Contenu, domaines, comptes, intégrations, conformité et plan de sortie. | Limites fonctionnelles, export, hausse de prix, dépendance éditeur. |
| Hébergement managé | CMS ou application classique avec besoin de support. | Code, plugins, données, validation des mises à jour, usage. | Frontière floue entre gestion serveur et maintenance applicative. |
| Cloud managé / PaaS | Application évolutive, équipe produit, automatisation. | Architecture, identités, données, coûts, observabilité et résilience. | Facturation variable, configuration complexe, verrouillage fournisseur. |
| Infrastructure gérée par l’équipe | Contraintes fortes, compétences et contrôle nécessaires. | Presque tout le cycle opérationnel. | Charge d’astreinte, patching, compétences rares et faux sentiment de maîtrise. |
Le meilleur modèle minimise le coût total du niveau de service nécessaire. Garder tous les serveurs n’est pas plus souverain si personne ne sait les restaurer ; externaliser n’est pas plus simple si les responsabilités restent opaques.
5. Cloud et restauration : anatomie d’un incident ordinaire
À 9 h 12, le support signale que certaines demandes n’arrivent plus dans le CRM. Le site répond. Le formulaire affiche une confirmation. Le monitoring d’infrastructure reste vert. Pourtant, le service métier est défaillant depuis la veille au soir.
Une supervision centrée sur le serveur passe à côté, car l’échec se produit après l’acceptation du formulaire, dans une file dont les messages sont rejetés par une API distante après l’expiration silencieuse d’un secret. Une supervision de parcours aurait compté les confirmations, les messages traités et les enregistrements effectivement créés, puis alerté sur leur divergence avant que le commercial ne découvre le problème.
L’équipe doit d’abord préserver les demandes, empêcher les doublons, renouveler le secret par le canal prévu et rejouer uniquement les événements non confirmés ; si les identifiants d’idempotence, les journaux de corrélation et la file de rétention ont été conçus ensemble, la restauration consiste en une opération contrôlée plutôt qu’en un export manuel suivi de plusieurs jours de réconciliation.
Le post-incident ne devrait donc pas conclure « le token était expiré ». Il examine pourquoi le renouvellement n’était pas possédé, pourquoi le test synthétique s’arrêtait avant le CRM, pourquoi l’alerte de rejet n’était pas routée et pourquoi aucun tableau ne rapprochait entrées du site et sorties de l’intégration.
Cette scène donne quatre exigences contractuelles supplémentaires. D’abord, surveiller les transactions de bout en bout. Ensuite, conserver suffisamment de données pour rejouer sans dupliquer. Puis, tester les secrets et certificats avant leur échéance. Enfin, mesurer la restauration depuis le point de vue métier, pas depuis le redémarrage d’un composant.
La leçon est simple. Le serveur peut aller bien. Le service, non.
Un contrat cloud mature désigne donc le propriétaire de chaque dépendance, documente le mode dégradé, protège les données en attente et précise qui autorise un rejeu lorsque l’opération risque de créer des commandes, des paiements ou des messages en double.
Le rapport mensuel doit rendre ce travail visible : objectifs de service, incidents et quasi-incidents, changements, restaurations testées, vulnérabilités ouvertes, capacité, coûts variables et décisions attendues. Une suite de voyants verts sans rapprochement avec les transactions ne constitue pas un pilotage.
Ajoutez enfin les échéances futures — domaines, certificats, licences, fins de support et contrats fournisseurs — sur un horizon de douze mois. Une maintenance sérieuse traite le calendrier comme une source de risque prévisible et mesurable.
6. Budget : calculer le coût total annuel
Utilisez cette formule :
Plateforme + trafic/stockage + licences + maintenance préventive + support incident + sécurité + sauvegardes + amélioration + gouvernance.
Les offres très basses couvrent souvent seulement plateforme et quelques mises à jour automatiques. Demandez le volume inclus, les horaires, les exceptions, la propriété des comptes, le taux hors forfait et les prestations facturées pendant un incident.
Le niveau de service déplace fortement le coût. Une astreinte 24/7, une cible 99,99 %, une restauration de quelques minutes et plusieurs régions nécessitent une organisation différente d’un site vitrine tolérant une intervention le jour ouvré suivant. Achetez la disponibilité que le métier sait valoriser.
7. Conseils Logiks : cinq tests avant de signer
- Demandez au prestataire de restaurer une sauvegarde, pas de montrer qu’elle existe.
- Faites tomber un service tiers en recette et observez le mode dégradé.
- Vérifiez qui contrôle domaine, DNS, dépôt, compte cloud et facturation.
- Sélectionnez un incident fictif et suivez la chaîne d’escalade jusqu’au décideur métier.
- Faites chiffrer la sortie complète et demandez un exemple d’export.
8. Plan de mise sous contrôle en 90 jours
8.1. Jours 1 à 30 — Inventaire et criticité
- recenser actifs, comptes, fournisseurs et propriétaires ;
- cartographier les parcours et dépendances critiques ;
- mesurer disponibilité, erreurs et performance actuelles ;
- définir RPO, RTO et heures de support ;
- corriger les accès orphelins et renouvellements à risque.
8.2. Jours 31 à 60 — Capacités d’exploitation
- installer supervision et alertes actionnables ;
- documenter sauvegarde, restauration, déploiement et incident ;
- tester correctif, rollback et export ;
- définir SLO et budget d’erreur ;
- prioriser vulnérabilités et dette de maintenance.
8.3. Jours 61 à 90 — Contrat et exercices
- aligner contrat, RACI, sévérités et indicateurs ;
- exécuter un exercice d’incident ;
- restaurer les données dans un environnement isolé ;
- partager le tableau de bord avec le propriétaire métier ;
- planifier revues mensuelles et test annuel de sortie.
9. FAQ
9.1. Quelle différence entre hébergement et maintenance ?
L’hébergement fournit l’infrastructure. Le travail de maintenance maintient application, dépendances, données, sécurité, performance et fonctionnement. Une offre peut combiner les deux, mais son périmètre doit les distinguer.
9.2. À quelle fréquence faut-il maintenir un site ?
La supervision est continue ; les revues et mises à jour suivent un rythme adapté au risque. Une vulnérabilité critique peut exiger une action immédiate, alors qu’une évolution mineure attend une fenêtre mensuelle. Évitez un calendrier unique pour tous les composants.
9.3. Un SLA de 99,9 % est-il suffisant ?
Il autorise théoriquement 43,2 minutes d’indisponibilité par mois. La réponse dépend de la période de chiffre d’affaires, des parcours touchés et du mode dégradé. Définissez le SLO à partir de l’impact métier, puis vérifiez que l’organisation peut le tenir.
9.4. Les sauvegardes de l’hébergeur suffisent-elles ?
Pas toujours. Vérifiez périmètre, fréquence, rétention, séparation, export et restauration. Une copie gérée dans le même compte peut être affectée par une erreur ou une compromission commune. Testez une restauration complète.
9.5. Que doit contenir un contrat de maintenance web ?
Actifs, responsabilités, horaires, sévérités, délais, mises à jour, sauvegardes, supervision, sécurité, changements, rapports, exclusions, tarifs, propriété et réversibilité. Les verbes doivent être associés à des preuves.
9.6. Faut-il rester chez le même prestataire que celui qui a créé le site ?
Ce peut être efficace si la documentation, les comptes et le contrat sont sains. Ce n’est pas une obligation. La capacité à transférer sans perdre domaines, données ou compréhension est justement un critère de qualité de la construction.
10. Conclusion
L’hébergement rend le service présent. La maintenance le garde digne de confiance. Entre les deux se trouve un contrat d’exploitation : actifs connus, responsabilités nommées, cibles proportionnées, restauration testée et décisions appuyées sur des mesures.
La bonne offre n’est pas celle qui promet « aucun souci ». C’est celle qui décrit ce qui sera surveillé, comment l’échec sera géré et comment le client conservera la maîtrise.
11. Sources principales
- Eurostat — 53% of EU enterprises used paid cloud services in 2025, 3 février 2026.
- Google SRE — Availability table, consulté le 13 juillet 2026.
- Google SRE — Production services best practices, consulté le 13 juillet 2026.
- HTTP Archive — Web Almanac 2025, Page Weight, publié en 2026.
- HTTP Archive — Web Almanac 2025, Performance, publié en 2026.
- NIST — Secure Software Development Framework 1.1, consulté le 13 juillet 2026.
- DORA — Software delivery performance metrics, consulté le 13 juillet 2026.
- OWASP — Top 10:2025, consulté le 13 juillet 2026.