WordPress ou Ruby on Rails : lequel choisir pour votre projet ?
Je travaille avec les deux, alors on me pose souvent la question. La réponse courte : WordPress pour publier, Rails pour faire tourner une activité. La réponse longue tient en quelques critères.
Ce que chacun fait bien
WordPress est un outil de publication. Il est né pour les blogs et il est devenu excellent pour tout ce qui ressemble à des pages qu’on écrit, qu’on illustre et qu’on met à jour : site vitrine, site d’actualités, catalogue, boutique avec WooCommerce. Son atout principal, c’est son interface d’administration, que des millions de gens savent déjà utiliser, et son écosystème d’extensions.
Ruby on Rails est un framework pour construire des applications. Il n’y a pas d’interface d’administration toute faite ni de thème à choisir : on part d’une page blanche, mais avec des fondations solides pour tout ce qu’une application demande (comptes utilisateurs, base de données, tâches de fond, envoi d’e-mails, API). Shopify, GitHub ou Basecamp ont été construits avec.
La question qui tranche
Demandez-vous ce que les visiteurs viennent faire sur votre site.
S’ils viennent lire (vous découvrir, consulter vos services, acheter un produit dans un catalogue classique), WordPress fera l’affaire, plus vite et pour moins cher.
S’ils viennent travailler (déposer un dossier, suivre une commande, réserver selon des règles propres à votre métier, échanger avec d’autres utilisateurs), vous construisez une application. WordPress peut le faire à coups d’extensions, mais vous finirez par vous battre contre lui.
Quelques cas concrets
| Projet | Mon conseil |
|---|---|
| Site vitrine d’une entreprise, avec un blog | WordPress, ou un site statique si vous le modifiez rarement |
| Boutique en ligne avec un catalogue classique | WordPress et WooCommerce |
| Extranet où vos clients suivent leurs dossiers | Rails |
| Plateforme qui met en relation deux types d’utilisateurs | Rails |
| Catalogue alimenté automatiquement par un logiciel métier | Rails, ou WordPress si le volume reste modeste |
| Outil interne qui remplace des tableurs partagés | Rails |
Les signaux qu’on a choisi le mauvais outil
Côté WordPress : vous empilez quinze extensions pour obtenir un comportement métier, chacune ajoutant ses propres réglages et ses propres failles. Les mises à jour deviennent une source d’angoisse. Le développeur passe plus de temps à contourner l’existant qu’à construire.
Côté Rails : vous avez payé une application sur mesure pour un site de cinq pages que vous modifiez deux fois par an. Chaque changement de texte demande un développeur. C’est du gâchis.
Et le coût ?
À périmètre égal, un site WordPress coûte moins cher au départ, parce qu’une grande partie existe déjà. Une application Rails coûte plus à construire, mais elle fait exactement ce dont vous avez besoin, et rien d’autre. Sur plusieurs années, le calcul peut s’inverser : un WordPress transformé en application à force d’extensions coûte cher en maintenance et en contournements.
Les deux demandent un suivi. WordPress, pour les mises à jour de sécurité du cœur et des extensions. Rails, pour les montées de version du framework et des bibliothèques. Méfiez-vous de quiconque vous promet un site « sans maintenance ».
Le cas où l’on fait les deux
Ce n’est pas rare : un site WordPress pour la partie publique (présentation, blog, référencement), et une application Rails derrière pour l’espace client ou le back-office métier. Les deux communiquent par API. Chacun fait ce qu’il fait de mieux.
Pour décider
Si vous hésitez, décrivez-moi ce que vos utilisateurs doivent pouvoir faire, pas la technologie que vous imaginez. Le choix découle presque toujours de là, et je n’ai aucun intérêt à vous vendre l’un plutôt que l’autre.