Ruby on Rails 8 : Nouvelles Fonctionnalités et Guide de Migration 2026

Ruby on Rails 8 constitue la version la plus importante depuis Rails 7, avec des remplacements de Redis par des solutions basées sur la base de données, une authentification native et un pipeline de déploiement simplifié. Publiée en novembre 2024 et désormais mature avec la version Rails 8.1 en octobre 2025, cette mise à jour élimine les dépendances externes qui nécessitaient auparavant une infrastructure dédiée.

Le Solid Trifecta : Infrastructure Adossée à la Base de Données

Avant Rails 8, la plupart des applications en production dépendaient de Redis pour les tâches de fond, le cache et le pub/sub WebSocket. Le Solid Trifecta remplace ces trois composants par des adaptateurs qui s'appuient directement sur la base de données, compatible avec PostgreSQL, MySQL et SQLite.

Ce changement architectural réduit considérablement la complexité opérationnelle. Plus besoin de surveiller, dimensionner et maintenir une instance Redis. Le compromis concerne le débit : Redis reste plus rapide pour les scénarios à très haut volume, mais pour la grande majorité des applications, les adaptateurs basés sur la base de données offrent des performances largement suffisantes.

Solid Queue pour les Tâches de Fond

Solid Queue remplace Sidekiq, Resque ou Delayed Job par un backend Active Job adossé à la base de données. Il exploite FOR UPDATE SKIP LOCKED sur PostgreSQL 9.5+, MySQL 8.0+, et propose un fallback élégant sur SQLite.

# config/environments/production.rb
config.active_job.queue_adapter = :solid_queue

# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      processes: 2
      polling_interval: 0.1

Le plugin Puma démarre Solid Queue en parallèle du serveur web en développement, ce qui supprime la nécessité d'un processus séparé :

# config/puma.rb
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"] || Rails.env.development?

Solid Queue prend en charge les tâches récurrentes, les contrôles de concurrence et des fonctionnalités critiques comme la mise en pause et la reprise par file d'attente. Pour les applications traitant moins de 10 000 tâches par minute, la charge est absorbée sans difficulté.

Solid Cache et Solid Cable

Solid Cache stocke les caches de fragments HTML dans la base de données plutôt que dans Memcached ou Redis. Le stockage sur disque (SSD/NVMe) coûte une fraction du prix de la RAM, permettant des pools de cache plus importants avec une rétention plus longue. Basecamp exploite un cache Solid Cache de 10 To avec une rétention de 60 jours en production.

# config/environments/production.rb
config.cache_store = :solid_cache_store

Solid Cable remplace l'adaptateur pub/sub Redis pour Action Cable. Les messages WebSocket sont écrits dans une table de base de données et interrogés toutes les 100 ms par défaut. Le résultat est quasi temps réel pour la plupart des cas d'utilisation, avec une purge des messages après 24 heures.

# config/cable.yml
production:
  adapter: solid_cable
  polling_interval: 0.1
  keep_messages_around_for: 1.day

Générateur d'Authentification Intégré

Rails 8 intègre un générateur d'authentification natif qui produit un scaffolding complet : connexion par session, déconnexion et réinitialisation de mot de passe. Aucun gem externe n'est nécessaire pour l'authentification de base.

# Générer le scaffolding d'authentification
bin/rails generate authentication

Cette commande crée le modèle User, le modèle Session, le SessionsController, le PasswordsController et un concern Authentication. Le code généré utilise has_secure_password avec bcrypt et inclut une limitation de débit (10 tentatives de connexion par 3 minutes par IP).

# app/controllers/concerns/authentication.rb
module Authentication
  extend ActiveSupport::Concern

  included do
    before_action :require_authentication
    helper_method :authenticated?
  end

  private

  def require_authentication
    resume_session || request_authentication
  end

  def resume_session
    Current.session = find_session_by_cookie
  end

  def find_session_by_cookie
    Session.find_by(id: cookies.signed[:session_id]) if cookies.signed[:session_id]
  end

  def request_authentication
    session[:return_to_after_authenticating] = request.url
    redirect_to new_session_path
  end

  def authenticated?
    Current.session.present?
  end
