# Choisir ses langages : douze ans, beaucoup de réponses, une nouvelle question

> De Scala à Kotlin puis à Go : douze ans de choix de langages back-end, les leçons derrière chaque changement, et pourquoi l'IA pourrait décider du prochain.

Source: https://www.bluewise.fr/fr/choosing-languages-a-journey-in-plurals-with-new-destination  
Author: Marc Morel  
Published: 2026-04-15  
Category: Engineering

## Des langages, au pluriel, avec une nouvelle destination

J'ai écrit *langages*, et non *langage*, à dessein. Il n'existe pas de réponse unique à la question « quel langage de programmation devrions-nous utiliser ? », et quiconque vous en propose une en une phrase n'a probablement jamais eu à vivre avec les conséquences.

La réponse dépend, d'abord et avant tout, de ce que vous construisez. Ensuite, elle dépend de tout ce qui entoure le code : le confort de ce que vos équipes connaissent déjà bien, la profondeur de leur expertise, les évolutions du marché, et les avantages et inconvénients très réels du recrutement sur une stack plutôt qu'une autre. Un langage est un choix technique, mais c'est aussi un choix humain, économique et organisationnel.

Dans mon cas, le pluriel n'a jamais été une posture philosophique. C'était une contrainte ferme. Nous construisions des apps mobiles natives, chaque plateforme avec son propre langage et sa propre chaîne d'outils. Nous construisions des sites web avec des front-ends riches et complexes. Nous exposions des API et traitions de gros volumes de données. Aucun langage unique ne pouvait bien servir tout cela, et prétendre le contraire aurait été une illusion coûteuse.

Côté front-end, nous avons choisi **Nuxt et Vue.js avec TypeScript**. TypeScript nous a apporté ce qui manquait depuis longtemps au code front-end : un langage typé, soutenu par un excellent linting, qui attrape les erreurs avant les utilisateurs.

Nous n'avons délibérément pas choisi React. Non pas faute de qualités, mais parce que, pour une équipe comme la nôtre, il évoluait beaucoup trop vite. Même les briques les plus élémentaires étaient des cibles mouvantes. Prenez React Router : quelque chose d'aussi fondamental que naviguer d'une page à une autre a vu son API réinventée d'une version majeure à l'autre. Chaque montée de version ressemblait à un petit tremblement de terre. Les patterns que nous venions de maîtriser étaient dépréciés ; les tutoriels d'il y a six mois ne s'appliquaient plus ; et expliquer au métier qu'un sprint serait consacré à réapprendre comment *naviguer entre les pages* était une conversation que personne ne voulait avoir deux fois. Nous voulions construire des produits, pas courir après un framework.

Pour les API et le Big Data, **Python** était, et reste, un citoyen de première classe. Son écosystème data, ses bibliothèques et son adoption par les data engineers le rendent irremplaçable dans ce domaine.

Cet article se concentre cependant sur une partie de ce paysage : **les langages back-end**. C'est là que mes décisions les plus importantes ont été prises, là qu'elles ont eu l'impact le plus profond sur les équipes, la delivery et les coûts, et là que l'histoire a été la plus mouvementée, de 2014 à aujourd'hui. Les choix front-end, mobile et data ci-dessus sont le décor ; le back-end est le voyage.

Dans cet article, je veux partager un parcours qui s'étend sur plusieurs années : les décisions de langage que j'ai prises en tant que responsable technique, ce qui a fonctionné, pourquoi cela a fonctionné, et pourquoi, à certains moments, j'ai dû changer des choix qui fonctionnaient encore. Non pas parce qu'ils avaient échoué, mais parce que le contexte autour d'eux avait bougé.

## Acte I (2014) : Scala, faire revenir les talents dans une maison JVM en difficulté

Ma première grande décision de langage en tant que responsable technique est arrivée à un moment difficile. Je dirigeais une maison principalement JVM, principalement Java, qui avait grand besoin de renouveau. Les équipes étaient bloquées. Les livraisons étaient devenues rares. Et, comme souvent quand le succès disparaît, la pression ne cessait de monter, jusqu'à ce que les frictions entre équipes se transforment en comportements réellement toxiques et que le moral atteigne son point le plus bas.

