Interview : « Le développeur de 2030 sera un orchestrateur d'agents IA »

Sophie :

Le premier signal, c'est la généralisation des assistants IA dans les IDE. En 2024, GitHub Copilot était utilisé par environ 30 pour cent des développeurs professionnels en France. Aujourd'hui, début 2026, on est au-dessus de 75 pour cent toutes solutions confondues : Copilot, Claude Code, Cursor, Tabnine, Codeium, Continue. C'est devenu invisible, comme l'autocomplétion il y a quinze ans. Un développeur qui code sans assistant en 2026 fait figure d'exception, et pas toujours pour de bonnes raisons.

Le deuxième signal, plus discret mais structurant, c'est la décomposition des tâches. Les équipes que j'accompagne ne se demandent plus « qui code cette feature » mais « quelle partie peut être déléguée à un agent autonome, quelle partie nécessite une revue humaine ». Le travail change de granularité. On orchestre des micro-tâches plutôt que d'écrire des fichiers complets ligne par ligne.

Le troisième signal, c'est l'évolution des entretiens techniques. Les tests d'algorithmique pure perdent du terrain. Les entreprises commencent à évaluer la capacité d'un candidat à diriger une IA, à détecter ses erreurs, à itérer avec elle. Ce sont de nouvelles compétences que les écoles classiques n'enseignent pas encore.

Sophie :

Cette inquiétude est légitime et il faut y répondre honnêtement, sans la balayer. Oui, sur les tâches que l'on confiait classiquement à un stagiaire ou un junior débutant — créer un formulaire CRUD, écrire des tests unitaires basiques, traduire un mockup en HTML/CSS — un assistant IA fait aujourd'hui mieux et plus vite. C'est un fait, pas une opinion.

Mais le travail d'un junior n'a jamais été uniquement composé de ces tâches. Un junior, c'est aussi quelqu'un qui apprend la culture de l'entreprise, qui comprend pourquoi telle décision technique a été prise il y a deux ans, qui pose les questions naïves qui révèlent des incohérences. Tout cela, l'IA ne le fait pas. Elle ne sait pas que la fonction X a été codée comme ça parce qu'un client a fait une demande bizarre en 2023.

Le vrai problème, c'est que les entreprises recrutent moins de juniors qu'avant. Pas parce que l'IA les remplace techniquement, mais parce que la formation initiale d'un junior coûte cher et que le retour sur investissement met deux à trois ans. Avec un assistant IA et un développeur confirmé bien outillé, certaines équipes choisissent de ne pas passer par cette phase. C'est un problème de marché, pas de capacité.

Sophie :

Je donne toujours le même conseil : maîtriser les fondamentaux à fond, mieux que ne le ferait un junior d'il y a cinq ans. Algorithmique, structures de données, complexité, modèles de concurrence, bases de données, réseaux. Ce sont les briques que l'IA assemble pour vous. Si vous ne savez pas reconnaître un mauvais assemblage, vous êtes condamné à valider du code médiocre sans comprendre pourquoi il est médiocre.

La deuxième priorité, c'est la lecture critique de code. Aujourd'hui, sur huit heures de travail effectif, un développeur en passe quatre à cinq à lire et valider du code généré ou existant. Cette compétence — détecter une faille de sécurité, repérer une fuite mémoire, comprendre un edge case mal géré — devient centrale. Or elle ne s'acquiert qu'en lisant beaucoup de code, en faisant des revues, en analysant des post-mortems d'incidents. Les écoles classiques l'enseignent peu.

Troisième priorité : comprendre comment les IA fonctionnent, sans forcément devenir spécialiste ML. Savoir ce qu'est un transformer, comment les modèles hallucinent, pourquoi un RAG est plus fiable qu'un LLM seul, comment évaluer la qualité d'une réponse. Sans ces bases, vous utilisez l'IA comme un oracle magique et vous accumulez des bugs subtils.

Quatrième priorité, et c'est la plus sous-estimée : la communication écrite. Pour bien diriger une IA, il faut savoir formuler un problème de manière précise, contextualiser, anticiper les zones d'ombre. Les développeurs qui écrivent mal en langue naturelle écrivent aussi mal leurs prompts.

Sophie :

C'est la question qui m'occupe au quotidien. J'ai trois juniors dans mon équipe, tous arrivés ces dix-huit derniers mois. Tous codent avec Claude Code ou Copilot dès la première heure. Et au début, j'ai été frustrée. Je leur demandais d'expliquer pourquoi telle ligne avait été écrite comme ça, et la réponse était souvent un haussement d'épaules : « c'est ce que l'IA a proposé, ça passait les tests ».

J'ai changé d'approche. Je n'interdis pas l'IA — ce serait absurde et contre-productif. Mais j'impose deux règles. Première règle : avant de soumettre une pull request, le développeur doit pouvoir réécrire de mémoire au tableau l'algorithme principal de sa fonction. S'il ne peut pas, il a externalisé sa pensée à l'IA et il faut qu'il revienne en arrière. Deuxième règle : chaque revue de code commence par une question ouverte de ma part : « pourquoi tu as choisi cette approche plutôt qu'une autre ». S'il n'a pas de réponse, on en discute ensemble.

