En août 2025, TypeScript est devenu le langage le plus utilisé sur GitHub. Il s’agit du changement le plus important dans le classement des langues de GitHub au cours des dix dernières années et il s’est produit pendant la période d’adoption la plus accélérée des agents d’IA de codage.
Il était prévu auparavant que le codage des agents d’IA réduirait l’importance de la sélection de la langue. On supposait que les organisations deviendraient indépendantes des piles et sélectionneraient les piles technologiques en fonction uniquement des besoins du problème commercial, laissant de côté les considérations du bassin de recrutement de développeurs disponible. Au lieu de cela, à peine deux ans après l’adoption généralisée des outils de codage de l’IA, le marché semble plus restreint, avec un rétrécissement rapide des langages de codage disponibles et l’accent est principalement mis sur une seule famille de langages.
Analyse du changement
Le rapport Octoverse d’octobre 2025 de GitHub a compté les contributeurs de TypeScript. Ses 2,64 millions de contributeurs mensuels ont marqué une augmentation de 66 % d’une année sur l’autre. En 2025, TypeScript a vu plus d’un million de développeurs écrire leur premier code TypeScript dans GitHub.
Cette croissance s’ajoute à une position déjà fortement dominante. En 2025, Stack Overflow a envoyé une enquête aux développeurs qui a collecté plus de 49 000 réponses. Parmi ces réponses, 66 % ont déclaré avoir utilisé JavaScript. Presque chaque année depuis 2011, JavaScript domine cette position. En conclusion, la famille JavaScript est à la fois la plus utilisée et celle qui connaît la croissance la plus rapide sur GitHub.
Cela vaut la peine d’aborder brièvement un problème avec la méthode de comptage de GitHub ; compter l’activité sur GitHub, c’est compter l’activité sur leur propre site, ce qui présente un conflit d’intérêts car ils souhaitent peut-être qu’il soit beau. En outre, les tendances de la mode ont un impact sur le type d’informations incluses dans les référentiels publics. Toutefois, les indicateurs correspondent toujours aux données d’enquête, ce qui est raisonnable compte tenu de l’ampleur de cette tendance particulière.
Les modèles écrivent mieux dans le code qu’ils ont le plus vu
Son fonctionnement est assez simple. Les modèles apprennent du code publié, et la plupart du code publié est écrit en JavaScript et TypeScript. En fait, une grande partie du code est centrée sur React.
Cela crée un écart substantiel dans les résultats que les développeurs peuvent voir chez leurs agents un jour après avoir modifié leur pile. Demandez à un agent de codage de générer un composant React typé et le résultat sera généralement compilé, conforme aux normes de la base de code et nécessitera un minimum de modifications. En revanche, lorsque vous demandez au même agent de générer du code pour un framework backend Svelte, Solid ou moins populaire, le résultat a tendance à être beaucoup plus mince. En outre, vous verrez davantage d’API inventées et l’échafaudage aura besoin de plus de corrections avant d’être exécutable.
En conséquence, cela change désormais la façon dont les équipes sélectionnent leurs tapis. Il ne s’agit plus simplement de décider quel framework est le plus efficace ou le plus simple à utiliser, mais plutôt quel framework est le plus compatible avec les outils de l’équipe, car l’écart de productivité en termes de sortie d’agent utilisable au cours d’un cycle de construction étendu est aggravé. Lorsque cette équipe produit un résultat, celui-ci est publié, récupéré et inclus dans les sessions de formation ultérieures, creusant ainsi l’écart de productivité.
Rien de tout cela ne laisse présager un verdict technique. Solid et Svelte sont de bons frameworks, et plusieurs frameworks plus modernes surpassent React en termes de vitesse brute. Le marché a récompensé le choix que les modèles connaissaient déjà.
Les modèles sont construits en Python, mais les produits sont livrés en JavaScript
Un contrepoids valable aux points ci-dessus est que le développement de l’IA se fait en Python. La formation des modèles, l’évaluation et la plupart des outils de recherche fonctionnent en Python, et cela n’a pas changé.
Cependant, très peu de ce avec quoi le client interagit est écrit en Python. En fait, le front-end d’un produit d’IA est essentiellement une fenêtre qui diffuse des jetons. Cela nécessite également des boutons pour exécuter des outils, une étape d’approbation pour tout ce qui pourrait conduire à un résultat négatif et une explication de ce que le système a fait et pourquoi. Tout cela se fait en JavaScript et TypeScript, que le modèle provienne d’OpenAI, d’Anthropic ou d’un modèle ouvert que l’entreprise héberge sur son propre matériel.
Fin 2025, GitHub avait signalé plus de 1,1 million de référentiels publics utilisant un SDK LLM, soit une augmentation de 178 % par rapport à l’année précédente. Cette augmentation était principalement due au développement d’applications plutôt qu’au développement de modèles. Chaque projet pilote d’entreprise qui dépasse le stade de la démonstration nécessite que quelqu’un crée le composant destiné à l’utilisateur, et les outils standard de l’industrie pour ce travail sont des frameworks JavaScript.
Les systèmes de types sont devenus le garde-fou du code généré
L’opinion de GitHub est que ce changement a signifié que les développeurs se tournent vers des langages typés, car les systèmes de type rendent le développement assisté par agents plus sûr. Le code généré présente un type d’échec spécifique. Il se lit et est bien structuré. Il fonctionne même parfaitement dans les langages dynamiques, pour ensuite planter en raison de différences de forme après trois appels. Les vérificateurs de type en identifieront une grande partie avant même que le code ne soit exécuté.
Cette théorie s’est avérée exacte dans la pratique. En 2026, l’utilisation de TypeScript par les développeurs professionnels a atteint 78 %, soit une augmentation par rapport aux 69 % deux ans auparavant. Environ 40 % des développeurs écrivent exclusivement en TypeScript, et seulement 6 % des développeurs écrivent exclusivement en JavaScript brut.
Les types d’erreurs qu’un compilateur trouvera ont tendance à être les types d’erreurs qu’un réviseur humain négligera face à 400 lignes de code raisonnable.
● Une fonction est appelée avec un objet pour lequel il manque l’un des champs obligatoires.
● Le code contient l’hypothèse selon laquelle une valeur existe, ce qui entraîne la transmission d’une valeur nulle ou indéfinie.
● La forme d’une réponse API a changé et le gestionnaire généré utilise toujours l’ancienne.
Le goulot d’étranglement est passé de l’écriture du code à la vérification du code
Le rapport de terrain d’OpenAI concernant l’utilisation d’agents de codage dans le calcul scientifique de juillet 2026 énonce très clairement la limite : la vérification est devenue le facteur limitant, par opposition à la génération de code. Bien qu’il s’agisse d’un fournisseur examinant son propre produit et qu’il doive être pris avec précaution, le résultat coïncide avec ce que de nombreuses équipes d’ingénierie, en particulier celles extérieures à la recherche, ont constaté au cours de l’année écoulée.
Lorsqu’un frontal performant est terminé en un après-midi au lieu de trois semaines, la partie la plus lente du processus consiste à déterminer si tout ce qui apparaît à l’écran est correct, sécurisé et maintenable. Cela change ce que l’on attend d’un développeur JavaScript. La rapidité de saisie du code n’a jamais été la valeur réelle du poste, mais elle a été utilisée comme mesure approximative de la compétence lors du processus d’embauche. Le code généré a supprimé la mesure et laissé le jugement.
On s’attend à ce qu’un effet React se déclenche deux fois au cours du développement, et un développeur qui n’en est pas conscient peut passer une journée entière à enquêter sur ce qu’il pense être un bug dû à un appel d’API en double. Une requête générée semblera correcte dans l’environnement de développement avec des exemples de données, mais elle peut finir par analyser une table entière lorsqu’elle est utilisée dans l’environnement de production. Une vérification d’authentification peut être placée n’importe où dans un composant et être inefficace, ce qui peut donner l’illusion de sécurité, mais cette illusion disparaît lorsque quelqu’un la teste réellement.
Il existe un désalignement que les équipes ont tendance à négliger. La capacité de production est quasiment infinie et augmente à chaque agent supplémentaire ou à chaque nouvel abonnement. En revanche, la capacité d’examen est limitée par le nombre d’ingénieurs suffisamment familiarisés avec le système pour identifier une erreur plausible. Il est peu probable que ce chiffre augmente au même rythme. Ajouter davantage de capacité de génération de code à une équipe qui a déjà atteint sa limite de capacité de révision n’augmente pas le taux de livraison. Cela déplace simplement le goulot d’étranglement de l’écriture à la révision. Une équipe pourrait doubler sa capacité de génération de code en une semaine, mais cela ne changera pas le nombre de personnes disponibles pour la révision. C’est pourquoi la contrainte s’est déplacée et pourquoi des outillages supplémentaires n’apportent pas la solution.
Il n’en va pas de même pour les pratiques d’embauche. La plupart des sélections évaluent toujours si un candidat peut parvenir à une solution de travail, ce qui est la partie pour laquelle les outils l’aident déjà. Certaines entreprises ont commencé à évaluer la compétence opposée. Ils présentent aux candidats des blocs de code générés par l’IA qui contiennent une erreur et observent combien de temps l’erreur reste non résolue.
Les agences de placement de personnel ont également évolué dans cette direction. Par exemple, Full Scale décrit désormais les ingénieurs JavaScript qu’il place comme maîtrisant les outils d’IA et le sens du produit, plutôt que des lignes de code écrites. Une entreprise qui envisage d’embaucher un développeur JavaScript dédié acquiert désormais autant de capacités de révision que de renforcement des capacités. Cela semble un changement mineur jusqu’à ce qu’un flux de connexion généré par l’IA entre en production sans intervention humaine.
La concentration a un coût
Un marché qui valorise ce que les modèles savent déjà rend difficile l’introduction de quelque chose de nouveau. Un nouveau framework publié cette année ne comporte aucun corpus préexistant de données de formation, ce qui rend difficile l’utilisation de celui-ci par les agents, obligeant les équipes à l’éviter, conduisant à un scénario dans lequel aucun corpus n’est généré. Le délai habituel de financement est insuffisant pour que les solutions fondées sur le mérite puissent briser ce cycle. Les frameworks qui ont atteint leurs objectifs avant 2023 bénéficient désormais d’un avantage qui n’a rien à voir avec la qualité de la conception.
Le risque est plus restreint pour une seule entreprise. Une entreprise dont le produit, les outils et le pipeline de recrutement tournent autour d’une seule famille linguistique a fait le même pari à trois reprises. C’est une situation confortable tant que la famille linguistique maintient sa domination, et coûteuse si elle faiblit.
La première prédiction était à moitié correcte. L’IA a en effet éliminé une grande partie du coût d’écriture de code dans un langage que personne dans l’équipe ne comprenait. Le coût de la compréhension et de l’appropriation persiste toujours, et pour la plupart des équipes, il s’agit du principal coût qui détermine la pile technologique.
