Besoin d’authentification, de traitement en arrière-plan, d’export PDF ou de facturation Stripe ? Quelqu’un a presque certainement publié une gem pour cela, et c’est exactement pourquoi les développeurs utilisent si souvent les gems Rails. C’est aussi pourquoi un Gemfile peut se transformer en une facture de maintenance à laquelle personne ne s’est inscrit.
L’ampleur de l’écosystème explique l’affection. RubyGems.org, le registre officiel des gems Ruby on Rails et de tous les autres packages Ruby, héberge actuellement 193 910 gems, 244 700 utilisateurs enregistrés et près de 255 milliards de téléchargements.
Parmi les dix gems Ruby les plus populaires de tous les temps, les leaders sont bundler et un cluster de gems AWS SDK, mais trois bibliothèques Rails fondamentales font également partie de la liste, avec i18n, activesupport et rake dépassant chacun 1,3 milliard de téléchargements.
Ajoutez une ligne à votre Gemfile, exécutez bundle install, et vous héritez de milliers d’heures de travail des personnes qui maintiennent ces bibliothèques Ruby. Cet article est la version honnête de la façon dont nous traitons cet héritage chez Redwerk : les gems que nous exécutons en production lorsque nous créons et maintenons des applications Ruby on Rails pour nos clients, celles que nous supprimons, et la règle qui décide lesquelles sont lesquelles.
Chaque Gem Rails est aussi un Passif
Une gem Rails est une bibliothèque de code Ruby conditionnée que vous intégrez dans un projet pour ajouter une fonctionnalité sans la construire vous-même. Chaque gem de votre Gemfile est du code dont vous dépendez mais que vous n’avez pas écrit, maintenu par des personnes que vous n’avez jamais rencontrées, et capable de planter, de devenir obsolète ou de devenir hostile. Ce n’est pas de la paranoïa. C’est la réalité documentée du logiciel moderne, où la réutilisation est la norme et où la surface d’attaque a grandi en même temps.
Les données le confirment. En août 2025, des chercheurs ont découvert une campagne de 60 gems malveillantes se faisant passer pour des outils d’automatisation des médias sociaux, actives depuis au moins mars 2023 et téléchargées plus de 275 000 fois avant d’être retirées. Maintenir le registre lui-même n’est pas gratuit non plus, car Ruby Central estime que l’exploitation de RubyGems.org, y compris les serveurs, l’infrastructure et les mainteneurs rémunérés, coûte environ 500 000 $ par mois. Rien de tout cela ne signifie que les gems sont mauvaises. Cela signifie que chacune est une décision, et les décisions méritent un processus.
Comment Décider si une Gem Mérite sa Place
La plupart des articles évoquent l’instinct ici, mais l’instinct ne se transfère pas à travers une équipe ni ne s’explique à un client. Avant qu’une gem ne soit ajoutée à un Gemfile, nous la soumettons à une courte liste de contrôle. L’objectif n’est pas de minimiser le nombre de gems pour le plaisir. Il s’agit de s’assurer que chaque dépendance paie son loyer.
- Signaux de maintenance : fréquence des publications, ratio des problèmes ouverts par rapport aux problèmes résolus, et risque lié au facteur bus. Une gem astucieuse avec un seul mainteneur et un an de silence reste un risque.
- Poids et empreinte transitive : une gem entraîne ses propres dépendances, et vous héritez de toutes, nous vérifions donc ce qui arrive en aval avant de nous engager.
- Le test « Rails le fait-il déjà ? » : nous privilégions Rails simple et standard, et si le framework le couvre, nous utilisons le framework.
- Réversibilité : si la gem est abandonnée demain, à quel point est-il difficile de la supprimer ? Nous évaluons le risque de dépendance dès le départ.
- Licence et budget : les versions gratuites et payantes comptent lorsqu’un client surveille ses dépenses.
- Posture de sécurité : versions signées, mainteneur réactif et historique propre.
- Adéquation avec l’équipe : les développeurs qui héritent de l’application doivent vivre avec nos choix.
Notre règle de travail est simple : si personne dans l’équipe ne peut expliquer pourquoi une gem se trouve dans le Gemfile, elle ne devrait pas y être.
Il n'y a Pas de Gemfile Unique Correct
La bonne liste de gems dépend du projet qui vous est confié, ce que les articles génériques n’admettent jamais. Une agence est constamment confrontée à cela, car nous passons de nouvelles constructions à des bases de code vieilles de dix ans, et tout ce qui se trouve entre les deux. Il n’existe pas de liste universelle de gems Ruby on Rails qui convienne à toutes les situations.
- Lors des nouvelles constructions, nous nous appuyons sur les options par défaut modernes de Rails et une infrastructure minimale supplémentaire.
- Sur les applications héritées ou existantes, nous auditons avant d’ajouter, minimisons les changements, et respectons les modèles déjà présents.
- Pour les clients soucieux de leur budget, nous évitons les gemmes payantes et les services supplémentaires lorsqu’une option basée sur une base de données fait l’affaire.
- Pour les clients soumis à des réglementations strictes, nous renforçons les outils de sécurité et adoptons des politiques de mise à jour conservatrices.
Même framework, Gemfile différent, selon le projet.
Les Fondations : Serveur, Base de Données et Tâches d'Arrière-plan
Certains choix ne valent pas la peine d’être débattus. Pour le serveur web, nous utilisons Puma, et pour la base de données, PostgreSQL, et sur une configuration client typique, aucune de ces décisions ne suscite beaucoup de discussion. L’appel véritablement intéressant réside dans les tâches d’arrière-plan.
Avec Rails 8, le traitement en arrière-plan est devenu un véritable carrefour. Active Job est l’abstraction de mise en file d’attente du framework, et la question pratique est de savoir quel adaptateur se trouve derrière. La décision entre activejob, sidekiq et solid queue dépend généralement de l’infrastructure et de l’échelle plutôt que de la syntaxe.
Le compromis entre solid queue et sidekiq en est le cœur. Solid Queue est livré par défaut avec Rails 8 et stocke les tâches dans votre base de données existante en utilisant une fonctionnalité de verrouillage PostgreSQL et MySQL appelée FOR UPDATE SKIP LOCKED, il n’a donc pas besoin de Redis ni de service supplémentaire. Cela vous apporte une intégrité transactionnelle, où une tâche et les données dont elle dépend sont validées ensemble, ainsi qu’une exploitation simplifiée. Sidekiq est basé sur Redis, éprouvé au combat, et reste le champion du débit une fois que vous dépassez quelques milliers de tâches par minute. Si vous inversez la comparaison, la logique sidekiq vs solid queue est identique : vous pesez le coût d’infrastructure supplémentaire et le risque transactionnel d’un magasin séparé contre la vitesse brute.
Pour la plupart des applications clientes traitant moins d’un millier de tâches par minute, Solid Queue est le bon choix par défaut et une chose de moins à gérer. Lorsqu’un produit fonctionne réellement à grande échelle, Redis justifie son coût. Lorsque nous avons reconstruit le bot Slack PlusPlus, la version Python originale a cédé sous la charge, nous l’avons donc réarchitecturée sur Ruby on Rails avec Redis, PostgreSQL et AWS, et elle gère désormais plus d’un million d’actions utilisateur par minute. C’est à cette échelle que l’infrastructure plus lourde se justifie clairement.
La Couche Données : Extensions Active Record
Les gems dans Ruby on Rails qui touchent votre couche de données méritent une attention particulière, car elles sont proches de tout. La plupart des applications ont besoin de la même poignée de fonctionnalités : pagination, suppression logique, recherche plein texte, regroupement basé sur le temps et modélisation JSONB. Pendant des années, cela a nécessité de recourir à une gem par réflexe.
Nous associons chaque besoin à un candidat. Pagy est léger et rapide pour la pagination. Pg_search s’appuie sur PostgreSQL plutôt que d’ajouter un cluster Elasticsearch dont vous n’avez pas encore besoin. Groupdate permet de gagner du temps réel lorsque vous regroupez des enregistrements par jour, semaine ou mois.
Vous n’avez probablement pas besoin d’une gem pour cela, cependant. La suppression logique est l’exemple classique, car une colonne `deleted_at` et une portée par défaut gèrent la plupart des cas sans dépendance, et éviter la gem permet d’éviter les bugs subtils pour lesquels les bibliothèques de suppression logique sont connues. Active Record moderne modélise également les colonnes JSONB nativement, alors utilisez une extension uniquement lorsque vos requêtes dépassent réellement les fonctionnalités intégrées.
Authentification et Autorisation
Les lecteurs confondent constamment ces deux termes, il est donc utile de les séparer clairement. L’authentification consiste à prouver qui est un utilisateur. L’autorisation consiste à décider de ce que cet utilisateur est autorisé à faire une fois qu’il est connecté. Ils nécessitent des outils différents, et le paysage pour le premier a récemment évolué.
Rails 8 a livré un générateur d’authentification intégré qui structure les sessions, la gestion des mots de passe et les flux de réinitialisation sans gem. Pour une configuration client simple, ce générateur natif est maintenant notre point de départ, et il élimine une dépendance lourde que nous ajoutions automatiquement. Devise conserve sa place lorsque un projet a besoin de son écosystème mature d’extensions, telles que les comptes confirmables, les connexions verrouillables, ou plusieurs fournisseurs OmniAuth, où une reconstruction manuelle coûterait plus cher que la dépendance.
Pour l’autorisation, nous nous standardisons sur Pundit, qui conserve la logique de permission dans des objets de politique Ruby simples qu’un nouveau développeur peut lire en quelques minutes. Des politiques claires et testables sont bien plus importantes sur une application que nous rendons à une équipe cliente que n’importe quel langage de requête astucieux.
Frontend et Vues
Le frontend est le véritable carrefour, et nous choisissons en fonction de l’équipe et du produit du client, pas de la mode. Deux voies réellement bonnes existent, et la mauvaise crée des années de friction. Bien choisir ici dépend surtout de qui maintiendra l’application ensuite.
Hotwire vous maintient dans Rails, produit moins de JavaScript, et convient aux applications axées sur le contenu et lourdes en CRUD qu’une équipe Rails possédera. Inertia avec React est pertinent lorsque le produit est hautement interactif, ou lorsque le client possède déjà des développeurs React qui porteront le frontend.
Pour la structure des vues, nous utilisons ViewComponent pour garder le balisage testable et réutilisable, ce qui profite à quiconque hérite de la base de code. Sur le pipeline d’assets, Rails 8 préfère Propshaft à la configuration Sprockets plus ancienne, et pour la plupart des nouvelles constructions, nous suivons cette norme. Le principe directeur est la maintenabilité pour l’équipe qui utilisera l’application après notre départ.
Création d'API
La plupart des applications clientes exposent une API à un moment donné, et les choix là-bas échangent la familiarité contre la performance. Les options par défaut sont bien jusqu’à ce qu’elles ne le soient plus, et savoir quand changer est la compétence. Nous essayons de ne pas optimiser pour un problème que l’application n’a pas encore.
Pour la sérialisation JSON, nous commençons généralement avec Active Model Serializers ou Blueprinter, et nous passons à une option plus rapide comme Alba seulement lorsque le profilage montre que la sérialisation est le véritable goulot d’étranglement. Nous traitons les API REST comme étant axées sur la documentation, générant une spécification OpenAPI afin que les autres équipes du client puissent s’intégrer sans avoir à rétro-ingénier nos contrôleurs. Cette discipline a montré sa valeur sur Cleanagents, une application à la demande pour les nettoyeurs indépendants en Allemagne et en Autriche, où la plateforme existante n’exposait aucune API. Nous avons construit des API RESTful en Rails pour communiquer avec l’application Android, utilisé la gem Geocoder pour résoudre les coordonnées des commandes, et poussé ce géocodage dans un processus d’arrière-plan afin que l’application reste réactive.
GraphQL a une place réelle lorsqu’un client a de nombreux consommateurs avec des besoins de données différents, tels que plusieurs frontends frappant un backend. Pour une seule application avec des points de terminaison prévisibles, cela ajoute généralement une complexité de schéma et des maux de tête de mise en cache qu’une simple API REST aurait évités. Nous la recommandons lorsque le produit l’exige, et nous dissuadons les clients lorsqu’elle n’est pas nécessaire.
Fonctionnalités IA : La Réalité de 2026
De nombreux produits souhaitent désormais un modèle linguistique quelque part dans la pile, et Rails a rattrapé son retard. Des gems comme ruby-openai et le plus récent RubyLLM rendent l’appel d’un modèle et l’obtention de résultats structurés vraiment pratiques. Les associer à une approche de sortie typée permet de maintenir des réponses suffisamment prévisibles pour être stockées et traitées.
La mise en garde que la plupart des articles omettent est la plus importante. Ne greffez pas de dépendances IA sur un produit qui n’en a pas besoin, et soumettez chaque gem d’IA au même examen que toute autre dépendance. Le risque n’est pas théorique. Dans les tests de Sonatype, 27,8 % des recommandations de mise à jour de dépendances d’un LLM faisaient référence à des versions qui n’avaient jamais été publiées, et quelques-unes pointaient vers des packages véritablement compromis. Un agent de codage IA recommandant avec confiance une gem hallucinée est précisément le moment où il faut revenir à des choix simples et vérifiés.
Observabilité, Journalisation et Sécurité en Production
Pour les applications que nous maintenons, quelques catégories ne sont pas optionnelles. La journalisation structurée avec Lograge, les métriques de base et le suivi des erreurs via quelque chose comme Sentry font la différence entre résoudre un incident en quelques minutes et deviner dans le noir. Ces gems méritent leur place précisément parce que vous ne les remarquez que lorsqu’elles manquent.
L’audit des dépendances appartient au pipeline, pas à la mémoire de quelqu’un. Nous exécutons bundler-audit pour signaler les gems avec des vulnérabilités connues et Brakeman pour l’analyse statique de sécurité, tous deux connectés à CI afin qu’une dépendance risquée échoue à la construction plutôt que d’atteindre la production. Cela est plus important pour une agence livrant à des clients que pour un projet personnel solo, et c’est l’un des éléments de notre checklist de revue de code Ruby on Rails que nous traitons comme non négociables.
Expérience Développeur et Tests
La culture des tests concerne vraiment la qualité de l’application après la fin de notre implication. Nous nous standardisons sur RSpec avec FactoryBot pour les fixtures, Capybara pour les tests système et navigateur, et un profileur lorsque nous devons trouver où le temps est réellement investi. L’objectif est une suite à laquelle la propre équipe du client peut faire confiance et qu’elle peut étendre.
Nous utilisons Bullet pour attraper les requêtes N+1 en développement avant qu’elles ne deviennent des ralentissements en production, car rien n’érode la confiance dans une base de code héritée plus rapidement qu’une page qui se charge lentement sans raison apparente. Une couverture solide et des modèles de requêtes clairs sont ce qui fait d’un transfert un véritable transfert plutôt qu’un au revoir et bonne chance. Cette maintenabilité est le véritable livrable.
Maintenir un Gemfile Sain au Fil des Ans
La partie du travail qui définit le travail d’agence est de maintenir un Gemfile sain longtemps après le lancement. Nous traitons la maintenance comme une routine plutôt qu’une mission de sauvetage, car les mises à jour petites et fréquentes sont bien moins chères que le saut de version une fois tous les trois ans qui se transforme en une migration de plusieurs semaines. En pratique, cela signifie quelques habitudes permanentes :
- Audit régulier : nous examinons les dépendances à intervalles réguliers au lieu d’attendre que quelque chose se casse, en exécutant bundle outdated et bundler-audit dans CI afin que les gems obsolètes et les vulnérabilités connues apparaissent à chaque compilation.
- Mettre à jour par petites étapes : les versions patch et mineures sont intégrées à un rythme régulier, et les versions majeures sont planifiées délibérément en lisant d’abord le journal des modifications, de sorte qu’aucune mise à jour ne survienne comme une surprise.
- Automatiser les tâches répétitives : des outils comme Dependabot ou Renovate ouvrent des pull requests de mise à jour pour nous, ce qui maintient le backlog visible et les différences suffisamment petites pour être examinées.
- Surveiller l’abandon : nous signalons les gems avec un seul mainteneur ou un long silence, puis nous les remplaçons délibérément avant qu’une dépendance non maintenue ne bloque une mise à niveau de Rails ou de Ruby.
- Maintenir Ruby et Rails à jour : rester sur les versions prises en charge du framework et du langage évite les impasses de sécurité et de compatibilité qui accompagnent les versions de fin de vie.
- Épurer ce que personne ne peut justifier : chaque audit est aussi une occasion de supprimer les gems que personne ne peut expliquer, ce qui réduit la surface d’attaque et la charge de maintenance en même temps.
- S’appuyer sur la suite de tests : une couverture solide est ce qui rend tout ce qui précède sûr, car elle nous permet de mettre à niveau avec confiance plutôt qu’avec espoir.
Sur les applications clientes héritées, cette discipline est là où le rendement se manifeste. Les applications qui sont agréables à maintenir cinq ans plus tard sont celles où quelqu’un a gardé le Gemfile honnête, et ce travail compte bien plus au fil du temps qu’il ne le montre jamais dans une démonstration de fonctionnalités.
Construisez-le avec une Équipe qui Livre Réellement du Rails
Un bon Gemfile est un signe de jugement en ingénierie, et le jugement est ce pour quoi vous embauchez réellement lorsque vous faites appel à une agence. Chez Redwerk, nous avons passé des années à construire et maintenir des applications Rails où les choix de dépendances avaient de réelles conséquences. Les études de cas racontent cette histoire mieux que n’importe quelle liste de fonctionnalités.
Nous avons reconstruit le bot Slack PlusPlus à partir d’un prototype Python qui ne pouvait pas évoluer vers un système Rails gérant plus d’un million d’actions par minute. Nous avons construit le backend et les API RESTful pour Cleanagents afin qu’une application Android puisse servir les nettoyeurs indépendants en Allemagne et en Autriche. Et sur Adfectious, une plateforme de publicité mobile, nous avons conçu l’architecture et un moteur de traitement de bannières, avec du code d’installation livré sur Ruby on Rails, PHP, ASP, C# et JSP. Si vous démarrez une nouvelle application Rails, ou si vous vous demandez si votre Gemfile actuel vous aide ou vous coûte cher, contactez-nous et nous examinerons cela.
Découvrez comment nous avons utilisé Ruby on Rails et des gems comme Geocoder pour lancer Cleanagents, une plateforme de nettoyage à la demande acquise plus tard par Helpling.de
