Les vérités sur le métier d'un développeur polyglotte

Introduction

J’ai appris à programmer en Caml, en COBOL (sur AS/400), en C et en Assembleur, durant mes années d’école. J’aimais vraiment comprendre comment parler à une machine à bas niveau. J’ai aimé le COBOL et l’AS/400 avec son environnement sans souris : la navigation était complexe, mais la concentration sur un seul écran était simple en même temps.

Ce que j’ai apris plus tard est la partie qui compte aujourd’hui pour mon chemin dans l’ingénierie logiciel. Java, pour les systèmes typés et très scalables. Kotlin, pour moderniser Java. Node.js, pour les projets web. Python, pour le traitement de données et le scripting. Et PHP… qui m’a surtout appris pourquoi Node.js est meilleur pour le web.

On trouve beaucoup de blogs aujourd’hui qui parlent pourquoi devenir développeur polyglotte à l’ère de l’IA, mais pas assez sur ce que cela coûte. Très certainement, l’industrie avec l’IA va pousser les développeurs vers le polyglottisme, que ce soit par choix ou non (“AI Coding Agents Are Removing Programming Language Barriers”). Si c’est le chemin souhaité, ce qui compte aujourd’hui est d’avoir une stratégie sur ce qu’il faut apprendre et explorer, plutôt que de se concentrer sur un langage ou une stack en particulier. C’est aussi une façon d’utiliser l’IA comme outil d’apprentissage, au lieu de la laisser penser à votre place.

Après presque 3 ans, je remets mes notes d’apprentissage sur le blog, en commençant par un peu de nostalgie après plus de 10 ans dans la tech.

#1 La charge mentale et le changement de contexte

A la fin d’une journée de travail bien chargée, le changement de contexte peut être épuisant (l’un des principaux goulots d’étranglement du développement avec l’IA). Ce que je fais pour l’éviter est simple : j’organise mes journées par stack et par projet (un jour, un contexte). Pour moi, cela s’est avéré plus efficace que d’étaler quatre projets sur cinq matinées, et c’est le changement qui m’a le plus aidée à rester concentrée et efficace (même avant l’IA).

L’IA a tout de même allégé mon quotidient, avec des outils comme Copilot dans l’IDE, qui assistent pour corriger la syntaxe dans les différents languages au fur et à mesure qu’on écrit le code et que je n’ai plus besoin de mémoriser à 100%.

Une autre astuce utile pour moi est de choisir une stack pratique et maintenable, et là je me suis trompée pendant un moment. Personnellement, j’évite les frameworks SSR très opinionated comme Next ou Nuxt ; j’ai une impression que ces frameworks rendent des sites simples compliqués à maintenir (au moins le contexte mental). Je préfère Astro maintenant, parce qu’il donne une expérience de configuration proche d’un site en HTML brut, ce qui rend la maintenance plus évidente et est plus simple pour la charge mentale. D’ailleurs, ce blog a été construit avec le framework Astro, comme je l’ai partagé dans l’article Astro Starter Blog I18n template.

#2 Le manque de profondeur

En tant que généraliste, des fois on apprend les profondeurs d’un langage ou d’un framework lorsqu’on rencontre de vrais problèmes en production. Performance, cache, sécurité… pas toujours appris avec la documentation ou dans une formation, mais lors d’un vrai incident en production.

La vérité, c’est que je ne vais pas toujours en profondeur dans tout l’écosystème technique de chaque langage ou stack que j’utilise. Il n’y a pas assez de temps dans une carrière pour le faire plus de cinq fois.

J’ai vu des équipes construire une API en Node.js parce que le développement est plus rapide, mais dès que ça monte en charge avec des gros volumes de données et d’appels d’API arrivent (y compris d’autres problèmes de maintenance), le besoin de migrer vers un écosystème plus structuré et plus performant devient évident. L’environnement de migration cible serait donc re-évalué en se basant sur des comportements et problématiques réels, comme les équipes chez Uber, qui sont passés de Node.js au langage Go pour répondre à des exigences techniques parfois difficiles à anticiper au début d’un projet.

C’est là que l’IA a eu le plus d’impact pour moi, avec un bon processus d’orchestration. J’utilise l’IA comme un expert sur différents domaines, par exemple :

• pour investiguer et comparer des solutions,
• pour développer de petits PoC et comparer les performances (parfois juste par curiosité),
• pour relire et challenger mon approche ou idée,
• pour monter de version une bibliothèque ou un framework obsolète (un processus pénible et coûteux),
• et pour trouver les cas limites en amont plutôt qu’en production.

