Article mis à jour le 25 septembre 2026
Faut-il utiliser un thème WordPress ou PrestaShop, le personnaliser, ou faire développer son site entièrement sur mesure ? C’est une question que l’on me pose régulièrement, et la réponse a beaucoup évolué ces dernières années.
Un thème peut permettre de lancer rapidement un excellent site. Un développement sur mesure peut offrir davantage de liberté et de contrôle. Mais aujourd’hui, le choix n’est plus aussi binaire. Entre les thèmes de blocs WordPress, les thèmes enfants, les page builders, les design systems, les composants personnalisés, les nouveaux thèmes PrestaShop et les architectures headless, il existe de nombreuses solutions intermédiaires.
L’intelligence artificielle et des outils comme Figma ont également changé la manière de concevoir un site. Il est désormais possible de travailler de façon beaucoup plus continue entre contenu, design, développement et tests.
La première question reste pourtant la même : qu’est-ce que je veux faire de mon site web ?
Avant de choisir une technologie, il faut donc comprendre les besoins du projet. Un site vitrine de quelques pages, un média avec plusieurs rédacteurs et un site e-commerce connecté à un ERP n’ont ni les mêmes contraintes ni les mêmes priorités.
Si votre projet concerne la création d’une boutique en ligne et que vous hésitez encore entre WooCommerce et PrestaShop, je vous conseille d’abord de lire mon article PrestaShop ou WooCommerce : quelle solution choisir pour son e-commerce ?.
Thème ou sur-mesure : la réponse rapide
Dans la majorité des projets, je ne recommande pas de choisir entre thème et sur-mesure uniquement en fonction du budget. Il faut regarder ce que le site doit accomplir aujourd’hui, mais aussi ce qu’il devra permettre dans deux ou trois ans.
Un thème ou une base existante est généralement pertinent lorsque vos besoins sont proches de standards déjà éprouvés. Cela permet de réduire le temps consacré à la création de fondations qui existent déjà.
Le sur-mesure devient particulièrement intéressant lorsque votre design, vos parcours utilisateurs, vos fonctionnalités ou vos contraintes métier constituent une véritable différence.
Entre les deux, une troisième voie est souvent la plus pertinente : utiliser une base fiable puis développer uniquement les composants réellement spécifiques.
Avant de choisir, définissez les besoins de votre site
Le choix technique doit venir après le cadrage. Commencer par choisir un thème, un page builder ou un framework avant d’avoir défini le besoin revient à choisir les matériaux d’une maison avant d’avoir réalisé les plans.
Je conseille de commencer par répondre à quelques questions simples :
- Quel est l’objectif principal du site : vendre, générer des contacts, informer, fidéliser ou proposer un service ?
- Quels sont les parcours les plus importants pour les utilisateurs ?
- Combien de types de contenus et de gabarits différents sont réellement nécessaires ?
- Qui devra modifier le contenu après la mise en ligne ?
- Le site doit-il communiquer avec un CRM, un ERP, un PIM ou une application ?
- Le design doit-il être fortement différenciant ?
- Quelles sont les exigences de performance, d’accessibilité et de référencement naturel ?
- Qui assurera la maintenance dans un an, trois ans ou cinq ans ?
Ces réponses permettent généralement d’identifier assez vite le bon niveau de personnalisation et d’éviter de payer pour une complexité dont le projet n’a pas besoin.
Les principales différences entre un thème et du sur-mesure
Un thème et un développement sur mesure répondent à des logiques différentes. Il ne faut donc pas chercher une solution systématiquement meilleure que l’autre, mais celle qui correspond réellement au projet.
Le budget initial d’un thème est généralement plus faible lorsque les besoins correspondent bien à la base choisie. Un développement sur mesure demande davantage de travail lorsque le design, les composants et les fonctionnalités doivent être conçus spécifiquement.
Le délai de lancement peut également être réduit avec un thème si peu d’adaptations sont nécessaires. À l’inverse, un projet sur mesure demande généralement davantage de cadrage, de design, de développement et de recette.
Pour la personnalisation et l’identité visuelle, le sur-mesure offre naturellement davantage de liberté. Mais un thème bien construit peut lui aussi être fortement personnalisé, notamment lorsqu’il est associé à un design system cohérent.
Concernant les performances, aucune des deux solutions ne gagne automatiquement. Un thème léger et correctement configuré peut être extrêmement rapide. Un développement sur mesure peut aller encore plus loin dans l’optimisation, mais uniquement si la qualité du développement est au rendez-vous.
La même logique s’applique au SEO, à l’accessibilité, à la maintenance et à l’évolutivité. Ces éléments dépendent avant tout de la qualité de conception et d’implémentation.
Un thème n’est donc pas automatiquement lent ou mauvais pour le SEO, tout comme un site sur mesure n’est pas automatiquement rapide et bien optimisé.
Quand utiliser un thème WordPress ou PrestaShop ?
Utiliser un thème reste une excellente solution lorsque votre besoin se rapproche de ce que la base propose déjà. L’erreur consiste surtout à sélectionner un thème uniquement parce que sa démonstration est jolie.
Il faut regarder ce qui se trouve derrière la démo : structure des templates, qualité du code, fréquence des mises à jour, documentation, accessibilité, dépendances, extensions obligatoires et facilité de personnalisation.
Le prix de la licence n’est qu’une petite partie du coût réel. Il faut ajouter le temps nécessaire à la configuration, à l’intégration des contenus, aux adaptations graphiques, aux éventuels développements spécifiques et à la maintenance.
Je déconseille également de considérer qu’un thème gratuit est automatiquement moins sécurisé qu’un thème premium. La provenance, la qualité du développement et la maintenance sont beaucoup plus importantes.
WordPress : les block themes changent la notion de thème
Sur WordPress moderne, un thème n’est plus forcément un ensemble rigide de templates que l’on doit contourner avec des dizaines d’options.
Avec un block theme, le Site Editor permet de travailler sur les différentes parties du site à l’aide de blocs : pages, navigation, en-tête, pied de page, templates et patterns.
Pour un projet personnalisé, theme.json permet également de centraliser une partie du design system : couleurs, typographie, espacements et autres réglages globaux.
Un projet peut donc utiliser un thème de blocs comme base, désactiver ce dont il n’a pas besoin et créer des patterns ou blocs spécifiques. On obtient ainsi une approche intermédiaire entre le thème standard et le développement totalement spécifique.
Voici par exemple la logique d’un fichier theme.json simplifié :
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"color": {
"palette": [
{
"slug": "brand",
"name": "Couleur de marque",
"color": "#1d3557"
}
]
},
"typography": {
"fluid": true
}
}
}L’exemple est volontairement minimal et doit être adapté à la version de WordPress et au design system du projet.
Lorsqu’un thème parent classique est utilisé, un thème enfant reste également utile pour conserver les personnalisations sans modifier directement les fichiers du parent.
WordPress, ACF et thème squelette
Une autre approche que j’utilise régulièrement consiste à partir d’un thème squelette volontairement léger, puis à construire uniquement les templates et composants dont le projet a réellement besoin. Associé à ACF, cela permet de conserver la souplesse de WordPress tout en gardant un contrôle précis sur le HTML, le CSS, le JavaScript et la structure des données.
ACF permet notamment de créer des champs métier structurés et des blocs adaptés au contenu du site. Plutôt que de laisser l’utilisateur construire librement chaque page, je peux lui proposer les bons champs, les bons composants et les bonnes options au bon endroit. L’objectif est de trouver un équilibre entre autonomie éditoriale et cohérence du design.
Cette méthode fonctionne particulièrement bien pour les sites vitrines sur mesure, avec WooCommerce, les projets avec des types de contenus spécifiques, des fiches structurées ou des intégrations avec des API, CRM, ERP ou autres services externes. Elle évite également d’embarquer de nombreuses fonctionnalités inutiles lorsqu’un projet n’en a pas besoin.
Un thème squelette n’empêche pas de profiter des évolutions récentes de WordPress. Il est possible d’utiliser theme.json pour centraliser une partie du design system, notamment les couleurs, la typographie et les espacements, puis d’utiliser des patterns et des blocs personnalisés pour offrir des compositions réutilisables dans l’éditeur.
ACF s’intègre également à cette logique moderne. Les blocs personnalisés peuvent être déclarés avec block.json et utiliser des templates de rendu spécifiques, ce qui permet de conserver une organisation claire entre données, édition et affichage.
Côté SEO et performances, cette approche donne surtout la possibilité de maîtriser ce qui est réellement envoyé au navigateur. Je privilégie un HTML sémantique, des templates simples, le chargement des scripts et styles uniquement lorsqu’ils sont nécessaires, ainsi que des images correctement dimensionnées et adaptées aux différents écrans. L’objectif reste d’obtenir de bons résultats sur les Core Web Vitals, sans ajouter des dépendances uniquement par confort de développement.
Cette façon de travailler s’intègre aussi très bien dans un workflow avec Figma. Les composants et règles définis dans la maquette peuvent être retranscrits dans le design system du thème, puis déclinés sous forme de templates, blocs et patterns.
Comme pour tout développement sur mesure, cette liberté implique aussi de prévoir la maintenance. Le thème, les champs personnalisés, les blocs, les dépendances et les intégrations doivent être testés lors des évolutions de WordPress, de PHP ou des extensions utilisées. Des tests réguliers sur le responsive, l’accessibilité, le SEO et les performances permettent de conserver un site fiable dans le temps.
PrestaShop : des thèmes plus modernes et personnalisables
PrestaShop a lui aussi beaucoup évolué depuis la première publication de cet article. Les versions récentes du CMS modernisent progressivement l’architecture technique et la manière de concevoir les thèmes.
Les nouvelles bases de thèmes sont pensées pour faciliter la création de boutiques modernes, adaptées au mobile et plus facilement personnalisables.
Les bonnes pratiques accordent également davantage d’importance au HTML sémantique, à la navigation clavier, à la gestion du focus, aux contrastes et à l’accessibilité.
Cela change là encore la question. Il n’est pas toujours nécessaire de choisir entre un thème générique acheté tel quel et une création intégralement reconstruite.
Une base moderne peut être personnalisée pour conserver les avantages de PrestaShop tout en créant une identité réellement spécifique à la boutique.
Quand choisir un développement sur mesure ?
Le développement sur mesure devient particulièrement intéressant lorsque votre site constitue un véritable outil métier ou lorsque l’expérience proposée fait partie de votre différenciation.
C’est notamment le cas lorsqu’il faut créer des parcours atypiques, des composants complexes, une forte identité graphique, de nombreuses interactions, des règles métier spécifiques ou des connexions importantes avec le système d’information.
Le premier avantage reste celui que j’évoquais déjà dans la première version de cet article : vous ne partez pas d’une maquette générique que vous essayez ensuite de faire correspondre à votre projet. Le design et les composants sont conçus à partir du besoin.
Le deuxième avantage est le contrôle technique. Le développeur peut décider précisément quels scripts, styles, bibliothèques et fonctionnalités doivent être chargés.
Cela peut permettre d’obtenir un site très léger. Mais il faut apporter une nuance importante : le sur-mesure n’est performant que si le code sur mesure est lui-même performant.
Il en va de même pour la sécurité. Un code spécifique n’est pas automatiquement plus sûr qu’une extension connue et régulièrement maintenue.
Enfin, contrairement à une idée parfois répandue, le sur-mesure doit lui aussi être maintenu. Le CMS évolue, PHP et les bibliothèques évoluent, les navigateurs évoluent et des vulnérabilités sont découvertes. Les mises à jour, sauvegardes et tests de compatibilité restent donc indispensables.
Page builder ou développement spécifique ?
Les page builders permettent à une équipe marketing ou éditoriale de produire rapidement des mises en page sans demander une intervention du développeur à chaque modification.
C’est un avantage réel, surtout lorsqu’un site comporte de nombreuses landing pages ou que sa mise en page doit évoluer souvent.
Il faut cependant évaluer chaque solution sur des critères concrets : poids des ressources, quantité de JavaScript, structure HTML, accessibilité, compatibilité avec le cache, responsive, maintenance et dépendance à l’outil.
Je préfère donc éviter les règles du type « un page builder produit X % de code en plus ». Le nombre de lignes de code ne permet pas de déterminer à lui seul si un site sera rapide ou bien référencé.
Ce qui importe est ce que reçoit réellement le navigateur et ce que vit réellement l’utilisateur.
Sur WordPress, il faut aussi comparer les page builders tiers à la solution native. Avec les block themes et le Site Editor, de nombreux sites peuvent désormais disposer d’une grande souplesse éditoriale sans ajouter un constructeur complet supplémentaire.
Comment mesurer réellement les performances ?
La performance d’un site doit être mesurée plutôt que supposée. Le simple fait d’utiliser un thème léger ou de développer un site sur mesure ne suffit pas pour garantir de bons résultats.
Les Core Web Vitals donnent trois indicateurs particulièrement utiles :
- LCP pour mesurer la vitesse d’affichage du contenu principal
- INP pour mesurer la réactivité aux interactions
- CLS pour mesurer la stabilité visuelle
Les objectifs généralement recherchés sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1.
Ces résultats dépendent de beaucoup plus de choses que du thème : hébergement, cache, images, polices, JavaScript, scripts marketing, extensions, requêtes réseau, base de données et qualité du développement.
Un projet sérieux devrait donc prévoir un budget de performance et mesurer ses pages importantes avant et après la mise en production.
Accessibilité : un critère à prévoir dès le départ
L’accessibilité ne doit plus être traitée comme une correction réalisée à la fin du projet.
Elle concerne aussi bien le design que le développement : contraste des couleurs, taille des zones interactives, navigation au clavier, structure des titres, formulaires, messages d’erreur, textes alternatifs, focus visible et HTML sémantique.
Ces éléments doivent idéalement être intégrés dès les maquettes et le design system, puis vérifiés pendant le développement et avant la mise en production.
Pour un projet e-commerce, cette question est particulièrement importante et doit également être vérifiée en fonction du périmètre réglementaire applicable à l’activité.
Sécurité : thème et sur-mesure doivent être maintenus
Il n’existe pas de choix technique qui permette d’éliminer le besoin de maintenance.
Un site WordPress ou PrestaShop doit être sauvegardé, surveillé et maintenu. Les mises à jour du CMS, du thème, des modules ou extensions et du code spécifique doivent être testées.
La sécurité consiste à réduire les risques plutôt qu’à imaginer un système parfaitement invulnérable. Utiliser des composants provenant de sources fiables, conserver les logiciels à jour et disposer d’une stratégie de sauvegarde et de restauration reste indispensable.
Pour un projet professionnel, j’ajouterais une règle simple : toute solution technique doit avoir un responsable clairement identifié pour sa maintenance future.
SEO : un thème ne fait pas le référencement à votre place
Un thème présenté comme « SEO friendly » n’est pas une stratégie de référencement.
Le référencement dépend notamment de la qualité des contenus, de l’intention de recherche, de l’architecture du site, du maillage interne, des titres, de l’indexabilité, des performances et de l’expérience proposée aux utilisateurs.
Le thème doit fournir une bonne base technique, avec un HTML propre, une hiérarchie cohérente et de bonnes performances. Mais il ne remplacera ni le travail éditorial ni la stratégie SEO.
Il faut donc éviter de choisir un thème uniquement parce que sa fiche commerciale promet un site parfaitement optimisé pour Google.
L’intelligence artificielle change-t-elle le choix entre thème et sur-mesure ?
L’intelligence artificielle accélère certaines étapes d’un projet web, mais elle ne supprime pas la nécessité de choisir une bonne architecture.
Pour la création de contenu, une IA peut aider à rechercher des angles, structurer un article, résumer un brief, préparer des variantes ou proposer une première meta description.
Elle peut également intervenir beaucoup plus tôt dans le projet. À partir d’un brief, il devient possible d’explorer rapidement plusieurs structures de pages, idées de contenus ou parcours avant de passer à la conception détaillée.
L’IA doit toutefois rester un assistant. Publier automatiquement de grandes quantités de contenus sans expertise, sans vérification et sans valeur ajoutée pour l’utilisateur n’est pas une stratégie SEO durable.
Pour le développement, les assistants de code basés sur l’IA peuvent générer une première implémentation, expliquer du code existant, créer des tests, proposer un refactoring ou participer à une revue de code.
Sur un projet WordPress ou PrestaShop, cela peut accélérer certaines tâches répétitives et permettre au développeur de consacrer davantage de temps à l’architecture, aux fonctionnalités métier, aux performances et à l’expérience utilisateur.
Mais un code généré automatiquement doit être traité comme le code produit par n’importe quel autre contributeur : il doit être relu, testé et validé avant d’être mis en production.
Il faut également éviter de transmettre à un outil d’IA des secrets, identifiants, données clients ou informations confidentielles sans avoir vérifié la manière dont les données sont traitées.
Figma et le workflow moderne entre design et développement
Le processus classique dans lequel le graphiste termine toutes ses maquettes puis les transmet au développeur existe toujours. Mais des outils comme Figma permettent aujourd’hui de travailler de façon beaucoup plus collaborative.
Dans Figma, un design system peut centraliser les couleurs, typographies, espacements, variables et composants du projet.
Le développeur peut ensuite inspecter les propriétés du design, mesurer les espacements, consulter les variables, exporter les ressources et récupérer les informations nécessaires à l’implémentation.
Cette approche permet de créer un véritable lien entre la maquette, le design system et les composants développés.
Dans un projet WordPress, les variables et composants définis dans Figma peuvent par exemple être traduits en tokens theme.json, styles globaux, patterns et blocs.
Dans un projet PrestaShop, la même logique permet de conserver une cohérence entre le système de design et les composants du thème.
Le bénéfice n’est pas seulement de gagner du temps. Cela évite aussi qu’un design system vive uniquement dans les maquettes alors que le site en production adopte progressivement d’autres règles.
Figma et l’IA ne remplacent donc pas le travail de conception. Ils permettent surtout d’accélérer les itérations et de rapprocher les différentes étapes du projet.
Faut-il envisager un WordPress ou PrestaShop headless ?
Une architecture headless sépare le CMS utilisé pour gérer les données et les contenus de l’application chargée de les afficher.
WordPress et PrestaShop disposent d’API permettant de construire des architectures dans lesquelles le CMS n’est plus directement responsable de l’affichage du front-end.
Le headless peut avoir du sens dans un écosystème complexe : application mobile, plusieurs front-ends, nombreux canaux de diffusion, besoins applicatifs très spécifiques ou architecture découplée.
En revanche, je ne recommande pas de passer en headless uniquement parce que cette architecture paraît plus moderne.
Elle ajoute une couche supplémentaire à développer et à maintenir. Il faut gérer le front-end, son hébergement, les déploiements, le cache, les prévisualisations, le tracking, les métadonnées SEO, le routage et la synchronisation avec le CMS.
Pour un site vitrine ou une boutique relativement classique, une architecture traditionnelle bien optimisée reste souvent plus simple à exploiter et à maintenir.
Comment choisir entre thème, personnalisation et sur-mesure ?
Plutôt que de chercher une réponse universelle, il est plus pertinent d’examiner les contraintes concrètes du projet. Quelques situations permettent déjà d’orienter la décision.
- Si votre besoin correspond largement à des gabarits classiques, un thème ou un block theme bien sélectionné peut suffire.
- Si votre budget initial est limité, une base existante avec une personnalisation ciblée permet de concentrer les investissements sur les éléments importants.
- Si le site doit être lancé rapidement, réutiliser une base éprouvée peut réduire considérablement le périmètre du projet.
- Si votre identité visuelle constitue un avantage concurrentiel, un design system et un thème fortement personnalisé ou sur mesure deviennent plus intéressants.
- Si vous avez des parcours ou interactions réellement atypiques, développer des composants spécifiques peut être plus pertinent que de contourner les limites d’un thème.
- Si le site contient de nombreuses règles métier, l’architecture fonctionnelle doit passer avant le choix graphique.
- Si vos équipes doivent créer régulièrement de nouvelles pages, l’autonomie éditoriale devient un critère majeur.
- Si les performances sont critiques, fixez des objectifs mesurables et testez-les plutôt que de supposer qu’une technologie sera naturellement rapide.
- Si le site doit alimenter plusieurs applications ou canaux, une architecture API ou headless peut mériter d’être étudiée.
- Si personne n’est identifié pour maintenir le site après sa mise en ligne, il est généralement préférable de réduire la complexité technique.
Dans de nombreux projets, la bonne réponse se situe finalement entre les deux extrêmes : une base fiable associée à du développement spécifique uniquement là où il apporte une véritable valeur.
Alors, thème ou sur-mesure pour WordPress et PrestaShop ?
Il n’existe pas de réponse universelle.
Si votre besoin est relativement standard, une base existante bien choisie peut vous faire économiser beaucoup de temps et de budget sans nécessairement sacrifier les performances, le SEO ou la qualité du site.
Si votre projet repose sur une identité forte, des parcours originaux, des fonctionnalités métier ou des intégrations complexes, le sur-mesure peut devenir beaucoup plus pertinent.
Et, dans de nombreux cas, la meilleure solution se trouve entre les deux : conserver une fondation fiable et développer uniquement ce qui fait réellement la différence.
C’est particulièrement vrai avec les outils actuels. WordPress permet de créer des block themes et des design systems avec le Site Editor et theme.json. PrestaShop dispose de bases de thèmes plus modernes. Figma rapproche le design et le code. L’intelligence artificielle peut accélérer la rédaction, le prototypage, le développement et les tests.
Mais ces outils ne remplacent pas les choix d’architecture, l’expérience, la maintenance et la validation humaine.
Mon conseil reste donc finalement assez proche de celui de la première version de cet article : commencez par définir ce que vous voulez réellement faire avec votre site. Ensuite seulement, choisissez les outils qui permettent d’y arriver avec le moins de complexité inutile.
Vous pouvez consulter mes réalisations pour voir différents exemples de projets et me contacter si vous souhaitez discuter de votre futur site WordPress ou PrestaShop.
