Une mise à jour fait disparaître le formulaire de devis. Une modification de mise en page exige plusieurs heures. Le site reste bloqué sur un environnement ancien parce qu’une extension métier ne fonctionne plus ailleurs. La dette technique WordPress devient un problème commercial lorsque maintenir le site absorbe le budget qui devrait servir à le faire évoluer.
Faut-il pour autant tout refaire ? Pas nécessairement. La bonne décision dépend de ce qui bloque réellement : un défaut localisé, une dépendance structurelle, l’hébergement ou une architecture devenue inadaptée. Ce guide propose une méthode pour établir le diagnostic, comparer les coûts et organiser les travaux en préservant les contenus, les données et les parcours qui font vivre votre activité.
Le repère de départ : réparer lorsque les défauts sont isolables sur un socle maintenable ; migrer progressivement lorsque les contenus restent utiles mais qu’une dépendance bloque l’évolution ; reconstruire lorsque les contraintes sont transversales et que les adaptations successives ne permettent plus d’atteindre les objectifs.
Les étapes pour décider
- Reconnaître les symptômes et les urgences
- Réaliser un audit avec des preuves
- Classer les risques et les priorités
- Choisir le bon scénario
- Comparer les coûts sur 24 mois
- Préserver le référencement
- Préparer la bascule et le retour arrière
- Construire un plan de modernisation
Ce que recouvre réellement la dette technique WordPress
La dette technique désigne les contraintes accumulées qui rendent les évolutions plus coûteuses, plus lentes ou plus risquées. Elle peut venir d’un raccourci assumé pour lancer une activité, d’une personnalisation non documentée ou d’un composant qui n’est plus maintenu. Un choix raisonnable à la création du site peut devenir problématique lorsque le volume, l’équipe ou les besoins changent.
Elle ne se confond ni avec un design ancien ni avec la maintenance normale. Renouveler une licence utile n’est pas une dette. Dépendre d’une licence détenue uniquement par un prestataire injoignable crée en revanche un risque de continuité. De même, trente extensions cohérentes et suivies peuvent être plus faciles à maintenir que dix extensions dont plusieurs modifient les mêmes fonctions.
Un défaut doit être décrit par son effet : « cette personnalisation du thème parent disparaît à chaque mise à jour », « personne ne connaît le traitement qui transmet les commandes au CRM » ou « le changement de PHP provoque une erreur reproductible dans ce module ». C’est beaucoup plus exploitable que « le site est vieux ».
Les signes d’une dette technique devenue commerciale
| Symptôme | Hypothèses à vérifier | Impact possible |
|---|---|---|
| Mises à jour reportées | Incompatibilité connue, absence de tests, modification directe des fichiers | Exposition prolongée et coût de remise à niveau |
| Site lent malgré le cache | Requêtes coûteuses, scripts tiers, ressources saturées, mauvaise configuration | Parcours dégradé et travail administratif ralenti |
| Chaque petite modification coûte cher | Modèles dupliqués, styles dispersés, dépendances inconnues | Retard des campagnes et des nouvelles offres |
| Formulaires ou commandes intermittents | Erreurs JavaScript, API externe, webhook, cache inadapté | Demandes perdues ou traitement manuel |
| Une seule personne sait intervenir | Accès, documentation ou code non transmis | Dépendance opérationnelle |
| Personne n’a testé une restauration | Sauvegarde incomplète ou procédure inconnue | Durée de reprise imprévisible |
Ces symptômes ne prouvent pas tous une dette structurelle. Un formulaire peut échouer à cause d’un problème de délivrabilité email ; une page lente peut subir une API externe indisponible. L’audit doit relier le symptôme à une cause avant de chiffrer la solution.
Ce qui doit être traité avant toute réflexion de refonte
Une compromission suspectée, une fuite de données, un paiement défaillant ou une indisponibilité persistante relève d’abord de la gestion d’incident. Préservez les éléments utiles au diagnostic, limitez l’exposition et rétablissez un fonctionnement maîtrisé. Un projet de reconstruction ne remplace pas cette intervention, et recopier une installation compromise peut transporter le problème dans le nouveau site.
Un audit utile doit produire des preuves et des scénarios
Je recommande de partir de quelques parcours représentatifs : consulter une prestation, envoyer une demande, rechercher un produit, commander et administrer une fiche. L’objectif est de comprendre ce qui doit continuer à fonctionner avant de choisir les composants à changer. Le diagnostic technique doit être relié à ces usages.
1. Cartographier les composants et leur rôle
Relevez le cœur WordPress, le thème parent et enfant, les extensions actives et inactives, les mu-plugins, les snippets, les tâches planifiées et les services externes. Pour chaque composant, notez sa fonction, son responsable, sa licence, ses dépendances et les données qu’il conserve. Une extension désactivée ne doit pas être supprimée automatiquement si elle contient encore des données nécessaires à un export.
Cherchez également les personnalisations dans le thème, les modifications directes d’extensions, les modèles de constructeur, les shortcodes et les champs personnalisés. L’absence de code dans un dépôt Git ne signifie pas l’absence de développement spécifique : des règles métier peuvent être stockées dans une extension de snippets ou dans la base.
2. Vérifier le serveur et les compatibilités
L’audit couvre PHP, PHP-FPM, MariaDB ou MySQL, le stockage, la mémoire, les caches et les tâches de fond. Sur un serveur Ubuntu administré avec Plesk, vérifiez notamment le gestionnaire PHP du domaine, ses limites, les journaux et les tâches planifiées. Une saturation des workers ou une requête SQL coûteuse ne se corrige pas forcément en remplaçant le constructeur de pages.
La version PHP cible doit être encore prise en charge et compatible avec les dépendances du site. Consultez le calendrier officiel de support PHP au moment du projet, puis testez la combinaison réelle sur une copie isolée. « La page d’accueil fonctionne » ne valide ni les paiements, ni les tâches cron, ni les appels API.
3. Mesurer les performances sur les bons parcours
Comparez visiteurs anonymes et connectés, mobile et ordinateur, pages servies par le cache et pages dynamiques. Une boutique peut afficher rapidement son accueil tout en bloquant sur le panier. Relevez les temps serveur, les erreurs, les appels externes et le comportement sous une charge représentative.
Les Core Web Vitals donnent des repères complémentaires : LCP au plus 2,5 secondes, INP au plus 200 millisecondes et CLS au plus 0,1, évalués au 75e percentile des visites, en distinguant mobile et ordinateur. Les mesures de laboratoire aident au diagnostic ; elles ne remplacent pas les données des utilisateurs réels. L’absence de données terrain sur un petit site n’est pas une preuve de bonne ou de mauvaise performance.
Un score PageSpeed isolé ne décide donc pas d’une refonte. Retenez des indicateurs liés au besoin : temps nécessaire à l’équipe pour publier une offre, taux d’erreur du formulaire, durée du passage en caisse et fréquence des incidents. Comparez avant et après dans des conditions similaires.
4. Examiner les données, les accès et la restauration
Identifiez les tables volumineuses, les options chargées automatiquement, les tâches en attente et les traces qui s’accumulent. Documentez leur propriétaire avant tout nettoyage. Une table inconnue n’est pas forcément inutile, et un remplacement SQL brut peut endommager les données sérialisées utilisées par WordPress.
Vérifiez qui possède le domaine, l’hébergement, les comptes administrateurs, les licences et les accès aux services de paiement ou d’email. Testez une restauration sur un environnement isolé. Cette vérification doit couvrir fichiers et base de données, ainsi que les éléments externes indispensables au fonctionnement.
Les livrables à demander à la fin de l’audit
- Un inventaire des composants et dépendances, avec les accès manquants.
- Un registre des défauts : preuve, impact, priorité, action proposée et responsable.
- Une liste des parcours métier à tester et leur état initial.
- Au moins les scénarios raisonnablement applicables, avec périmètre, coût et limites.
- Un plan de bascule, des critères de validation et une procédure de reprise.
Si un point reste inconnu faute d’accès ou de données, il doit apparaître comme une incertitude à lever. Il ne doit être ni présenté comme sain, ni transformé automatiquement en motif de reconstruction. Mon article consacré à l’audit SEO complète le volet visibilité de ce diagnostic.
Classer les priorités sans fabriquer un score trompeur
Une moyenne globale peut masquer un problème critique. Un paiement hors service ne devient pas acceptable parce que le reste du site est bien documenté. Je privilégie une grille de décision par défaut, avec une priorité liée à l’impact, à l’exposition et à la capacité de reprise.
| Priorité | Situation | Décision attendue |
|---|---|---|
| P0 — incident | Compromission en cours, données exposées ou parcours vital indisponible | Traiter l’incident immédiatement et organiser la continuité |
| P1 — risque critique | Composant essentiel vulnérable sans correction applicable, restauration impossible | Réduire l’exposition et préparer rapidement une solution vérifiée |
| P2 — dette pénalisante | Erreurs récurrentes, dépendance bloquante, temps de maintenance excessif | Planifier une correction ou un remplacement mesurable |
| P3 — amélioration | Duplication limitée, documentation incomplète sans blocage immédiat | Intégrer au travail de maintenance prévu |
Cette grille est une proposition de travail, pas une norme ou un score de sécurité certifié. Pour chaque ligne, ajoutez un effort estimé sous forme de fourchette et un niveau de confiance. Un défaut simple peut être corrigé rapidement ; un défaut critique peut nécessiter une mesure temporaire avant son traitement définitif.
Exemple : « formulaire de devis non reçu » reste une hypothèse tant que l’on n’a pas vérifié l’enregistrement, la transmission et la réception. Une fois l’échec confirmé, son importance dépend du rôle du formulaire dans l’activité et des solutions de remplacement disponibles. La priorité doit découler de faits observables.
Réparer, migrer ou reconstruire : les critères qui changent la décision
| Scénario | Quand le retenir | Ce qu’il ne résout pas à lui seul |
|---|---|---|
| Réparation ciblée | Défauts identifiés, socle maintenu, changements isolables et testables | Architecture globalement inadaptée |
| Migration progressive | Contenus et données utiles, dépendance remplaçable par étapes | Difficultés d’une longue coexistence entre deux systèmes |
| Reconstruction | Modèles, données ou parcours nécessitant une remise à plat cohérente | Mauvaise organisation, absence de maintenance future |
| Changement d’hébergement | Limite d’infrastructure démontrée | Code défectueux, dépendances abandonnées ou données incohérentes |
Réparer lorsque le socle reste exploitable
La réparation est adaptée lorsque les fonctions principales sont stables, les composants essentiels sont maintenus et les défauts peuvent être isolés. Elle peut consister à corriger une requête, retirer un script inutile, remplacer une extension limitée ou sortir une personnalisation du thème parent.
Fixez un résultat attendu : disparition d’une erreur reproductible, parcours restauré, mise à jour testée ou durée d’administration réduite. Prévoyez aussi une limite d’effort. Si chaque correction révèle une dépendance non maîtrisée, le scénario doit être réévalué plutôt que poursuivi sans plafond.
Migrer progressivement lorsque le contenu reste pertinent
Une migration progressive convient lorsqu’un thème ou un constructeur bloque l’évolution, alors que les contenus, l’arborescence et les données restent utiles. Le pilote doit inclure un modèle représentatif, ses composants dynamiques et son usage sur mobile. Une page très simple ne valide pas la migration d’un catalogue filtrable.
Le passage d’Elementor à Gutenberg ou GreenShift n’est pas une conversion automatique garantie. Les widgets spécifiques, formulaires, conditions d’affichage et contenus dynamiques demandent une reprise. La coexistence de deux systèmes peut temporairement augmenter les styles chargés et la charge de maintenance ; elle doit avoir un périmètre et une date de sortie.
J’explique ce travail dans la migration d’Elementor vers GreenShift et dans mon protocole de migration vers Gutenberg. Le choix de l’outil vient après l’inventaire des fonctions à préserver.
Reconstruire lorsque les contraintes sont transversales
Une reconstruction devient pertinente si le site repose sur des composants essentiels abandonnés, des modifications multiples non traçables et des structures de données incompatibles avec les objectifs. Elle peut aussi répondre à une évolution métier importante : catalogue devenu transactionnel, nouveaux espaces clients ou processus de vente entièrement revus.
Le dossier doit montrer pourquoi les options plus ciblées ne suffisent pas. Refaire toutes les pages sans revoir les responsabilités, les tests et les règles de maintenance produit souvent une nouvelle dette. À l’inverse, reconstruire le code ne signifie pas supprimer les contenus utiles, changer toutes les URL ou abandonner l’historique commercial.
Trois situations pour rendre la décision concrète
Site vitrine lent mais stable : le diagnostic révèle une image principale trop lourde, des scripts marketing inutilisés et un formulaire qui enregistre correctement les demandes. La première option est une optimisation ciblée avec comparaison avant/après. Aucun de ces constats ne justifie seul une reconstruction.
Site éditorial difficile à maintenir : des centaines de contenus utiles dépendent de modèles personnalisés dans un ancien constructeur. Les données sont exportables et les pages peuvent être reprises par familles. Un pilote de migration permet de mesurer le coût réel et de vérifier le rendu avant de généraliser.
Boutique avec logique métier dispersée : prix, stocks et facturation sont modifiés par plusieurs développements sans documentation. La décision dépend d’abord de la possibilité de reconstruire les règles et de réconcilier les données. Une remise à plat peut être justifiée, mais la continuité des commandes impose un plan de transition spécifique.
Ces situations sont illustratives : elles ne décrivent pas des résultats clients ni des audits réalisés sur votre site.
Comparer les coûts sur 24 mois, avec les mêmes hypothèses
Le coût de l’inaction comprend les corrections récurrentes, le temps perdu par l’équipe et les incidents documentés. Ajoutez les licences et frais d’exploitation qui diffèrent réellement entre les scénarios. Séparez les coûts constatés des pertes possibles : un manque à gagner estimé n’est pas une facture certaine.
Coût total comparé = travaux initiaux + exploitation sur la période + temps interne + transition + risque résiduel estimé. Incluez la recette, la formation, la double exploitation et la reprise de données lorsqu’elles s’appliquent. Évitez de compter deux fois les mêmes heures dans la maintenance et le temps interne.
Voici un exemple fictif, en euros HT, sur 24 mois. Les postes communs aux trois options sont exclus. Les coûts mensuels supposent une charge stable dès la fin des travaux ; dans un vrai devis, le calendrier de transition doit être détaillé.
| Poste | Réparer | Migrer par étapes | Reconstruire |
|---|---|---|---|
| Travaux initiaux, recette et transition incluses | 2 000 € | 6 000 € | 12 000 € |
| Maintenance et temps interne mensuels | 350 € | 150 € | 100 € |
| Coût récurrent sur 24 mois | 8 400 € | 3 600 € | 2 400 € |
| Total comparé hors incidents hypothétiques | 10 400 € | 9 600 € | 14 400 € |
Avec ces seules hypothèses, la migration coûte 800 € de moins que la réparation sur 24 mois. Son surcoût initial de 4 000 € est compensé en 20 mois par 200 € d’économie mensuelle. Si l’économie réelle n’est que de 100 € par mois, cette durée passe à 40 mois. Le résultat dépend donc davantage d’hypothèses vérifiées que de la présentation du devis.
La reconstruction peut rester nécessaire pour atteindre un objectif métier inaccessible autrement, mais le tableau ne la justifie pas par les seules économies de maintenance. Comparez alors explicitement le bénéfice attendu, ses incertitudes et les solutions alternatives. Ces montants servent à expliquer la méthode ; ils ne constituent ni mes tarifs ni une estimation de votre projet.
Pour une boutique, raisonnez sur la marge contributive perdue pendant une panne plutôt que sur le seul chiffre d’affaires. Pour un site de services, partez des demandes effectivement reçues, du taux de transformation observé et de la capacité à les traiter. Une amélioration de performance ne garantit pas un pourcentage de ventes supplémentaire.
Préserver le référencement pendant les travaux
Le référencement se prépare dès l’inventaire. Croisez le crawl, les sitemaps, Search Console et les données de fréquentation pour repérer les pages importantes. Conservez leur intention, leurs contenus utiles, leurs liens et leur accessibilité. Une reconstruction graphique ne nécessite pas automatiquement de changer les adresses.
Lorsque des URL changent, préparez une correspondance vers des pages réellement équivalentes, des redirections permanentes directes et le contrôle des liens internes, canoniques et sitemaps. Évitez les renvois massifs vers l’accueil. Les recommandations de Google sur les migrations préconisent de conserver les redirections aussi longtemps que possible, généralement au moins un an, et rappellent que la visibilité peut fluctuer pendant le traitement.
Vérifiez également les images, les PDF, les versions linguistiques et les données structurées qui correspondent réellement au contenu. Sur la préproduction, protégez l’accès ; au lancement, contrôlez qu’aucune restriction de test ne bloque involontairement les pages publiques.
La validation doit comparer des familles de pages, pas seulement l’accueil. Une fiche produit, une archive, une page de prestation et un article peuvent utiliser des modèles différents. Aucun prestataire sérieux ne peut promettre une absence absolue de variation SEO ; il peut en revanche fournir une méthode, des contrôles et un suivi.
Organiser la bascule d’un site qui continue à travailler
Le risque majeur d’une refonte en préproduction est de remettre en ligne une base devenue ancienne. Pendant les travaux, le site actif a pu recevoir des commandes, créer des comptes, enregistrer des demandes ou modifier les stocks. Écraser sa base par celle du chantier peut faire disparaître ces changements.
Isoler la préproduction et tester les flux
La copie de test doit empêcher les emails réels, les paiements de production et les synchronisations non souhaitées vers le CRM ou la logistique. Contrôlez les webhooks, les tâches cron, les abonnements et les clés API. Protégez les données personnelles de la copie et limitez les accès.
Testez les mises à niveau et la migration dans cet environnement. La documentation WordPress sur les migrations détaille notamment les précautions liées aux changements d’adresse et aux données stockées. Une opération de remplacement doit être adaptée aux structures WordPress et vérifiée avant son application à la production.
Définir une recette métier avant le lancement
| Parcours | Contrôles à prévoir |
|---|---|
| Contact ou devis | Validation, enregistrement, réception email et transmission CRM |
| Achat | Prix, taxes, livraison, paiement, confirmation et état de commande |
| Compte client | Connexion, récupération du mot de passe, droits et historique |
| Administration | Édition, médias, recherche et gestion des rôles |
| Automatisations | Cron, webhooks, absence de doublons et gestion des erreurs |
| Navigation | Mobile, clavier, liens, recherche et pages d’erreur |
Définissez les critères d’acceptation avec le responsable métier. Une sauvegarde restaurable, aucun défaut bloquant sur les parcours essentiels et une procédure de reprise validée constituent des conditions de lancement ; ils ne sont pas des améliorations à reporter après la bascule.
Préparer un retour arrière qui respecte les nouvelles données
Décidez ce qui sera déployé : fichiers, configuration, modèles ou données. Prévoyez une synchronisation finale et, si nécessaire, une courte suspension des écritures avec information des utilisateurs. Une migration sans interruption est une contrainte d’architecture à étudier, pas une promesse automatique.
Le retour arrière doit préciser le déclencheur, le responsable et les données à conserver. Restaurer une base sauvegardée avant le lancement peut effacer des commandes reçues depuis. Selon le projet, il faudra revenir sur le code en conservant les données, réconcilier les écritures ou corriger en avant. Une modification de schéma peut rendre l’ancien code incompatible : ce point se teste avant la bascule.
Un plan de 90 jours fondé sur des jalons vérifiables
Ce calendrier est un cadre adaptable pour un projet de taille raisonnable, pas un délai garanti. Une urgence de sécurité n’attend pas le prochain jalon ; un système complexe peut nécessiter davantage de temps.
| Période indicative | Travail | Condition pour poursuivre |
|---|---|---|
| Jours 1 à 15 | Inventaire, traitement des urgences, sauvegarde et mesures initiales | Périmètre connu et restauration vérifiée |
| Jours 16 à 30 | Comparaison des scénarios, budget et critères de recette | Décision documentée et responsabilités attribuées |
| Jours 31 à 60 | Corrections ou migration d’un pilote représentatif | Résultats acceptés et estimation révisée |
| Jours 61 à 75 | Extension du travail, contrôles SEO et répétition de bascule | Parcours critiques validés et reprise préparée |
| Jours 76 à 90 | Déploiement, surveillance et transfert de documentation | Fonctionnement stable et suivi attribué |
Après lancement, surveillez les erreurs serveur, les demandes reçues, les paiements, les tâches en attente et l’indexation. Comparez les résultats à une période représentative, en tenant compte des campagnes et de la saisonnalité. Une baisse du trafic seule ne permet pas d’attribuer immédiatement le problème à la refonte.
Éviter de recréer la même dette six mois plus tard
Chaque nouvelle extension doit répondre à un besoin identifié, avoir un responsable et une méthode de retrait. Les règles métier doivent être séparées autant que possible de la présentation. Documentez les personnalisations et versionnez le code pour comprendre ce qui change et revenir sur une modification.
Prévoyez un processus de mise à jour avec sauvegarde, tests proportionnés et contrôle des parcours critiques. La documentation de sécurisation WordPress rappelle l’importance de réduire les risques par plusieurs mesures complémentaires. Une protection serveur ou un WAF ne dispense pas de maintenir les composants applicatifs.
Tenez un registre simple des exceptions : composant concerné, raison du report, risque accepté, mesure temporaire et date de réexamen. Ce qui a été reporté volontairement ne doit pas devenir invisible. Mesurez dans le temps les heures de correction, les incidents et le délai pour publier une évolution : c’est là que la réduction de dette devient observable.
Questions fréquentes sur la dette technique WordPress
Comment savoir si mon site WordPress doit être refait ?
Une reconstruction se justifie lorsque les contraintes touchent plusieurs couches et empêchent d’atteindre les objectifs avec des corrections raisonnables. L’audit doit comparer cette option à la réparation et à la migration progressive. L’âge du site ou son apparence ne suffisent pas.
Un grand nombre d’extensions signifie-t-il forcément une forte dette ?
Non. Leur rôle, leur maintenance, leurs interactions et leur impact réel comptent davantage. Il faut identifier les doublons et les dépendances, puis tester les retraits. Supprimer une extension sans examiner ses données peut faire perdre une fonction ou un historique utile.
Peut-on mesurer financièrement la dette technique ?
On peut comparer les coûts constatés de maintenance, le temps interne et les incidents, puis construire des scénarios sur une même période. Les pertes commerciales hypothétiques doivent être distinguées des dépenses certaines. Les estimations doivent préciser leurs hypothèses et leur sensibilité.
Comment limiter le risque SEO pendant une reconstruction ?
Inventoriez les pages utiles, conservez les URL lorsque c’est possible et préparez des redirections vers des contenus équivalents si elles changent. Vérifiez les contenus, liens, canoniques, sitemaps et restrictions d’indexation. Le suivi après lancement reste nécessaire : aucune méthode ne garantit une visibilité absolument constante.
L’audit doit-il inclure le serveur ?
Oui. Une limite de mémoire, des workers PHP saturés, des requêtes lentes, un stockage défaillant ou des appels externes peuvent expliquer les symptômes. Remplacer un thème ou un constructeur sans examiner ces causes peut laisser le problème intact.
Changer d’hébergeur peut-il suffire ?
Oui, si une limite d’infrastructure est démontrée et si l’application reste maintenable. Le transfert ne supprime toutefois pas les défauts du code, les extensions abandonnées ni les dépendances non documentées. Il faut valider l’hypothèse par des mesures.
Faut-il abandonner Elementor pour réduire la dette technique ?
Pas systématiquement. Un site Elementor maîtrisé et maintenu peut rester adapté. Une migration devient pertinente lorsque les dépendances, performances ou coûts d’évolution le justifient. Le pilote doit vérifier les fonctions dynamiques, le rendu et le coût de reprise avant généralisation.
Peut-on moderniser une boutique sans perdre les commandes ?
Oui, à condition de prévoir la conservation des écritures de production, une synchronisation finale et un plan de bascule adapté. Une base de préproduction ancienne ne doit pas remplacer aveuglément la base active. Le retour arrière doit lui aussi préserver les nouvelles commandes.
Combien coûte un audit ou une reconstruction WordPress ?
Le coût dépend du nombre de modèles, des intégrations, des données, des personnalisations et des exigences de continuité. Demandez un périmètre, des livrables et des hypothèses chiffrées. Les montants illustratifs de cet article ne constituent pas un devis.
Quels accès préparer pour un audit ?
Préparez l’inventaire des accès WordPress, hébergement, sauvegardes, licences et outils de mesure, ainsi que les coordonnées des responsables des intégrations. Les accès sont fournis par un canal sécurisé, avec les droits nécessaires au périmètre convenu. N’envoyez pas de mots de passe dans un formulaire de contact.
Faire le bon investissement pour votre site
La modernisation doit rendre le site plus fiable et plus simple à faire évoluer. La décision peut être une réparation ciblée, une migration par étapes ou une reconstruction. Sa qualité se juge à la précision du diagnostic, au coût global, à la maîtrise de la transition et à la maintenance prévue ensuite.
En tant que développeur indépendant spécialisé dans WordPress et l’administration serveur, je peux examiner ensemble les composants du site, son hébergement et ses parcours métier pour établir un diagnostic priorisé. L’objectif est de vous donner un plan compréhensible : ce qui doit être corrigé maintenant, ce qui peut attendre et ce qui mérite d’être remplacé.
Pour une première prise de contact, indiquez l’adresse du site, les blocages rencontrés, les fonctions indispensables et les éventuelles périodes pendant lesquelles une interruption est exclue. Ces éléments permettent de définir le périmètre de l’audit et les accès nécessaires.
