Les langages de programmation les plus populaires en 2025

• Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
• Selon l’enquête IEEE Spectrum, Python conserve cette année encore la 1re place, tandis que JavaScript recule de la 3e à la 6e place
• Cette évolution serait liée à une tendance où JavaScript, très utilisé pour le développement web, est remplacé par le codage assisté par l’IA (par ex. le vibe coding)
• Les indicateurs traditionnellement utilisés, comme le nombre de questions sur Stack Exchange ou l’activité sur GitHub, ont fortement chuté depuis l’adoption de l’IA, ce qui remet en cause les méthodes classiques de mesure de la popularité des langages
• Avec la généralisation de la génération de code par l’IA, l’importance des différences de syntaxe et de structure entre les langages diminue, et la tendance à ne plus s’attacher à un langage particulier devient nette
• Cela pourrait freiner l’émergence de nouveaux langages et l’expansion de leurs écosystèmes, et même conduire à la disparition du concept même de popularité des langages de programmation

---

Aperçu

• IEEE Spectrum a publié une analyse globale des principaux langages de programmation et des tendances de 2025
• Ce classement reflète plusieurs points de vue, dont le marché de l’emploi, l’écosystème open source, ainsi que l’usage dans le monde académique et dans l’industrie
• L’analyse fournit aussi des informations sur les caractéristiques des principaux langages, les raisons de leur progression et les langages spécialisés selon les domaines techniques

Classement des langages cette année

• Dans le classement de base Spectrum de 2025, Python reste n°1, tandis que JavaScript tombe à la 6e place
• Dans le classement Jobs aussi, Python s’est hissé à la 1re place, et SQL conserve une forte compétitivité sur le marché de l’emploi
• Le nombre total de questions sur les langages dans Stack Exchange a chuté à 22 % du niveau de 2024

Critères de calcul du classement

• Popularité : calculée à partir de divers forums en ligne, dépôts logiciels, données d’offres d’emploi et tendances de recherche
• Usage en production : analyse des langages effectivement les plus utilisés sur le marché à partir des offres de recrutement des entreprises et de la participation aux projets open source
• Analyse par domaine : prise en compte de critères permettant d’identifier les langages qui se distinguent dans des secteurs comme l’IA, l’embarqué, le web ou le mobile
• Pour mesurer la popularité, divers indicateurs ont été utilisés, comme le volume de recherches Google, les questions Stack Exchange, l’activité GitHub ou les mentions dans les publications scientifiques
• Mais à mesure que les développeurs résolvent leurs problèmes via des conversations avec des LLM (ChatGPT, Claude, etc.), les signaux de données publiques diminuent
• Grâce aux outils d’IA (comme Cursor), le nombre même de questions baisse, ce qui affaiblit la validité des indicateurs existants

L’IA brouille les frontières entre les langages

• Des développeurs expérimentés aux débutants, la dépendance à l’IA réduit l’attention portée à la syntaxe et aux structures de contrôle des langages
• Avec suffisamment de données d’entraînement, l’IA peut générer du code dans n’importe quel langage
• Le choix du langage pourrait ainsi devenir un facteur secondaire, comme les différences d’instructions CPU au niveau matériel
• À l’avenir, les débats sur la popularité des langages pourraient être relégués au rang de sujet de niche, comparable à une discussion sur l’écartement des voies ferrées

L’émergence de nouveaux langages deviendra encore plus difficile

• Autrefois, un écosystème de langage pouvait se diffuser à partir de livres, de démos et d’exemples de code (par ex. The C Programming Language)
• Mais comme l’IA exige de grandes quantités de données d’entraînement, les nouveaux langages partent avec un désavantage en matière de support
• Il a d’ailleurs été observé que l’IA produit de moins bons résultats dans les langages moins utilisés
• Cela pourrait créer un environnement dans lequel il devient difficile pour un nouveau langage d’atteindre une masse critique

L’avenir de la programmation

• Les langages modernes remplissent essentiellement deux rôles : l’abstraction du traitement des données et la prévention des erreurs des développeurs
• Mais les progrès de l’IA ouvrent la voie à un nouveau flux centré non plus sur la structure du langage, mais sur prompt → langage intermédiaire → exécution
• Dans ce cas, au lieu de maintenir et modifier le code source, une approche fondée sur la régénération via l’ajustement du prompt pourrait s’imposer
• Le rôle du programmeur de demain devrait se concentrer moins sur la syntaxe du langage que sur la conception d’architecture, le choix des algorithmes et l’intégration système