end

Les réinitialisations de mot de passe utilisent des jetons signés et limités dans le temps, générés par has_secure_password, plutôt que des jetons stockés en base de données. Le générateur n'inclut volontairement ni l'inscription, ni la vérification d'email, ni la connexion sociale. Le code généré sert de fondation à étendre, pas de remplacement de Devise.

Gestion des Paramètres Plus Sûre avec params.expect

Rails 8 introduit params.expect, une alternative plus sûre au pattern params.require.permit. La nouvelle méthode lève une exception sur les clés manquantes au lieu de retourner silencieusement nil.

# Avant (Rails 7)
def user_params
  params.require(:user).permit(:name, :email, :role)
end

# Après (Rails 8)
def user_params
  params.expect(user: [:name, :email, :role])
end

La méthode expect vérifie que la clé :user existe et ne contient que les attributs autorisés. Si la clé est absente, elle lève immédiatement ActionController::ParameterMissing, évitant les bugs silencieux en aval.

Propshaft : Le Nouveau Pipeline d'Assets par Défaut

Propshaft remplace Sprockets comme pipeline d'assets par défaut. Là où Sprockets gérait la compilation, la minification et le fingerprinting dans un système monolithique unique, Propshaft se concentre exclusivement sur le service et le fingerprinting des assets statiques.

Pour le bundling JavaScript, Propshaft délègue aux outils modernes : esbuild, Vite ou Bun. Le traitement CSS passe par Tailwind CLI ou dart-sass. Le résultat est un pipeline plus rapide et plus prévisible, aligné avec l'outillage frontend actuel.

# Gemfile (Rails 8 par défaut)
gem "propshaft"

# Aucune configuration nécessaire pour l'utilisation de base
# Les assets dans app/assets sont servis et fingerprinted automatiquement