Ces deux règles m'ont permis de garder la formation effective des juniors tout en bénéficiant des gains de productivité de l'IA. Sur six mois, je vois la différence : ils progressent toujours, mais autrement. Ils maîtrisent moins de syntaxe par cœur, ils sont meilleurs en revue critique et en architecture qu'à mes débuts à âge équivalent.

Sophie :

Je ne suis pas dans la prédiction futuriste, je décris ce que je vois déjà émerger dans les équipes qui ont cinq ans d'avance sur le marché. En 2030, le développeur médian passera la majorité de son temps à concevoir, déboguer et superviser des systèmes composés d'agents IA spécialisés. Un agent qui lit la base de connaissances, un agent qui propose une architecture, un agent qui code, un agent qui teste, un agent qui revoit le code, un agent qui déploie. Le développeur orchestre ce chœur.

Ses tâches concrètes : définir le contrat de chaque agent (quelles entrées, quelles sorties, quelles garanties), instrumenter les flux pour observer ce qui se passe, intervenir quand un agent diverge ou se trompe, faire évoluer le système au fil des retours. C'est un travail à mi-chemin entre le développement classique et le métier d'architecte SRE.

Ce qui ne changera pas : la nécessité de comprendre profondément ce qui se passe sous le capot. Un orchestrateur qui ne sait pas lire le code de ses agents, qui ne sait pas écrire un test reproductible, qui ne sait pas analyser un log de production, n'est qu'un manager dépendant de ses outils. Et ce métier-là sera moins valorisé, pas plus.

Sophie :

Un assistant comme Copilot répond à une demande ponctuelle. Vous tapez « écris une fonction qui valide un email », il propose. Vous acceptez ou non. C'est un dialogue tour par tour, court, et c'est vous qui décidez à chaque étape.

Un agent autonome, c'est différent. Vous lui donnez un objectif global — « ajoute la fonctionnalité de réinitialisation de mot de passe à cette application » — et il enchaîne plusieurs actions sans intervention : il lit le code existant, identifie les fichiers à modifier, écrit les modifications, lance les tests, corrige si les tests échouent, commit, ouvre une pull request. Il peut tourner pendant trente minutes sans qu'on lui demande quoi que ce soit. Outils typiques en 2026 : Claude Code en mode autonome, Devin, Aider en plan mode, des agents personnalisés avec LangGraph ou CrewAI.

Ce qui change, c'est l'échelle d'autonomie et donc le niveau de risque. Un agent peut très bien partir dans une mauvaise direction pendant vingt minutes et produire un code subtilement faux. La supervision humaine reste indispensable mais elle se déplace : on intervient moins souvent, mais à des moments plus stratégiques. Bien encadrer un agent demande de définir clairement ses garde-fous, ses critères d'arrêt, ses indicateurs de succès. C'est une compétence en soi.

Sophie :

Je ne crois pas à cette analogie pour une raison simple : le monteur vidéo travaille sur un produit fini relativement standardisé — une vidéo respecte certaines conventions, certaines durées, certains codes. Le développement logiciel, lui, a une combinatoire infinie. Chaque entreprise a ses contraintes métier, ses dettes techniques, ses choix d'architecture historiques. Aucun outil grand public ne peut absorber cette complexité.

Ce que je crois en revanche, c'est qu'on aura une polarisation. D'un côté, des profils très techniques, capables de concevoir des systèmes complexes, de raisonner sur la performance, la sécurité, la fiabilité. Ces profils seront rares et bien payés, peut-être encore mieux payés qu'aujourd'hui. De l'autre côté, des profils qui font du développement d'application standard, en s'appuyant lourdement sur des outils IA. Ces profils seront plus nombreux, plus interchangeables, et leur salaire pourrait stagner.

Le risque pour les générations qui démarrent en 2026 n'est pas de ne pas trouver de travail. C'est de rester bloqué dans la deuxième catégorie sans jamais accéder à la première. Pour passer de l'une à l'autre, il faut investir dans les fondamentaux et dans la profondeur technique, ce qui prend du temps. C'est un investissement de carrière, pas une formation de trois mois.

Sophie :

Je lui réponds que oui, c'est une voie qui reste solide, à condition que l'enfant ait un goût réel pour la résolution de problèmes et la curiosité technique. Le métier va évoluer, comme tous les métiers, mais le besoin de gens qui comprennent profondément comment fonctionnent les systèmes informatiques ne va pas disparaître. Au contraire : plus le monde se logiciel-ise, plus ces compétences sont stratégiques.

Ce que je leur dis aussi, c'est que la formation classique seule ne suffit plus. Une école d'ingénieur ou un cursus universitaire en informatique reste un excellent socle, mais il faut le compléter par de la pratique massive en autonomie : projets personnels, contributions open source, expérimentations avec des LLM et des agents. Un étudiant en 2026 qui sort de cinq ans de cursus sans avoir publié un seul projet sur GitHub, sans avoir intégré une API LLM, sans avoir contribué à un projet collectif, partira avec un retard.

Enfin, je leur dis qu'il vaut mieux pour leur enfant de viser un métier qu'il aime vraiment plutôt qu'un métier qui « paye bien » sans intérêt personnel. Le développement reste un métier exigeant, qui demande de l'apprentissage permanent. Sans passion réelle, on tient cinq ans, dix au mieux, puis on décroche. Et un développeur qui décroche dans un monde où l'IA accélère l'évolution des outils est plus difficile à reclasser qu'avant.