Conclusion et perspectives

• La programmation traverse sa plus grande transformation depuis l’apparition des compilateurs dans les années 1950
• Même si la bulle de l’IA se dégonfle en partie, l’usage des LLM pour aider à écrire du code a de fortes chances de perdurer
• À partir de 2026, le concept même de « langage populaire » pourrait donc perdre de sa pertinence, et de nouveaux indicateurs pour mesurer la popularité deviendraient nécessaires

[skrevolve]

Python est quand même en baisse.

[shakespeares]

Pour l’instant, l’écosystème de JavaScript reste de loin bien plus vaste, mais avec l’IA, je pense qu’il y a une possibilité d’aller vers des langages de plus bas niveau comme Rust.

[GN⁺]

Commentaires Hacker News

• Avec l’aide de l’IA, les programmeurs se préoccupent de moins en moins d’un langage précis ou de ses détails, mais au final, le destin veut qu’un petit problème soit relié à toute une série de complexités et nous force à replonger en profondeur. Tout le monde ne vise pas le niveau assembleur comme les code golfers de ffmpeg, mais il doit bien y avoir une raison pour laquelle les langages de troisième génération gardent encore leur présence. Au fond, c’est un compromis entre expressivité et précision, entre ce sur quoi nous voulons nous concentrer et les détails que nous voulons déléguer. Si l’on abandonne les lunettes (la transparence) pour obtenir des résultats plus rapides, il faut alors un mécanisme d’observation alternatif solide pour vérifier ce qui se passe ensuite.
  • Il faut garder à l’esprit que cet article vient de l’IEEE. Le public visé par l’IEEE, ce sont davantage les scientifiques que les programmeurs. Pour les scientifiques, le code est un moyen d’exprimer leurs idées, et tant qu’ils peuvent les exprimer le plus vite possible, le fait que le code soit désordonné ou peu réutilisable leur importe peu. Par exemple, le fait que des scientifiques mentionnent Arduino comme un langage leur paraît naturel. Les scientifiques qui utilisent Arduino ne connaissent pas forcément le C++, mais ils sont fiers de pouvoir coder en « Arduino ».
  • Ce sont clairement deux cas très différents. Si un compilateur produit un mauvais résultat pour une architecture donnée, on peut soumettre un bug report et obtenir de l’aide de la communauté ou de l’extérieur. En pratique, ce genre de choses est rare avec les langages ou bibliothèques populaires, et si l’on s’aventure à ce point dans les cas limites, c’est qu’on a déjà les compétences pour les traiter. Mais si une IA donne un mauvais résultat, il faut tout découvrir soi-même. On ne peut pas vraiment aller demander à OpenAI ou Anthropic « pourquoi ça fait ça ? ». Dans le premier cas, il est parfois acceptable de ne pas tout savoir ; dans le second, ce ne l’est absolument pas.
  • Si la majorité des développeurs se désintéressaient vraiment du jeu d’instructions des CPU ou des particularités du matériel, on ne générerait même pas une syntaxe de langage : on générerait directement du code machine pour l’architecture cible. On enverrait peut-être même simplement un prompt et une AI VM produirait le code machine final. Cela arrivera peut-être un jour, mais nous n’en sommes absolument pas là aujourd’hui.
  • Utiliser l’IA dans un domaine que l’on maîtrise mal est vraiment dangereux, et je pense qu’il ne faut pas encourager cela.
  • Ils n’ont fait qu’élargir la « large planche au-dessus de l’abîme ».
