Quel est l'avenir du métier de développeur ?
Une équipe expérimentée adopte la génération de code à fond. Et ça marche, des fonctionnalités qui sortaient en semaines sortent en jours. Puis, sous la pression du delivery, ce qui semblait dispensable a sauté : les tests, la revue, le temps passé à comprendre ce qu'on met en production. Quelques mois plus tard, cette même équipe fait deux dailys par jour. Un à 9 h, un à 18 h. Plus vraiment pour se coordonner, pour se surveiller. Et malgré cela, personne n'arrive à stabiliser la production.
Cette histoire n'est malheureusement pas une carricature mais un cas client. Il ne s'agissait pas d'un problème lié à l'outil, il a tenu ses promesses. C'est la discipline qui a cédé et la maîtrise qui a disparu.
En observant cette équipe on se pose une question.
Quand le prix du code chute, quel sont les centres de coût du développement logiciel ? Et comment s'adaptent, dès maintenant, un développeur et un manager ?
Un mot de méthode avant de commencer. Je vais distinguer tout du long deux registres : les données de marché, sourcées et vérifiables, et ce que j'observe depuis mon poste, un témoignage de terrain que j'assume comme tel.
Le constat du marché
L'usage monte, la confiance baisse
Le premier fait est un paradoxe. L'adoption de l'IA par les développeurs n'a cessé de croître. D'après le Stack Overflow Developer Survey (nouvelle fenêtre), la part de ceux qui utilisent ou prévoient d'utiliser l'IA est à 84 % en 2025 (nouvelle fenêtre). L'adoption n'est plus la question.
Dans le même temps, la confiance s'effrite. Le sentiment favorable à l'égard de ces outils a reculé jusqu'à 60 %. On s'en sert de plus en plus, on y croit de moins en moins. Sur l'exactitude précisément, le constat de 2025 est sans appel : 46 % de défiance contre 33 % de confiance. Ces chiffres supportent une tendance robuste de désenchantement face à l'IA dans le quotidien des développeurs.
Une adoption profondément inégale
Derrière ces moyennes se cache une dispersion considérable. Chez les clients d'Athoria, je vois s'étaler des consommations allant de 20 € à 1000 € par mois et par développeur, soit une dispersion d'un facteur 50 au sein d'une même industrie, parfois d'une même équipe.
Cette dispersion s'explique à deux niveaux qui s'influencent l'un l'autre.
D'abord au niveau des organisations, certaines se sont adaptées plus vite, ont mis en place une stratégie, un gouvernance. Certaines accusent encore le coût du changement de modèle de prix de Github Copilot en juin. On estime à 52 % la part de shadow AI, c'est-à-dire d'usage hors de tout cadre officiel. Le manque d'un outil performant et sponsorisé au niveau groupe entraine les gens vers des logiciels publics dès que la donnée ne paraît pas sensible.
Au niveau individuel le même écart se creuse. D'un côté, ceux qui ont construit un véritable harnais autour du modèle : contexte injecté, règles versionnées dans le dépôt, serveurs MCP qui exposent l'environnement réel du système. De l'autre, ceux qui restent sur la configuration par défaut : un prompt « à vide », sans fichier de règles, sans cadre. Les mesures publiques les plus proches confirment l'écart : 14 % des développeurs utilisent des agents au quotidien quand 52 % n'en utilisent aucun (nouvelle fenêtre). Il y a peu de mesures pour les configurations plus basiques comme les instructions ou les skills. Ce que j'observe chez nos clients c'est qu'un peu plus de la moitié des développeurs enrichissent leur contexte.
Des gains réels, mais concentrés sur l'écriture
Que produit, au fond, cette adoption ? Le rapport DORA 2025 (State of AI-assisted Software Development) apporte la réponse la plus rigoureuse à ce jour. Il mesure entre autres les effets standardisés de l'adoption de l'IA, avec un intervalle de crédibilité de 89 %. L'effet le plus fort, et de loin, porte sur l'efficacité individuelle (environ +0,17), la productivité de l'écriture. Mais le plus fort effet indésirable en aval est l'instabilité de livraison (environ +0,10), tandis que le débit de livraison, lui, ne bouge presque pas (+0,03).
La lecture est limpide, les gains se concentrent sur l'individu qui écrit, le coût se concentre sur la stabilité du système livré. C'est la deuxième année consécutive où DORA observe une dégradation de la stabilité. En parallèle on à vu AWS et cloudflare tomber fin 2025 et la stabilité d'acteurs majeurs comme Github ne fait que se dégrader.
Il est également observé une augmentation du volume de code pour les mêmes foncionnalité, des pull requests plus grosses et une baisse de la qualitée des revues. J'ajoute personnellement à ça la proliferation de tests de très basse qualité générés par l'IA pour augmenter la couverture. Ils sont généralement très couplés à l'implementation et truffés de mocks superflux. J'encourage tout développeur qui veut tirer pleinement profit de l'IA à surveiller les tests de près, j'y reviendrais dans mes conseils et actions.
Le marché de l'emploi exige la séniorité
Aux états-Unis, les offres pour développeurs sont en recul de 32 % par rapport à l'avant-Covid, mais en hausse de 14 % sur un an (avril 2026), un rebond tiré par l'IA : 47 % des offres mentionnent désormais des compétences IA. C'est aussi devenu le métier le plus « séniorisé » qui soit : 30,7 % des offres visent des profils seniors, moins de 2 % des juniors. Les jeunes diplômés ne représentent plus que 7 % des embauches dans les grandes entreprises technologiques, et l'emploi des jeunes développeurs a reculé d'environ 20 % depuis fin 2022 (Stanford-ADP).
En France, les recrutements de cadres informatiques sont en baisse de 21 % par rapport à 2023 (APEC), l'emploi des jeunes cadres en recul de 13 % en deux ans. Tout cela est attribué à l'IA mais aussi à la conjoncture économique et je rejoins cet avis, l'IA favorise les compétences associées aux profils séniors mais dans le même temps les budgets sont scrutés, les deadlines se raccourcissent et chaque recrutement se doit d'être bon.
Sur le terrain que ce soit au sein d'Athoria où les recrutements sont exigents ou chez les clients pour qui j'ai eu l'occasion de faire des entretiens techniques, je constate la même chose. Beaucoup de candidatures, une compétence moyenne en baisse, et des postes difficiles à pourvoir. La synthèse tient en une phrase, on ne cherche plus de gens uniquement pour produire du code, un développeur doit comprendre comment son travail se lie à de la valeur métier.
Où est passé le coût ? Les quatre questions
Alors où sont les coûts ? L'écriture n'a jamais représenté l'essentiel du coût d'un logiciel sur sa durée de vie. L'IA à réduit à presque rien une part qui était déjà petite. Le coût n'a donc pas disparu, il s'est déplacé. Vers quatre endroits précis, qui sont quatre questions qu'un système pose toujours et dont la part augmente mécaniquement.
1. Spécifier : quoi construire ?
Puisque les fonctionnalités sont livrables plus vite alors pour apporter plus de valeur il faut passer plus de temps à comprendre les besoins du métier. L'implémentation est toujours un reflet de la compréhension du besoin.
Malheureusement spécifier n'est pas simple et la difficulté crois exponentiellement avec le nombre de stakeholders. Comprendre le besoin était déjà un point faible pour beaucoup de développeurs ayant une posture d'éxecutant. C'est l'un des facteur qui nuit le plus au recrutement de juniors.
Ici les organisations les plus agiles et celles dont les représentant du métier sont les plus proches des développeurs ont un avantage considérable. Celles qui segmentent la compréhension et l'implémentation en introduisant des intermédiaires (Product Owners et Business Analyst par exemple) devront porter une attention particulière à ce que la transmission de ces informations et des retours utilisateurs soit efficace et précise.
2. Architecturer : est-ce que ça tient ensemble ?
L'IA produit de la vraisemblance locale. Elle imite la forme du code sans modèle de l'intention ni des flux d'ensemble. La télémétrie d'Apiiro (donnée de l'éditeur à prendre avec un grain de sel) dessine un contraste net : ce qui s'améliore avec l'IA, c'est la syntaxe (−76 % d'erreurs) et les bugs logiques (−60 %), ce qui empire, ce sont les failles architecturales (+153 %) et les escalades de privilèges (+322 %). CodeScene observe le phénomène inverse mais convergent : l'IA performe mal sur du code mal structuré, ce qui fait de l'architecture un véritable investissement de productivité.
Un exemple vécu, cette semaine encore : j'ai commenté une pull request où une donnée était chiffrée dans une fonction… pour être déchiffrée dans la suivante. Des gardes défensives sur des cas impossibles. Des try/except qui ne faisaient strictement rien. La cérémonie du bon code, sans le bon code. L'IA écrit du code qui a l'air juste, et « avoir l'air juste » n'est pas une propriété de l'ingénierie logicielle.
Le modèle n'est pas incapable de comprendre votre architecture simplement la plupart des prompts ne lui donnent pas les informations nécessaires ni l'injonction de comprendre. Contrairement à vous le modèle ne construit pas une compréhension implicite du projet alors ajoutez dans votre code base ces informations clés pour faire office de mémoire pour votre assistant. Attention cependant, les commentaires et les READMEs sont peu mis à jour et finissent par contenir de fausses informations, ce point est supporté par de multiples études. Ce que je recommande ici c'est une documentation minime et ciblée de votre projet maintenue par l'assistant.
3. Vérifier : est-ce juste ?
C'est le cœur du sujet. Le volume de code produit à significativement augmenté. Conséquence sur les équipes : le temps de revue est multiplié par deux à cinq (une véritable « taxe senior »), et 31 % des pull requests sont mergées sans aucune revue (Faros). C'est la version mesurée de l'anecdote des deux dailys.
L'objection mérite d'être posée frontalement : l'IA ne vérifiera-t-elle pas elle-même ? En partie, oui, et c'est une fonctionnalité qu'intègre de plus en plus de plateformes. Mais la vérification déléguée ne fait que déplacer la question d'un cran, le code revu par l'IA mérite tout de même d'être revu et compris parce qu'à la fin, quelqu'un signe la mise en production. Et ce quelqu'un a un nom, pas un numéro de version.
Ici comme pour le code écrit par des humains toutes les bonnes pratiques doivent rester et même être renforcées, le format doit être constant, les types déclarés, l'analyse statique poussée et adaptée au projet ainsi qu'aux convictions de l'équipe. Plus important de tous les tests se doivent d'être irréprochables. Si toutes ses conditions sont réunies alors le fardeau de la revue est réellement réduit avec confiance.
4. Maintenir : est-ce que ça tient dans le temps ?
Vient enfin l'effet de stock, le plus mécanique. Le nombre de commits est multiplié par trois à quatre (Apiiro), les pull requests augmentent de 29 % par an (Octoverse). Chaque ligne générée aujourd'hui est une ligne à comprendre, à sécuriser et à faire tourner pendant cinq ans. Et ce stock se dégrade qualitativement : le refactoring s'est effondré (de 25 % à moins de 10 % de code déplacé), les blocs de code dupliqués ont quadruplé (GitClear), les incidents ont augmenté de 243 % (Faros).
Une dette de compréhension s'installe, du code en production dont plus personne ne possède le modèle mental. C'est exactement le mal de l'équipe aux deux dailys : leur production tournait, mais leur compréhension n'avait pas suivi le rythme de leur code. Autrement dit : le code n'est pas un actif, c'est un passif. L'actif, c'est l'équipe qui le fait tourner.
S'assurer au travers de la relecture que le volume de code n'augmente pas inutilement est une base solide pour faciliter la compréhension et réduire la surface sur laquelle les erreurs peuvent se produire. A ça j'ajouterais logger et observer. Si pour livrer plus on accepte de comprendre un peu moins alors il devient essentiel de se donner tous les outils pour reproduire puis comprendre les instabilités le plus vite possible et les ajouter à la suite de tests pour s'assurer que ce comportement ne se reproduira plus. Cette pratique permet l'amélioration continue du harnais qui sécurise votre production.
La nuance : quand l'ingénierie peut s'effacer
Il faut aussitôt retourner ces quatre questions, car elles ne se posent pas partout. Là où il n'y a rien à spécifier durablement, rien de critique à vérifier, rien à intégrer, rien à maintenir, l'IA seule suffit, et c'est même son meilleur usage : vitesse maximale, zéro cérémonie.
C'est le cas des prototypes et des POC, où l'intention se découvre en codant ; des démonstrations et des maquettes ; des scripts isolés et des automatisations ponctuelles ; du glue code ; des analyses jetables. Sur ce terrain (greenfield, isolé, spécifié, jetable), l'IA excelle. Je ne plaide donc pas pour de l'ingénierie partout : ce serait du gaspillage. Je plaide pour le discernement, c'est-à-dire pour la capacité à reconnaître quand ces quatre questions sont pertinnentes et quand elles ne le sont pas.
Une façon simple de s'orienter consiste à situer son projet sur deux axes : son degré d'intégration (isolé ou interconnecté) et sa criticité (anodin ou critique). Un prototype de démonstration ou un notebook d'analyse exploratoire occupent le bas du tableau : l'IA seule suffit. Un service de paiement ou une brique d'authentification occupent le haut. Les cas les plus instructifs sont hors diagonale : le bot Slack interne, très intégré mais anodin, qu'on peut générer sans cérémonie ; la migration de données en production ou le rapport réglementaire, peu intégrés mais critiques, où la vérification prime même sans architecture durable. Plus on monte vers le haut et la droite de ce repère, plus la valeur se déplace vers le fait d'en répondre.
Un garde-fou, enfin : le piège, c'est le projet jetable qui ne l'est plus : le script personnel qui finit en production, le POC qu'on livre. Le jour où l'une des quatre questions réapparaît, l'ingénierie redevient nécessaire.
La responsabilité ne se délègue pas
Spécifier, vérifier, architecturer, maintenir : ces quatre questions ont un point commun. Ce sont précisément celles où la responsabilité ne se délègue pas à l'outil. Produire est devenu bon marché. Répondre de ces quatre questions reviennent au centre du métier.
Ce qui reste incertain
Tout ce qui précède est documenté, sources à l'appui. Ce qui suit ne l'est pas. En mai dernier, Dario Amodei et Sam Altman eux-mêmes ont publiquement révisé leurs prédictions sur l'emploi. Ceux qui fabriquent les modèles se sont trompés sur leur impact. Prenons le temps de nous poser certaines questions mais méfiez vous des conjectures.
Plus de logiciel, ou moins de monde ?
La première incertitude porte sur le volume. Deux récits s'affrontent, et les mêmes données nourrissent les deux. Le scénario de l'expansion (l'effet Jevons) : le coût par fonctionnalité s'effondre, donc la demande explose, les backlogs sont enfin traités, les logiciels sur-mesure deviennent rentables pour les PMEs. Si de nouvelles niches deviennent viables alors il y aura autant ou plus de développeurs. Ses appuis : le rebond de +14 % des offres tiré par l'IA, des offres « IA » en hausse de 45 % par rapport à 2020, et surtout le précédent historique (les compilateurs, l'open source, le cloud) : chaque saut de productivité a jusqu'ici augmenté l'emploi de développeurs.
Le scénario de la compression : les gains se concentrent, on produit le même logiciel avec moins de monde, et la porte d'entrée du métier ne se rouvre pas. Ses appuis : le recul de 20 % des jeunes développeurs, les 7 % de jeunes diplômés, la séniorisation extrême, les licenciements de 2026 étiquetés « IA ».
Les mêmes données portent les deux histoires : c'est précisément pourquoi il faut se méfier des deux. Toute l'histoire du logiciel a, jusqu'ici, tranché pour l'expansion. Mais « jusqu'ici » n'est pas une garantie, et l'élasticité de la demande n'est pas la même selon qu'on est une grande entreprise technologique, une ESN ou une PME. Pour le marché français, c'est d'ailleurs le modèle des ESN (le jour-homme face à la productivité par tête) qui est le plus directement interrogé.
Mon avis est que la production de logiciels va baisser en prix mais pas sont entretien. J'ai donc du mal à voir, en moyenne, les entreprises de petite taille rentabiliser des logiciels sur-mesure mais au global plus d'entreprises pouront se le permettre surtout si ils sont bien spécifiés pour apporter rapidement de la valeur. L'agilité étant de mise dans ces cas. Les plus grandes entreprises à mon avis ne vont pas significativement changer de masse salariale à court terme et le secteur devrait continuer d'avoir une bonne croissance dans les prochaines années. Les compétences, elles, vont évoluer. Maitriser un language sur le bout des doigts ne sera plus la grande demande.
Comment fabriquer des seniors sans le chemin d'hier ?
La seconde incertitude est plus aiguë encore, et c'est un paradoxe. La valeur se déplace vers des compétences de senior, celles qu'on acquiert en ayant constaté de projet en projet ce qui fonctionne et ce qui ne fonctionne pas. Si les jeunes diplômés ne sont pas recrutés sur quels projets vont-ils faire leurs armes ?
Ce qui est certain c'est que les compétences clés changent. Les développeurs, peu importe leur experience, doivent être plus proche de leur produit et plus proche de la théorie. Hier il fallait être capable de produire du code pour être développeur, aujourd'hui il faut savoir ce qui fait qu'un code est bon et comment il répond aux besoins exprimés.
Les cursus vont devoir s'adapter, la culture du développement aussi et ça prendra du temps. En attendant le recrutement se complexifie lentement mais surement et les entreprises comme Athoria renforcent déjà leurs parcours de formation internes pour pallier ces manques.
Trois risques structurels
Au-delà du « combien de développeurs », trois risques structurels méritent d'être nommés.
Le premier est celui de la souveraineté et de la dépendance. La génération se concentre chez une poignée de fournisseurs, souvent hors d'Europe. On leur envoie du code et des données ; on subit leurs prix, leurs conditions, leurs ruptures de service et le contexte géopolitique. Plus on industrialise, plus le lock-in grandit. Les parades existent : catalogue MCP interne, abstraction des fournisseurs, cloisonnement des données sensibles, modèles open-weights.
Le deuxième concerne la sécurité et la propriété intellectuelle. Le code généré arrive en production avec une provenance et des licences floues ; les prompts deviennent un canal de fuite pour les secrets et le code propriétaire ; la surface d'attaque et la chaîne d'approvisionnement logicielle s'élargissent.
Le troisième, le plus lent et le plus sous-estimé, est la dette de compétence et de compréhension. À force de déléguer l'écriture, on perd deux choses : la main (savoir écrire et relire à bon niveau) et le modèle mental du système. C'est le pendant individuel du paradoxe du pipeline : on érode la compétence même par laquelle on saurait juger l'IA.
Ces trois risques ont un point commun : chacun érode la capacité à répondre de ses systèmes, c'est-à-dire la ressource qui devient le métier. Ce n'est donc pas un hors-sujet, les DSI font ou feront face à ses sujets dans un futur proche.
Du constat à l'action
Je ne sais pas combien il faudra de développeurs en 2030. Mais je sais quelles équipes seront en position de force dans tous les scénarios, et c'est vérifiable dès maintenant. Voici six actions : aucune ne parie sur un scénario, toutes sont rentables que la demande explose ou que les effectifs se compriment.
Pour les développeurs
Construisez votre harnais. Spécifiez comme vous codez : des fichiers versionnés dans le dépôt (conventions, architecture, interdits), des serveurs MCP qui donnent à l'IA le contexte réel de votre système, des critères d'acceptation écrits avant de générer et des tests de bonne qualité. Ces instructions sont du code : on les revoit, on les partage, on les améliore. Si une génération est mauvaise cherchez pourquoi, ajustez le contexte et validez si l'ajustement est bénéfique.
Investissez dans vos compétences. Maîtrisez ce nouvel outil. Affirmez vos convictions sur les bonnes pratiques, l'architecture et l'agilité. Spécifier correctement et être capable de trancher un choix d'implémentation sont des compétences qui auront de la valeur peut importe le scénario. Apprenez également à mettre en place un pipeline de qualité solide pour votre application. Sachez ce qui fait un bon test, un bon log. vous vous en remercierez.
Faites de la lecture critique votre compétence signature. En revue, exigez le pourquoi avant le quoi, et traquez la cérémonie (gardes impossibles, try/except redondants) avec un réflexe de suppression. Utilisez l'IA pour relire le code de l'IA, mais signez vous-même. La ligne de responsabilité tient en une phrase : ne mergez jamais ce que vous ne sauriez pas expliquer dans un post-mortem.
Pour les managers
Mesurez l'aval, pas le volume. Une équipe qui livre plus vite avec un taux d'incidents qui monte n'est pas en train de gagner : elle emprunte (Faros : +34 % de débit, mais +243 % d'incidents). À côté de la vélocité, suivez le churn de code, le délai de première revue, la part de pull requests mergées sans revue, le ratio incidents/PR. Et souvenez-vous du contre-modèle : quand on ne voit plus le système, on se met à surveiller les gens. Deux dailys par jour, c'est un symptôme de métriques absentes.
Trouver le goulot d'étranglement. Avant c'était l'ecriture, aujourd'hui la revue, demain ce sera probablement la maintenance. Prenez du feedback de vos équipes et imaginer les solutions ensemble. Le temps de revue se budgète comme du travail, pas comme un overhead. Le refactoring doit être vendu pour ce qu'il est devenu : un investissement de productivité IA, puisque l'IA performe mal sur du code malsain. Et votre guilde IA doit recevoir un mandat réel (règles, catalogue MCP, évaluation des outils), pas reposer sur le bénévolat de quelques évangélistes.
Fabriquez vos seniors, maintenant. Ils se recrutent aujourd'hui. Continuez d'embaucher des jeunes diplômés, mais changez leur parcours : binômes de revue (et pas seulement de production), rotations sur la maintenance, shadowing d'incidents. L'IA est encouragée, mais chaque ligne mergée doit pouvoir être expliquée. Car le marché ne vous vendra plus des seniors à volonté : la fabrique de seniors, désormais, c'est vous.
Conclusion
L'équipe aux deux dailys n'avait pas un problème d'IA. Elle avait cessé de pouvoir répondre de son système.
L'IA ne remplace pas les développeurs. Elle change ce qui est rare : non plus produire du code, mais s'en servir pour répondre aux problématiques de nos clients. Notre travail consiste à déplacer l'effort exactement là où la responsabilité reste humaine : mesurer, lire, répondre, transmettre. L'ingénieurie est de retour.
Besoin d'un expert pour identifier le goulot d'étranglement dans vos équipes ? Contacter-nous. (nouvelle fenêtre)