# Pourquoi Ruby on Rails reste pertinent en 2022

> Rails n'est pas mort — loin de là. Retour sur les raisons pour lesquelles nous continuons à le recommander pour les projets web ambitieux.

Date : 10/11/2022
Auteurs : Aurélien N., Raphael P.
Tags : Ruby on Rails, Architecture, Backend

---

Ruby on Rails a dix-huit ans. Dans un écosystème où les frameworks naissent et meurent à un rythme effréné, cette longévité est en soi un argument. Mais la longévité ne suffit pas — il faut que le framework continue à résoudre les bons problèmes. Et après une dizaine de projets livrés en Rails ces trois dernières années, on pense que c'est le cas.

Cet article n'est pas un plaidoyer aveugle. On utilise React Native pour le mobile, Next.js quand le projet l'exige, des architectures serverless quand c'est pertinent. Mais quand un client nous demande "quel backend pour mon app ?", la réponse par défaut reste Rails. Voici pourquoi.

## Les fondamentaux n'ont pas vieilli

### Convention over configuration

Le principe fondateur de Rails — des conventions fortes plutôt qu'une configuration explicite — est plus pertinent que jamais. Quand on arrive sur un projet Rails qu'on n'a jamais vu, on sait où trouver les modèles, les contrôleurs, les routes, les migrations, les tests. La structure est la même partout. C'est un gain d'onboarding qu'on sous-estime tant qu'on n'a pas passé trois jours à comprendre l'arborescence d'un projet Express.js monté "from scratch".

Ce n'est pas de la rigidité — c'est un contrat. Le développeur qui rejoint le projet dans six mois ne perdra pas une semaine à comprendre "comment c'est organisé ici". Il sait déjà.

### La productivité n'est pas un gros mot

On entend parfois que la productivité de Rails est un argument de "petit projet", que ça ne tient pas sur du vrai logiciel. C'est faux, et ça trahit une confusion entre productivité et précipitation.

Un développeur Rails expérimenté génère un scaffold, écrit les validations métier, branche l'authentification avec Devise, pose les autorisations avec Pundit, configure Sidekiq pour les jobs asynchrones, et a un back-office ActiveAdmin fonctionnel — en une journée. Pas parce qu'il bâcle, mais parce que chaque brique est pensée pour s'emboîter sans friction.

Chez imagine-app, on a livré un MVP complet — authentification, CRUD, back-office, envoi d'emails transactionnels, déploiement Heroku — en deux semaines pour un client du secteur immobilier. Avec un framework où il faut choisir son ORM, son routeur, son système de validation, son moteur de templates, et les câbler ensemble, on y serait encore.

### ActiveRecord — l'ORM qui assume ses choix

ActiveRecord est opinionated. Il couple le modèle à la base, il utilise des conventions de nommage strictes, il encourage les callbacks. Certains développeurs détestent ça — ils préfèrent des ORMs plus "purs" comme Sequelize ou TypeORM, qui séparent proprement les couches.

On comprend l'argument théorique. En pratique, ActiveRecord permet d'écrire des modèles lisibles et expressifs :

```ruby
class Reservation < ApplicationRecord
  belongs_to :user
  belongs_to :slot

  validates :date, presence: true
  validates :slot, uniqueness: 

  scope :upcoming, -> 
  scope :confirmed, -> 

  after_create :notify_admin
  after_confirm :send_confirmation_email
end
```

On lit ce fichier et on comprend le métier. Pas besoin de chercher dans trois fichiers différents comment la réservation est persistée, validée et liée aux autres entités. Tout est là, déclaratif, en vingt lignes.

Et les migrations ? Un `rails generate migration AddPhoneToUsers phone:string` et c'est fait. Versionné, réversible, partagé avec l'équipe via Git. On a travaillé sur des projets Node.js où les migrations étaient des scripts SQL à la main — en 2022, ce n'est pas acceptable.

## Un écosystème mature et stable

### Les gems qui comptent

