Si votre application Rails envoie des emails, génère des factures PDF ou synchronise des données avec un service tiers, elle utilise probablement des tâches de fond. Et si elle a quelques années, il y a de fortes chances que ces tâches tournent sur DelayedJob. C'était le bon choix à l'époque. Aujourd'hui, Rails 8 propose un successeur intégré, plus simple et plus fiable : Solid Queue. Voici pourquoi la bascule vaut le détour, et comment elle se déroule concrètement.
Un « job », c'est quoi au juste ?
Quand un visiteur clique sur « Valider ma commande », il ne devrait pas attendre que l'email de confirmation parte, que le PDF se génère et que la comptabilité se mette à jour avant de voir sa page se recharger. Ces opérations sont déportées : l'application les range dans une file d'attente et les exécute en arrière-plan, pendant que l'utilisateur poursuit sa navigation. C'est ça, un job — une unité de travail différée.
Les cas typiques sont partout : envois d'emails et de notifications, traitements d'images, exports de données, appels à des API externes, rapports planifiés la nuit. Sans système de jobs, ces tâches ralentissent chaque page ou, pire, échouent silencieusement. Avec, elles deviennent fiables et rejouables : une tâche qui échoue peut être relancée automatiquement, sans intervention.
DelayedJob : ce qui a vieilli
DelayedJob a longtemps été le choix par défaut, et il fonctionne toujours. Mais il n'est plus activement soutenu comme il l'a été, et son modèle montre son âge. Il repose sur un mécanisme de verrouillage en base qui gère mal les gros volumes, offre peu de visibilité sur ce qui tourne, et sa gestion des échecs reste rudimentaire. Beaucoup d'équipes l'ont d'ailleurs quitté pour Sidekiq — puissant, mais qui impose Redis, donc un serveur supplémentaire à installer, sécuriser, sauvegarder et facturer.
Le vrai problème n'est pas technique, il est stratégique : chaque brique externe est une pièce mobile de plus. Une pièce qui peut tomber en panne, qui demande des mises à jour, et que votre prestataire doit connaître pour intervenir. Moins il y en a, plus votre application est simple à maintenir dans la durée.
Solid Queue : le nouveau standard, sans dépendance
Solid Queue est le système de tâches de fond livré par défaut avec Rails 8. Sa force tient en une phrase : il s'appuie sur votre base de données existante (PostgreSQL, MySQL, SQLite), sans Redis ni aucun service tiers. Les jobs sont stockés dans des tables de votre base, aux côtés de vos données métier.
Les bénéfices sont directs. Moins de pièces mobiles : plus de Redis à héberger, un composant de moins qui peut lâcher un dimanche soir. Une fiabilité renforcée : les jobs profitent des transactions et des sauvegardes de votre base, donc rien ne se perd entre deux systèmes désynchronisés. Un support pérenne : c'est maintenu par l'équipe Rails elle-même, ce qui garantit des mises à jour et une compatibilité sur le long terme. Solid Queue gère aussi nativement les tâches planifiées (l'équivalent d'un cron) et les priorités, sans extension supplémentaire.
Pour un dirigeant, le calcul est simple : une brique de moins à maintenir, une facture d'hébergement allégée, et un socle sur lequel n'importe quel développeur Rails saura intervenir demain, parce que c'est devenu le standard.
À quoi ressemble la migration ?
La bonne nouvelle, c'est que Rails a introduit une couche d'abstraction, Active Job, qui sépare vos tâches de l'outil qui les exécute. Si votre application est déjà écrite proprement, vos jobs ne savent même pas s'ils tournent sur DelayedJob ou sur Solid Queue. Le travail consiste alors surtout à changer l'aiguillage : installer Solid Queue, créer ses tables, et pointer les points d'appel vers le nouveau moteur.
En pratique, la migration se déroule en quelques étapes maîtrisées : installer Solid Queue et générer ses tables, basculer la configuration de la file d'attente, remplacer les points d'appel restants qui invoquaient DelayedJob directement, puis faire tourner les deux en parallèle le temps de vider l'ancienne file. Aucune interruption de service n'est nécessaire. Le risque principal n'est pas la bascule elle-même mais les vieux appels non standardisés, hérités d'avant Active Job — c'est là que l'audit du code fait la différence.
Pour une application Rails de taille moyenne, l'opération se chiffre en heures, pas en semaines. C'est exactement le genre de mise à niveau à prix fixe que nous prenons en charge : audit des points d'appel, migration testée, et bascule sans coupure. Vous voulez savoir ce que ça donnerait sur votre application ? Jetez un œil à nos ressources ou à nos tarifs, et parlons-en.