Peut-on avoir sa propre IA ? Ce que votre entreprise possède vraiment
Avoir sa propre IA : ce qu'on vend sous ce nom aux PME, qui peut vraiment entraîner un modèle, ce que votre entreprise possède à la fin, et comment le vérifier.
36 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
On l’entend dans les médias, on le lit sur LinkedIn : bientôt, l’IA écrira tout le code, et l’on n’aura plus besoin de développeurs. Pour un dirigeant qui envisage de faire développer un logiciel, la question est concrète. Faut-il attendre ? Faut-il encore faire appel à des professionnels ?
La promesse n’est pas neuve. Depuis les premiers ordinateurs, plusieurs grandes avancées de l’informatique ont été présentées comme celles qui rendraient les programmeurs inutiles. À ce jour, en 2026, les données disponibles montrent un métier qui change, avec un recul de l’emploi des plus jeunes dans les métiers exposés à l’IA, mais pas un métier qui disparaît.
« Développeur » désigne en réalité plusieurs métiers. Le codeur reçoit une description déjà faite de ce qu’il faut construire, et la transforme en programme qui fonctionne. Le développeur part d’un problème et conçoit lui-même la solution. L’ingénieur logiciel, enfin, traite chaque choix comme une hypothèse à vérifier : il essaie, observe ce que font les utilisateurs, corrige, et garde un logiciel que l’on peut encore modifier sans risque.
Dave Farley est coauteur, avec Jez Humble, de Livraison continue (titre original en anglais : Continuous Delivery), le livre de référence sur la livraison continue logicielle, et auteur de L’Ingénierie logicielle moderne (titre original en anglais : Modern Software Engineering). Il distingue lui aussi ces trois profils dans une vidéo publiée en juin 2025. Pour lui, l’ingénieur logiciel aborde les problèmes avec une démarche scientifique et rationnelle, et sait, après chaque petite modification, si son logiciel peut être mis en production.
L’IA ne menace pas ces trois métiers de la même façon. Pour le premier, l’histoire de l’informatique offre déjà un précédent.
Dans les années 1960, un programme s’écrivait d’abord à la main, sur des feuilles de programmation. Il fallait ensuite le reporter sur des cartes perforées pour que l’ordinateur puisse le lire. Dans les grandes organisations, ce travail revenait souvent à des opérateurs de saisie, qui perforaient les cartes au clavier, selon l’ACONIT, association consacrée à l’histoire de l’informatique, et la Fédération des équipes Bull. Ils saisissaient surtout des données de gestion. Dans les petites structures, les programmeurs perforaient souvent eux-mêmes leurs cartes.
Ce poste était alors confié le plus souvent à des femmes. Le document de la Fédération des équipes Bull l’écrit au féminin, « opératrice de saisie », et lui demande de la « dextérité ». Sa seule évolution mène à « opératrice de vérification » ou à « monitrice ». Le poste masculin d’« opérateur de mécanographie », lui, peut mener à « technicien de mise en route (en fait programmeur) ».
Cette répartition reposait sur une idée reçue, que l’histoire a démentie : un travail de femme serait un travail d’exécution. Aux États-Unis, les premières personnes à programmer l’ENIAC, l’un des tout premiers ordinateurs, étaient des femmes. Selon l’historien Nathan Ensmenger, cité par l’université Stanford, leurs responsables les avaient choisies parce qu’ils voyaient dans la programmation une tâche de bureau peu qualifiée, « comparable au classement, à la dactylographie ou au standard téléphonique » (en anglais : “akin to filing, typing, or telephone switching”). La programmation s’est révélée un travail intellectuel exigeant. Les hommes y sont alors arrivés, aidés par des tests de recrutement fondés sur des profils de personnalité qui les favorisaient. En France, les chercheuses Isabelle Collet et Nicole Mosconi font le même constat dans un article de 2010 : les femmes occupaient 34 % des métiers de l’informatique en 1982, et 20 % en 2002. Les hommes y sont arrivés en masse « à mesure que les emplois gagnaient en prestige ».
Au cours des années 1970, des terminaux reliés à des ordinateurs en temps partagé permettent au programmeur de taper lui-même son programme, sans passer par les cartes, rappelle l’encyclopédie Wikipédia. En 1980, aux États-Unis, une personne sur cinq travaillant dans l’informatique était encore opérateur de saisie. Le Bureau of Labor Statistics, l’organisme public américain de statistiques du travail, prévoyait déjà la baisse de cette demande. Le métier a survécu dans la saisie de données sur écran, qui recule toujours : 520 220 emplois en 1999, 174 930 en 2018, selon la Monthly Labor Review, la revue de cet organisme.
Ce qui a presque disparu, ce n’est pas le programmeur. C’est l’étape où quelqu’un d’autre tapait ce qu’un programmeur avait conçu. Aux États-Unis, on comptait 176 500 programmeurs en 1970, selon un bulletin du Bureau of Labor Statistics. En 2025, si l’on compte avec eux les développeurs de logiciels, ils sont 1 828 600, dix fois plus, selon le même organisme. Les catégories de 1970 et de 2025 ne sont pas strictement comparables : ce rapport donne un ordre de grandeur.
Le Census Bureau, l’institut public américain de recensement, décrit les programmeurs comme des professionnels qui travaillent « à partir de spécifications rédigées par des développeurs ou par d’autres personnes » (en anglais : “from specifications drawn up by software developers or other individuals”). Parmi les intitulés qu’il range dans ce métier figure d’ailleurs celui de « codeur ». C’est précisément le travail que les outils d’IA font déjà bien. Dans sa vidéo, Dave Farley juge les IA « très bonnes pour traduire des instructions détaillées en code » (en anglais : “very good at translating detailed instructions into code”).
Le métier de programmeur recule déjà. Selon le Bureau of Labor Statistics, les programmeurs étaient 585 000 en 2000 et 110 800 en 2025. Une partie de cette baisse tient à un changement de classement : depuis 2000, les statistiques américaines comptent à part les ingénieurs et développeurs de logiciels. Mais pour les dix ans à venir, le Bureau prévoit encore un recul de 7 %. Il l’explique par l’automatisation d’une partie de ce travail, notamment par l’IA, et par le fait que les tâches les plus qualifiées reviennent désormais aux développeurs.
À notre lecture, le codeur occupe désormais une place comparable à celle des opérateurs de saisie : il exécute une description pensée par d’autres. C’est à cette étape que s’attaquent aujourd’hui les outils d’IA.
L’IA n’est pas née avec ChatGPT. L’idée d’une machine capable de raisonner précède de plusieurs siècles les premiers ordinateurs.
À la fin du XIIIe siècle, le philosophe majorquin Raymond Lulle conçoit un « Art » fondé sur la combinaison de notions. Certaines de ses figures sont faites de cercles qui tournent les uns sur les autres pour former ces combinaisons, selon la Stanford Encyclopedia of Philosophy, l’encyclopédie de philosophie de l’université Stanford. En 1642, Blaise Pascal invente une machine à calculer, que présente aujourd’hui le Musée des arts et métiers. En 1655, le philosophe anglais Thomas Hobbes écrit que raisonner revient à calculer, comme le rappelle le chercheur Giuseppe Longo dans un cours de l’École normale supérieure. Gottfried Wilhelm Leibniz, philosophe et mathématicien allemand, rêve ensuite d’une langue où deux personnes en désaccord trancheraient en se disant « Calculons » (en latin : Calculemus), rapporte la revue The Public Domain Review.
En 1843, la mathématicienne britannique Ada Lovelace décrit la machine analytique imaginée par Charles Babbage. Elle en pose aussi la limite : la machine « n’a nullement la prétention de créer quoi que ce soit. Elle peut faire tout ce que nous savons lui ordonner d’exécuter » (en anglais : “has no pretensions whatever to originate anything. It can do whatever we know how to order it to perform”), selon sa note G.
En 1950, le mathématicien britannique Alan Turing ouvre un article de la revue Mind par ces mots : « Je propose d’examiner la question : les machines peuvent-elles penser ? » (en anglais : “I propose to consider the question, ‘Can machines think?’”). En août 1955, John McCarthy et trois autres chercheurs proposent d’organiser, l’été suivant, au Dartmouth College, une étude de deux mois consacrée à l’« intelligence artificielle » (en anglais : “artificial intelligence”). Leur proposition part du principe que tout aspect de l’intelligence « peut en principe être décrit si précisément qu’une machine peut être fabriquée pour le simuler » (en anglais : “can in principle be so precisely described that a machine can be made to simulate it”).
Les outils d’IA dont on parle en 2026 ne se contentent plus de compléter une ligne de code. Ce sont des agents. Dans une publication de décembre 2024, Anthropic, l’éditeur de l’IA Claude, distingue deux cas. Dans le premier, un programme enchaîne des étapes fixées à l’avance. Dans le second, l’agent, le modèle d’IA « dirige lui-même ses étapes et l’usage de ses outils » (en anglais : “dynamically direct their own processes and tool usage”).
En développement, un agent IA lit le code existant, le modifie, lance les tests automatisés et recommence tant qu’ils échouent. Anthropic note qu’un agent peut « améliorer ses solutions en se servant des résultats des tests » (en anglais : “iterate on solutions using test results as feedback”). On parle de développement agentique. La même publication précise que « la relecture humaine reste essentielle » (en anglais : “human review remains crucial”).
À notre lecture, un agent IA exécute très bien une tâche qui ne demande pas de jugement : transformer une description précise en code qui passe les tests. C’est le travail du codeur. Il ne décide pas à votre place de ce qui mérite d’être construit, et il ne répond pas de ce choix devant vos utilisateurs. On ne peut donc plus se contenter d’être codeur ou programmeur : la valeur d’un professionnel se trouve dans ce qui ne se délègue pas à une machine.
Ce n’est pas la première fois qu’un outil doit rendre les programmeurs inutiles.
En novembre 1954, une équipe d’IBM présente FORTRAN. Ce langage permet d’écrire un calcul sous une forme proche de la notation mathématique, puis laisse la machine le traduire en instructions. Son rapport préliminaire l’annonce : FORTRAN « devrait pratiquement éliminer le codage et le débogage » (en anglais : “should virtually eliminate coding and debugging”), c’est-à-dire la recherche et la correction des erreurs. Il devait permettre de résoudre un problème pour moins de la moitié du coût habituel.
Trente ans plus tard, Fred Brooks revient sur ces promesses. Il a dirigé chez IBM la conception d’une grande gamme d’ordinateurs, fondé le département d’informatique de l’université de Caroline du Nord, et reçu le prix Turing, la plus haute distinction de la discipline. Dans « Pas de solution miracle » (titre original en anglais : “No Silver Bullet”), un texte de 1986, il rappelle qu’on parle de « programmation automatique » depuis près de quarante ans. Il y cite un autre informaticien, David Parnas : la programmation automatique « a toujours été un euphémisme » (en anglais : “always has been a euphemism”) pour désigner la programmation dans un langage de plus haut niveau que celui dont on disposait jusque-là.
Ce que l’on présentait comme une machine qui programme seule était en réalité un nouveau langage, dans lequel des programmeurs devaient encore écrire.
En 1959, un comité réuni à l’initiative du département de la Défense des États-Unis conçoit COBOL, un langage destiné à la gestion. Ses instructions sont construites comme des phrases en anglais, selon IEEE Spectrum. Jean Sammet, membre de ce comité, l’a écrit en 1978 : il était « certainement prévu (et attendu) que le langage puisse être utilisé par des programmeurs novices et lu par la direction » (en anglais : “certainly intended (and expected) that the language could be used by novice programmers and read by management”).
L’idée revient en janvier 2023, quand Andrej Karpathy, chercheur en intelligence artificielle et cofondateur d’OpenAI, publie ce message :
The hottest new programming language is English
Le langage de programmation le plus en vogue du moment, c'est l'anglais.
En février 1981, le magazine britannique Personal Computer World présente The Last One, un générateur de programmes. Le journaliste David Tebbutt y voit un logiciel qui pourrait devenir « le dernier jamais écrit par un être humain » (en anglais : “the last one ever written by a human being”). Le codeur « va devoir changer de métier » (en anglais : “going to have to change his job”), écrit-il. Les autres professionnels de l’informatique, selon lui, y gagneront.
En 1982, James Martin publie un livre au titre explicite : Développer des applications sans programmeurs (titre original en anglais : Application Development Without Programmers). Entré chez IBM à la fin des années 1950, il est devenu consultant et a écrit plus de cent livres sur l’informatique, selon The Register. Dans la préface, que le développeur Simon Willison cite sur son blog, il prévoit que « la plupart des ordinateurs devront, à l’avenir, fonctionner au moins en partie sans programmeurs » (en anglais : “most computers in the future will have to work at least in part without programmers”). Son livre présente les langages dits « non procéduraux » : on y décrit le résultat voulu, et non les étapes pour l’obtenir.
Dans les années qui suivent arrivent les ateliers de génie logiciel, les AGL (outils CASE, en anglais). Ils permettent de dessiner une application sous forme de schémas, ses données comme ses traitements, et certains en génèrent ensuite le code. IEF, conçu par Texas Instruments avec James Martin et son cabinet, produisait ainsi du code COBOL, selon Wikipédia. En France, ces ateliers accompagnent la méthode Merise, élaborée à partir de 1978 à l’initiative du ministère de l’Industrie : AMC Designor, MEGA ou WinDesign, selon un cours de Bernard Espinasse, enseignant-chercheur à l’université d’Aix-Marseille.
Ces outils sont présentés comme la solution aux problèmes de productivité et de qualité du métier. En 1992, Chris Kemerer, alors chercheur à la MIT Sloan School of Management, pose la question dans la revue spécialisée IEEE Software : pourquoi tant d’organisations achètent-elles ces outils pour les laisser sur l’étagère ? Il cite une étude : un an après leur introduction, 70 % de ces outils et techniques n’avaient jamais servi, 25 % n’étaient employés que par une seule équipe, et 5 % l’étaient largement, sans qu’on en tire tout le parti.
La programmation orientée objet découpe un programme en « objets », qui regroupent des données et les opérations qui s’y appliquent. Brooks lui-même en attendait beaucoup en 1986. Il doutait pourtant qu’elle règle l’essentiel de la difficulté.
En 1990, dans le magazine d’informatique BYTE, Brad Cox annonce « une révolution industrielle du logiciel fondée sur des pièces réutilisables et interchangeables » (en anglais : “a software industrial revolution based on reusable and interchangeable parts”), dans « Il existe une solution miracle » (titre original en anglais : “There Is a Silver Bullet”). Cofondateur de la société Stepstone et à l’origine du langage Objective-C, il commercialise des « circuits intégrés logiciels » (en anglais : “Software-ICs”) : des composants logiciels pensés comme les puces que l’on assemble sur une carte électronique.
Avec les systèmes de gestion de contenu (CMS), créer un site web ne demande plus d’écrire de code. WordPress, le plus répandu, fait fonctionner 39,7 % des sites web, selon le relevé de W3Techs du 16 octobre 2026. Ses extensions ajoutent à un site un formulaire, une boutique ou un agenda : ce sont des fonctions écrites par des développeurs, que chacun peut ensuite installer en quelques clics depuis le répertoire officiel de WordPress.
Les éditeurs de ces outils promettent de se passer du code. En septembre 2010, Wix, un service de création de sites web, met en avant une interface où l’on construit son site en faisant glisser des éléments à la souris, et qui « retire de l’équation les codes informatiques complexes » (en anglais : “removing complex computer codes from the equation”). Ces fonctions et ces outils restent écrits par des développeurs. Ce qui change, c’est qui les assemble.
En 2014, le cabinet d’études Forrester a baptisé « low-code » des plateformes qui accélèrent la création d’applications en « réduisant considérablement la quantité de code écrit à la main » (en anglais : “dramatically reducing the amount of hand-coding required”). Le low-code consiste à construire une application en assemblant des blocs visuels plutôt qu’en écrivant du code.
En 2019, le cabinet d’études Gartner a prédit que, d’ici 2024, le low-code représentera « plus de 65 % de l’activité de développement d’applications » (en anglais : “more than 65% of application development activity”), rapporte ADTmag. Ces plateformes doivent permettre à des employés sans formation en programmation, qu’ADTmag appelle des développeurs « citoyens » (en anglais : “citizen developers”), de créer eux-mêmes leurs applications d’entreprise. En juin 2021, Gartner est allé plus loin : d’ici 2024, 80 % des produits et services technologiques seraient construits par des personnes qui ne sont pas des professionnels de la technologie, rapporte le site Technology Decisions. Nous n’avons pas trouvé de bilan de ces prévisions publié par Gartner.
En février 2024, au World Government Summit de Dubaï, Jensen Huang, PDG du fabricant de puces Nvidia, a déclaré, selon Tom’s Hardware : « Notre travail est de créer une technologie informatique telle que personne n’ait à programmer » (en anglais : “It is our job to create computing technology such that nobody has to program”). Et : « Tout le monde est désormais programmeur » (en anglais : “Everybody in the world is now a programmer”).
En janvier 2025, dans l’émission d’entretiens de l’animateur américain Joe Rogan, Mark Zuckerberg, PDG de Meta, a annoncé que Meta et les autres entreprises du secteur auraient « probablement en 2025 » (en anglais : “probably in 2025”) une IA capable de tenir le rôle d’un ingénieur de niveau intermédiaire, rapporte Fortune.
En février 2025, Sam Altman, PDG d’OpenAI, l’éditeur de ChatGPT, invitait dans un billet de blog à imaginer un agent d’IA capable, à terme, de faire « la plupart des choses » (en anglais : “most things”) que fait un ingénieur logiciel de quelques années d’expérience dans une grande entreprise, sur des tâches de deux jours au plus.
Le 10 mars 2025, Dario Amodei, PDG d’Anthropic, s’est exprimé devant le Council on Foreign Relations, un cercle de réflexion américain sur la politique étrangère. « Je pense que nous y serons dans trois à six mois, au point où l’IA écrit 90 % du code », a-t-il déclaré (en anglais : “I think we’ll be there in three to six months, where AI is writing 90% of the code”). « Et dans douze mois, nous pourrions être dans un monde où l’IA écrit pratiquement tout le code » (en anglais : “And then in 12 months, we may be in a world where AI is writing essentially all of the code”). Une semaine plus tôt, Anthropic avait annoncé une levée de fonds de 3,5 milliards de dollars.
Ces quatre déclarations sont celles de dirigeants d’entreprises qui développent de l’IA ou fabriquent les puces qui la font fonctionner. Deux d’entre elles portent une échéance : 2025 pour Mark Zuckerberg, septembre 2025 et mars 2026 pour Dario Amodei. On peut donc les comparer à ce qui s’est passé depuis. Pour les 90 % annoncés par Dario Amodei, la seule vérification extérieure que nous ayons trouvée vient de Ryan Greenblatt, directeur scientifique de Redwood Research, un organisme de recherche sur la sécurité de l’IA. En octobre 2025, il jugeait cette prédiction « probablement fausse » (en anglais : “probably false”). Selon lui, l’IA écrivait alors environ 50 % du code d’Anthropic, et 90 % dans certaines équipes seulement. Pour l’échéance annoncée par Mark Zuckerberg, nous n’avons trouvé aucune vérification extérieure.
Aucune de ces vagues n’a fait baisser le nombre total de personnes qui développent des logiciels pour leur métier, même si celui des seuls programmeurs recule. Aux États-Unis, programmeurs, ingénieurs et développeurs de logiciels occupaient 1 282 000 emplois en 2000, et 1 828 600 en 2025, selon le Bureau of Labor Statistics. Ces chiffres comptent des emplois : ceux qui programment pour leur plaisir, ou à côté d’un autre métier, n’y figurent pas.
En France, aucune série publique ne suit les seuls développeurs sur une longue période. Les chiffres disponibles portent sur l’ensemble des informaticiens : ils indiquent une tendance, pas le nombre de développeurs. On comptait 200 000 informaticiens en 1985 et près de 300 000 dix ans plus tard, selon le Centre d’analyse stratégique et la Dares cités par Le Monde Informatique. En 2017, l’Insee recensait 730 000 personnes dans les métiers du numérique, un ensemble plus large encore.
Les échecs offrent un point de comparaison. Quand les machines sont devenues plus fortes que les joueurs, on pouvait craindre de voir ces derniers déserter le jeu. En mai 1997, Deep Blue, un ordinateur d’IBM, est devenu le premier à battre un champion du monde en titre, Garry Kasparov, dans un match disputé aux conditions de tournoi, selon IBM. Les joueurs, eux, n’ont pas disparu. La Fédération française des échecs comptait 50 883 licenciés pour la saison 2019-2020, et 92 815 pour la saison 2025-2026, au 1er septembre 2026 : le nombre de licenciés a presque doublé, alors que les machines jouent mieux que les humains depuis 1997.
Il en va peut-être de même pour la programmation. Depuis février 2025, on parle de « vibe coding », un terme introduit par Andrej Karpathy, que l’on pourrait traduire par « coder à l’intuition » : on décrit en langage courant ce que l’on veut, et l’IA écrit le code. Selon l’encyclopédie Wikipédia, cette pratique permet à des amateurs sans formation en ingénierie logicielle de produire des logiciels. À notre lecture, beaucoup de ces « vibe codeurs » ne sont ni des professionnels ni des développeurs de métier, et ils n’apparaissent pas dans les statistiques d’emploi.
Pour ceux qui en font leur métier, le marché de 2026 est plus dur, surtout en début de carrière. L’Apec, l’association pour l’emploi des cadres, a compté sur son site 31 370 offres d’emploi de développeurs en 2022, et 15 830 en 2024. Seules 24 % de ces offres étaient ouvertes aux débutants, contre 30 % pour l’ensemble des offres. La baisse s’est poursuivie en 2025, avec 12 690 offres, selon Le Monde Informatique. Sur le site d’emploi Indeed, les offres de développement logiciel publiées en France se situaient, au 16 octobre 2026, à 51,3 % de leur niveau de février 2020, contre 89,1 % pour l’ensemble des offres, selon les données de l’Indeed Hiring Lab.
En France, des chercheurs du LIFT, un laboratoire de HEC Paris, ont étudié avec la Banque de France les déclarations d’embauche. Dans leur étude d’octobre 2026, les embauches en CDI des développeurs et ingénieurs informatiques de 21 à 29 ans ont baissé d’environ 42 % entre novembre 2022 et mars 2026, contre 11 % dans les métiers moins exposés à l’IA. Les auteurs précisent que cette baisse est aussi la plus difficile à attribuer à l’IA : le secteur avait beaucoup recruté en 2021 et 2022, avant la remontée des taux d’intérêt.
Ceux qui annonçaient la fin des programmeurs, il y a quarante ans, ressemblent-ils à ceux qui l’annoncent aujourd’hui ? Sur un point au moins : chez IBM en 1954, chez Brad Cox en 1990 comme chez les dirigeants d’entreprises d’IA aujourd’hui, l’annonce venait de ceux qui créaient ou vendaient l’outil. La différence, cette fois, est réelle : une IA écrit déjà une partie du code. Mais la question reste la même. Qui décide de ce que ce code doit faire ?
Les développeurs se servent de l’IA. Le site de questions-réponses Stack Overflow interroge chaque année les développeurs qui le fréquentent. Dans son enquête 2025, 84 % des répondants utilisent des outils d’IA pour développer, ou comptent le faire. Ils s’en méfient aussi : 46 % doutent de l’exactitude des réponses, contre 33 % qui leur font confiance. Leur premier reproche, cité par 66 % d’entre eux : des solutions « presque justes, mais pas tout à fait » (en anglais : “almost right, but not quite”).
Le site Stack Overflow, lui, a perdu l’essentiel de ses questions. Pendant des années, les développeurs y posaient leurs questions et y trouvaient celles des autres. En mars 2014, 207 169 questions y ont été publiées. En novembre 2022, le mois où OpenAI a lancé ChatGPT, elles n’étaient plus que 109 120, et en septembre 2026, 974. Nous avons relevé ces chiffres le 20 octobre 2026 sur l’interface publique de Stack Exchange, qui ne compte que les questions encore en ligne. La baisse avait commencé avant ChatGPT ; elle s’est accélérée ensuite. Dès janvier 2025, Gergely Orosz, auteur de la lettre d’information The Pragmatic Engineer, constatait que le site n’avait pas reçu aussi peu de questions par mois depuis 2009, et y voyait l’effet des assistants d’IA.
Le temps que l’IA fait gagner aux développeurs reste difficile à établir. METR, un organisme de recherche qui évalue les modèles d’IA, a publié en juillet 2025 une expérience menée avec 16 développeurs expérimentés, qui travaillent sur des logiciels dont le code est public. Pour chacune de leurs 246 tâches réelles, un tirage au sort décidait s’ils pouvaient utiliser l’IA ou non. Avec l’IA, ils ont mis 19 % de temps en plus pour terminer leurs tâches. Avant l’expérience, ils comptaient gagner 24 % de temps ; après, ils estimaient encore en avoir gagné 20 %. Ils allaient donc moins vite tout en croyant aller plus vite.
En février 2026, METR a relancé l’expérience avec 57 développeurs et plus de 800 tâches. Les résultats penchent cette fois vers un gain de temps, mais METR les juge peu probants, à cause de la façon dont l’échantillon s’est constitué. De plus en plus de développeurs ont refusé de participer. Parmi ceux qui ont participé, 30 à 50 % disent avoir écarté certaines tâches parce qu’ils ne voulaient pas les faire sans IA. L’expérience perd donc justement les tâches où l’IA aide le plus : selon METR, le gain réel est probablement supérieur à celui mesuré. À ce jour, l’organisme revoit le protocole de son étude.
Quand écrire du code coûte moins cher, on voit mieux ce qui ralentissait déjà les projets. Comprendre le besoin, décider de ce qu’il faut construire, recueillir la réaction des utilisateurs, relier le logiciel aux autres outils de l’entreprise, vérifier qu’il fonctionne, le mettre en service : aucune de ces étapes ne va plus vite parce que le code s’écrit plus vite.
Eliyahu Goldratt, physicien devenu spécialiste de l’organisation industrielle, l’explique dans Le But (titre original en anglais : The Goal), un roman d’entreprise publié en 1984 : accélérer une étape qui n’est pas le goulot d’étranglement ne fait pas produire davantage à l’usine.
Les meilleurs professionnels du logiciel le disent depuis longtemps. Fred Brooks, dès 1986, distingue deux parts dans la construction d’un logiciel. La première est la traduction : exprimer une idée dans la langue de la machine, avec ses limites. La seconde est la conception : décider de la structure, souvent très complexe, de ce que le logiciel doit faire. Selon lui, les grands gains de productivité du passé ont levé des obstacles de la première part : des machines très limitées, des langages peu commodes, un temps de calcul rare.
FORTRAN, COBOL, les langages non procéduraux, les ateliers de génie logiciel, les objets, les CMS, le low-code : à notre lecture, chacun a allégé la traduction. Aucun n’a dispensé de la conception.
« La partie la plus difficile de la construction d’un logiciel est de décider précisément ce qu’il faut construire » (en anglais : “The hardest single part of building a software system is deciding precisely what to build”), écrit Brooks. Les clients, poursuit-il, n’ont presque jamais pensé leur problème dans le détail qu’exige un logiciel. D’où son conseil : prévoir de nombreux allers-retours entre le client et celui qui conçoit le logiciel.
En 2001, dix-sept praticiens du logiciel signent le Manifeste agile. Il demande aux utilisateurs et aux développeurs de « travailler ensemble quotidiennement tout au long du projet ». Et il fait d’« un logiciel opérationnel » la « principale mesure d’avancement ».
Une IA qui écrit du code allège, elle aussi, la traduction. Elle ne décide pas à votre place de ce que votre logiciel doit faire. Allen Holub, auteur de livres sur la conception de logiciels, que nous citons dans notre article sur la création d’une application avec l’IA, tire la même conclusion dans une publication : tant qu’une IA ne saura pas mener une conversation avec les utilisateurs pour faire émerger leurs besoins, ce travail reste humain.
There is no such thing as "Agentic software development" or an "Agentic SDLC." There's just Agentic coding. Big difference. Coding is a small part of the overall process. […]
Le "développement logiciel agentique" ou le "cycle de vie agentique du logiciel", cela n'existe pas. Il n'y a que le codage agentique. La différence est grande. Le codage n'est qu'une petite partie de l'ensemble du processus.
Le codeur ne s’occupe ni de comprendre le besoin ni de recueillir la réaction des utilisateurs : il reçoit une description déjà faite. Le développeur s’en charge en partie, puisqu’il conçoit la solution. L’ingénieur logiciel les prend toutes en charge, parce qu’il travaille par l’expérience : chaque fonctionnalité est une hypothèse, que l’usage confirme ou corrige. Dans sa vidéo, Dave Farley le rappelle : comprendre un problème assez bien pour en écrire des instructions détaillées reste un travail difficile.
Nous respectons cette distinction. Ce qui compte pour nous, au final, c’est l’ingénierie logicielle. La personne qui traite les problèmes d’ingénierie, et pas seulement de codage, sera, selon nous, la dernière à être remplacée, si cela arrive un jour.
Ce qu’il aurait fallu faire dès les premiers projets n’a rien de nouveau : travailler chaque jour avec les utilisateurs, mettre souvent en service un logiciel qui fonctionne, et vérifier chaque modification avant qu’elle ne les atteigne.
La question utile n’est pas de savoir si une IA écrira le code de votre logiciel : elle en écrit déjà une partie. La question est de savoir qui décide de ce que le logiciel doit faire, qui vérifie qu’il le fait, et qui le fera évoluer quand votre activité changera.
Quand vous recrutez un développeur ou choisissez un prestataire, savoir écrire du code ne suffit pas. Demandez-lui comment il s’y prend pour comprendre ce que le logiciel doit faire, et comment il sait, après chaque modification, que celui-ci peut être mis en service auprès de vos utilisateurs.
Le rapport DORA 2025, publié par le programme de recherche de Google Cloud sur le développement et la mise en production des logiciels, s’appuie sur les réponses de près de 5 000 professionnels de la tech. Il décrit l’IA comme un amplificateur. Elle renforce les équipes qui ont déjà de bonnes pratiques, et aggrave les difficultés des autres. La différence se trouve autour du code : des tests automatisés qui vérifient chaque modification avant qu’elle n’atteigne vos utilisateurs, une relecture de ce que l’outil a écrit, des mises en production qui ne cassent pas ce qui marchait la veille.
Ceux qui travaillent ainsi n’ont pas attendu l’IA. Elle rend seulement visibles, pour tous, des difficultés qu’ils signalent depuis longtemps.
Chez DEVEDANOS, l’IA fait partie de nos outils, et ce sont ces pratiques d’ingénierie qui l’encadrent. Nous échangeons avec les utilisateurs de votre application pour comprendre leurs besoins et définir les fonctionnalités. Des agents IA de développement écrivent ensuite une grande partie du code de votre logiciel. Chaque modification qu’ils proposent est vérifiée par des tests automatisés et relue avant d’être mise en production. Pour piloter ces agents, nous utilisons notre propre extension pour Claude Code, l’outil de développement d’Anthropic, baptisée agentic-cd, ainsi que nWave, une extension publique pour le même outil. Notre approche reste celle d’une équipe d’ingénierie : décider avec vous de ce qui mérite d’être construit, et vérifier chaque modification.
Pour le développement d’un logiciel sur mesure, nous travaillons pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer. Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez. Une application vivante n’est jamais finie : si l’on cesse de la faire évoluer, elle ne reçoit plus que des correctifs de sécurité et des mises à jour des composants sur lesquels elle repose, et c’est une application qui se meurt.
Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression. Si une régression est introduite, nous corrigeons sans surcoût et nous ajoutons un test automatisé qui vérifie le comportement attendu à chaque modification future : la régression ne peut pas revenir par la même porte.
Un agent IA peut-il construire l’application à lui seul ? Notre article sur la création d’une application avec l’IA compare les différents outils, et fait la part entre ce qu’ils font seuls et ce qui demande un professionnel. Vous préparez le budget de cette application ? Notre article sur le budget d’une application explique pourquoi viser un objectif plutôt qu’une liste de fonctionnalités.
Pour confier à l’IA des tâches répétitives de votre entreprise, notre page automatisation IA pour PME décrit ce que nous pouvons mettre en place.
Vous hésitez à lancer votre logiciel en attendant de voir ce que fera l’IA ? On en parle ?
Avoir sa propre IA : ce qu'on vend sous ce nom aux PME, qui peut vraiment entraîner un modèle, ce que votre entreprise possède à la fin, et comment le vérifier.
Oui, l'IA sait créer une application qui fonctionne. Ce que l'outil fait bien seul, où il s'arrête, et quand faire appel à un professionnel.
Fin des SaaS, SaaSpocalypse : depuis 2024, l'annonce revient sans cesse. Ce qu'elle révèle sur ce que vous payez vraiment avec un logiciel, et ce que l'on sait depuis plus de quarante ans.