Pourquoi on choisit toujours Ruby on Rails en 2026

Capsens a livré sa première plateforme Rails en 2013. C'était Rails 4, Ruby 2.0, on déployait encore sur Heroku, on découvrait Sidekiq, on écrivait du Sass en CoffeeScript. Aujourd'hui on est en Rails 8, Ruby 3.4, on déploie avec Kamal, on hésite entre Sidekiq et Solid Queue, et on écrit du JavaScript à peine plus humain qu'à l'époque. Treize ans, six versions majeures de Rails, deux refontes complètes de l'écosystème front, et le choix de fond n'a jamais bougé.

‍

À chaque revue de stack technique (tous les 18 mois environ), on se repose la question. Est-ce qu'on reste sur Rails ? Est-ce qu'on regarde Next.js full-stack, Phoenix, Django, Go ? À chaque fois, après un benchmark sérieux, la réponse est la même. On reste.

‍

Cet article expose pourquoi. Pour les fondateurs fintech qui hésitent entre stacks, pour les développeurs qui se demandent si Rails est encore un bon pari, pour les CTO qui regardent une refonte et doutent.

L'argument qu'on ne pourrait pas tenir sans les chiffres

Avant les raisons, le terrain. Quand vous regardez les licornes du web français, vous tombez sur une concentration anormalement élevée de Rails. Doctolib gère ses millions de consultations en Rails depuis 2013. Pennylane a recruté 120 développeurs Ruby en trois ans après sa création en 2020. Sorare, Qonto, Aircall, Swile — toutes en Rails sur leur core. À l'international, c'est GitHub, Shopify, Airbnb, Basecamp, Substack qui parlent la même langue.

‍

Cette concentration n'est pas un hasard, et elle n'est pas que de la nostalgie. Si tant d'équipes qui ont passé l'échelle du milliard de valorisation choisissent et conservent Rails, c'est qu'il y a là quelque chose qui marche, malgré les rumeurs de mort répétées chaque année depuis dix ans.

La vélocité que personne ne sait imiter

C'est l'argument historique du framework, et il n'a pas vieilli. Convention over Configuration signifie que sur la quasi-totalité des décisions techniques courantes (où mettre quel fichier, comment nommer une colonne, comment structurer un controller), Rails a déjà décidé pour vous. Vous ne perdez pas de temps à débattre, vous écrivez du code métier.

‍

La doctrine Rails formule la chose en une phrase qu'on ne devrait jamais relire sans un sourire : "Vous n'êtes pas un flocon de neige magnifique et unique." Abandonnez votre individualité technique, faites comme tout le monde, concentrez-vous sur ce qui compte vraiment, c'est-à-dire la fonctionnalité métier que vous livrez à vos utilisateurs.

‍

En 2026 cette discipline n'a jamais été aussi précieuse. Pendant que les équipes Node.js débattent encore de leur ORM (Prisma, Drizzle, Sequelize ?), de leur framework (Express, Fastify, Hono, NestJS ?), de leur structure de dossiers (par feature, par layer, hybride ?), une équipe Rails a déjà livré trois fonctionnalités.

‍

C'est un avantage compétitif tangible. Sur les projets fintech qu'on a livrés, on observe régulièrement un écart de productivité significatif par rapport à une stack équivalente Node.js ou Django sur les six premiers mois. Moins de réunions de "comment on s'organise", plus de code qui répond à un besoin.

L'écosystème comme actif accumulé

L'autre force de Rails, c'est son côté batteries-included. Le framework intègre nativement ce que d'autres écosystèmes obligent à assembler à la main : ORM, migrations, framework de tests, mailer, jobs en arrière-plan, upload de fichiers, temps réel, sécurité, internationalisation, caching. Depuis Rails 8 sorti fin 2024, l'authentification est même native, plus besoin de Devise pour les cas d'usage simples.

‍

DHH appelle ça the One Person Framework. L'idée qu'une seule personne peut construire et maintenir une application complète sans avoir besoin de cobbler douze librairies tierces. Sur le terrain, ça se traduit par des commandes comme celle-ci :