Les applications existantes utilisant Sprockets peuvent continuer à le faire. Le chemin de migration implique la suppression des directives spécifiques à Sprockets (//= require) et l'utilisation des import maps ou d'un bundler JavaScript.

Kamal 2 et Thruster : Déploiement Sans Interruption

Rails 8 est préconfiguré avec Kamal 2, un outil de déploiement qui transforme un serveur Linux vierge en serveur de production avec une seule commande. Kamal 2 remplace Traefik par Kamal Proxy, un reverse proxy conçu sur mesure.

# Déployer sur un serveur vierge
kamal setup

# Déploiements suivants
kamal deploy

Thruster se positionne entre Kamal Proxy et Puma, fournissant l'accélération X-Sendfile pour les téléchargements, la compression automatique des assets (gzip/brotli) et le support HTTP/2. Le Dockerfile généré par Rails 8 inclut Thruster par défaut.

# Extrait du Dockerfile généré par Rails 8
RUN gem install thruster
CMD ["thrust", "./bin/rails", "server"]

Cette stack (Kamal 2 + Kamal Proxy + Thruster + Puma) gère la terminaison SSL, les déploiements sans interruption et les redémarrages progressifs sans services externes comme Nginx ou HAProxy.

Support SQLite Amélioré pour la Production

Rails 8 améliore le support SQLite pour une utilisation en production. Le pooling de connexions, le mode WAL et une concurrence améliorée rendent SQLite viable pour les applications de petite à moyenne taille. Combiné avec le Solid Trifecta, une application Rails 8 mono-serveur peut fonctionner entièrement sur SQLite sans serveur de base de données externe.

# config/database.yml (configuration SQLite en production)
production:
  primary:
    adapter: sqlite3
    database: storage/production.sqlite3
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  cache:
    adapter: sqlite3
    database: storage/production_cache.sqlite3
  queue:
    adapter: sqlite3
    database: storage/production_queue.sqlite3
  cable:
    adapter: sqlite3
    database: storage/production_cable.sqlite3

Cette configuration fait tourner l'ensemble de la stack applicative depuis quatre fichiers SQLite. Kamal monte le répertoire storage comme un volume persistant, garantissant la survie des données lors des redémarrages de conteneurs.

Mise à Jour de Rails 7 vers Rails 8

Le chemin de migration de Rails 7.2 vers Rails 8.0 est simple si l'application traite déjà les avertissements de dépréciation. Les applications sur Rails 7.0 ou 7.1 devraient effectuer la mise à jour de façon incrémentale : 7.0 vers 7.1, puis 7.2, puis 8.0.

Étape 1 : Mettre à Jour les Dépendances

# Gemfile
gem "rails", "~> 8.0"

bundle update rails

Étape 2 : Exécuter la Tâche de Mise à Jour

bin/rails app:update

Cette commande met à jour les fichiers de configuration vers les valeurs par défaut de Rails 8. Il convient de revoir chaque changement attentivement via git diff. Les modifications clés incluent la nouvelle valeur par défaut de Regexp.timeout (1 seconde), le comportement mis à jour de db:migrate (chargement du schéma sur les bases fraîches) et la configuration Propshaft.

Étape 3 : Gérer la Réorganisation du Schéma

Rails 8 réordonne les colonnes de schema.rb pour correspondre à l'ordre réel des colonnes en base de données. Il est recommandé d'exécuter le dump du schéma immédiatement pour isoler ce diff cosmétique des vrais changements de migration :

bin/rails db:schema:dump
git add db/schema.rb
git commit -m "Reorder schema columns for Rails 8"

Étape 4 : Adopter les Nouvelles Fonctionnalités de Façon Incrémentale

Le Solid Trifecta, Propshaft et le générateur d'authentification sont opt-in pour les applications existantes. L'adoption se fait individuellement une fois la mise à jour principale stabilisée :

1. Remplacer l'adaptateur de tâches par Solid Queue
2. Basculer le cache store vers Solid Cache
3. Migrer Action Cable vers Solid Cable (si applicable)
4. Évaluer la migration vers Propshaft pour le pipeline d'assets

Étape 5 : Mettre à Jour la Gestion des Paramètres

Remplacer les appels params.require.permit par params.expect dans les contrôleurs. Ce changement est optionnel mais recommandé pour une validation des paramètres plus stricte.

Rails 8.1 : Tâches Continuables et CI Intégré

Rails 8.1, publié en octobre 2025, capitalise sur les fondations de Rails 8 avec deux fonctionnalités phares. Les tâches continuables (ActiveJob::Continuable) divisent les tâches longues en étapes reprises automatiquement. Si un serveur redémarre en cours d'importation, la tâche reprend exactement là où elle s'est arrêtée au lieu de repartir de zéro.

# app/jobs/import_records_job.rb
class ImportRecordsJob < ApplicationJob
  include ActiveJob::Continuable

  def perform(cursor:)
    records = Record.where("id > ?", cursor.value || 0).limit(1000)

    records.each do |record|
      process(record)
      cursor.advance(record.id)
    end
  end
end

Rails 8.1 introduit également une configuration CI intégrée et le rendu Markdown natif, réduisant encore davantage les dépendances externes.

Conclusion

• Le Solid Trifecta (Queue, Cache, Cable) élimine Redis comme dépendance obligatoire pour les tâches de fond, le cache et les WebSockets
• Le générateur d'authentification intégré fournit une base pour l'authentification par session sans gems tiers
• params.expect remplace params.require.permit avec une gestion des paramètres plus stricte et plus sûre
• Propshaft remplace Sprockets comme pipeline d'assets par défaut, déléguant le bundling aux outils modernes
• Kamal 2 et Thruster offrent un déploiement sans interruption sans Nginx ni Capistrano
• La mise à jour depuis Rails 7.2 est incrémentale : mettre à jour les dépendances, exécuter app:update, adopter les nouvelles fonctionnalités une par une
• Rails 8.1 ajoute les tâches continuables et le CI intégré pour les équipes cherchant à réduire les outils externes