L'écosystème Ruby a un avantage décisif : la maturité. Les gems qu'on utilise au quotidien ne sont pas des projets de weekend — ce sont des bibliothèques maintenues depuis des années, utilisées par des milliers d'applications en production.

**Devise** pour l'authentification. On peut débattre de son architecture interne, mais en pratique : on l'installe, on configure les modules (confirmable, lockable, trackable…), et l'authentification est réglée. OAuth avec OmniAuth, 2FA avec devise-two-factor — tout s'emboîte.

**Pundit** pour les autorisations. Des policies simples, testables, qui vivent à côté des modèles. Pas de DSL complexe, pas de rôles magiques — juste des classes Ruby avec des méthodes qui retournent true ou false.

**Sidekiq** pour les jobs asynchrones. Redis-backed, rapide, avec un dashboard intégré. On lance un job d'envoi d'email, de génération de PDF, de synchronisation API — et on sait qu'il sera exécuté, retried en cas d'échec, et loggé.

**ActiveAdmin** pour le back-office. On en a déjà parlé dans notre article sur le [backend de Simone.paris](/blog/simone-paris-rails-backend-app-ios) — un DSL déclaratif qui génère un back-office complet avec filtres, export CSV, dashboards. Pour la plupart des projets, ça suffit largement et ça évite de coder un admin from scratch.

La stabilité de ces gems est cruciale. On maintient des applications Rails en production depuis quatre ou cinq ans. Les mises à jour mineures passent sans casse. Les mises à jour majeures sont documentées, avec des guides de migration. C'est le genre de confiance qu'on ne trouve pas dans l'écosystème npm, où une mise à jour de dépendance peut casser la moitié du projet.

### Le testing intégré

Rails a intégré le testing dans sa culture dès le premier jour. `rails generate model` crée le fichier de test en même temps que le modèle. Les fixtures, les factories (avec FactoryBot), les tests d'intégration — tout est prévu.

On utilise RSpec sur tous nos projets, avec Shoulda Matchers pour les validations, VCR pour enregistrer les réponses d'APIs tierces, et Capybara pour les tests d'intégration quand c'est nécessaire. La suite de tests d'un projet moyen tourne en moins de deux minutes — assez rapide pour tourner en CI sur chaque push.

Ce n'est pas que les autres frameworks ne permettent pas de tester. C'est que Rails rend le testing si naturel que ne pas tester demande un effort conscient. Et sur des projets maintenus pendant des années, cette culture du test fait toute la différence.

## Passer à l'échelle

### Le mythe de la scalabilité

L'argument le plus fréquent contre Rails, c'est "ça ne scale pas". On l'entend depuis 2008. Et pourtant :

- **Shopify** traite des milliards de dollars de transactions par an sur Rails
- **GitHub** héberge plus de 80 millions de dépôts sur Rails
- **Basecamp** et **Hey** (lancé en 2020) servent des centaines de milliers d'utilisateurs sur Rails
- **Airbnb** a construit toute sa plateforme initiale sur Rails

"Rails ne scale pas" est un raccourci pour "je n'ai pas appris à optimiser une application Rails". Les vrais bottlenecks sont rarement le framework — ce sont les requêtes N+1, l'absence de cache, les jobs synchrones qui devraient être asynchrones, les index manquants en base.

Un développeur senior Rails sait poser un `includes` pour éviter le N+1, configurer le cache fragment, brancher un CDN, mettre les tâches lourdes dans Sidekiq. Ces optimisations sont documentées, outillées (Bullet, rack-mini-profiler, New Relic), et on les applique sur chaque projet qu'on accompagne.

### Rails 7 — un vrai renouveau

Rails 7, sorti en décembre 2021, est la release la plus significative depuis Rails 5. Elle confirme une direction claire : simplifier le stack frontend sans sacrifier l'expérience utilisateur.