‍

rails generate scaffold Investment amount:decimal investor:references project:references signed_at:datetime

‍

Une commande, trente secondes, et vous avez un modèle, un controller, des vues, des routes RESTful, et une migration de base. On utilise rarement scaffold tel quel en production, mais le fait que la commande existe et fonctionne en 2026, alors qu'elle existait déjà en 2008, dit quelque chose sur la cohérence de la philosophie Rails dans la durée.

‍

L'écosystème de gems est probablement le plus mature du web. Sidekiq, Devise, Pundit, RSpec, Capybara, AASM, Pagy — tous maintenus depuis dix ans ou plus, avec des choix architecturaux qui ont eu le temps d'être éprouvés. Quand on intègre une gem Rails, on tombe rarement sur une décision absurde. Quelqu'un l'a probablement vue avant nous et l'a corrigée.

La communauté française qui pèse

En France, la communauté Ruby est particulièrement vivante, et c'est un sujet rarement abordé hors du cercle. Le Wagon, bootcamp français, forme chaque année plus de 1 000 développeurs au web et enseigne le métier à travers Rails. Conséquence directe : un flux régulier de juniors et de profils reconvertis qui arrivent sur le marché avec une compétence Rails native.

‍

Capsens reçoit des candidatures Le Wagon en continu, dont une partie significative se transforme en CDI après deux ou trois ans d'expérience complémentaire. C'est un pipeline de talents qu'aucun autre framework en France ne peut offrir au même niveau.

‍

L'effet boule de neige est puissant. Plus il y a de licornes françaises sur Rails, plus elles recrutent en Rails, plus les écoles forment en Rails, plus les développeurs apprennent Rails. La langue commune se renforce avec le temps — ce qui est rare dans l'écosystème web où les modes changent tous les 18 mois.

‍

Au passage, la communauté française organise des rencontres régulières (Paris.rb, Lille.rb) et anime depuis peu une newsletter dédiée, Ruby Biscuit, que nous éditons chez Capsens. Il y a une vie collective autour du langage, pas seulement un usage industriel.

"Mais Rails ne scale pas" : le mythe à enterrer

C'est l'objection qu'on entendait il y a dix ans et qu'on entend encore venir de gens qui n'ont pas suivi les évolutions du framework.

‍

Les faits, en 2026. Rails 8 a livré la trinité Solid : Solid Queue pour les jobs en background, Solid Cache pour le cache applicatif, Solid Cable pour le temps réel. Ces trois bibliothèques permettent de scaler Rails sans Redis, toute la stack tient sur PostgreSQL. Ça simplifie énormément les déploiements et réduit drastiquement l'infrastructure nécessaire.

‍

Kamal 2 est devenu l'outil de déploiement officiel. Il permet de déployer une application Rails sur n'importe quel serveur Linux avec une simple commande, sans dépendre de Heroku, Vercel ou AWS. 37signals (la société de DHH) opère son produit Hey sur ses propres serveurs et économise des millions par an grâce à ce setup.

‍

Hotwire (Turbo + Stimulus) a transformé la manière dont Rails livre du front. Beaucoup de projets qui auraient nécessité React + API en 2020 sont aujourd'hui livrés en Rails + Hotwire — gain de productivité énorme, réduction du JavaScript embarqué côté client, et expérience utilisateur quasi-équivalente à une SPA pour la majorité des cas d'usage.

‍

Pennylane a documenté publiquement le maintien d'un monolithe Rails de 120 développeurs sans souffrir, en utilisant Packwerk (un outil offert par Shopify) pour modulariser leur code. La solution n'était pas dans le passage aux microservices, qui auraient ajouté plus de complexité qu'ils n'en auraient résolu, mais dans la modularisation du monolithe.

‍

