Pourquoi on choisit toujours Ruby on Rails en 2026

Une obsession qui a 13 ans et qui n'a pas vieilli

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, et on utilisait 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 de l'écosystème front-end, mais le choix de fond n'a pas bougé.

‍

À chaque revue de stack technique — tous les 18 mois environ — on se pose 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 sur Rails. Pas par paresse, par calcul.

‍

Cet article expose ce calcul. 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.

‍

Les licornes françaises parlent Ruby

Avant les arguments, le terrain. Si vous regardez les licornes du web français — entreprises valorisées plus d'un milliard de dollars — vous tombez sur une concentration anormalement élevée de Rails. Doctolib (créée en 2013), Aircall (2014), Qonto (2016), Sorare et Swile (2018), Pennylane (2020). Ce sont, pour la plupart, des entreprises dont le cœur métier est codé en Rails.

‍

À l'international, les références sont connues : GitHub, Shopify, Airbnb, Twitch, Coinbase, Basecamp (la maison-mère de Rails), Substack. La langue Ruby on Rails est parlée chez les acteurs qui scalent, contrairement à ce qu'affirme le mythe répété chaque année.

‍

Pennylane illustre le point particulièrement bien : 120 développeurs Ruby en trois ans, des dizaines de milliers de lignes de code ajoutées par semaine, et un monolithe Rails qui tient. Ils l'ont raconté publiquement en utilisant Packwerk (un outil offert par Shopify) pour modulariser leur code. Quand la communauté Rails partage ses outils internes à ce niveau de qualité, l'écosystème devient un actif collectif.

‍

Argument n°1 — La vélocité de Convention over Configuration

C'est l'argument historique de Rails, et il n'a pas vieilli. "Convention over Configuration" — le principe qui a fait la fortune du framework — signifie que sur 95 % des décisions techniques courantes (où mettre quel fichier, comment nommer une colonne de base de données, 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 de manière inoubliable :

‍

"Vous n'êtes pas un flocon de neige magnifique et unique."

‍

C'est la phrase la plus puissante du framework. Elle dit : abandonnez votre individualité technique, faites comme tout le monde, et concentrez-vous sur ce qui compte vraiment — 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 que Capsens a livrés, on chiffre régulièrement le gain : 30 à 40 % de productivité par rapport à une stack équivalente en Node.js / Express ou Django, sur les 6 premiers mois d'un projet.

‍

Argument n°2 — Le scaffolding et le batteries-included

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 (ActiveRecord), système de migrations, framework de tests (Minitest ou RSpec), gestion des emails (ActionMailer), des jobs en arrière-plan (ActiveJob + Solid Queue depuis Rails 8), de l'upload de fichiers (ActiveStorage), du temps réel (ActionCable + Solid Cable), de la sécurité (ActionDispatch), de la i18n, du caching (Solid Cache).

‍

Depuis Rails 8 (sortie 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.

‍

Pour illustrer, voici la commande qui crée un modèle, un controller, des vues, des routes RESTful et une migration de base de données en Rails :

‍

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

‍

Une commande, trente secondes, et vous avez une ressource fonctionnelle, testable, déployable. Le développeur Node.js qui assemble la même chose à la main perd une demi-journée — et la moitié des choix qu'il a faits seront discutables dans six mois.

‍

Argument n°3 — Un écosystème mature et une communauté française vivante

Treize ans après la sortie de Rails 1.0, l'écosystème Ruby est l'un des plus matures du web. Les gems les plus utiles — Devise, Sidekiq, Pundit, Rspec, Capybara, Faker, AASM, Geocoder, Wicked, Pagy — sont maintenues depuis 10+ ans, par des mainteneurs investis, et leurs choix architecturaux ont eu le temps d'être éprouvés.

‍

En France spécifiquement, la communauté Ruby est particulièrement vivante. 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 se transforme en CDI après quelques années d'expérience complémentaire.

‍

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), un podcast (le podcast du Wagon), et désormais une newsletter dédiée — Ruby Biscuit — que nous éditons chez Capsens. C'est un signe : il y a une vie collective autour du langage, et pas seulement un usage industriel.

‍

Argument n°4 — La courbe d'apprentissage la plus douce du marché

