Rails 8 est sorti, et derrière le numéro de version se cache un changement de philosophie qui parle directement aux propriétaires d'applications, pas seulement aux développeurs. Le fil conducteur de cette version tient en une idée : moins de pièces mobiles. Là où une application Rails moderne empilait ces dernières années une demi-douzaine de services externes, Rails 8 en réintègre l'essentiel dans le framework. Concrètement, cela veut dire une facture d'hébergement plus légère, une application plus simple à maintenir, et un socle sur lequel n'importe quel développeur Rails saura intervenir demain. Voici ce qui change vraiment.

La « Solid trifecta » : adieu Redis

C'est l'apport le plus concret de Rails 8. Pendant des années, une application Rails un peu sérieuse avait besoin de Redis — un serveur supplémentaire, en mémoire, pour gérer les tâches de fond, le cache et les fonctionnalités temps réel. Redis fonctionne très bien, mais c'est une brique de plus : à installer, sécuriser, sauvegarder, surveiller et facturer. Rails 8 la rend, dans la majorité des cas, superflue grâce à trois composants livrés par défaut, la Solid trifecta.

Solid Queue gère les tâches de fond (envoi d'emails, génération de PDF, appels à des API externes) en s'appuyant sur votre base de données existante, sans Redis. Solid Cache fait de même pour le cache : il stocke les fragments de page et les résultats de calcul directement dans la base, ce qui permet au passage de garder un cache bien plus volumineux qu'en mémoire vive, pour un coût dérisoire. Solid Cable, enfin, alimente les fonctionnalités temps réel — notifications qui apparaissent sans recharger la page, mises à jour en direct — toujours sans dépendance externe.

Le bénéfice pour un dirigeant est simple à formuler : un serveur de moins à héberger et à maintenir. Une pièce mobile qui ne peut plus tomber en panne un dimanche soir, une ligne de moins sur la facture d'infrastructure, et une application dont l'architecture tient désormais sur votre seule base de données. Moins il y a de composants, moins il y a de choses qui cassent.

Un déploiement enfin apprivoisé

Mettre une application Rails en production a longtemps été un art réservé aux initiés, ou une raison de payer cher des plateformes clés en main. Rails 8 intègre Kamal, un outil de déploiement qui installe votre application sur n'importe quel serveur — un VPS à quelques euros par mois, votre propre machine, ou plusieurs à la fois — avec une seule commande. Il gère les conteneurs, les mises en ligne sans coupure et les retours en arrière si quelque chose tourne mal.

À ses côtés, Thruster prend en charge des tâches habituellement déléguées à des serveurs frontaux séparés : compression, mise en cache des fichiers statiques, certificats HTTPS automatiques. Là encore, la logique est la même — internaliser ce qui exigeait auparavant des outils tiers. Pour le propriétaire d'une application, cela ouvre la porte à des hébergements bien moins chers que les plateformes managées, sans sacrifier la simplicité ni la fiabilité de mise en ligne.

Une authentification intégrée, sans usine à gaz

Presque toutes les applications ont besoin de comptes utilisateurs : inscription, connexion, mot de passe oublié. Historiquement, cela passait par des librairies externes puissantes mais lourdes, souvent surdimensionnées pour le besoin réel. Rails 8 propose désormais un générateur d'authentification natif : une base de connexion propre, sécurisée et sans dépendance, que l'on fait apparaître en une commande.

Ce n'est pas censé remplacer les solutions les plus complètes dans tous les cas, mais pour l'immense majorité des applications, c'est suffisant, plus léger et plus facile à faire évoluer. Une dépendance de moins, encore, et un code que votre prestataire n'a pas besoin d'aller déchiffrer dans une librairie tierce.

Faut-il migrer, et quand ?

Soyons honnêtes : si votre application tourne bien sur une version récente de Rails, il n'y a pas d'urgence à basculer pour la seule beauté du geste. Rails 8 ne va pas transformer votre chiffre d'affaires du jour au lendemain. La vraie question n'est pas « Rails 8 est-il mieux ? » — il l'est — mais « où en est mon application aujourd'hui ? ».

Si vous êtes déjà en retard — une version de Rails qui approche de sa fin de support, une pile technique alourdie par Redis et une poignée de services externes, un hébergement managé qui coûte cher — alors la mise à niveau vers Rails 8 devient un excellent point d'arrivée. Vous ne rattrapez pas seulement le retard : vous simplifiez durablement l'architecture au passage, et vous réduisez vos coûts récurrents. C'est précisément le genre de mise à niveau à prix fixe que nous prenons en charge : audit de l'existant, migration testée, suppression des dépendances devenues inutiles. Pour voir ce que ça donnerait sur votre application, jetez un œil à nos ressources ou à nos tarifs, et parlons-en.