06.10.2026 · Signal Titans Editorial
Yukihiro Matsumoto a bâti Ruby autour d’une idée radicale : programmer devrait être agréable.

Yukihiro « Matz » Matsumoto n’a pas commencé Ruby parce qu’une entreprise lui avait remis un cahier des charges commercial. Il l’a commencé parce que les langages disponibles ne lui convenaient pas vraiment. Dans son propre récit rétrospectif, Ruby est « né » le 23 février 1993, au cours d’une conversation sur la création d’un langage de script orienté objet. Il voulait quelque chose de pratique au quotidien, mais aussi réellement orienté objet et agréable à utiliser.
Un langage né d’une insatisfaction, pas d’un plan d’affaires
Matsumoto connaissait déjà Perl et Python, mais aucun ne correspondait au langage qu’il cherchait. Il appréciait la rapidité d’expression des langages de script, tout en souhaitant un modèle objet plus cohérent et une conception dans laquelle l’orientation objet ne semblerait pas ajoutée après coup. L’histoire officielle de Ruby explique qu’il a puisé dans des langages qu’il aimait — Perl, Smalltalk, Eiffel, Ada et Lisp — plutôt que d’essayer de réinventer chaque idée. L’originalité venait de la combinaison et surtout de ce qu’il choisissait d’optimiser.
Cette cible était inhabituelle : le programmeur. Matsumoto a souvent résumé son objectif par l’idée de rendre les programmeurs heureux. Dans un entretien de 2003, il expliquait qu’un langage de programmation est une interface entre l’humain et l’ordinateur, et que la partie humaine doit donc compter. Il ne poursuivait pas la simplicité comme une valeur absolue. La documentation officielle de Ruby reprend l’une de ses idées récurrentes : rendre le langage naturel plutôt que simplement simple, même si l’implémentation interne doit devenir plus complexe.
Deux années avant la première diffusion publique
L’idée initiale n’est pas devenue immédiatement un langage mondialement connu. Matsumoto a passé des mois à faire fonctionner un interpréteur et a continué à façonner son design relativement loin de l’attention internationale. Dans une rétrospective publiée en 1999 sur la liste ruby-talk, il écrit que Ruby 0.95 a été diffusé sur des groupes de discussion japonais en décembre 1995. Ruby 1.0 a suivi en décembre 1996. Pendant plusieurs années, une grande partie de la communauté et de la documentation est restée concentrée au Japon.
Ce démarrage lent compte, car l’histoire technologique est souvent réécrite comme une suite de succès instantanés. Ruby n’avait aucune garantie d’adoption mondiale. C’était un projet personnel de conception qui a progressivement trouvé ses utilisateurs. Sa syntaxe laissait de la souplesse, les valeurs se comportaient de manière cohérente comme des objets, et les blocs, itérateurs, exceptions, garbage collection et classes riches permettaient d’écrire de petits programmes expressifs sans empêcher le langage de servir ensuite à des applications plus importantes.
« Programmer happiness » devient une véritable contrainte d’ingénierie
La formule peut sembler vague, mais elle produit des décisions très concrètes. Matsumoto cherche à garder le code proche du modèle mental du programmeur. Il valorise la concision, plusieurs manières de résoudre un problème et des API qui rendent la bonne voie confortable au lieu de l’imposer par des règles rigides. Dans ses entretiens, il insiste aussi sur le métier : lire du code, apprendre d’autres langages, comprendre les fondamentaux et porter une attention particulière aux interfaces.
La philosophie de Ruby devient beaucoup plus visible à l’échelle internationale avec l’expansion de son écosystème, notamment grâce à Ruby on Rails et aux bibliothèques distribuées sous forme de gems. Le site officiel de Ruby évoque aujourd’hui plus de 200 000 gems et attribue à la communauté l’extension du langage bien au-delà de ce qu’une seule personne pourrait construire. Matsumoto a créé le langage, mais sa longévité dépend des personnes qui ont développé frameworks, bibliothèques, outils, documentation et communautés locales.
Une philosophie de conception qui a survécu au problème d’origine
Ruby n’a jamais été la seule réponse au développement logiciel, et ce n’était pas l’ambition de Matsumoto. Sa contribution plus profonde est l’idée que l’expérience du développeur n’est pas une décoration ajoutée après la « vraie » ingénierie. La syntaxe, le comportement des erreurs, les bibliothèques et les conventions modifient la façon dont les gens pensent, la vitesse à laquelle ils transforment une idée en code fonctionnel et le sentiment de lutter contre une machine ou, au contraire, d’exprimer une intention.
Trois décennies après ses premières versions publiques, Ruby continue d’être maintenu, utilisé et discuté. De nouveaux langages sont apparus, le matériel a profondément changé et le développement logiciel traite désormais de problèmes qui existaient à peine en 1993. Pourtant, la question située derrière Ruby reste actuelle : lorsque nous concevons un système technique, quelle expérience cherchons-nous à optimiser ? La réponse de Matsumoto était particulièrement claire. La machine compte, mais la personne qui l’utilise compte aussi.