• Il est très difficile de trouver de bonnes sources pour ce genre de données. StackOverflow est aussi en déclin, et la méthodologie de l’IEEE reste malgré tout assez réaliste, mais toutes les sources de données utilisées ont leurs propres défauts. Le nombre de résultats Google est le signal indirect le plus instable. Les résultats de recherche incluent à peu près tout ce qui mentionne la requête, sans aucune garantie que cela représente réellement 2025. En plus, les gens qui utilisent un langage ne l’expriment généralement pas explicitement comme « langage de programmation X ». Considérer toute visibilité médiatique comme une exposition de « top language » est forcé. TIOBE utilise aussi cette méthode et, sans gêne, affiche une popularité au centième près. Si l’on regarde les anciennes données, la popularité du C a chuté de moitié en seulement deux ans, puis a doublé l’année suivante, alors que le marché réel n’avait absolument pas changé. La marge d’erreur de cette méthode est de ±50 %.
  • Pour mesurer la demande réelle d’un langage, les données d’offres d’emploi sont les plus pratiques et les plus utiles. Elles ne montrent pas directement le volume de code réellement en production dans les entreprises, mais dans la plupart des cas elles donnent la vision la plus intuitive de l’usage réel, de la demande et des tendances du secteur. Bien sûr, si une grande organisation utilise massivement quelque chose comme COBOL dans une banque mais qu’il y a très peu de mobilité, cela peut ne pas apparaître dans les données ; malgré cela, on n’a pas vraiment de meilleure source.
  • Ces sources sont souvent auto-renforçantes et auto-référentielles. Il vaut mieux utiliser l’outil qui est le meilleur, celui que je maîtrise le mieux, celui que veulent les clients ou celui qui rapporte le plus. Ada, COBOL, FORTH, Lua, etc. relèvent aussi de ce contexte. En dehors du SEO, les métriques de popularité n’ont au fond pas beaucoup de sens.
    • Lien vers le cas Ada
    • Lien vers le cas COBOL
    • Lien vers le cas FORTH
    • Lien vers le cas Lua
  • Chez TIOBE, Perl est soudain entré dans le Top 10 cette année, mais je n’ai jamais vu de nouveau développeur Perl. Même chose pour Ada. Je me demande bien où sont tous les développeurs Ada.
  • Ce que j’aime dans ce genre de statistiques, c’est les stats de langage par repo public GitHub. Elles donnent, depuis 2012, le nombre de repos publics et de PR pour chaque langage.
  • Peut-être qu’à ce stade, les statistiques de requêtes LLM sont la meilleure source possible. L’article lui-même (TFA) en parle longuement.
• Je pensais que JavaScript serait numéro 2, mais on dirait que TypeScript lui a pris sa place. Personnellement, je considère JavaScript et TypeScript comme relevant presque de la même famille, donc je pense qu’il faudrait additionner leurs scores.
  • Dans ce type de classement, il faut les regrouper pour considérer qu’ils sont vraiment deuxièmes.
  • Il faut effectivement fusionner ces deux-là, et d’ailleurs je ne comprends toujours pas pourquoi Arduino figure dans cette liste.
  • Je suis d’accord aussi. Il y a d’autres éléments à regrouper, et il serait souhaitable de rassembler également les langages basés sur la BEAM.
  • Si l’on fusionne aussi Java & Kotlin, C & C++, alors JS & TS ne seront peut-être même pas deuxièmes.
• Ceux qui sont surpris de voir Java classé aussi haut : vous n’avez fait que du backend nodejs dans des startups de 10 personnes pendant toute votre carrière ? Vous n’avez jamais travaillé dans de grandes entreprises, en particulier dans l’enterprise software ?
  • Java est désormais le nouveau COBOL. La finance, l’assurance et la santé se sont massivement tournées vers Java il y a des décennies, et la migration de l’ancien code COBOL vers Java continue encore.
  • Il y a aussi quelque chose d’un peu étrange : j’ai travaillé plus de cinq ans chez Google et je savais déjà par les statistiques qu’il y avait énormément de code Java, mais en pratique je n’ai regardé du code Java que trois fois. J’ai l’impression que Java est très utilisé, mais dans des zones isolées à l’intérieur même des entreprises, comme s’il était cantonné à un segment précis de la chaîne de valeur économique.
  • Ceux qui sont surpris par la place élevée de Java ne viennent probablement pas de la finance. Bien sûr, l’enterprise ne se résume pas à Java ; dans certaines grandes entreprises hors finance, ce sont Microsoft, .NET et C# qui dominent.