Dans cette situation, je ne voulais pas ajouter un bouleversement technique au bouleversement humain. J'ai donc fait un choix délibéré : **garder la JVM**. C'était un environnement d'exécution bien connu et éprouvé, que nos opérations comprenaient, avec un vaste écosystème de bibliothèques sur lequel nous pouvions continuer à nous appuyer. Ce que je voulais changer, ce n'était pas le runtime, c'était qui voulait nous rejoindre, et l'énergie que ces personnes apporteraient.

Mon pari pour attirer les meilleurs talents a été **Scala**, un langage compatible JVM qui, à l'époque, exerçait un fort attrait sur les ingénieurs ambitieux. Ses avantages étaient réels :

- **L'expressivité.** Une syntaxe concise, une inférence de types puissante et des fonctions d'ordre supérieur nous permettaient de dire beaucoup avec peu de code.
- **La programmation fonctionnelle comme citoyenne de première classe.** L'immuabilité par défaut, le pattern matching et les case classes encourageaient un code plus facile à raisonner et plus sûr en concurrence.
- **Un système de types puissant** capable d'encoder des règles métier et d'attraper des classes entières d'erreurs à la compilation.
- **Une interopérabilité Java transparente.** Nous gardions toutes les bibliothèques Java dont nous dépendions, et pouvions migrer progressivement plutôt que réécrire.
- **Un écosystème riche pour les systèmes concurrents et intensifs en données**, avec Akka, Play et Spark parmi ses fleurons.
- **Un aimant à talents.** Scala signalait une ambition d'ingénierie, et attirait des personnes profondément attachées à leur métier.

Et cela a fonctionné. Dans une maison de notre taille, une quarantaine de développeurs, une poignée de personnes très talentueuses et très motivées change tout. Des projets bloqués depuis des mois ont recommencé à avancer. Nous avons livré de la valeur métier rapidement, et la base de code est devenue plus propre en chemin. Surtout, le moral a commencé à remonter : le succès engendre la confiance, et la confiance engendre la collaboration. C'était un premier succès, authentique.

### Le prix de la puissance

Mais Scala est difficile. Difficile à bien écrire, et encore plus difficile à lire, surtout dans une équipe où experts et débutants travaillent côte à côte sur la même base de code. La flexibilité même qui ravissait nos ingénieurs les plus seniors devenait une source de friction pour tous les autres.

Avec le temps, les coûts sont devenus impossibles à ignorer :

- **Plusieurs langages en un.** Scala peut s'écrire comme « un meilleur Java » ou comme de la programmation fonctionnelle pure avec des bibliothèques avancées. Sans une discipline forte, une même base de code finit par contenir plusieurs dialectes.
- **Les implicites et la profondeur d'abstraction.** Les conversions et paramètres implicites, les opérateurs symboliques et les constructions avancées au niveau des types pouvaient rendre quelques lignes de code presque opaques pour quiconque n'en était pas l'auteur.
- **Une compilation lente.** Les temps de build augmentaient avec la base de code, allongeant la boucle de rétroaction dont les développeurs dépendent à chaque minute de la journée.
- **Un outillage peu commode.** L'outil de build avait sa propre courbe d'apprentissage abrupte, et le support des IDE peinait à suivre les fonctionnalités les plus avancées du langage.
- **Des montées de version fragiles.** L'incompatibilité binaire entre versions majeures transformait chaque montée de version en un effort coordonné à travers les bibliothèques.
- **Un vivier de recrutement plus étroit.** Les ingénieurs Scala expérimentés étaient rares et chers, et l'intégration des nouveaux venus prenait longtemps.

Au final, il nous manquait ce que je considère comme la marque d'une excellente ingénierie : **faire des choses complexes avec simplicité**. Au lieu de cela, nous faisions trop souvent des choses simples avec complexité. Ce n'était pas aussi efficace que cela aurait dû l'être.

## Interlude (2016) : Kotlin, le juste milieu équilibré

Avant d'aller plus loin, nous avons cherché un chemin plus doux en terrain connu. Ce chemin a été **Kotlin**, et pendant un temps ce fut un choix réellement bon et équilibré. Il conservait tout ce que la JVM nous avait apporté, tout en supprimant une grande partie de ce qui rendait Scala difficile à vivre :

