Réponse en bref
Les correctifs sont une liste précise de changements sur un site déjà en ligne : erreurs réparées, pages plus rapides, meilleure version mobile, nouveaux blocs et intégrations. Ils se distinguent de la refonte, qui reprend tout le site, et de la maintenance, qui court de mois en mois. Décrivez chaque problème avec les étapes pour le reproduire, sauvegardez d’abord et redirigez chaque adresse modifiée.
Correctifs de site : changer ce qui fonctionne déjà
Modifier un site internet déjà en ligne, c’est toucher à un outil qui apporte des demandes : réparer un formulaire, accélérer une page lente, ajouter une rubrique au menu. Le site garde son adresse, son contenu et son historique dans les moteurs de recherche. Le risque, c’est que chaque changement tombe sur un système vivant, utilisé par des clients au même moment.
Une refonte change l’apparence et l’organisation de tout le site ; elle touche en général tous les gabarits et souvent la structure des pages. La maintenance est un accord permanent : quelqu’un surveille le site chaque mois, installe les mises à jour, garde des sauvegardes et réagit en cas de panne. Partir de zéro, c’est un nouveau site qui remplace l’ancien. Les correctifs se placent entre les deux : une liste définie de changements, faite une fois, avec un résultat vérifiable.
Une longue liste de changements peut glisser vers une refonte, et de petites demandes passées chaque mois relèvent déjà de la maintenance. Un correctif se juge à la disparition du problème précis, une refonte au fonctionnement de tout le site, et la maintenance à la rapidité de réponse.
Tâches courantes, du formulaire cassé à la vitesse et au mobile
La demande la plus fréquente est un bug : un bouton qui ne fait rien, une page qui renvoie une erreur, un prix mal affiché, un formulaire qui envoie les demandes dans le vide. Attention aux formulaires : une panne silencieuse ressemble trait pour trait à une semaine calme. Envoyer une demande de test et vérifier qu’elle arrive dans la boîte mail, le CRM ou la messagerie de l’équipe reste l’une des vérifications les moins chères et les plus utiles.
La vitesse forme le deuxième grand groupe. web.dev, le site de Google pour les développeurs, décrit trois Core Web Vitals avec un seuil pour chacun : le contenu principal doit apparaître en 2,5 secondes au plus (Largest Contentful Paint), la page doit réagir à un clic ou un appui en 200 millisecondes (Interaction to Next Paint) et la mise en page ne doit pas bouger de plus de 0,1 sur l’échelle de Cumulative Layout Shift. Il recommande de mesurer au 75e centile des chargements, séparément sur mobile et sur ordinateur. Remèdes habituels : images allégées, moins de scripts lourds, tailles fixes pour les blocs.
La version mobile est le troisième. Google Search Central indique que Google utilise la version mobile du contenu d’un site pour l’indexer et le classer, et que seul le contenu affiché sur le site mobile sert à l’indexation. Un texte masqué sur téléphone, ou un tableau qui déborde de l’écran, est donc un problème de référencement autant que d’usage. Le reste est connu : titres et descriptions, liens cassés, un nouveau bloc sur l’accueil, un paiement en ligne, un chat, un flux de produits pour une marketplace.
Rédiger une demande de correctif exploitable par un développeur
Une bonne demande répond à quatre questions. Qu’est-ce qui ne marche pas, en une phrase. Où exactement : l’adresse de la page, l’appareil, le navigateur. Comment le reproduire : les étapes depuis l’ouverture de la page jusqu’au moment de la panne. Et comment vous saurez que c’est réglé : le résultat attendu. Une capture ou un court enregistrement vaut mieux qu’un paragraphe.
Séparez les erreurs des souhaits. « Le formulaire ne s’envoie pas » est une erreur avec une fin claire. « Rendez l’accueil plus moderne » est un souhait qui demande un brief de design avant toute estimation. En tête, ce qui coûte des demandes ou de l’argent ; à la fin, l’esthétique. Une liste numérotée, un problème par ligne, permet d’estimer et de valider chaque point séparément.
Accès et sauvegarde récente avant toute intervention
Le travail demande des accès : l’administration du CMS ou du constructeur, l’hébergement ou le serveur, le bureau d’enregistrement du domaine, parfois l’outil d’analyse et le service d’e-mail qui envoie les notifications des formulaires. Donnez au prestataire ses propres comptes plutôt que votre mot de passe. Les gros changements sont plus sûrs sur une copie du site, une version de test où une erreur ne coûte rien, puis passent en ligne après vérification.
La deuxième condition est une sauvegarde. La documentation WordPress divise une sauvegarde en deux parties, la base de données et les fichiers, et précise qu’il faut les deux pour restaurer un site ordinaire. Elle conseille une sauvegarde hebdomadaire pour les petits sites et quotidienne pour les sites très actifs, toujours une avant une mise à jour, et au moins trois à cinq copies récentes conservées à des endroits différents : hébergement, stockage en ligne, ordinateur local. Le conseil vise WordPress, mais la logique vaut pour toute plateforme : avant de changer quoi que ce soit, assurez-vous d’un chemin de retour.
Garder ses positions quand les correctifs changent les adresses
La plupart des correctifs ne touchent pas aux adresses des pages, et les moteurs les remarquent à peine. Le risque apparaît quand on renomme des pages, fusionne des rubriques ou déplace le site vers un autre domaine ou vers HTTPS. Le guide de Google Search Central sur les migrations commence par une carte : la liste des anciennes URL avec la nouvelle URL de chacune, établie à partir des sitemaps, des journaux du serveur et du CMS.
Cette carte devient un ensemble de redirections. Google demande des redirections permanentes côté serveur, comme la 301 ou la 308, envoyées directement de chaque ancienne URL vers sa destination finale sans chaînes, et conseille de les garder en général au moins un an. Sa page sur les redirections explique la différence : après une redirection permanente, Google traite la cible comme l’adresse canonique ; après une temporaire, comme la 302 ou la 307, l’ancienne adresse peut rester dans les résultats. Les redirections en JavaScript y sont présentées comme un dernier recours, car Google risque de ne jamais les voir si le rendu échoue.
Même une migration soignée ne passe pas inaperçue. Le même guide prévient que le classement fluctuera temporairement pendant que Google explore à nouveau le site. Les liens internes doivent pointer vers les nouvelles adresses, le sitemap doit être mis à jour et chaque nouvelle page doit porter une balise canonique qui pointe vers elle-même.
Mettre à jour le CMS et les extensions sans casser le site
Les mises à jour sont le correctif qui ne finit jamais. La documentation WordPress explique que depuis la version 3.7 la plupart des sites installent seuls, en arrière-plan, les mises à jour mineures et de sécurité, tandis que les versions majeures demandent toujours un clic sur le bouton de mise à jour. Elle avertit aussi qu’une mise à jour remplace les fichiers du cœur : toute modification faite directement dedans est perdue. Sa procédure manuelle désactive les extensions avant et les réactive après. Un changement écrit dans le cœur plutôt que dans un thème ou une extension a une date de péremption.
La sécurité suit la même ligne. L’OWASP présente son Top 10 comme la référence sur les risques les plus critiques des applications web ; l’édition en vigueur date de 2025. Sa troisième catégorie, les défaillances de la chaîne d’approvisionnement logicielle, couvre les ruptures ou compromissions lors de la construction, de la distribution ou de la mise à jour des logiciels, héritière d’une ancienne entrée sur les composants aux vulnérabilités connues. Parmi les mesures citées par l’OWASP : supprimer les dépendances, fonctions et composants inutilisés, mettre à jour à temps selon le risque et déployer par étapes plutôt que partout à la fois.
Quand refaire le site coûte moins qu’une nouvelle série de correctifs
Corriger a du sens tant que la base est saine. Les signes du contraire se repèrent vite : chaque changement casse quelque chose ailleurs, personne n’ose mettre à jour le CMS parce que le code a été modifié sur place, le thème ou la plateforme n’est plus maintenu, la version mobile est un site à part dont personne ne s’occupe et les devis des petites tâches ne cessent de grimper.
Un test pratique consiste à additionner le coût de la prochaine année de changements et à le comparer au prix d’un site neuf qui règle les mêmes problèmes. Si la liste touche la plupart des gabarits, ou si l’activité a tant changé que la structure du site ne lui convient plus, une refonte ou un nouveau site est en général la réponse honnête. Si les problèmes sont locaux et la plateforme vivante, corriger coûte moins et préserve l’historique dans les moteurs.
Que préparer avant de commander des correctifs de site
Beaucoup de choses se font sans prestataire. Textes, photos, prix et blocs simples dans un constructeur ou un CMS sont pensés pour être modifiés par le propriétaire. Le code, la configuration du serveur, les redirections, les intégrations et tout ce qui touche aux paiements ou aux données personnelles reviennent plutôt à quelqu’un qui fait ce travail tous les jours.
Avant de commander, préparez la liste des problèmes rédigée comme décrit plus haut, les comptes d’accès, la preuve qu’une sauvegarde récente existe et les chiffres d’analyse qui montrent quelles pages apportent des demandes et lesquelles sont lentes. Avec tout cela sur une feuille, n’importe quel studio, VITON13 compris, peut chiffrer chaque point séparément, et vous choisissez par où commencer pour modifier un site internet sans mauvaise surprise.
Checklist pratique
- Envoyez une demande de test par chaque formulaire et vérifiez qu’elle arrive dans la boîte mail, le CRM ou le chat.
- Écrivez chaque problème sur sa propre ligne : page, appareil, étapes pour le reproduire et résultat attendu.
- Faites une sauvegarde récente des fichiers et de la base de données, et gardez-en des copies à plusieurs endroits.
- Avant de renommer une page, listez les anciennes et nouvelles adresses et prévoyez une redirection permanente pour chacune.
- Après chaque mise à jour ou correctif, ouvrez les pages clés sur un téléphone et envoyez une nouvelle demande de test.
Questions et réponses
Quelle différence entre correctifs de site et maintenance continue ?
Les correctifs sont une liste ponctuelle de changements dont on vérifie le résultat point par point. La maintenance est un accord permanent : mises à jour, sauvegardes et réaction aux pannes de mois en mois. De petits correctifs commandés chaque mois deviennent de fait de la maintenance.
Corriger un site peut-il faire baisser son référencement ?
Les changements qui gardent les adresses des pages le font rarement. Des pages renommées, des rubriques fusionnées ou un nouveau domaine exigent des redirections permanentes depuis chaque ancienne adresse, et Google prévient que les positions peuvent osciller un moment même après une migration soignée.
Puis-je mettre à jour moi-même les extensions WordPress avant les correctifs ?
Oui, si vous sauvegardez d’abord les fichiers et la base de données, puis vérifiez les pages principales. Si quelqu’un a modifié directement les fichiers du cœur ou un vieux thème, faites d’abord regarder un développeur, car la mise à jour peut effacer ces modifications.
De quels accès un développeur a-t-il besoin pour corriger un site ?
En général l’administration du CMS et l’hébergement ou le serveur ; parfois le bureau d’enregistrement du domaine, l’outil d’analyse et le service qui envoie les e-mails des formulaires. Créez des comptes dédiés au prestataire pour pouvoir couper l’accès à la fin du travail.
Comment choisir entre corriger le site actuel et en faire un nouveau ?
Comparez une année de changements prévus au prix d’un site neuf qui règle les mêmes problèmes. Si chaque changement casse d’autres parties, si la plateforme n’est plus maintenue ou si la plupart des gabarits sont à reprendre, le neuf l’emporte en général.