Lorsqu’on commence un nouveau projet informatique, une question qui revient parfois – en particulier si l’équipe est relativement jeune – est : « Quel langage / framework devons-nous utiliser ? Quel est le meilleur langage de programmation du moment ? ». On entre alors dans un long débat ; tel langage contient plus de modules et a une communauté plus grande, tel autre est plus performant ou propose une meilleure CI/CD.

À la recherche de la perfection

En tant que lead dev, j’ai parfois dû répondre moi-même à cette question. Lorsqu’un nouveau projet était lancé dans le groupe, on attendait de moi que j’indique la meilleure voie à suivre, celle qui allait garantir le succès du projet. À l’inverse, j’ai aussi eu l’occasion de voir (et de subir) les effets d’un mauvais choix et donc d’une mauvaise réponse à cette question.

Alors, quel est le meilleur langage de programmation et le meilleur framework ? Si vous êtes un manager sur le point de lancer un nouveau projet, vous êtes au bon endroit : je vais vous donner LA réponse à cette question. Si vous êtes développeur et que vous débattez avec vos collègues pour savoir quelle stack est la plus optimisée, bienvenue également !

Je pourrais vous proposer des graphiques avec le nombre de réponses StackOverflow par langage pour parler de la popularité des langages, comptabiliser le nombre de paquets dans le gestionnaire de paquets du langage, le nombre de stars github pour chaque framework, vous faire un comparatif des performances dans un superbe benchmark couvrant toutes les situations… mais ce ne serait pas une bonne manière de répondre. Toutes ces façons de comparer des langages viennent d’une incompréhension profonde, mais trop répandue, sur le métier de développeur.

Le vrai métier de développeur

En tant que développeur, notre métier n’est pas d’écrire du code, mais de résoudre des problèmes.

Si vous êtes payé au nombre de lignes de code que vous écrivez, ou si vous pensez que votre productivité s’évalue au nombre de commits faits par jour, alors votre employeur (ou vous) n’avez rien compris à ce que vous faites. Je peux écrire un code de 8000 lignes pour faire un Hello World. Ça n’aura aucun intérêt, ce sera lent, plein de tests idiots, mais c’est techniquement réalisable. Ce n’est pas pour ça que cela aura de la valeur. À l’inverse, un jour un collègue avait une base de données de plusieurs milliers de lignes dans un format inutilisable pour lui ; avec un script de quinze lignes j’ai transformé cette base pour qu’il puisse l’intégrer à ses outils et s’en servir et je lui ai fait gagner deux mois de travail de conversion manuelle.

Alors, en quoi est-ce lié au meilleur langage de programmation ? En tout. Si notre métier n’est pas d’écrire du code, alors notre choix de langage ou de framework ne doit pas être basé sur la vitesse du framework ou le nombre de sucres syntaxiques abscons permettant de faire les choses de manière plus courte. En réalité, dans l’écosystème des langages de programmation moderne, les performances sont comparables lorsqu’on les regarde à une échelle humaine. En d’autres termes, même si d’un framework à l’autre on pourra avoir un facteur 2 ou 3 en termes de vitesse, la variation est trop faible pour être réellement notable par un utilisateur humain. C’est encore plus vrai lorsqu’on prend en compte le fait que la majeure partie des différences de performances sont liées à l’implémentation de l’application elle-même, pas du framework ou du langage.

Le nombre de paquets disponibles, d’extensions, de questions SO, toutes ces valeurs semblent au premier abord plus intéressantes : effectivement, si dans un langage il est possible de ne pas réinventer la roue, autant se diriger vers celui-ci, n’est-ce pas ? Mais c’est là encore un leurre. En réalité, si l’écosystème de chaque langage / framework est bien entendu très différent, la majeure partie des langages modernes proposent des solutions pour faire la quasi-totalité des applications de manière sensiblement similaire. Bien entendu, le fait de faire du web ou de l’application lourde aura un impact, mais pour le reste, que vous fassiez du Ruby, du Python, du PHP, du Rust, du Node, du Java ou même du R, vous trouverez un package permettant de faire une API, de vous connecter à une base de données ou de parser du JSON. Si votre cas est trop spécifique pour être présent dans un langage, alors il est probablement trop spécifique pour être présent tout court. Il existe quelques exceptions à cette règle (je pense par exemple à l’intelligence artificielle qui est principalement faite en Python et en Java) mais elles sont plus que rares.

Faire un choix

Alors, quel critère retenir ? C’est très simple : celui de votre équipe. Apprendre un nouveau langage a un coût en temps. Il faut plusieurs mois, et même souvent plusieurs années, pour être aussi efficace avec un nouveau langage ou un nouveau framework qu’avec celui qu’on pratique quotidiennement depuis notre sortie du lycée. C’est du temps que vous ne passerez pas à développer de nouvelles fonctionnalités, à répondre aux besoins de vos clients, bref, à résoudre des problèmes. De fait, le meilleur langage de programmation, la meilleure stack, c’est celle que votre équipe connait et maîtrise.

Est-ce que cela veut dire qu’on ne doit jamais faire évoluer son équipe – et sa stack – vers de nouveaux langages ? Bien évidemment, non. Mais migrer vers un nouvel outil ne doit pas se faire parce que le nouvel outil est meilleur, mais parce que l’ancien n’est plus assez bien. Si vous trouvez que votre environnement actuel (ou celui de vos précédents projets) ne répond plus à vos attentes, vous ralentit et augmente la complexité de votre travail, alors oui, il est temps d’en changer. Mais dans ce cas, vous aurez une liste précise de besoins : pourquoi votre ancienne stack ne vous convient plus ? Qu’est-ce qu’elle rend plus difficile ? Qu’est-ce que vous devez améliorer ? Vous ne chercherez pas le meilleur langage, vous chercherez celui qui répond à vos nouveaux besoins. Vous pourrez de plus prendre en compte le temps de formation à ce nouveau langage dans votre vélocité.

Et vous, quelle(s) technologie(s) utilisez-vous sur vos projets, et pourquoi ?