SLA WordPress : vos engagements de service
La plupart des freelances WordPress et agences web parlent de « maintenance » sans jamais préciser leurs engagements concrets.
Or, un SLA (Service Level Agreement) Voir notre définition , ou accord de niveau de service, est la clé pour établir une relation de confiance durable : il définit noir sur blanc vos obligations, délais, et garanties de performance.
Dans cet article, découvrez ce qu’est un SLA, pourquoi il est indispensable pour vos offres WordPress / SEO, et un modèle prêt à l’emploi à intégrer dans vos contrats.
Qu’est-ce qu’un SLA (Service Level Agreement) ?
Un SLA est un document contractuel qui fixe les niveaux de service garantis entre un prestataire et son client.
Il ne s’agit pas d’une simple “promesse commerciale”, mais d’un engagement mesurable : temps de réponse, disponibilité, sécurité, performance, etc.
Objectifs d’un SLA :
- Définir les attentes de chaque partie
- Éviter les malentendus et litiges
- Donner de la valeur au service de maintenance
- Prouver votre sérieux et professionnalisme
Pourquoi intégrer un SLA en SEO UX WordPress
Pour un site WordPress, un SLA couvre trois piliers essentiels :
- Fiabilité technique (sécurité, mises à jour, uptime)
- Performance SEO / UX (vitesse, disponibilité mobile, suivi PageSpeed)
- Support & communication (délai de réponse, transparence, reporting)
Le SLA devient alors un outil de réassurance commerciale, idéal dans vos devis ou pages « maintenance WordPress / SEO ».
Exemple de tableau SLA prêt à l’emploi
Prestataire : [Votre nom / entreprise]
Client : [Nom du client]
Période d’application : [Date de début – Date de fin ou « renouvelable mensuellement »]
| Catégorie | Indicateur (KPI) | Niveau de garantie | Modes de mesure | Action du prestataire |
|---|---|---|---|---|
| Disponibilité | Temps de disponibilité du site | ≥ 99,5 % par mois | Outil de monitoring (ex. : UptimeRobot, Pingdom) | Crédit de 10 % du montant mensuel par tranche de 0,5 % manquante |
| Réactivité – Support | Délai de réponse aux tickets | – Niveau 1 (info) : ≤ 24 h – Niveau 2 (bug) : ≤ 8 h – Niveau 3 (panne) : ≤ 2 h | Ticketing via [outil : email, Trello, etc.] | Relance automatique + escalade au-delà du délai |
| Maintenance | Mises à jour de sécurité | Appliquées dans les 48 h suivant publication | Journal de maintenance mensuel | Notification immédiate + correction sous 24 h supplémentaires |
| Sauvegardes | Fréquence & restauration | – Sauvegarde quotidienne – Test de restauration mensuel | Logs WP Vivid / UpdraftPlus + rapport mensuel | Restauration immédiate en cas de perte + compensation si échec |
| SEO & Performance | Score PageSpeed (Google) Absence d’erreurs 4xx/5xx | ≥ 90 (mobile) / ≥ 95 (desktop) après optimisation 0 erreur critique détectée | Rapport mensuel via PageSpeed Insights + Screaming Frog / Matomo | Optimisation corrective incluse sans coût supplémentaire |
| UX & Accessibilité | Temps de chargement & conformité | ≤ 2,5 s sur mobile Conformité RGAA partielle niveau A | Audit trimestriel (Lighthouse / Wave) | Rapport d’amélioration UX + correctifs mineurs inclus |
| Reporting Client | Suivi & transparence | Rapport mensuel ou trimestriel selon pack | Tableaux de bord Analytics, Tag Manager, Matomo | Envoi automatisé + synthèse actionnable |
| Support | Heures d’ouverture | Lundi au vendredi, 9h–18h (hors jours fériés) | Horodatage des échanges | Réponse différée au prochain jour ouvré |
Notes
- Les jours fériés légaux ne sont pas comptabilisés dans les délais de réponse.
- Les données de monitoring sont accessibles au client sur demande mensuelle.
- Ce SLA s’applique uniquement aux prestations couvertes par le contrat (ex. : maintenance active, pas création ponctuelle).
Comment prioriser et combiner et classifier les demandes ?
Toutes les demandes clients n’ont pas la même urgence ni le même impact sur la performance d’un site.
Pour garantir une gestion fluide et équitable, Citywizz applique une double logique de priorisation :
- une classification technique (Niveau 1, 2, 3) pour mesurer la criticité d’un incident,
- et une hiérarchisation fonctionnelle inspirée de la méthode MoSCoW (Must / Should / Could / Won’t) pour organiser les évolutions et optimisations.
Cette approche combinée permet de traiter rapidement ce qui bloque tout en planifiant intelligemment ce qui fait progresser le site sur le long terme.
Méthode compréhensible pour le client (Niveaux d’incidents critique / majeur / mineur)
| Niveau | Objectif | Exemple typique |
|---|---|---|
| N1 – Critique | Restaurer le service | Site down, faille de sécurité |
| N2 – Majeur | Corriger un dysfonctionnement majeur | Erreur 500, lenteurs, bug de plugin |
| N3 – Mineur | Améliorer ou optimiser | Ajustement CSS, performance secondaire |
Avantage : très compréhensible pour le client.
Limite : ne gère pas la priorité métier ou l’importance fonctionnelle d’une demande non urgente.
Niveau 1 – Critique
Type d’incident : Blocage total ou risque majeur
Exemples concrets :
- Le site est inaccessible (erreur 500, 503, DNS, base de données).
- Le site est piraté (injection de code, redirections, spam, malware).
- Le certificat SSL est expiré, empêchant l’accès sécurisé.
- Une mise à jour a corrompu la base ou fait planter le site.
- Le formulaire de paiement ou de réservation ne fonctionne plus.
Délai : - Temps de réponse : ≤ 3 h
- Intervention : immédiate (astreinte 24/7 possible)
Délais contractuels :
- Prise en compte : sous 3 heures ouvrées maximum
- Planification / début d’intervention : immédiat (dans la même demi-journée)
Niveau 2 – Majeur
Type d’incident : Dysfonctionnement important sans blocage total
Exemples concrets :
- Lenteurs importantes (chargement > 5 s sur mobile).
- Erreur d’affichage sur la page d’accueil ou une page stratégique.
- Plugin essentiel défaillant (cache, SEO, formulaire).
- Problème d’indexation SEO ou balise canonique incorrecte.
- Formulaire de contact inactif alors que le site reste accessible.
Délai : - Temps de réponse : ≤ 6 h ouvrées
- Intervention : ≤ 1 jour ouvré
Délais contractuels :
- Prise en compte : sous 6 heures ouvrées maximum (dans la journée)
- Mise au planning : sous 1 jour ouvré maximum
Niveau 3 – Mineur
Type d’incident : Bug léger, optimisation ou demande non urgente
Exemples concrets :
- Correction de style (typo, couleurs, marges).
- Lien brisé sur une page secondaire.
- Ajout ou mise à jour de contenu (texte, image, alt).
- Optimisation SEO mineure (meta, redirections, maillage interne).
- Test d’accessibilité ou mini-correctif UX.
Délai : - Temps de réponse : ≤ 12 h ouvrées
- Intervention : ≤ 72 h ouvrées
- Prise en compte : sous 12 heures ouvrées maximum (dans la journée du lendemain)
- Mise au planning : en moyenne sous 5 à 7 jours ouvrés
Méthode MoSCoW (Must / Should / Could / Won’t)
L’objectif de cette méthode est de hiérarchiser les besoins ou demandes évolutives (fonctionnalités, SEO, UX, design…).
Elle est idéale pour les phases d’évolution d’un site ou d’un projet web continu.
| Priorité | Définition | Exemple |
|---|---|---|
| Must have | Obligatoire, bloquant si absent | Sauvegarde, uptime, sécurité |
| Should have | Important, améliore la performance | Suivi SEO mensuel, optimisation Core Web Vitals |
| Could have | Optionnel, amélioration UX | Ajout d’un module ou micro-interaction |
| Won’t have (for now) | Hors périmètre ou reporté | Nouvelle section, redesign complet |
Avantage : utile pour cadrer les évolutions fonctionnelles / SEO.
Limite : pas conçu pour la gestion d’incidents techniques en temps réel.
Combinaison pour articuler le SLA
Étape 1 – Classification technique (N1, N2, N3)
Pour gérer les urgences et la réactivité.
Étape 2 – Priorisation MoSCoW
Pour planifier les demandes d’amélioration, UX, SEO, refonte partielle.
Étape 1 – Classification technique (N1, N2, N3)
| Type | Exemple | Priorité | Délai cible |
|---|---|---|---|
| Incident critique (N1) | Site inaccessible | Must have | Intervention immédiate |
| Dysfonctionnement majeur (N2) | Lenteur du serveur | Should have | < 3h ouvrées |
| Optimisation UX | Réduction CLS mobile | Could have | Sous 7 jours |
| Nouvelle fonctionnalité | Création d’un espace client | Won’t have (for now) | Planifiée trimestre suivant |
Étape 2 – Priorisation MoSCoW
Pour planifier les demandes d’amélioration, UX, SEO, refonte partielle.
| Méthode | Usage idéal | Domaine |
|---|---|---|
| Niveaux d’incident (1–3) | Réactivité & SLA | Maintenance / support |
| MoSCoW | Arbitrage des évolutions | SEO, UX, refonte, roadmap |
| Les deux combinés | Gestion complète (opération + stratégique) | Citywizz : maintenance + pilotage web |
Les avantages d’un SLA pour le freelance et le client
Pour le client : transparence, sécurité, réactivité mesurée.
Pour le freelance :
- Moins de discussions “hors contrat”
- Moins de stress et d’urgences imprévues
- Une image d’expert structuré
Mettre en place un SLA, c’est passer du statut de simple technicien WordPress à celui de partenaire de confiance.
C’est aussi une excellente arme marketing : un SLA bien présenté prouve votre rigueur, valorise vos tarifs et fidélise vos clients.
