Maintenance en cours
Nous améliorons votre expérience. Le site sera de retour dans quelques instants.
Nous effectuons une mise à jour. Revenez dans quelques minutes.
', 'Maintenance', array( 'response' => 503 ) ); } } add_action( 'template_redirect', 'activer_mode_maintenance' ); ``` Ce snippet fait trois choses : 1. Il vérifie si l'utilisateur courant a la capacité `manage_options` (réservée aux administrateurs). 2. Si ce n'est pas le cas, il affiche un message de maintenance avec `wp_die()`. 3. Il renvoie un code HTTP 503. Vous pouvez remplacer `manage_options` par `edit_posts` si vous voulez aussi autoriser les éditeurs et les auteurs à accéder au site. La fonction `current_user_can()` de WordPress accepte n'importe quelle capacité définie dans le système de rôles. Pour désactiver : supprimez le snippet de `functions.php` ou commentez-le. ### Via .htaccess (restriction par IP) Si vous voulez que seule votre adresse IP puisse accéder au site, la méthode `.htaccess` est radicale et efficace. Elle intervient au niveau du serveur Apache, avant même que WordPress ne se charge. Ajoutez ces lignes au début de votre fichier `.htaccess` (avant les règles WordPress) : ```apache RewriteEngine On RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.012$ RewriteCond %{REQUEST_URI} !^/maintenance\.html$ RewriteRule ^(.*)$ /maintenance.html [R=503,L] ``` Remplacez `123.456.789.012` par votre adresse IP publique (tapez "quelle est mon IP" dans Google pour la trouver). Et créez un fichier `maintenance.html` à la racine de votre site avec votre page de maintenance personnalisée. Cette méthode a l'avantage de bloquer tout le trafic avant que PHP ne s'exécute. Votre serveur consomme zéro ressource pour les visiteurs en maintenance. En revanche, elle ne fonctionne que sur les serveurs Apache. Si vous êtes sur Nginx, la configuration équivalente se fait dans le fichier de virtual host du serveur - pas dans `.htaccess`. Attention : si votre fournisseur d'accès vous attribue une IP dynamique, vous devrez mettre à jour la règle à chaque changement. Vérifiez votre IP avant de vous couper vous-même l'accès. ### Via WP-CLI (ligne de commande) Si vous avez un accès SSH à votre serveur et que WP-CLI est installé, c'est la méthode la plus rapide : ```bash # Activer le mode maintenance wp maintenance-mode activate # Vérifier le statut wp maintenance-mode status # Désactiver wp maintenance-mode deactivate ``` Trois commandes, pas de fichier à éditer, pas de FTP. WP-CLI crée et supprime le fichier `.maintenance` pour vous. C'est la méthode privilégiée dans les environnements de déploiement automatisé (CI/CD, scripts de mise à jour) parce qu'elle s'intègre dans n'importe quel pipeline. La commande `wp maintenance-mode` est disponible depuis WP-CLI 2.6.0. Si votre version est plus ancienne, mettez-la à jour avec `wp cli update`. ## Personnaliser la page de maintenance La page par défaut de WordPress - texte blanc sur fond blanc avec "Briefly unavailable for scheduled maintenance" - ne rassure personne. Vos visiteurs méritent mieux. Voici comment créer une page de maintenance qui fait le travail. ### Créer un template maintenance.php sur mesure WordPress cherche un fichier `maintenance.php` dans le dossier `/wp-content/` avant d'afficher son message par défaut. Si ce fichier existe, c'est lui qui s'affiche. Aucun plugin nécessaire. Créez le fichier `/wp-content/maintenance.php` avec ce template de base : ```php
Nous améliorons votre expérience. Le site sera de retour dans quelques instants.
Revenez dans quelques minutes.
', 'Maintenance', array( 'response' => 503 ) ); } add_action( 'template_redirect', 'activer_mode_maintenance' ); ``` Ce code exempte les admins, le back-office, l'API REST WordPress et l'API WooCommerce. Ajoutez d'autres URI selon vos besoins. ## Désactiver le mode maintenance et débloquer un site Activer le mode maintenance, c'est facile. Le désactiver aussi - en théorie. Mais il arrive que WordPress reste bloqué en maintenance après une mise à jour interrompue. Voici comment gérer les deux cas. ### Désactivation normale La méthode dépend de la façon dont vous avez activé le mode maintenance : - **Plugin (SeedProd, WP Maintenance Mode, etc.)** - Retournez dans les réglages du plugin et basculez l'interrupteur sur "Désactivé" ou "Off". Testez en navigation privée pour vérifier que la page de maintenance a disparu. - **Fichier .maintenance** - Connectez-vous via FTP (FileZilla, Cyberduck) ou votre gestionnaire de fichiers (cPanel, Plesk) et supprimez le fichier `.maintenance` à la racine de WordPress. - **Snippet functions.php** - Éditez le fichier `functions.php` de votre thème enfant et supprimez ou commentez le code du mode maintenance. - **Règles .htaccess** - Retirez les lignes RewriteCond/RewriteRule que vous aviez ajoutées et sauvegardez. - **WP-CLI** - Exécutez `wp maintenance-mode deactivate` en SSH. Dans tous les cas, videz le cache de votre site (WP Rocket, LiteSpeed Cache, Varnish, ou le cache de votre hébergeur) après désactivation. Sinon, la page de maintenance en cache peut continuer à s'afficher pour certains visiteurs pendant plusieurs minutes. ### Site bloqué en mode maintenance : diagnostic et solutions C'est un problème courant. Vous lancez une mise à jour, la connexion coupe ou le serveur timeout, et votre site reste coincé sur "Briefly unavailable for scheduled maintenance. Check back in a minute." même après 30 minutes. Voici les causes possibles et les solutions, dans l'ordre à suivre : **1. Le fichier .maintenance n'a pas été supprimé** C'est la cause dans 90 % des cas. WordPress crée ce fichier au début de chaque mise à jour et le supprime à la fin. Si la mise à jour s'interrompt (timeout PHP, erreur mémoire, coupure réseau), le fichier reste. Solution : connectez-vous via FTP ou le gestionnaire de fichiers et supprimez le fichier `.maintenance` dans le répertoire racine de WordPress (là où se trouvent `wp-config.php` et `wp-content/`). Le site revient immédiatement. **2. Un plugin provoque un conflit au redémarrage** Le fichier `.maintenance` n'existe plus, mais le site affiche toujours une erreur ? Un plugin mis à jour partiellement peut provoquer une erreur fatale au chargement. Solution : renommez le dossier `/wp-content/plugins/` en `/wp-content/plugins_disabled/` via FTP. Ça désactive tous les plugins d'un coup. Si le site revient, renommez le dossier d'origine et réactivez les plugins un par un depuis le tableau de bord pour identifier le coupable. **3. Limite de mémoire PHP dépassée** Les mises à jour consomment plus de mémoire que le fonctionnement normal. Si votre hébergeur alloue 64 Mo ou 128 Mo de mémoire PHP, une mise à jour lourde peut échouer silencieusement. Solution : ajoutez cette ligne dans `wp-config.php`, avant la ligne `/* That's all, stop editing! */` : ```php define( 'WP_MEMORY_LIMIT', '256M' ); ``` Puis relancez la mise à jour manuellement depuis **Tableau de bord → Mises à jour**. **4. Fichiers core WordPress corrompus** Si une mise à jour du core WordPress s'est interrompue, certains fichiers peuvent être incomplets ou manquants. Solution : téléchargez la dernière version de WordPress depuis wordpress.org, décompressez l'archive, et uploadez les dossiers `wp-admin/` et `wp-includes/` via FTP en écrasant les existants. Ne touchez pas à `wp-content/` (c'est là que sont vos thèmes, plugins et uploads). **5. Le cache serveur continue d'afficher la page de maintenance** Votre site fonctionne, mais certains visiteurs voient encore la page de maintenance. Le problème vient du cache - soit le cache applicatif (WP Rocket, W3 Total Cache), soit le cache serveur (Varnish, Cloudflare). Solutions : - Purgez le cache depuis le plugin de cache WordPress. - Si vous utilisez Cloudflare, allez dans **Caching → Configuration → Purge Everything**. - Pour Varnish, purgez via le panneau de votre hébergeur ou en SSH avec `varnishadm "ban req.url ~ /"`. - En dernier recours, ajoutez un paramètre URL `?nocache=1` pour vérifier que le site fonctionne bien sans cache. ### Prévenir le blocage en maintenance Quelques habitudes pour éviter de se retrouver dans cette situation : - Mettez à jour vos plugins un par un, pas tous en même temps. Si l'un d'eux pose problème, vous saurez lequel. - Augmentez le timeout PHP de votre serveur à 300 secondes minimum pour les mises à jour (paramètre `max_execution_time` dans `php.ini` ou via votre hébergeur). - Faites une sauvegarde complète (fichiers + base de données) avant chaque mise à jour majeure. UpdraftPlus, BlogVault ou les outils de sauvegarde de votre hébergeur font l'affaire. - Utilisez un environnement de staging pour tester les mises à jour avant de les appliquer en production. La plupart des hébergeurs gérés (Kinsta, WP Engine, Cloudways) proposent cette fonctionnalité. ## Mode maintenance et SEO : protéger son référencement Un mode maintenance mal configuré peut coûter des positions dans Google. Un mode maintenance bien configuré ne laisse aucune trace dans l'indexation. La différence tient à trois facteurs : le code HTTP, la durée, et la communication avec les moteurs de recherche. ### Le code HTTP 503 et son importance Le code HTTP que votre serveur renvoie pendant la maintenance détermine comment Google traite votre site : - **503 (Service Temporarily Unavailable)** - "Le site est temporairement indisponible, reviens plus tard." Google garde vos pages en index et ne modifie pas votre positionnement. C'est le code correct pour une maintenance. - **200 (OK)** - "Tout va bien, voici le contenu." Si votre page de maintenance renvoie un 200, Google peut indexer cette page à la place de votre vrai contenu. Sur un site de 500 pages, ça signifie potentiellement 500 pages remplacées par "Maintenance en cours" dans l'index. - **404 (Not Found)** - "Cette page n'existe pas." Google finira par désindexer vos pages si elles renvoient un 404 pendant trop longtemps. - **302 (Temporary Redirect)** - "Va voir ailleurs temporairement." Moins problématique qu'un 200, mais pas aussi explicite qu'un 503. Le 503 doit aussi inclure un header `Retry-After` qui indique aux crawlers quand revenir. Exemple : `Retry-After: 3600` (1 heure). Sans ce header, Googlebot peut revenir toutes les quelques minutes et accumuler des erreurs 503 dans la Search Console. Avec le header, il attend sagement. Vérifiez le code renvoyé avant de publier votre maintenance. Ouvrez votre terminal et exécutez : ```bash curl -I https://votresite.com ``` Vous devez voir `HTTP/1.1 503 Service Temporarily Unavailable` dans la réponse. Si vous voyez `200 OK`, votre configuration est incorrecte. ### Robots.txt, sitemaps et flux RSS pendant la maintenance Erreur fréquente : bloquer les robots dans `robots.txt` pendant la maintenance. Ne faites pas ça. Si vous ajoutez `Disallow: /` dans robots.txt, Google ne pourra plus crawler votre site - mais il ne saura pas non plus que vous renvoyez un 503. Résultat : il pourrait interpréter le blocage comme permanent et réduire la fréquence de crawl même après la fin de la maintenance. Laissez `robots.txt` inchangé. Le code 503 fait déjà le travail. Pour les sitemaps : gardez-les accessibles. Ils ne posent aucun problème pendant la maintenance. Quand Google visite les URL listées dans le sitemap et reçoit un 503, il comprend que c'est temporaire. En revanche, si le sitemap renvoie lui aussi un 503, Googlebot pourrait arrêter de le consulter. Les flux RSS suivent la même logique. Si votre flux RSS est inaccessible, les agrégateurs (Feedly, NewsBlur) afficheront une erreur à vos abonnés. Exemptez l'URL de votre flux dans la configuration du mode maintenance. ### Communiquer avec Google via la Search Console Si votre maintenance dure plus de quelques heures, prenez les devants : 1. Connectez-vous à Google Search Console. 2. Allez dans **Inspection d'URL** et testez votre page d'accueil. Vérifiez que le code renvoyé est bien 503. 3. Si vous constatez un pic d'erreurs 503 dans le rapport **Couverture** après la maintenance, pas de panique. C'est normal et les erreurs disparaîtront lors du prochain crawl une fois le site revenu en ligne. Google a officiellement confirmé qu'un 503 de moins de deux jours n'a aucun impact sur le positionnement. Au-delà de 48 heures en continu, le risque augmente : Googlebot pourrait considérer que le site est définitivement hors service et commencer à rétrograder les pages. Si votre maintenance dépasse cette fenêtre (migration complexe, refonte lourde), envisagez de garder au moins quelques pages clés accessibles en lecture seule, ou de mettre en place un environnement de staging public temporaire. ### Purger le cache et prévenir les conflits Les plugins de cache sont la source numéro un de problèmes SEO liés au mode maintenance. Voici le scénario type : 1. Vous activez le mode maintenance. Votre page de maintenance s'affiche correctement. 2. WP Rocket (ou LiteSpeed Cache, W3 Total Cache) met en cache la page de maintenance avec un code 200 (parce que le cache intercepte la requête avant le plugin de maintenance). 3. Vous désactivez le mode maintenance. Votre site est revenu. 4. Mais le cache continue de servir l'ancienne page de maintenance aux visiteurs - et à Googlebot. Pour éviter ça : - **Purgez le cache avant d'activer** le mode maintenance (pour vider les pages en cache). - **Purgez le cache après l'avoir désactivé** (pour supprimer la page de maintenance du cache). - Si vous utilisez la méthode `.htaccess` ou un `maintenance.php` personnalisé, le cache applicatif n'intervient pas (la redirection se fait au niveau serveur). C'est un avantage de ces méthodes sur les plugins. - Si vous avez un CDN (Cloudflare, Fastly, KeyCDN), purgez aussi le cache du CDN. Sinon, le CDN continuera de servir la version en cache, que ce soit la page de maintenance ou l'ancienne version du site. Un test simple après la fin de la maintenance : vérifiez votre site depuis un navigateur que vous n'avez jamais utilisé (ou en navigation privée, depuis un réseau différent - le Wi-Fi de votre téléphone par exemple). Si la page de maintenance s'affiche encore, c'est un problème de cache. ## Cas avancés Les guides classiques couvrent le mode maintenance pour un blog ou un site vitrine. Mais si vous gérez une boutique WooCommerce, un réseau Multisite ou un déploiement automatisé, la logique change. ### Mode maintenance sur WooCommerce Mettre une boutique en ligne en maintenance n'est pas anodin. Contrairement à un blog où le pire scénario est un visiteur qui ne peut pas lire un article, une boutique WooCommerce peut perdre de l'argent chaque minute. Avant d'activer le mode maintenance sur un site WooCommerce, pensez à ces points : - **Commandes en cours de traitement** - Vérifiez qu'aucun paiement n'est en attente de confirmation. Les passerelles comme Stripe et PayPal envoient des webhooks de confirmation (IPN pour PayPal, webhooks pour Stripe). Si votre site est en maintenance et que ces endpoints sont bloqués, la commande peut rester en statut "En attente" indéfiniment. Exemptez les URL `/wc-api/` et `/?wc-api=` dans votre configuration. - **Emails transactionnels** - WooCommerce envoie des emails de confirmation de commande, d'expédition, etc. Si le mode maintenance bloque le cron WordPress (`wp-cron.php`), ces emails ne partiront pas. Exemptez `wp-cron.php` ou utilisez un vrai cron serveur à la place du cron WordPress. - **Stocks et disponibilité** - Si vous modifiez les prix ou les stocks pendant la maintenance, assurez-vous que les paniers en cours sont vidés à la réactivation. Sinon, un client pourrait finaliser une commande avec un ancien prix. L'approche la plus sûre pour WooCommerce : créez une page de maintenance qui n'affecte que le frontend, tout en gardant le back-office, les webhooks et le cron actifs. Le snippet suivant exempte les endpoints critiques : ```php function maintenance_woocommerce() { if ( current_user_can( 'manage_options' ) ) return; if ( defined( 'DOING_CRON' ) && DOING_CRON ) return; $uri = $_SERVER['REQUEST_URI']; $exempted = [ '/wp-admin', '/wp-login', '/wp-json', '/wc-api', 'wp-cron.php' ]; foreach ( $exempted as $path ) { if ( strpos( $uri, $path ) !== false ) return; } wp_die( 'Nous mettons à jour notre boutique. Les commandes existantes sont traitées normalement.
', 'Maintenance', array( 'response' => 503 ) ); } add_action( 'template_redirect', 'maintenance_woocommerce' ); ``` ### WordPress Multisite Sur un réseau Multisite, le mode maintenance peut s'appliquer à deux niveaux : un seul site du réseau, ou l'ensemble du réseau. **Maintenance d'un seul site** - Les méthodes classiques fonctionnent (plugin, functions.php, .maintenance). Le fichier `.maintenance` doit être placé à la racine de l'installation WordPress principale, pas dans le répertoire du sous-site. Le mode maintenance s'appliquera alors à tout le réseau, ce qui n'est probablement pas ce que vous voulez. Pour cibler un seul site, la méthode functions.php avec vérification du `blog_id` est plus adaptée : ```php function maintenance_site_specifique() { if ( get_current_blog_id() !== 3 ) return; // ID du site à maintenir if ( current_user_can( 'manage_options' ) ) return; wp_die( 'Ce site est en maintenance.', 'Maintenance', array( 'response' => 503 ) ); } add_action( 'template_redirect', 'maintenance_site_specifique' ); ``` Ce code doit être placé dans un mu-plugin (`/wp-content/mu-plugins/maintenance.php`) pour s'exécuter sur tout le réseau et filtrer par `blog_id`. **Maintenance du réseau entier** - Le fichier `.maintenance` à la racine affecte tous les sites. WP-CLI propose aussi `wp maintenance-mode activate --url=site.com` pour cibler un site spécifique dans un réseau. ### Automatiser avec des cron jobs Si vous effectuez régulièrement de la maintenance planifiée (chaque nuit, chaque semaine), l'automatisation évite d'oublier de désactiver le mode maintenance à 3 h du matin. Un cron serveur (pas le cron WordPress, qui dépend des visites) peut activer et désactiver le mode maintenance à des horaires précis : ```bash # Activer à 2h00 du matin 0 2 * * * /usr/local/bin/wp maintenance-mode activate --path=/var/www/html # Désactiver à 4h00 du matin 0 4 * * * /usr/local/bin/wp maintenance-mode deactivate --path=/var/www/html ``` Si WP-CLI n'est pas disponible, vous pouvez créer et supprimer le fichier `.maintenance` directement : ```bash # Activer 0 2 * * * echo ' /var/www/html/.maintenance # Désactiver 0 4 * * * rm -f /var/www/html/.maintenance ``` Ajoutez une notification (email, Slack) à la fin du cron pour confirmer que la maintenance s'est bien terminée. Un simple `curl -s -o /dev/null -w "%{http_code}" https://votresite.com` après la désactivation vous donne le code HTTP renvoyé. Si c'est 200, tout va bien. Si c'est encore 503, il y a un problème. ### Surveillance avec UptimeRobot ou Pingdom Le mode maintenance rend votre site volontairement indisponible. Votre outil de monitoring va donc vous alerter - sauf si vous le préparez. **Avant la maintenance :** - Mettez en pause le moniteur dans UptimeRobot, Pingdom, Better Uptime ou l'outil que vous utilisez. Ça évite de déclencher des alertes inutiles et de fausser vos statistiques de disponibilité. - Si votre outil le permet, planifiez une "maintenance window" (UptimeRobot Pro et Pingdom proposent cette fonctionnalité). Le moniteur continue de vérifier, mais les alertes sont supprimées pendant la fenêtre définie. **Après la maintenance :** - Réactivez le moniteur. - Vérifiez que le premier check post-maintenance renvoie un code 200. - Contrôlez le temps de réponse : si votre site met 8 secondes à répondre juste après la maintenance (parce que le cache se reconstruit), c'est normal. Si c'est encore le cas une heure après, il y a un problème. Ces outils ne sont pas un luxe. Un fichier `.maintenance` oublié peut rester en place pendant des jours si personne ne visite le site pour s'en apercevoir. Un moniteur vous envoie une alerte dans les 5 minutes. ## FAQ ### Mon site WordPress est bloqué en mode maintenance, que faire ? Connectez-vous à votre serveur via **FTP** ou le **gestionnaire de fichiers** de votre hébergeur. Supprimez le fichier **`.maintenance`** qui se trouve à la **racine de WordPress** (au même niveau que `wp-config.php`). Dans 90 % des cas, le site revient immédiatement. Si le problème persiste, renommez le dossier `plugins/` en `plugins_disabled/` pour **désactiver tous les plugins**, puis réactivez-les un par un pour identifier le conflit. ### Le mode maintenance affecte-t-il le référencement SEO ? **Non**, à condition de renvoyer un **code HTTP 503** (pas un 200 ni un 404) et de ne pas dépasser **48 heures** de maintenance continue. Google conserve vos pages dans son index et ne modifie pas votre positionnement pendant un 503 temporaire. Au-delà de deux jours, le risque de rétrogradation augmente. Ajoutez aussi un header **`Retry-After`** pour indiquer aux crawlers quand revenir. ### Peut-on personnaliser la page de maintenance sans plugin ? **Oui.** Créez un fichier **`maintenance.php`** dans le dossier **`/wp-content/`** de votre installation WordPress. WordPress charge automatiquement ce fichier à la place du message par défaut quand le mode maintenance est actif. Vous avez le **contrôle total** sur le HTML, le CSS et les headers HTTP. Un template fonctionnel avec les bonnes pratiques est fourni plus haut dans ce guide. ### Quelle est la différence entre le mode maintenance et une page "coming soon" ? Le **mode maintenance** renvoie un **code HTTP 503** et sert à des interventions techniques de courte durée. Une **page "coming soon"** renvoie un **code 200** et sert à préparer un lancement sur plusieurs jours ou semaines. La distinction est importante pour le SEO : un 503 dit à Google de **garder vos pages en index**, tandis qu'un 200 sur une page "coming soon" peut **remplacer votre contenu** dans l'index si elle reste trop longtemps. ### Comment autoriser certains utilisateurs à accéder au site pendant la maintenance ? Si vous utilisez un plugin comme **SeedProd**, configurez les **rôles autorisés** dans les réglages (administrateurs, éditeurs, etc.). En méthode manuelle, utilisez **`current_user_can()`** dans votre snippet functions.php. Par exemple, `current_user_can('edit_posts')` autorise les éditeurs et les administrateurs, tandis que `current_user_can('manage_options')` n'autorise que les administrateurs. ### Combien de temps peut-on laisser un site en mode maintenance ? Il n'y a pas de limite technique, mais Google recommande de ne pas dépasser **48 heures** en continu avec un code 503. Au-delà, Googlebot peut commencer à considérer le site comme **définitivement hors service**. Pour une maintenance longue (migration, refonte), gardez au minimum vos pages les plus importantes accessibles ou mettez en place un **environnement de staging** temporaire. ### Le mode maintenance bloque-t-il les commandes WooCommerce en cours ? **Non**, si votre configuration est correcte. Les commandes déjà passées continuent d'être traitées en base de données. En revanche, les **webhooks de paiement** (Stripe, PayPal) doivent rester accessibles pour que les confirmations arrivent. Exemptez les URL **`/wc-api/`** et **`wp-cron.php`** de votre mode maintenance pour éviter de bloquer les transactions. ## Pour aller plus loin Le mode maintenance n'est qu'un maillon d'une stratégie de maintenance WordPress plus large. Si vous travaillez régulièrement sur votre site, ces ressources complémentaires vous seront utiles : - Notre [guide complet de maintenance WordPress](/blog/wordpress/guide-maintenance) couvre l'ensemble des opérations récurrentes, de la sauvegarde à l'optimisation de la base de données. - La [checklist de maintenance mensuelle](/blog/wordpress/checklist-maintenance-wordpress-mensuelle) vous donne une liste d'actions à effectuer chaque mois pour garder votre site performant et sécurisé. - Pour les [mises à jour WordPress](/blog/wordpress/mise-a-jour-wordpress-guide), on a détaillé la procédure complète (core, thèmes, plugins) avec les précautions à prendre. - Si vous cherchez à créer une [page de maintenance personnalisée](/blog/wordpress/page-maintenance-guide) plus avancée, notre guide dédié va plus loin dans le design et l'UX. - Et si malgré tout vous rencontrez un [bug ou une erreur](/blog/wordpress/bugs-solutions) après la maintenance, on a compilé les solutions aux problèmes les plus fréquents, y compris l'[écran blanc](/blog/wordpress/page-blanche-solutions) et les [erreurs 500](/blog/wordpress/erreur-500-solutions). Si la maintenance technique n'est pas votre tasse de thé, notre [service de maintenance WordPress](/services/wordpress/maintenance) s'en charge pour vous. Et pour toute question, [contactez-nous](/contact).