Dette technique
L'ensemble des raccourcis et des restes accumulés sur un site qui ne gênent pas aujourd'hui mais rendent chaque intervention suivante plus longue, plus risquée et plus chère.
Définition
La dette technique d’un site WordPress est l’ensemble des raccourcis et des restes accumulés qui ne gênent pas aujourd’hui mais rendent chaque intervention suivante plus longue, plus risquée et plus chère. Extensions abandonnées, contenus enfermés dans un constructeur de page, versions en retard, données oubliées en base : rien de tout cela ne se voit en façade. Comme une dette financière, elle a un capital, ce qu’il faudrait reprendre, et des intérêts, le surcoût payé à chaque mise à jour, chaque panne et chaque refonte.
Qu’est-ce que la dette technique ?
Une image venue du développement logiciel, qui s’applique très bien à un site WordPress.
L’expression vient de Ward Cunningham, dans un retour d’expérience présenté à la conférence OOPSLA en 1992. Il y écrit que livrer du code écrit au premier jet revient à s’endetter. Un peu de dette accélère le travail tant qu’elle est remboursée vite, mais chaque minute passée ensuite sur du code « pas tout à fait juste » compte comme un intérêt. Le danger, dit-il, apparaît quand la dette n’est jamais remboursée.
Sur un site WordPress, la dette vient rarement du code écrit par le propriétaire. Elle naît de choix : une extension ajoutée pour un besoin ponctuel puis oubliée, un thème modifié directement, une mise en page confiée à un constructeur de page, une mise à jour repoussée parce qu’elle fait peur. Chacun de ces choix était raisonnable sur le moment. C’est leur accumulation, et l’absence de trace, qui transforme une facilité en dette.
Où se cache la dette technique d’un site WordPress ?
Presque jamais là où le visiteur regarde. Cinq endroits reviennent sur les sites que l’on reprend.
Les restes d’extensions
La documentation officielle des développeurs WordPress est explicite : la désactivation d’une extension ne retire ni ses options ni ses tables. Seule la suppression depuis l’administration lance un nettoyage, et seulement si l’auteur de l’extension l’a prévu. Des années d’essais laissent donc une base remplie de données que plus rien n’utilise.
Les contenus prisonniers d’un outil
Un constructeur de page enregistre souvent la mise en forme sous forme de codes courts mêlés au texte. Le jour où l’outil est retiré, ces codes s’affichent souvent en clair. C’est le verrouillage par le constructeur, l’une des dettes les plus coûteuses à solder.
Les modifications faites au mauvais endroit
Du code ajouté directement dans le thème principal disparaît à sa prochaine mise à jour. Pour ne pas le perdre, on cesse de mettre le thème à jour, et la dette grossit. Le thème enfant existe précisément pour éviter ce piège.
Le retard de versions
Une extension abandonnée par son auteur, une version de PHP proche de sa fin de vie, un cœur de WordPress jamais mis à jour : chaque retard rend le rattrapage suivant plus gros, et la compatibilité avec PHP finit par bloquer.
Les rustines
Un correctif ajouté pour masquer un problème au lieu de le traiter, par exemple un filtre qui efface à l’affichage les codes courts d’un ancien constructeur, fonctionne. Mais il faut s’en souvenir, le maintenir, et il cache la dette au lieu de la rembourser.
Quels risques fait courir la dette technique ?
Rien le jour où elle se crée. Un peu à chaque intervention, ensuite.
Les intérêts se paient à des moments précis. À chaque mise à jour, quand il faut vérifier qu’un vieux morceau de code ne casse pas. À chaque sauvegarde et à chaque migration, qui emportent des données inutiles. À chaque panne, quand le diagnostic doit écarter des éléments dont plus personne ne connaît le rôle. Et lors d’une refonte, où une partie du budget sert à démêler l’existant avant de construire.
Le risque le plus sérieux touche la sécurité. Une extension abandonnée ne reçoit plus de correctif : la première faille publiée à son sujet reste ouverte. Une version de PHP en fin de vie, de même, ne reçoit plus de correctifs de sécurité. Dans ces deux cas, la dette technique cesse d’être une affaire de confort et devient une porte d’entrée.
Il y a aussi un coût moins visible : la dépendance. Un site dont seul l’ancien prestataire connaît les rustines est un site que l’on n’ose plus toucher. La dette se mesure alors à la peur qu’inspire la prochaine intervention.
Comment mesurer la dette technique d’un site WordPress ?
Par un inventaire, pas par une impression. Quatre relevés suffisent à l’évaluer.
| Relevé | Ce qu’il révèle |
|---|---|
| Extensions installées, actives ou non, avec la date de leur dernière mise à jour par l’auteur | Les extensions abandonnées et celles qui ne servent plus |
| Versions de PHP, du cœur et du thème | Le retard accumulé et l’écart avec les versions maintenues |
| Tables et réglages de la base comparés aux extensions présentes | Les restes d’extensions disparues |
| Temps passé et incidents à chaque mise à jour | Le montant réel des intérêts payés |
Le dernier relevé est le plus parlant pour un dirigeant : une maintenance qui prend de plus en plus de temps pour le même résultat est le signe le plus sûr d’une dette qui grossit.
Comment gérer la dette technique : faut-il tout rembourser ?
Non. Il faut rembourser celle dont les intérêts tombent souvent.
Dans un article de référence sur la notion, Martin Fowler distingue la dette prudente, choisie en connaissance de cause, de la dette imprudente, née du désordre. Il note qu’une dette prudente peut ne pas valoir son remboursement si ses intérêts sont faibles, par exemple dans une partie du code que l’on touche rarement. Appliqué à un site WordPress, cela donne un ordre de priorité simple : ce qui intervient à chaque mise à jour passe avant ce qui dort.
| Type de dette | Quand les intérêts tombent | Priorité |
|---|---|---|
| Extension abandonnée, PHP en retard | À chaque mise à jour, et à la prochaine faille publiée | Haute |
| Modifications hors thème enfant | À chaque mise à jour du thème | Haute |
| Contenus dans un constructeur de page | Au changement de thème ou d’outil | À planifier avec la prochaine refonte |
| Tables et réglages d’extensions disparues | Aux sauvegardes et aux migrations | Basse, à traiter avec précaution |
Une suppression en base ne se rattrape pas. Avant d’effacer une table qui semble orpheline, il faut vérifier qu’aucune extension active ne s’en sert, faire une sauvegarde et, si possible, tester sur une préproduction. Un nom de table ressemble souvent à celui d’une extension, il ne le prouve pas.
Ce que montre un site réel
Relevé du 13 octobre 2026, en lecture seule, sur un site vitrine WordPress 7.1.3 que nous maintenons. La base compte 194 tables, dont 12 seulement appartiennent au cœur de WordPress. 136 portent le préfixe d’une extension qui n’est plus installée sur le site : 35 pour WooCommerce, 27 pour un outil de maillage interne, 20 pour un outil de gestion multisite, 12 pour une extension de publication automatique, 11 pour une ancienne extension de sécurité, et d’autres plus petites. Elles pèsent environ 9 Mo sur 50 Mo de base. Le planificateur de tâches partagé par plusieurs extensions garde 2 712 tâches, dont 1 431 en échec, et 1 361 appartiennent à une extension d’intelligence artificielle, elle aussi disparue. Enfin, 4 contenus publiés, 12 brouillons et 21 modèles contiennent encore les codes courts d’un constructeur de page retiré, qu’un filtre efface à l’affichage. Notre lecture : rien ici ne menace le site, mais tout alourdit ses sauvegardes et compliquera une migration. Ce que le relevé ne mesure pas : l’effet de ces restes sur la vitesse d’affichage.
Questions fréquentes
Comment savoir si mon site WordPress a de la dette technique ?
Quelques signes ne trompent pas : des mises à jour repoussées parce qu’elles font peur, une extension que personne n’ose désactiver, un prestataire seul à savoir comment le site tient, des codes courts qui s’affichent en clair après un changement d’outil. Un inventaire des extensions, de la version de PHP et du contenu de la base donne ensuite la mesure précise. C’est l’objet d’une maintenance préventive.
Un site neuf peut-il déjà avoir de la dette technique ?
Oui, dès ses premiers choix. Ce n’est pas un défaut en soi : une dette choisie pour tenir un délai, et notée quelque part, reste une décision. Elle devient un problème quand personne ne sait plus qu’elle existe.
Supprimer une extension depuis l’administration efface-t-il ses données ?
Seulement si son auteur l’a prévu. WordPress lance alors une routine de désinstallation qui peut retirer réglages et tables. Une extension qui n’en a pas laisse ses données en base. La désactivation, elle, ne retire jamais les tables.
Faut-il refaire le site pour s’en débarrasser ?
Pas forcément. Une refonte efface une partie de la dette, mais elle en crée une nouvelle si les mêmes choix se répètent. Sur un site qui fonctionne, un remboursement progressif, en commençant par ce qui touche chaque mise à jour, coûte souvent moins cher qu’une reconstruction complète.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.