Rails scale parfaitement bien pour la grande majorité des projets web. Pour les rares cas extrêmes — moteurs de matching massifs, calculs financiers temps réel à haute fréquence, traitement de gros volumes vidéo — on couple Rails avec un service en Go ou en Rust pour la partie critique. C'est ce que font Qonto et Sorare, c'est aussi le pattern qu'on applique chez Capsens quand le besoin se présente.

Ce que l'IA change, et dont personne ne parle assez

C'est probablement l'argument le plus nouveau et le plus puissant en faveur de Rails en 2026. Et c'est précisément celui qui est sous-représenté dans le discours public.

‍

L'IA aime Rails. Trois raisons à ça, qu'on observe au quotidien.

‍

Rails est massivement représenté dans les datasets d'entraînement des grands modèles. C'est un framework qui existe depuis 2004, qui a des conventions stables, qui produit du code lisible et qui a une documentation publique de qualité. Les modèles le maîtrisent extrêmement bien. Quand vous demandez à Claude Code de générer un controller ou une migration ActiveRecord, le résultat est généralement correct dès la première itération.

‍

Les conventions strictes de Rails offrent un cadre parfait pour l'IA. Un assistant IA qui code dans un framework hyper-flexible doit deviner les conventions de votre projet, et il se trompe souvent. Dans Rails, les conventions sont publiques et universelles : l'IA sait où mettre quel fichier, comment nommer quoi, comment structurer un test. La productivité gagnée avec l'IA est sensiblement supérieure en Rails qu'en stack flexible.

‍

Et Ruby est lisible par les humains comme par les machines. Le code généré par l'IA est immédiatement compréhensible et reviewable, contrairement à du TypeScript généré qui demande souvent un effort de lecture supplémentaire.

‍

Sur le terrain, on observe régulièrement qu'un développeur Capsens équipé de Claude Code ou Cursor est sensiblement plus productif en Rails qu'en stack équivalente Node.js + TypeScript. C'est un argument qui n'existait pas il y a deux ans et qui à lui seul justifierait le choix de Rails même sans tous les autres listés au-dessus.

Notre stack en 2026

Pour donner du concret, voici la stack qu'on opère sur la quasi-totalité de nos projets fintech.

‍

Ruby 3.4 et Rails 8 sur les projets récents, Rails 7.2 sur les plus anciens (en cours de migration). PostgreSQL en base de données principale, avec quelques extensions selon les cas (PostGIS, pg_partman). Solid Queue pour les jobs en background, ou Sidekiq sur les projets historiques. React et React Native pour les besoins front complexes et les apps mobiles. Hotwire pour les interfaces Rails-natives quand c'est suffisant, et c'est de plus en plus de cas. Kamal pour les déploiements. Scaleway ou OVH pour l'hébergement, surtout depuis que DORA et le Cloud Act poussent vers du souverain européen. Sentry et Honeybadger pour le monitoring. GitHub Actions pour la CI/CD. Et Claude Code + Cursor comme assistants de développement quotidiens.

‍

Cette stack est stable, éprouvée, et nous permet de livrer une plateforme PSFP production-ready en 4 à 5 mois. C'est ce qu'on propose à nos clients. Et c'est ce qu'on ne changera pas tant qu'un meilleur compromis n'aura pas émergé. À ce jour, treize ans plus tard, il n'a pas émergé.

En conclusion

Le choix d'une stack technique est toujours un compromis. Aucun framework n'est "le meilleur" dans l'absolu. Chacun trace un équilibre entre productivité, performance, écosystème, courbe d'apprentissage, scaling, et facilité de recrutement.

‍

Ruby on Rails en 2026 atteint l'un des meilleurs équilibres du marché pour la plupart des projets web, et tout particulièrement pour les plateformes fintech qu'on construit : des applications complexes, qui vivent longtemps, qui doivent évoluer en suivant la réglementation, qui ont besoin de scaler progressivement, et qui sont maintenues par des équipes de 3 à 30 développeurs.

‍

Pour Capsens, Rails est ce compromis. Il l'était en 2013, il l'est en 2026.

‍