Un sondage effectué cet été, auprès de 5 000 professionnels et publié sur le site Sitepoint.com révèle que près de 6 % des développeurs ont déjà adopté Ruby on Rails (RoR ou Rails), et que 25 % s'y intéressent. Pourtant, ce framework open source (licence MIT), écrit en Ruby, n'existe que depuis un an. Une première version stable a été publiée en décembre 2005. Elle est issue d'un développement de la société 37 signals, icône du Web 2.0.

Malgré sa jeunesse, Rails va-t-il remplacer PHP et Java pour le développement d'applications Web ? La question mérite d'être posée. Mais, avant d'y répondre, il faut bien faire la distinction entre le langage Ruby et le framework Rails. Le premier est un langage interprété, nativement orienté objet, considéré comme l'évolution naturelle de Perl et de Smalltalk. Le second repose, lui, sur le motif de conception modèle, vue, contrôleur (MVC) qui fait aujourd'hui référence pour architecturer une application Web. Cette méthode a le mérite de dissocier correctement les couches métier et présentation.

Les arguments de Rails ont en tout cas convaincu Sun d'embaucher les créateurs de JRuby, une installation de Ruby pour Java. « La communauté Java ne s'arrête pas au langage Java, déclare Alexis Moussine-Pouchkine, architecte Java et services Web chez Sun. Rails répond bien aux besoins des application s Crud [Create, Retrieve, Update, Delete, NDLR]. » Ces dernières effectuent des opérations de lecture et d'écriture dans les bases de données. Le déploiement d'applications Rails sur une infrastructure Java gagnerait en robustesse. Elle donne aussi la possibilité aux partisans de Ruby d'utiliser des outils de développement avancés basés sur Netbeans.

Bien d'autres signes révèlent l'engouement pour ce framework. Des grands noms de l'informatique, comme Adobe, Apple, IBM ou Sun, soutiennent Rails. Des écoles renommées, telles l'Epita et l'Insia, l'ont associé à leur cursus 2007. Et de nombreuses entreprises et institutions l'ont adopté pour développer des applications sensibles. En France, c'est le cas de la communauté d'agglomération belfortaine, de Cartaix, un spécialiste de la fidélisation client, et d'Eyeka qui propose sur une plate-forme d'échange et de vente de photos et de vidéos sur le Web.

Ce succès repose d'abord sur l'adhésion des développeurs qui apprécient son utilisation. « Rails offre le meilleur compromis entre la productivité de PHP et l'approche structurée de Java EE (nouveau nom de J2EE depuis la version 1.5) », résume Jérémy Chatard, directeur technique de Breek, une SSII qui se spécialise dans Rails. « C'est le framework Web le mieux pensé qu'il m'ait été donné de voir depuis dix ans », s'enthousiasme James Duncan Davidson, le créateur de Tomcat, le serveur de JSP-servlets le plus utilisé au monde.

On peut comparer Rails aux Java Server Face (JSF) de Java EE ou au Zend Framework dans le monde PHP. Mais il se distingue en s'appuyant sur le principe de convention plutôt que de configuration. Il s'agit de ne configurer que les cas particuliers. La mise en oeuvre de ce principe repose sur l'application de règles implicites entre le développeur et le socle de développement. Elle requiert un effort de formation supplémentaire lors de la prise en main du framework. En contrepartie, le développeur n'a pas à gérer, entre autres, le mapping objet relationnel. « Il suffit que le nom de la table de la base de données corresponde à celui de la classe Ruby », détaille Richard Piacentini, cofondateur de Nuxos, une SSLL spécialiste de Rails.

Une fois ces conventions en tête, le développeur se concentre sur la dimension métier de son application et délègue la plomberie et les détails techniques au framework. Rails met en oeuvre un autre principe essentiel -  Dont Repeat Yourself (DRY)  - qui favorise la réutilisation et la standardisation du code. « Chaque partie de la logique applicative et de l'interface ne doit être exprimée qu'une seule fois et à un seul endroit dans l'application, ce qui aide à factoriser le code », argumente Richard Piacentini. Au final, Rails réduit significativement les coûts de développement et diviserait par trois le nombre de lignes de code à écrire par rapport à PHP, et bien davantage encore si on le compare à Java. Cette concision améliore la lisibilité des applications et donc leur maintenance.

Ce ne sont pas les seuls points distinctifs. Rails génère le squelette complet d'une application en quelques clics. Comme un L4G, il s'appuie sur le modèle de données pour produire les interfaces Crud correspondantes. Cette fonctionnalité génère à la fois la navigation, les vues, les modèles de données, et les tests unitaires associés. Lorsque le développeur souhaite adapter le squelette de l'application, il peut réaliser toutes les opérations -  manipuler les données de la base relationnelle, créer d'autres vues et règles métier  - avec un seul langage (Ruby) et un seul framework (Rails).

Ce framework, très séduisant, possède encore quelques lacunes. Les outils de développement restent, en effet, rudimentaires et les offres d'hébergement sont quasi inexistantes. En plus, les prestataires réellement expérimentés se comptent pour l'instant sur les doigts d'une main dans chaque pays. Des défauts de jeunesses qui seront vite corrigés.

En revanche, il souffre de deux autres défauts plus handicapants. Tout d'abord, même si 37 signals se targue de posséder 500 000 utilisateurs pour son application gestion de projet Basecamp, personne n'a de réel retour d'expérience sur sa capacité à monter en charge. C'est un problème pour les applications à très forte volumétrie. En outre, Ruby serait plus lent que PHP. Deux problèmes qui devraient être résolus à terme avec Yarv. Cette machine virtuelle, en cours d'écriture, accélérera ainsi l'exécution des applications avec du code précompilé. Et les efforts de Sun autour de JRuby devraient aller dans le même sens.

Dernière limite, conceptuelle celle-là. Rails s'avère très mal adapté à la reprise d'applications existantes, surtout si le modèle de données existe déjà et qu'il n'est pas parfait. « Rails est surtout adapté au développement de nouvelles applications métier, et autour de gros projets dans lesquels on manipule et met en forme de nombreuses données. Le gain sera encore plus significatif si le besoin d'interaction avec les données devient très intense », analyse Nicolas Cavigneaux, ingénieur développement spécialiste de Rails. Pour ne rien gâcher, Rails brille aussi sur les projets Web 2.0. Il comprend nativement les méthodes Ajax et peut, via certains modules complémentaires, générer des interfaces utilisateur évoluées.