• Je travaille comme développeur backend dans la fintech, et j’ai du mal à trouver un langage cible vers lequel évoluer. J’ai utilisé Node et Ruby, puis l’absence de système de types statiques m’a de plus en plus frustré. Même TypeScript a montré ses limites avec des options comme non strict. Des langages comme Java/.Net ou Go me donnent une impression vieillotte. Rust semble intéressant, mais ne correspond pas vraiment à mon parcours. Je me demande s’il y a un langage recommandable.
  • Si tu comptes rester dans la fintech, il n’y a pas vraiment grand-chose en dehors de Java, C#, C++, TypeScript. Cela dit, on trouve parfois aussi des entreprises qui utilisent Haskell, F# ou Scala. Ces langages servent surtout pour des DSL de workflow. Si les array languages t’intéressent, la finance est l’un des rares domaines où ils existent encore. En revanche, ce genre de poste est difficile à trouver. Tu peux regarder Dyalog (APL), J, BQN, Kdb+ (Q), ainsi que les ressources Arraycast.
  • Scala est le meilleur langage que j’aie jamais utilisé. Il combine les qualités de TypeScript avec les points forts de Java et Rust. Et la fintech est l’une des rares niches où l’on peut encore décrocher un emploi en Scala.
  • Rust est un langage généraliste, donc on peut tout faire avec. Mais le plus important reste toujours d’avoir le bon outil. L’écosystème est décisif, et tout dépend de ce que tu comptes développer.
  • Je me pose la même question, et j’ai l’impression que Gleam est le plus adapté. Il réunit à la fois la simplicité de Go et la commodité de Kotlin.
  • Java est lent, mais sa syntaxe s’améliore, et il constitue l’ossature de beaucoup d’entreprises de taille moyenne ou grande. Dans les petites structures, il est plus facile de trouver du JS/Ruby/Python, sans doute parce qu’elles privilégient davantage la productivité et les coûts d’ingénierie. C’est ce qui explique que l’usage des langages interprétés dépasse celui des langages enterprise ou orientés performance.
• Le fait qu’une enquête conclue qu’il y a plus d’utilisateurs de PHP et Ruby que de HTML est étonnant, et le fait même que HTML soit inclus comme langage de programmation est discutable. Il est aussi surprenant qu’Elixir soit derrière OCaml. J’ai déjà vu de grands acteurs sur Elixir, mais cela fait longtemps que je n’ai pas vu OCaml.
  • Cela vient peut-être du fait que peu de gens choisissent HTML comme « langage de programmation que j’utilise ».
  • Des collègues Java de mon premier emploi buvaient dans un parc quand la police leur a demandé leur métier. Ils ont répondu « programmeur », et le policier a réagi : « Ah, HTML donc. »
  • À la question de savoir s’il y a plus d’utilisateurs de PHP et Ruby que de HTML, mon expérience est que les développeurs backend/système étaient bien plus nombreux que les développeurs frontend, dans des proportions allant de 3:1 à 20:1. Cela dépend de la taille de l’entreprise, mais si l’on ne fait que du backend, on peut presque ne jamais toucher à HTML. Même dans des services très centrés sur le web, beaucoup de personnes ne manipulent en réalité jamais de HTML.
  • HTML est bien un langage de programmation à sa manière, mais il est presque jamais utilisé seul. Le fait qu’il apparaisse comme entrée indépendante dans une liste est un peu dénué de sens.
  • Chacun vit dans sa propre bulle ; moi, je continue à penser que Scala est un langage populaire.
• Je suis quand même content que Haskell apparaisse dans le classement, même s’il est au niveau de LabView à peu près (ce qui est un peu choquant). En revanche, l’article lui-même n’est pas très intéressant.
  • Haskell est au moins un langage amusant. Je suis aussi content que Julia, que j’adore, figure cette année dans la liste. C’est un signe qu’il reste encore de l’espoir pour les langages amusants. Après la collaboration SoC entre Intel et NVIDIA, Python et C++ vont probablement continuer à dominer la liste à l’avenir.
  • Comparer Haskell à LabView est quand même assez injuste.
• Je me demande ce qu’est exactement « Arduino ». Si c’est bien l’Arduino DIY que nous connaissons, alors ce n’est pas un « langage », c’est simplement du C++.
  • La documentation Arduino parle effectivement de « Arduino programming language », mais en pratique ce n’est guère plus que du C++ avec quelques typedef ajoutés. Je ne sais pas vraiment pourquoi.
  • C’est le même genre de logique que lorsqu’on classe HTML et CSS comme des langages, ou que des bibliothèques C/Fortran sont appelées bibliothèques « Python ».
  • Ce genre de distinction est étrange et nuit à la crédibilité du graphique. Dans cette logique, il faudrait aussi ajouter son score à celui du C++.
