WordPress ou Strapi, quelle API pour votre projet web ?

Quand un client me contacte à Pau pour la création de son site internet, la question de la technologie revient toujours : WordPress ou Strapi ? Ces deux outils exposent vos données via une API, mais leur philosophie est très différente. WordPress propose une API REST native et peut intégrer GraphQL via un plugin. Strapi est un CMS headless conçu dès le départ pour les architectures découplées. Voici comment je les compare, à partir de mes projets WordPress pour des clients du Béarn et de mes tests de Strapi.

L’API REST de WordPress
suffit à la plupart des projets

WordPress intègre une API REST depuis la version 4.7. Elle expose tous vos contenus (articles, pages, médias, types personnalisés) via des endpoints JSON standardisés. Pour la grande majorité des projets de création de site internet sur mesure que je réalise à Pau, c’est largement suffisant.

Ce que j’utilise au quotidien sur les sites WordPress que je développe :

• GET /wp-json/wp/v2/posts : liste des articles publiés
• GET /wp-json/wp/v2/pages/{id}?context=edit : contenu brut d’une page
• POST /wp-json/wp/v2/pages/{id} : mise à jour du contenu via un script
• PUT /wp-json/seopress/v1/posts/{id}/title-description-metas : optimisation SEO via SEOPress Pro

L’API REST WordPress présente un avantage décisif pour les projets de site internet : elle est disponible sans configuration dès l’installation. SEOPress, WooCommerce et la plupart des plugins premium exposent leurs propres extensions d’API REST. Vous intégrez ainsi des données e-commerce, de référencement ou de formulaires sans développement supplémentaire.

Sa limite réelle : le problème de sur-récupération (over-fetching). Un appel à /wp-json/wp/v2/posts retourne des dizaines de champs que vous n’utilisez peut-être pas. Sur un site à fort trafic, ça se ressent en performance. C’est là qu’entre en jeu GraphQL.

Quand utiliser GraphQL
avec WordPress ?

GraphQL résout exactement le problème d’over-fetching. Avec une requête GraphQL, vous demandez précisément les champs dont vous avez besoin, ni plus ni moins. Le plugin WPGraphQL transforme n’importe quel site WordPress en serveur GraphQL pleinement fonctionnel.

J’ai utilisé WPGraphQL sur un projet de site internet sur mesure avec un front-end Next.js. Les temps de chargement ont chuté de 40 % par rapport à l’équivalent en REST, simplement parce qu’on ne transportait plus de données inutiles entre le serveur WordPress et le front-end React.

Mais WPGraphQL a un coût : la complexité. Pour un site vitrine WordPress standard à Pau, mettre en place un front-end découplé avec GraphQL représente un surcoût de développement rarement justifié. GraphQL a du sens uniquement quand :

• Votre front-end est développé en React, Vue ou Next.js
• Vous avez plusieurs types de contenus imbriqués à requêter en une seule requête
• Votre site internet reçoit un trafic important qui justifie l’optimisation des payload JSON
• Votre équipe technique est à l’aise avec le schéma GraphQL et les resolvers

Pour la grande majorité des sites que je réalise dans les Pyrénées-Atlantiques, l’API REST WordPress reste la solution la plus rapide à mettre en œuvre et la plus simple à maintenir sur la durée.

Strapi,
pour quel type de projet ?

Strapi est un CMS headless open source développé en Node.js. Il génère une API REST dès l’installation, et une API GraphQL avec son plugin officiel. Vous modélisez vos types de contenus depuis une interface d’administration, et Strapi génère automatiquement les endpoints correspondants.

Je l’ai testé en détail sur la version 5, installation, modélisation et API comprises : tout est dans mon guide Strapi pour développeurs. Voici ce que j’en retiens face à WordPress.

Ce que Strapi fait mieux que WordPress :

• API REST générée automatiquement, GraphQL en un plugin officiel
• Modélisation de contenus entièrement libre, sans les contraintes du schéma WordPress
• Meilleures performances sur les requêtes de données complexes et imbriquées
• Moins de surface d’attaque : moins de plugins tiers qu’un WordPress classique, mais des dépendances npm à tenir à jour

Ce qui rend Strapi inadapté pour un site internet vitrine standard :

• Hébergement plus complexe : Node.js, PM2 ou Docker. Un hébergement mutualisé OVH ne suffit pas
• Pas d’éditeur visuel comme Gutenberg : la rédaction est moins intuitive pour le client
• L’écosystème WordPress n’existe pas : SEO, e-commerce WooCommerce, formulaires, tout doit être développé ou intégré à la main
• Coût de maintenance plus élevé sur le long terme, notamment pour les mises à jour majeures

WordPress ou Strapi,
le comparatif

Pour vous aider à choisir, voici comment je positionne les deux technologies selon le type de projet :

💡 Faites glisser le tableau vers la droite pour voir plus de colonnes

Mon avis

Pour la très grande majorité des projets de création de site internet à Pau et dans le Béarn, je recommande WordPress avec son API REST native. C’est la technologie que je maîtrise le mieux après 11 ans de développement web, c’est celle qui offre le meilleur ratio performance/coût de maintenance, et c’est celle qui vous donne le plus d’autonomie pour gérer votre site internet sans dépendre d’un développeur.

Je passe à Strapi uniquement quand le projet l’exige vraiment : application mobile avec plusieurs front-ends, architecture multi-site, ou besoins de modélisation de données qui dépassent ce que WordPress peut faire proprement. C’est rare, et ça se justifie toujours par un besoin technique précis, jamais par la mode.

Si vous hésitez sur la technologie pour votre projet de site internet à Pau, parlons-en. En 30 minutes, j’identifie la stack adaptée à votre activité, votre budget et vos objectifs dans les Pyrénées-Atlantiques.