IA et programmation : la fin du métier de développeur ?

Les outils suppriment des tâches, pas nécessairement le besoin

Le 10 novembre 1954, le groupe de recherche d'IBM présentait un rapport préliminaire sur FORTRAN. L'idée était claire : le langage devait « pratiquement éliminer le codage et le débogage ». Le rapport allait même jusqu'à évoquer un coût inférieur à la moitié de celui des méthodes habituelles.

FORTRAN a bel et bien retiré une partie du travail : traduire à la main des formules en instructions machine. En revanche, il n'a pas « supprimé » le débogage. Il a surtout changé l'endroit où le travail s'acharne : les développeurs ont gagné en abstraction, et les organisations ont logiquement demandé plus de logiciels.

Le même schéma s'est rejoué avec les langages de niveau supérieur, puis avec les bibliothèques, les moteurs de recherche pour retrouver des réponses techniques, les gestionnaires de paquets et les assistants de code. À chaque étape, une partie du processus devient plus facile, ce qui rend aussi économiquement envisageables des projets qui ne l'étaient pas avant.

En 1981, une entreprise britannique a même commercialisé un générateur de programmes BASIC appelé The Last One. Le nom voulait dire : « c'est le dernier outil dont vous aurez besoin ». Ça a aidé certains usages, notamment des logiciels de gestion, mais ce n'était évidemment pas le dernier mot. La promesse était séduisante : automatiser la production. La réalité est plus têtue : il faut toujours décider quoi construire, pour qui, et avec quelles contraintes.

Une adoption rapide, mais une confiance limitée

L'IA pousse encore plus vite dans ce cycle. D'après l'enquête annuelle de Stack Overflow, la part des développeurs qui utilisent déjà des outils d'IA ou prévoient de le faire est passée de 70 % en 2023 à 84 % en 2025. Environ la moitié des développeurs professionnels interrogés disaient les utiliser chaque jour.

Mais utiliser un outil n'est pas la même chose que lui faire confiance. Le sentiment favorable est passé de 77 % en 2023 à 60 % en 2025, puis a légèrement remonté à 62 % en 2026. En 2025, 46 % des répondants se méfiaient de l'exactitude des résultats, contre 33 % qui leur faisaient confiance. La frustration revient souvent : des solutions « presque justes, mais pas tout à fait ».

Ce « presque » coûte cher. Un résultat manifestement faux se rejette vite. Un résultat plausiblement correct oblige à lire attentivement, à tester, et parfois à explorer plusieurs zones du système pour vérifier que tout tient. L'enquête le montre : 45 % des développeurs estimaient que déboguer du code produit par l'IA leur prenait plus de temps.

Le vibe coding, l'expression popularisée en 2025 pour décrire une programmation pilotée surtout par des suggestions, aide à comprendre l'écart entre démonstration et usage réel. Dans l'enquête Stack Overflow, 72 % des développeurs disaient que cette approche ne faisait pas partie de leur pratique professionnelle. Générer vite un prototype ne veut pas dire réussir à maintenir un service fiable, sécurisé et compréhensible.

Le ressenti de vitesse ne suffit pas

Une étude de METR, un organisme de recherche à but non lucratif, a regardé ce qui se passe sur des tâches réelles. Début 2025, seize développeurs expérimentés ont travaillé sur 246 problèmes issus de leurs propres dépôts. Chaque tâche leur était assignée aléatoirement avec ou sans outils d'IA.

Avant l'expérience, ils pensaient gagner 24 % de temps grâce à l'IA. Après les tâches, ils estimaient leur gain à 20 %. Pourtant, le chronomètre indiquait qu'ils avaient pris 19 % de temps en plus. L'étude a ses limites : petit échantillon, outils plutôt récents au moment des tests, et codebases familières. Mais elle rappelle un point simple : se sentir plus rapide n'est pas une mesure de productivité.

METR a ensuite lancé une étude plus large, avec 57 développeurs et plus de 800 tâches. En février 2026, l'organisation a indiqué que les données étaient trop incertaines pour conclure sans risque. Certains participants refusaient de travailler sans IA. Les premiers résultats faisaient penser à un gain de 18 % pour ceux qui avaient participé aux deux études, mais l'incertitude était assez grande pour inclure l'hypothèse d'absence de gain.

Au final, la bonne réponse n'est donc ni de rejeter l'IA sur la base d'une étude, ni de compter uniquement les lignes générées. Il faut comparer le temps total, les retours en arrière, les défauts en production et le coût de revue, sur des tâches vraiment comparables. Un outil peut accélérer une étape tout en déplaçant le travail ailleurs.