• Je me suis posé une question semblable : est-ce que les assistants LLM vont finir par figer les langages de programmation actuels ? D’après ce que j’ai testé, plus un langage est populaire, mieux les LLM s’en sortent (à cause du volume de données d’entraînement), donc je me demande si cela ne va pas rendre l’adoption de nouveaux langages encore plus difficile. Si l’entraînement des LLM n’avait contenu que du code orienté objet, il aurait sans doute été bien plus difficile de faire progresser d’autres paradigmes aujourd’hui.
  • J’ai récemment travaillé avec un langage peu connu comme Hare, et Claude s’est montré plus utile qu’un moteur de recherche classique (même s’il a aussi raconté des absurdités). J’ai donc l’impression que les LLM n’auront peut-être pas un effet si fort que ça sur la fossilisation des langages.
  • D’après mon expérience, les LLM gèrent mieux les langages populaires, mais pas seulement : ils répètent aussi inutilement des réponses qui s’appuient sur des langages ou des outils connus. Et quand on leur fait remarquer, ils corrigent avec un « Oui, vous avez raison, ce n’est pas indispensable. Je vais vous donner un exemple plus clair et plus approprié… ». Ce serait bien qu’ils le fassent dès le départ, mais le code prend souvent une forme inutilement complexe. Pour un développeur peu expérimenté, il est difficile de filtrer cela, et c’est ainsi que du code bizarre se retrouve dans un dépôt git ou en production. On finit même par se demander si une grande entreprise n’a pas forcé l’insertion de son plugin ou de son code dans la réponse de premier niveau. Cette structure elle-même pourrait devenir un problème très grave à l’avenir. Le secteur de la publicité doit déjà saliver devant cette tendance, et si des pubs se retrouvent injectées dans les modèles LLM, ce sera encore pire.
    • J’aimerais qu’on ait des modèles ouverts, avec des données d’entraînement et des poids clairement publiés, et qu’on puisse les personnaliser de manière reproductible, un peu comme avec Nix
    • Il faudrait un moyen de déboguer le modèle au moment de l’inférence (par exemple via des éléments transparents comme des tags)
    • Je me demande s’il existe une méthode de vérification formelle de l’inférence des modèles
  • La barrière à l’adoption de nouveaux langages va effectivement devenir plus élevée. Mais aujourd’hui déjà, les raisons d’utiliser un langage de niche sont surtout :
    1. l’existence d’une base de code et de bibliothèques
    2. le fait qu’il rassemble des experts d’un domaine précis, donc même si un LLM est bon en Java, cela ne veut pas dire que tout le monde utilisera Java (sans parler du fun ou du CV)
  • Il a toujours été avantageux de choisir un langage populaire pour des raisons comme le recrutement. Choisir un langage moins populaire a toujours été un risque, et cela le reste aujourd’hui.
• Voir Python en tête est assez frustrant. D’après mon expérience, Python n’est agréable que pour les scripts ou pour bricoler seul un PoC. Je n’imagine pas utiliser Python pour du code qui dépasse 1 000 lignes, qui doit être maintenu par plusieurs personnes, ou qui met plus de quelques secondes à s’exécuter. Comme Python est devenu le langage par défaut pour enseigner aux non-spécialistes dans les universités américaines, beaucoup de gens brillants contribuent à son écosystème ; j’aimerais que ces efforts soient plutôt investis dans d’autres langages ou dans des langages compilés plus robustes. Je recommande un langage compilé, statiquement typé et avec support du multithreading.
  • Je suis totalement d’accord. Je ne l’utilise que pour les scripts. J’ai voulu faire un peu de ML l’an dernier, mais je détestais tellement Python que j’ai abandonné au bout d’un mois. Je ne comprends pas pourquoi Ruby n’est pas populaire. Python est devenu une sorte de premier langage par défaut (ça a aussi été mon cas), mais moi je recommanderais plutôt Ruby.
  • Je comprends. Python donne une impression de « mou ». Parmi les langages statiquement typés et compilés que je connais, il n’y a que Rust, C et C++, et chacun a ses défauts. J’aimerais beaucoup un C avec le tooling de Rust et un système de modules.
  • Même la syntaxe n’est pas terrible. Ça fonctionne peut-être bien, mais ce n’est pas un langage amusant.

[3ae3ae]

JS et TS sont presque le même langage, donc je me demande s’il ne faudrait pas les regrouper.

[beoks]

C'est étrange que HTML figure dans le classement.

[jjpark78]

J’ai du mal à croire que Java soit 2e.

[passerby]

Java et C# restent, hier comme aujourd’hui, le standard des environnements de serveurs web d’entreprise.

[jjpark78]

Le sondage de Stack Overflow et le classement des langages populaires sont vraiment très différents.