Ruby est probablement le langage backend dont le code est le plus proche du langage naturel. Vous écrivez :

‍

3.times do

‍

  puts "Hello, world"

‍

end

‍

Et même quelqu'un qui n'a jamais codé devine ce que ça fait. Cette qualité — la lisibilité du code Ruby — a un impact direct sur trois choses : la productivité d'un junior qui démarre, la vitesse de la code review (le code dit ce qu'il fait), et la maintenance long-terme (revenir sur du code Rails de 2018 reste lisible en 2026).

‍

Conséquence pratique côté recrutement : chez Capsens, on peut recruter d'excellents développeurs venant d'autres écosystèmes (Python, PHP, JavaScript) et les rendre productifs en Rails en quelques semaines. La courbe d'apprentissage Ruby est plus douce que celle de TypeScript + Node.js, plus douce que Go, beaucoup plus douce que Rust. C'est un argument de scalabilité d'équipe que les fondateurs fintech sous-estiment.

‍

Mais Rails ne scale pas ? Le mythe à enterrer définitivement

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

‍

Les faits, en 2026 :

‍

Rails 8 a apporté la trinité Solid. Solid Queue (jobs en background), Solid Cache (cache applicatif), Solid Cable (websockets 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. Le mouvement "décloud" prend de l'ampleur, et Rails est à l'avant-garde.

‍

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, et expérience utilisateur quasi-équivalente à une SPA pour la majorité des cas.

‍

Pennylane et Packwerk ont démontré qu'on peut maintenir un monolithe Rails de 120 développeurs sans souffrir. La solution n'est pas dans le passage aux microservices (qui auraient apporté plus de complexité), mais dans la modularisation du monolithe.

‍

Le verdict honnête : Rails scale parfaitement bien pour 95 % des projets web. Pour les 5 % de 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, et c'est aussi le pattern qu'on applique chez Capsens quand le besoin se présente.

‍

Ce que l'IA change en 2026 (et pourquoi ça renforce Rails)

C'est probablement l'argument le plus nouveau et le plus puissant de cet article. L'IA aime Rails.

‍

Trois raisons.

‍

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

‍

Ensuite, les conventions strictes de Rails sont un cadre parfait pour l'IA. Un assistant IA qui code dans un framework hyper-flexible (Node.js, Python sans Django) 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 supérieure en Rails qu'en stack flexible.

‍

Enfin, Ruby est lisible par les humains et par les IA. 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.

‍

Résultat : en 2026, un développeur Capsens avec Claude Code ou Cursor est typiquement 2 à 3 fois plus productif en Rails qu'en stack équivalente Node.js / TypeScript. C'est un argument quantifié qui n'existait pas il y a deux ans, et qui à lui seul justifierait le choix de Rails même sans tous les autres arguments listés ci-dessus.

‍

Notre stack Capsens en 2026

Pour information, voici la stack que nous opérons sur la quasi-totalité de nos projets fintech :

‍

• Ruby 3.4 + Rails 8 (ou 7.2 sur les projets plus anciens, en cours de migration)
• PostgreSQL comme base de données principale, avec extensions (PostGIS, pg_partman selon les cas)
• Solid Queue pour les jobs en background (sur les projets récents) ou Sidekiq (sur les projets historiques)
• React + React Native pour les besoins front complexes et les apps mobiles
• Hotwire pour les interfaces Rails-natives quand c'est suffisant (de plus en plus de cas)
• Kamal pour les déploiements
• Scaleway ou OVH pour l'hébergement souverain européen (de plus en plus, pour les contraintes DORA / Cloud Act)
• Sentry + Honeybadger pour le monitoring
• GitHub Actions pour la CI/CD
• 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 que nous proposons à nos clients, et c'est ce que nous ne changerons pas tant qu'un meilleur compromis n'aura pas émergé. À ce jour — treize ans plus tard — il n'a pas émergé.

‍

Conclusion : pourquoi on continue

Le choix d'une stack technique est l'art du compromis. Aucun langage, 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 que nous construisons : 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. Il le sera probablement encore en 2030 — et si ce n'est plus le cas, on l'écrira honnêtement dans un article qui s'appellera "Pourquoi on a quitté Rails en 2030". Mais ce jour n'est pas arrivé.

‍