La file d'attente se déplace vers la revue

C'est exactement ce que suggèrent les données agrégées par Faros AI. En 2025, une analyse de télémétrie portant sur plus de 10 000 développeurs et 1 255 équipes associait une forte adoption de l'IA à 21 % de tâches terminées en plus et 98 % de demandes de fusion supplémentaires. Mais le temps de revue a aussi augmenté de 91 %.

En 2026, une analyse portant sur 22 000 développeurs signalait une hausse de 34 % des tâches achevées par développeur. Dans le même temps, le temps médian de revue était multiplié par cinq. La part des demandes de fusion intégrées sans revue a augmenté de 31 %, et le ratio d'incidents par demande de fusion a plus que triplé. Ce n'est pas une preuve que l'IA cause tout, mais ça donne une image assez claire des risques opérationnels.

La mécanique est connue : si vous chauffez le grill plus vite, les assiettes s'accumulent au passe. En logiciel, produire plus vite peut saturer la revue, les tests ou l'exploitation. Si, face à cette pression, on réduit les contrôles, on augmente le volume tout en perdant en fiabilité.

Sur la sécurité, les signaux invitent à la prudence. Veracode a testé plus de cent modèles sur 80 tâches de programmation en 2025 : 45 % des résultats contenaient une faille de sécurité. Ce n'est pas une photographie de tout le code écrit en entreprise, mais c'est un signal concret : un code qui compile et passe une démo n'est pas automatiquement sûr.

Le principe de Fred Brooks, dans No Silver Bullet, aide à comprendre ce déplacement : les outils réduisent les difficultés accidentelles - syntaxe, code répétitif, configuration - mais pas forcément les difficultés essentielles : définir le comportement attendu, concevoir le système, vérifier qu'il répond au besoin. Dans l'exemple du remboursement, l'agent peut écrire la logique. Ce qu'il ne peut pas savoir sans règles explicites, c'est ce que l'entreprise doit décider.

Le travail junior est une étape d'apprentissage

Les tâches automatisées ne sont pas toutes « inutiles ». Les tickets simples, les corrections limitées et les petites évolutions servent souvent de premier terrain d'apprentissage : on y apprend les conventions du projet, les effets de bord, ce que veulent vraiment les utilisateurs, et ce que produit une mise en production.

Une analyse publiée en 2025 par le laboratoire d'économie numérique de Stanford, à partir de données de paie ADP, signalait une baisse proche de 20 % de l'emploi des développeurs âgés de 22 à 25 ans par rapport à son sommet de fin 2022. Une mise à jour utilisant des données jusqu'à juin 2026 indiquait que les jeunes travailleurs sur des métiers exposés à l'IA étaient 19 % sous la trajectoire de groupes moins exposés. La différence semblait surtout venir d'une baisse des embauches.

Ces résultats restent descriptifs, pas une preuve de causalité. Les taux d'intérêt, les recrutements excessifs pendant la pandémie et le ralentissement du marché tech jouent aussi. L'indice d'offres d'emploi en développement logiciel d'Indeed restait d'ailleurs environ 21 % sous son niveau de février 2020, après un creux à moins 39 % en mai 2025. On ne peut donc pas attribuer toute la baisse à l'IA.

Cela dit, la mise en regard avec les capacités des agents mérite d'être surveillée. Les tâches bien délimitées qu'on confiait hier à un junior sont justement celles que des agents essaient aujourd'hui de traiter. Si les entreprises arrêtent de recruter à ce niveau, elles peuvent gagner du temps à court terme et perdre du terrain sur le long terme.

Organiser un nouvel apprentissage plutôt que supprimer le premier échelon

Un développeur expérimenté n'apprend pas uniquement en lisant de la documentation. Il progresse en prenant en charge de petits changements, en se trompant dans un cadre contrôlé, en observant les conséquences, et en recevant une revue exigeante. Retirer les tâches simples, sans construire un autre parcours, ne supprime pas seulement du travail répétitif : ça peut aussi couper une partie de l'apprentissage.

Les équipes peuvent adapter la formation sans abandonner les agents. Par exemple :

