En 2017, une cliente m'a appelé en panique. Elle avait construit le site de son magasin de fleurs sur le constructeur de sites de GoDaddy, ça lui avait pris un weekend, c'était correct sur mobile, et elle en était fière. Ensuite elle a voulu ajouter un simple calendrier d'événements. Juste un calendrier. GoDaddy ne pouvait pas le faire. Pas sans un contournement tellement moche qu'un développeur junior en aurait eu honte. Elle a fini par me payer pour migrer le tout vers WordPress, et je me souviens m'être dit : pourquoi les gens commencent-ils ici d'abord ?
Point clé : le constructeur de GoDaddy sacrifie la flexibilité pour la simplicité plus que ses concurrents ; WordPress, Webflow et Squarespace offrent tous plus de possibilités à un coût comparable.
Je comprends, honnêtement. Le pitch de GoDaddy est séduisant. Inscrivez-vous, choisissez un modèle, tapez le nom de votre entreprise, lancez-vous avant midi. Pour quelqu'un qui n'a jamais touché à un CMS, cette vitesse ressemble à un superpower. Mais c'est du temps emprunté. Et après avoir créé bien plus de 12 000 sites chez Seahawk, j'ai perdu le compte du nombre de migrations GoDaddy que j'ai faites pour des clients qui en ont dépassé les limites plus vite qu'ils ne s'y attendaient.
Donc laissez-moi vous dire vers quoi j'ai réellement migré les clients (et moi-même), et pourquoi.
---
Le problème du constructeur GoDaddy n'est pas la vitesse, ce sont les limites
Le constructeur de site web de GoDaddy est vraiment rapide à mettre en place. Je ne vais pas prétendre le contraire. GoDaddy Airo, leur couche IA, peut créer un site de marque avec un logo et des modèles de campagne email avant que vous ayez fini votre café. L'éditeur est épuré, intuitif, et non menaçant pour les gens qui ne savent pas ce qu'est une div et ne veulent pas l'apprendre.
Mais.
Vous ne pouvez pas déplacer les sections librement. Vous ne pouvez pas éditer le HTML ou le CSS. Vous ne pouvez pas modifier les mises en page au-delà des options préconfigurées. Et vous ne pouvez certainement pas installer un plugin qui n'existe pas dans leur écosystème fermé. Comme l'exprime bluntement un examen approfondie du constructeur, la commodité de la configuration est réelle, mais dès que vous voulez quelque chose au-delà des bases du design, vous heurtez un mur.
Ce mur est le problème. Pas le générateur lui-même.
J'avais un client, une clinique de physiothérapie à Bristol, qui était sur GoDaddy depuis trois ans. Un site beau. Ensuite ils ont voulu des réservations en ligne avec des formulaires d'admission, l'intégration avec leur logiciel de gestion de cabinet, et un espace membres pour des bibliothèques de vidéos d'exercices. On a passé deux heures à auditer ce que GoDaddy pouvait supporter nativement. La réponse était essentiellement rien de cette liste. Trois ans de contenu, et ils devaient repartir de zéro architecturalement.
Ce n'est pas une histoire d'avertissement sur GoDaddy spécifiquement. C'est une histoire d'avertissement sur le choix des plateformes en fonction de la vitesse à laquelle vous pouvez commencer plutôt que de la distance à laquelle vous pouvez aller.
---
WordPress : Toujours le choix par défaut raisonnable pour la plupart
On déclare WordPress mort depuis pratiquement une décennie. Il alimente toujours environ 40 % du web entier. Ce n'est pas de l'inertie, c'est un effet de réseau à une échelle que rien n'a réussi à déloger.
Pourquoi je le recommande toujours
L'écosystème de plugins à lui seul vaut le prix d'admission (qui, soyons honnêtes, est gratuit). 60 000+ plugins signifient que pratiquement n'importe quelle fonctionnalité que vous pouvez imaginer a déjà été construite par quelqu'un, testée en production par des milliers de sites, et documentée à mort sur YouTube. WooCommerce pour le commerce électronique. ACF pour les champs personnalisés. Yoast ou Rank Math pour le SEO. La pile est ennuyeuse et c'est véritablement un compliment.
Pour les agences, le vivier de talents compte aussi. Je peux embaucher un développeur WordPress à Londres, Lagos ou Ljubljana et avoir une confiance raisonnable qu'il sait ce qu'est un type de publication personnalisé. Essayez ça avec un constructeur propriétaire.
Les réserves de WordPress dont je suis honnête
Ce n'est pas parfait. Les conflits de plugins sont réels. Maintenir 40 plugins à jour sans casser quelque chose est, comme l'a dit un commentateur de Hacker News, « faire du babysitting MySQL ». La sécurité est une préoccupation véritable quand vous exécutez une ancienne version d'un plugin mal maintenu. Et l'éditeur de blocs (Gutenberg) divise encore les opinions de façon presque théologique.
Mais pour un client qui a besoin d'une véritable flexibilité, la propriété du contenu, et un site qui peut évoluer avec lui ? WordPress reste ma première recommandation à moins que le cahier des charges ne pointe spécifiquement ailleurs.
---
WordPress Headless et Jamstack : Quand le cahier des charges pointe ailleurs
Il y a environ trois ans, Seahawk a commencé à recevoir plus de briefs où la « performance » était une exigence stricte, pas un « plus ». Des temps de chargement rapides. Des scores Core Web Vitals élevés. Du contenu servie sur plusieurs surfaces, web, app, peut-être un écran dans un environnement de vente au détail. L'hébergement WordPress traditionnel n'allait pas suffire.
C'est à ce moment-là que nous avons davantage misé sur l'architecture headless.
Ce que Headless signifie réellement (sans le jargon)
WordPress headless signifie que vous conservez WordPress comme backend, le référentiel de contenu, l'interface admin où votre client se connecte, mais vous découpler entièrement le frontend. La « tête » (ce que les utilisateurs voient) est construite dans un framework JavaScript comme Next.js ou Astro. WordPress sert du contenu via son API REST ou GraphQL. Le frontend récupère ces données et les affiche comme il le souhaite.
Le résultat : des chargements de page ultra-rapides, pas de goulot d'étranglement de rendu PHP, et une liberté totale sur votre architecture frontend. La sécurité s'améliore également car l'admin WordPress n'est pas exposé publiquement de la même manière.
Le paysage des CMS Jamstack
Si vous allez full Jamstack, vous n'avez même pas besoin d'utiliser WordPress comme backend. Il existe un champ solide et croissant d'options CMS headless construites spécifiquement pour cette architecture. Quelques-unes que j'ai utilisées en production :
- Contentful, mature, bien documentée, légèrement chère à grande échelle mais extrêmement fiable
- Sanity, modélisation de contenu extrêmement flexible, excellente DX, collaboration en temps réel pour les équipes éditoriales
- Storyblok, l'éditeur visuel est véritablement impressionnant pour les clients non-techniques qui veulent voir les changements en temps réel
- Strapi, open-source, auto-hébergeable, basé sur Node.js, idéal si vous voulez réduire les coûts d'infrastructure
- Directus, sous-estimé, particulièrement pour les projets riches en données qui ont besoin d'une véritable couche d'abstraction de base de données
Aucune de ces solutions n'est parfaite pour chaque projet. L'éditeur visuel de Storyblok est un plaisir pour les éditeurs mais il ajoute de la complexité côté développeur. Le langage de requête GROQ de Sanity a une courbe d'apprentissage. Choisissez en fonction du projet réel, pas du battage médiatique.
---
EmDash : Le nouveau venu qui mérite qu'on le surveille (avec des réserves)
Quelque chose d'intéressant est sorti en avril 2026.EmDash est un nouveau CMS soutenu par Cloudflare, se positionnant comme un successeur spirituel de WordPress, construit sur des technologies web modernes, avec isolation des plugins via Cloudflare Workers, et le contenu stocké sous forme de données structurées naturellement lisibles par les outils IA.
Le discours est vraiment intéressant. WordPress s'exécute sur PHP, ce qui fonctionne mais n'est pas exactement ce que vous concevriez de zéro en 2026. EmDash est construit pour le déploiement edge-native, le contenu structuré, et un monde où les assistants IA sont de plus en plus la façon dont les gens trouvent l'information.
Je n'ai pas encore déployé EmDash en production. Il a été lancé en bêta et je le surveille. Il y a des préoccupations réelles à noter :
- L'écosystème est tout nouveau. 60 000 plugins WordPress contre... pas ça. Encore.
- La fonctionnalité d'isolation des plugins ne fonctionne que sur le runtime Cloudflare, ce qui va bien si vous êtes engagé dans cette infrastructure, mais c'est limité si vous ne l'êtes pas.
- C'est un produit bêta. Risque inhérent. Je ne mets pas les bêtas devant les clients qui ont besoin de stabilité.
Le consensus honnête des gens qui l'ont testé est : techniquement impressionnant, pratiquement incomplet. À revoir dans 12-18 mois. Je ferai exactement ça.
---
Comment choisir réellement entre ces options
Voilà le truc, la plupart des contenus « quel CMS est le meilleur » en ligne traitent ça comme une comparaison de fiches techniques. Des cases à cocher. Des matrices de fonctionnalités. Ce n'est pas comme ça que vous choisissez une plateforme pour un vrai projet.
Voici comment j'aborde réellement la question :
- Demandez ce dont le client aura besoin dans 18 mois, pas aujourd'hui. Si c'est une petite fleuriste indépendante, WordPress sur un hébergement géré convient probablement. Si c'est une startup financée par du capital-risque s'attendant à une croissance 10x du trafic, préparez l'architecture dès maintenant.
- Demandez qui la maintiendra après le lancement. Une architecture headless Jamstack est brillante jusqu'à ce que le directeur marketing de 58 ans du client doive mettre à jour un article de blog. Alors c'est un ticket de support qui attend de se produire. Alignez la complexité technique à l'équipe.
- Demandez si le contenu va à plus d'un endroit. Plusieurs frontends (web + app + je ne sais quoi) pointent presque toujours vers une approche headless.
- Interrogez-vous sur les intégrations.CRM, systèmes de réservation, processeurs de paiement, analytique, cartographiez ceux-ci avant de vous engager sur une plateforme, pas après.
- Posez des questions sur le budget pour la maintenance continue. Une instance Strapi auto-hébergée nécessite quelqu'un qui maintienne la version de Node.js à jour. Cela coûte du temps ou de l'argent. Intégrez-le à vos calculs.
---
La réalité de la migration dont personne ne parle
Quitter GoDaddy (ou n'importe quel constructeur propriétaire) n'est pas trivial. Le contenu est généralement exportable sous une certaine forme, mais la structure souvent ne l'est pas. GoDaddy ne vous donne pas d'exports de base de données propres ou d'API de contenu. Vous pratiquez généralement du scraping, du copier-coller, ou vous utilisez des outils de migration tiers qui font environ 70% du travail et vous laissent nettoyer le reste manuellement.
J'en ai migré assez pour avoir un processus, mais je ne prétends pas que c'est élégant. Budgétez du temps réel pour ça. Et vérifiez absolument que votre transfert de domaine hors de GoDaddy est géré avec soin, ils ont un historique de rendre ce processus plus frictionnel qu'il ne devrait l'être.
La bonne nouvelle : une fois que vous êtes dehors, vous êtes dehors. Les clients qui migrent vers WordPress ou un CMS headless ne reviennent presque jamais.
---
FAQ
Le constructeur de site web de GoDaddy est-il bon pour quelque chose ?
Honnêtement, oui, pour des cas d'usage très spécifiques. Un site d'une page pour un artisan local qui a juste besoin d'une présence en ligne et d'un numéro de téléphone. Une page de destination temporaire. Quelque chose qu'une personne non-technique doit avoir en ligne en quelques heures et qu'elle ne devra jamais modifier de manière significative. Pour ces cas, la vitesse de mise en place est un vrai avantage. Pour tout ce qui a des ambitions de croissance, ça atteint rapidement ses limites.
Dois-je savoir coder pour passer à WordPress ?
Pas nécessairement. L'hébergement WordPress géré par des fournisseurs comme Kinsta, WP Engine, ou même Hostinger rend l'aspect opérationnel beaucoup plus abordable. Vous voudrez quand même avoir une certaine aisance avec l'interface d'administration et idéalement quelqu'un que vous pouvez appeler quand les choses se cassent. Mais de nombreux petits propriétaires d'entreprise gèrent des sites WordPress sans toucher une seule ligne de code.
Quelle est la différence entre un CMS headless et un CMS ordinaire ?
Un CMS traditionnel (comme WordPress classique) gère à la fois le stockage du contenu et le rendu de la page, c'est un système couplé. Un CMS headless gère uniquement le stockage du contenu et l'expose via une API. Votre frontend, construit dans le framework que vous préférez, récupère ce contenu et décide comment l'afficher. L'avantage est la flexibilité et la performance. L'inconvénient est que vous avez besoin d'un développeur frontend, pas seulement d'un créateur de site.
EmDash est-il prêt pour une utilisation en production ?
Non, pour la plupart des entreprises, à mon avis. Il a été lancé en bêta en avril 2026 et l'écosystème est véritablement naissant. L'architecture sous-jacente est intéressante et le soutien de Cloudflare lui donne de la crédibilité. Mais je ne mettrais pas le site marketing principal d'un client sur un CMS en bêta quand WordPress et des alternatives headless éprouvées existent. Suivez l'évolution en 2027.
Puis-je utiliser WordPress comme CMS headless ?
Oui, et c'est en fait un très bon compromis pragmatique. WordPress dispose d'une API REST intégrée et WPGraphQL est un plugin mature qui expose votre contenu via GraphQL. Vous obtenez ainsi l'interface d'administration familière que vos clients connaissent déjà, l'énorme écosystème de plugins, mais vous construisez votre frontend dans Next.js ou Astro et bénéficiez des avantages de performance d'une configuration Jamstack moderne. Nous avons livré plusieurs projets de cette façon chez Seahawk et cela fonctionne bien.
---
La fleuriste de 2017 est toujours cliente, pour ce que ça vaut. Elle est sur WordPress maintenant, avec un vrai plugin de réservation et un calendrier d'événements qui fonctionne réellement. Elle ne m'a pas appelé en panique depuis. C'est l'objectif, vraiment, construire quelque chose qui cesse d'être un problème pour que les gens puissent se concentrer sur leur vrai travail.
Choisissez l'ennuyeux. Choisissez la flexibilité. Choisissez ce que vous pouvez confier.