**Import maps** remplacent Webpack comme bundler par défaut. Plus de `node_modules`, plus de configuration Webpack, plus de temps de build de 45 secondes. On écrit du JavaScript moderne, le navigateur charge les modules directement. Pour les projets qui n'ont pas besoin de React, c'est une libération.

**Hotwire** (Turbo + Stimulus) devient le stack frontend officiel. Turbo Drive remplace les navigations classiques par des requêtes fetch transparentes. Turbo Frames permettent de mettre à jour des fragments de page sans recharger. Turbo Streams poussent des mises à jour en temps réel via WebSocket. Le tout sans écrire une ligne de JavaScript custom pour les cas courants.

On a utilisé Hotwire sur un projet de gestion interne cette année. Des listes filtrables en temps réel, des formulaires inline, des notifications push — le tout sans bundle JavaScript, sans API REST dédiée, sans state management côté client. Le code est plus simple, plus lisible, et plus facile à maintenir. Pour les projets où le "single-page app" est du over-engineering, Hotwire est la réponse que Rails attendait.

**Encrypted credentials** simplifient la gestion des secrets. Un fichier chiffré versionné dans Git, une master key en variable d'environnement. Plus de fichiers `.env` qui traînent, plus de secrets en clair dans les dépôts.

## Ce que Rails ne fait pas (et c'est normal)

On n'est pas dogmatiques. Il y a des cas où Rails n'est pas le bon choix :

**Les apps mobiles.** Rails est un backend. Pour le mobile, on utilise React Native — et Rails expose une API JSON classique ou GraphQL. Les deux se marient très bien, comme on l'a montré sur le projet [Simone.paris](/blog/simone-paris-rails-backend-app-ios).

**Les interfaces très interactives.** Un éditeur collaboratif en temps réel, un outil de design, un dashboard avec des dizaines de widgets interconnectés — pour ça, un framework frontend dédié (React, Vue) est justifié. Rails + Hotwire couvre 80% des besoins, mais les 20% restants existent.

**Le calcul intensif.** Ruby n'est pas le langage le plus rapide. Pour du traitement d'images en masse, du machine learning, de l'analyse de données lourde, on ira chercher Python ou Go. Mais ces cas sont rarement le cœur d'une application web — ce sont des services spécialisés qu'on peut brancher à côté.

**Les architectures microservices massives.** Si l'équipe fait 50 développeurs et qu'on a besoin de 30 services indépendants, Rails monolithe n'est probablement pas la bonne base. Mais combien de projets sont vraiment dans ce cas ? La plupart des startups et PME qu'on accompagne ont entre 2 et 8 développeurs. Pour elles, le monolithe Rails est un atout, pas une contrainte.

## En résumé

Après dix ans de projets, notre position est simple : Rails est le meilleur compromis entre productivité, maintenabilité et pérennité pour la majorité des applications web.

Ce n'est pas le framework le plus hype. Ce n'est pas celui qui impressionne dans les conférences tech. Mais c'est celui qui permet de livrer un produit fiable, de le maintenir pendant des années sans dette technique insurmontable, et de transmettre le projet à une autre équipe sans mode d'emploi de 50 pages.

On a vu des projets Next.js livrés en six mois et impossibles à maintenir au bout de deux ans — parce que l'équipe initiale avait câblé 40 dépendances npm qui n'étaient plus maintenues. On a vu des projets Express.js où chaque développeur avait réinventé sa propre architecture. On n'a jamais vu un projet Rails bien structuré devenir inmaintenable.

Et c'est peut-être ça, le vrai argument : on choisit pas un framework pour le premier mois, on le choisit pour les cinq ans qui suivent.

---

_Nos autres retours d'expérience sur Rails : [le backend de Simone.paris](/blog/simone-paris-rails-backend-app-ios), [l'architecture du baby-foot connecté Tekbak](/blog/architecture-rails-baby-foot-connecte), et pour un cas où on a choisi un autre stack : [GraphQL et serverless chez Cajoo](/blog/graphql-hasura-cajoo-quick-commerce)._