- **Toujours la JVM.** Même runtime, mêmes opérations, mêmes bibliothèques, et une interopérabilité totale avec notre code Java et Scala existant. Aucune migration big-bang nécessaire.
- **Moderne, mais lisible.** Une syntaxe concise, des data classes, des fonctions d'extension et des constructions fonctionnelles là où elles aident, sans la profondeur d'abstraction qui rendait le code Scala opaque pour les nouveaux venus.
- **La sûreté là où elle compte le plus.** La null safety intégrée au système de types supprimait l'une des sources d'erreurs de production les plus courantes sur la JVM.
- **Une concurrence pragmatique.** Les coroutines offraient une façon lisible d'écrire du code asynchrone, sans adopter un paradigme de programmation entièrement nouveau.
- **Un outillage de première classe.** Conçu par les créateurs d'IntelliJ, Kotlin bénéficiait d'un excellent support IDE dès le premier jour, et la compilation était nettement plus rapide qu'avec Scala.
- **Un vivier de talents plus large.** Les développeurs Java devenaient productifs en quelques semaines, et le statut de Kotlin comme langage de référence pour Android élargissait le vivier de personnes qui le connaissaient déjà.

Kotlin a rétabli un équilibre sain entre expressivité et simplicité, et nos vétérans Java comme nos experts Scala y ont trouvé leur place. Mais il n'a pas changé une chose fondamentale : nous tournions toujours sur la JVM. À mesure que notre migration vers Google Cloud Platform (GCP) s'accélérait, l'empreinte mémoire, le temps de démarrage et la consommation de ressources devenaient des préoccupations de premier ordre. C'est dans ce contexte qu'a commencé le chapitre suivant.

## Acte II (2017 à aujourd'hui) : Go, la force tranquille d'un langage ennuyeux

Le tournant suivant est venu, comme souvent les bonnes idées, de quelqu'un sur le terrain. Un prestataire de mon équipe ([Vincent Spiewak, qui a décrit les détails techniques ici](https://vspiewak.com/how-a-jvm-shop-became-a-go-shop/)) est venu me voir et m'a dit qu'il voulait construire une preuve de concept en **Go**.

Le nom ne m'était pas inconnu. D'anciens collègues de mes entreprises précédentes, qui travaillaient alors dans des endroits comme Algolia, et bien sûr Google, m'en parlaient depuis un moment. J'ai donc dit oui.

La preuve de concept a été un grand succès. Go est un langage ennuyeux, et c'est précisément sa force. Il y a généralement une seule façon évidente d'écrire quelque chose. Le code écrit par un ingénieur senior ressemble beaucoup au code écrit par un nouveau venu. Un formateur standard met fin aux débats de style avant qu'ils ne commencent. Lire le code de quelqu'un d'autre cesse d'être une enquête.

L'écosystème était déjà mature et couvrait toute notre stack : PostgreSQL, Elasticsearch, microservices et API. Une bibliothèque standard solide, une compilation rapide et des binaires statiques uniques rendaient le développement et le déploiement d'une simplicité rafraîchissante.

Ce qui m'a finalement convaincu, ce sont **les performances et la consommation de ressources**. Nous étions en pleine migration massive vers le cloud, où chaque mégaoctet de mémoire et chaque cycle CPU apparaît sur la facture. Des goroutines légères, une faible empreinte mémoire, un démarrage rapide et des images de conteneurs compactes faisaient de Go un excellent choix pour cette nouvelle réalité.

Ce fut un autre grand succès. Nous avons fait venir des prestataires Go professionnels avec quelques années d'expérience, des personnes très talentueuses, une fois encore. Et les développeurs Scala étaient contents aussi : ils ont trouvé un langage rapide à apprendre et offrant des performances impressionnantes. L'adoption a été rapide, et largement enthousiaste. Depuis 2017, Go est resté notre langage back-end de prédilection, et il l'est toujours aujourd'hui.

## Acte III : 2026, un changement majeur en deux lettres

> Aujourd'hui, en 2026, un changement majeur tient en deux lettres : **IA**.