Demander quelque chose à un modèle d’IA nous donne une réponse rapidement (parfois trop complaisante, selon le fournisseur) ; mais lui demander d’argumenter contre une idée ou un plan, permet d’entrer dans la profondeur technique et l’expertise qu’on n’a pas pris le temps de construire.

#3 La recherche d’emploi et le syndrome de l’imposteur

C’est celle que l’IA ne peut pas régler, sauf (peut-être) si on s’en sert comme coach de motivation…

Chaque nouvelle recherche d’emploi me ramenait souvent à la même phrase, pendant ou après un entretien : Vous n’avez pas X années sur la stack ou langage Y ou Nous cherchons quelqu’un avec plus d’expérience sur le langage Z.

Les intitulés et descriptifs des offres n’aident pas non plus. On essaie de mettre les gens dans des cases où le CV d’un développeur polyglotte et ingénieur curieux entre difficilement.

Je pense que le bon poste est une correspondance, pas un filtre. C’est un mélange entre la taille de l’entreprise (une start-up ou un grand groupe), l’étape de vie du produit (un MVP/nouveau projet ou un projet établi), ses objectifs, et enfin les compétences du candidat. Quand tout cela s’aligne, la question du nombre d’années par framework cesse d’être un point de blocage. Cet article de blog, « Le mythe des années d’expérience » (The Years of Experience Myth), mériterait d’être lu par les sceptiques.

Une réponse concrète est de construire quelque chose en public : des projets perso sur GitHub, de l’écriture de blogs, des contributions open source. Cela ne fera pas forcément sauter le filtre automatique, mais cela sert de vitrine sur les compétences plutôt qu’un décompte des années d’expérience. Cet article fait partie de cette démarche.

J’ai aussi rejoint la jeune start-up Les Martines comme cofondatrice technique, pour développer et maintenir l’application mobile. Le rôle est parfait pour moi comme side project passion pour l’instant : apprendre et innover en permanence, avec un impact réel pour la communauté qui s’est construite dans l’application.

L’IA comme outil d’apprentissage, pas pour penser à votre place

Robert C. Martin défend la version la plus tranchée de cet argument : que l’IA code mieux que vous et qu’il faut faire avec, et qu’il ne faut plus lire le code. Le fil Hacker News sur le second argument, vaut autant que la publication originale. Que l’on soit d’accord avec lui ou non, certains ingénieurs seniors n’écrivent plus de code, et c’est un vrai changement dans l’industrie.

J’ai pu tester et améliorer des pipelines d’agents, avec différents modèles frontier et avec des modèles open source. Le résultat observé n’est pas symétrique. Pour les modèles frontier à grande capacité, un bon fichier AGENTS.md suffit parfois à livrer du bon code (avec une bonne base de code), ou au moins une fonctionnalité qui marche (Context-Augmented Code Generation: How Product Context Improves AI Coding Agent Decision Compliance by 49%). Pour les modèles open source, en septembre 2026 (Qwen, DeepSeek), c’est l’orchestration du pipeline qui est la clé de bons résultats ; dans certains cas, donner trop de contexte n’est pas non plus une solution. Plus le modèle est petit ou bon marché, plus la structure doit venir d’un système d’orchestration autour de lui pour obtenir des résultats satisfaisants.

Plus important que le langage ou la stack technique : un projet bien structuré et bien documenté donne de meilleurs résultats avec les agent d’IA qu’un projet mal structuré. L’IA peut être exploité pour apprendre et appliquer des bonnes pratiques de code de qualité, éprouvées au fil des années et dans toute l’industrie :

• la clean architecture et les pratiques de clean code gardent les agents concentrés sur une couche à la fois pendant le TDD,
• les pratiques de TDD et de BDD pour les agents, pour que chaque fonctionnalité soit clairement conçue et que chaque nouveau bout de code soit testé avec les bons scénarios (How test-driven development amplifies AI success),
• les quality gates comme garde-fous : tests unitaires, tests d’intégration, tests E2E, tests de performance, seuils de couverture de code… cela garde les agents sur les rails et améliore les résultats.

Comprendre ne serait-ce que les bases de ces pratiques aide à construire des systèmes robustes. Les agents de code sont eux aussi plus performants dans des environnements bien structurés. Ces pratiques survivent à tous les langages et à toutes les stacks qu’on apprendra dans le futur.

Aujourd’hui, un meilleur pari est de comprendre comment les systèmes interagissent entre eux, l’architecture des systèmes et les protocoles, et pourquoi tel langage ou telle stack convient le mieux à un problème en particulier. Si tous les langages de programmation mentionnés dans cet article sont oubliés dans vingt ans (comme c’est presque le cas pour le Caml et le COBOL), l’esprit critique et les pratiques de qualité tiendront (espérons-le) encore.