# Message « Ce gabarit référence un modèle introuvable » après WordPress 7.0

> Symptôme, diagnostic et correctif pour une erreur d'identifiant de template apparue sur un thème hybride ancien après la montée vers WordPress 7.0.

- Auteur : Clément Hadrot
- Publié le : 2026-09-06
- Mis à jour le : 2026-09-06
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/gabarit-modele-introuvable-wordpress-70/

## L’essentiel

- Un identifiant de template devenu incohérent
- La cause : un slug historique jamais nettoyé
- Corriger sans perdre les personnalisations en base

« Ce gabarit référence un modèle introuvable » : ce message s'affiche depuis l'écran de gestion des templates, à la place du contenu attendu, sur la page d'accueil d'un site construit avec un thème hybride ancien, jamais mis à jour depuis sa création plusieurs années auparavant. La mise à jour vers WordPress 7.0 vient tout juste d'être appliquée sur l'environnement de production.

## Symptôme : un template fantôme dans l'administration

L'écran Data Views des templates affiche bien une entrée pour la page d'accueil, mais son ouverture déclenche ce message d'erreur au lieu de charger le contenu du gabarit. Le site continue pourtant de s'afficher normalement côté visiteur, ce qui indique que le rendu public utilise encore une résolution de fichier fonctionnelle, alors que l'entrée enregistrée en base pointe, elle, vers un identifiant devenu incohérent.

## Diagnostic : un slug historique jamais nettoyé

Une inspection de la table `wp_posts`, filtrée sur le type `wp_template`, révèle la source du problème : une entrée porte le nom `theme-hybride-ancien//accueil `, avec un espace final invisible à l'œil nu, hérité d'une modification manuelle en base de données réalisée des années auparavant par un précédent prestataire, probablement lors d'une tentative de correction improvisée.

```
wp db query "SELECT ID, post_name, post_title FROM wp_posts WHERE post_type = 'wp_template' AND post_name LIKE 'accueil%';" --path=/var/www/site-ancien
```

WordPress 7.0 a resserré la logique de résolution des identifiants de template, en s'appuyant plus strictement sur la correspondance exacte entre le slug enregistré en base et celui attendu par le fichier du thème. Les versions précédentes toléraient cette incohérence silencieusement, en retombant sur le fichier du thème sans signaler le problème sous-jacent.

> L'essentiel à retenir : Un identifiant de template devenu incohérent ; La cause : un slug historique jamais nettoyé ; Corriger sans perdre les personnalisations en base

## Correctif : nettoyer l'identifiant sans perdre les personnalisations

La tentation serait de supprimer purement l'entrée fautive en base, ce qui ferait perdre toute personnalisation enregistrée par un précédent éditeur sur ce template précis. La méthode la plus sûre consiste à corriger directement le `post_name` incriminé, en retirant l'espace superflu, plutôt qu'à repartir de zéro.

```
UPDATE wp_posts
SET post_name = 'accueil'
WHERE post_type = 'wp_template'
  AND post_name = 'accueil ';
```

Après cette correction, un vidage du cache d'objets et du cache de la table des templates, via `wp cache flush`, permet de vérifier immédiatement que l'écran Data Views retrouve un affichage cohérent du gabarit, sans avoir perdu les blocs personnalisés enregistrés par l'équipe éditoriale.

## Vérifier qu'aucun autre template n'est concerné

Une recherche plus large sur l'ensemble des entrées `wp_template` et `wp_template_part` permet de s'assurer qu'aucune autre incohérence de ce type ne subsiste ailleurs sur le même site, avant qu'elle ne se manifeste plus tard sur un autre gabarit du même thème hybride ancien.

```
wp db query "SELECT post_name FROM wp_posts WHERE post_type IN ('wp_template','wp_template_part') AND post_name != TRIM(post_name);" --path=/var/www/site-ancien
```

## Prévention : ne jamais éditer les slugs de template directement en base

Ce type d'incident trouve toujours sa source dans une intervention manuelle en base de données, réalisée sans passer par les mécanismes prévus par WordPress. Toute correction future sur un slug de template devrait passer par l'interface de l'éditeur de site ou par une fonction dédiée comme `wp_update_post()`, jamais par une requête SQL directe qui ignore les validations natives.

> Une incohérence tolérée silencieusement pendant des années finit toujours par ressurgir au moment d'une montée de version qui resserre les règles : mieux vaut la traquer avant qu'elle ne se rappelle à vous.

## Ce qu'il faut retenir

Le message « Ce gabarit référence un modèle introuvable » après une montée vers WordPress 7.0 pointe le plus souvent vers un identifiant de template corrompu, hérité d'une intervention manuelle en base plutôt que d'un bug de la nouvelle version elle-même. Un correctif ciblé sur le slug fautif, plutôt qu'une suppression radicale de l'entrée, permet de résoudre l'incident sans perdre les personnalisations accumulées au fil du temps.