Après les premières expérimentations, et avec des modèles et des harnais d'agents qui évoluent à un rythme remarquable, une chose m'est apparue clairement : le développement logiciel n'est plus ce qu'il était. Les agents écrivent, refactorent et testent désormais une part croissante de notre code, et ils passent progressivement du statut d'assistants à celui de véritables contributeurs.

Avec le recul, les moteurs de mes choix de langage ont évolué à chaque chapitre. D'abord, c'étaient des questions de **ressources humaines** : turnover, attraction des talents, recrutement. Puis ce sont devenues des considérations de **FinOps et d'efficacité** : performances, consommation de ressources, coût d'exploitation dans le cloud.

Aujourd'hui, je crois que les choix de langage devraient, et peut-être très bientôt *devront*, être guidés par un nouveau facteur : **les préférences des agents**.

## La grande inversion

Dans ce contexte, certains langages apparaissent très différemment de ce qu'ils étaient il y a quelques années. **Rust** en est l'exemple le plus clair. Pour les humains, sa courbe d'apprentissage est réputée abrupte : ownership, borrowing et lifetimes demandent du temps et de la patience à maîtriser. Pour les agents, cette même rigueur devient un atout, ce qui fait de Rust un choix très convaincant pour les back-ends :

- **Le compilateur comme relecteur infatigable.** Les messages d'erreur précis et exploitables de Rust donnent à un agent une boucle de rétroaction immédiate et fiable. Il itère face au compilateur jusqu'à ce que le code soit correct.
- **Des classes entières de bugs éliminées par construction.** La sûreté mémoire et l'absence de data races sont garanties à la compilation, plutôt que laissées à la vigilance d'une revue de code.
- **L'explicite partout.** Types, erreurs et ownership sont tous écrits en toutes lettres dans le code, laissant très peu de contexte implicite à deviner pour un agent.
- **Des performances et une sobriété exceptionnelles**, ce qui garde les leçons FinOps du chapitre précédent pleinement d'actualité.

C'est là que je vois une sorte d'inversion. Pour les humains, j'ai choisi des langages qui réduisaient la charge cognitive : simples, lisibles, rapides à apprendre, les raisons mêmes pour lesquelles Go l'a emporté. Pour les agents, la courbe d'apprentissage compte beaucoup moins. Ce qui compte, c'est tout ce que le langage vérifie lui-même, à quel point il est explicite, et à quelle vitesse il vous dit que vous avez tort.

Autrement dit, **les langages que je choisirais pour des humains et ceux que je choisirais pour des agents ne sont plus nécessairement les mêmes.**

## Ce qui change

Avec le recul, chaque choix était juste pour son époque, et chacun a fini par devoir céder la place au suivant.

| Chapitre | Langage | Moteur principal | Ce qu'il nous a apporté | Pourquoi nous sommes passés à autre chose |
| --- | --- | --- | --- | --- |
| Acte I (2014) | Scala (sur la JVM) | Les personnes : turnover, attraction des talents | Des experts motivés, des projets débloqués, une base de code plus propre | Trop difficile à bien écrire et à lire dans une équipe hétérogène ; builds lents, outillage difficile |
| Interlude (2016) | Kotlin (sur la JVM) | L'équilibre : l'expressivité sans la complexité | Code lisible, null safety, excellent outillage, recrutement plus facile | Toujours la JVM : empreinte et coûts de ressources lors de la migration vers le cloud |
| Acte II (2017 à aujourd'hui) | Go | L'efficacité : coûts cloud, performances, simplicité | Adoption rapide, code lisible, une empreinte sobre | Toujours notre langage back-end, mais le contexte évolue |
| Acte III (2026) | Rust, entre autres | Les agents : à quel point un langage fonctionne bien pour l'IA | Un compilateur qui relit chaque ligne, la sûreté par construction | L'histoire reste à écrire |

Ce qui n'a pas changé, c'est le principe dont je suis parti : des langages, au pluriel. Un choix de langage n'est jamais purement technique. Il reflète ce que vous construisez, qui le construit, ce que le marché offre et ce que cela coûte, et désormais, *qui* ou *quoi* écrit le code.

Le meilleur choix est rarement le plus à la mode. C'est celui qui convient à votre contexte aujourd'hui, fait avec l'humilité de le revoir demain.