• donner à un junior la responsabilité d'un petit système complet (end-to-end), plutôt que d'enchaîner des micro-corrections sans contexte ;
• lui demander de rédiger les critères d'acceptation et les tests avant de déléguer la génération de code ;
• organiser des revues conjointes où un senior parle des risques, pas seulement du style ;
• faire analyser par le junior les hypothèses et les limites du résultat produit par l'agent ;
• évaluer la compréhension du système et la qualité des décisions, pas le volume de lignes écrites.

Écrire une spécification et des tests n'est pas un travail « secondaire ». C'est une façon de transmettre les règles métier et de rendre explicites les choix. Dans un contexte européen, ces règles doivent aussi intégrer les contraintes de protection des données, de sécurité et de traçabilité. L'IA peut aider à produire une implémentation ; la responsabilité de définir et de contrôler le comportement reste à l'organisation.

Des agents plus autonomes, mais pas infaillibles

METR suit la durée des tâches que des agents logiciels peuvent finir avec succès dans la moitié des cas, en comparant leurs résultats à ceux d'experts humains. Dans cette série, la durée est passée d'environ trois secondes pour GPT-2 en 2019 à quatre minutes pour GPT-4 en 2023, puis à une heure pour Claude 3.7 Sonnet en février 2025. Claude Opus 4.6 atteignait environ douze heures un an plus tard.

Globalement, la durée a doublé environ tous les six mois, et plus vite depuis 2023. Mais une courbe qui accélère n'est pas une promesse. La mesure repose sur un taux de réussite de 50 %, les tâches sont plus « propres » que ce qu'on rencontre en production, et METR a signalé des limites de fiabilité après 16 heures. Prolonger jusqu'à un mois de travail humain en 2028 reste un scénario, pas une date verrouillée.

Même si les entreprises développent leurs propres outils, elles donnent parfois une image de la trajectoire. Google annonçait en 2024 que plus d'un quart de son nouveau code était généré par l'IA, puis « bien plus de 30 % » six mois plus tard. En mai 2026, Anthropic indiquait que Claude avait écrit plus de 80 % du code intégré à sa base. Ces chiffres sont liés à des contextes précis : ils ne veulent pas dire que 80 % du travail de développement a disparu.

Cinq évolutions plausibles pour les équipes

Voici cinq changements qui semblent crédibles à moyen terme, sans pour autant les présenter comme des certitudes :

1. Des équipes plus petites, mais davantage de projets. Les outils réduisent le coût d'une première version. Certaines petites entreprises ou équipes internes pourraient lancer des logiciels qui n'auraient pas justifié un trimestre de développement. Ça ne garantit pas une hausse des emplois dans chaque organisation, mais le coût plus bas peut créer de nouveaux usages.
2. Les spécifications et les tests prennent plus de place. Le code est souvent vu comme le livrable principal, alors que les règles métier finissent dans un document qu'on relit rarement. Avec une génération plus automatique, on aura plus tendance à relire les règles, les scénarios et les tests, et à considérer le code comme une sortie qu'on doit inspecter, pas seulement produire.
3. Des logiciels pensés pour une seule personne, ou un besoin très précis. Si un outil simple peut être construit en une soirée plutôt qu'en plusieurs mois, certains utilisateurs bâtiront des solutions temporaires pour leur propre activité. Reste que maintenance et sécurité comptent : un prototype utile peut devenir critique sans que personne ne l'ait prévu.
4. La lecture de code devient une compétence plus visible. Les organisations auront besoin de gens capables de repérer les hypothèses, les risques et les changements vraiment importants. Les outils de revue devront mieux pointer les zones sensibles, les tests manquants et les comportements observables, pas juste afficher un gros diffs.
5. Chaque changement laisse une trace plus claire. Une demande de fusion pourra indiquer qui a produit le changement, qui l'a vérifié et ce qui a réellement été testé. Cette traçabilité aide la maintenance et la sécurité, et colle aussi aux exigences de gouvernance qui montent.

Le scénario le plus probable n'est donc pas « un développeur qui ne fait plus rien », ni « un agent qui remplace une équipe entière sans supervision ». C'est plutôt un métier où une partie croissante de l'implémentation est déléguée, pendant que définir le besoin, relire, arbitrer et assumer la responsabilité prend plus de place.

Pour savoir si cette évolution améliore vraiment votre activité, mesurez le cycle complet : délai entre la demande et la mise en production, défauts après livraison, temps de revue, incidents, et satisfaction des utilisateurs. Comparez des tâches comparables, et séparez le temps de génération du temps nécessaire pour comprendre et maintenir le résultat. Sans ça, vous ne saurez pas si l'IA a réduit le travail ou juste déplacé le goulot.