Tout le monde peut-il créer ses propres logiciels avec l’IA ?

Depuis l’émergence des IA, je cherche comment améliorer mes protocoles de travail (les suites d’étapes que je suis pour mener chaque tâche) et la réalisation de mes tâches au quotidien. Cette recherche est passée par la création d’outils, qui automatisent ces protocoles pour faire plus, faire mieux et en moins de temps. À mesure qu’ils s’étendent, une question me revient : n’importe qui pourrait-il en faire autant ?

Ma réponse est non. L’IA a fait s’effondrer le prix d’écrire un logiciel. La barrière n’a pas disparu pour autant : elle tient désormais à la structure qu’il faut penser et au temps qu’il faut avoir devant soi pour aller au bout. Les obstacles sont moins visibles, mais ils sont toujours là.

L’IA a beaucoup moins changé ce qui a toujours été le plus dur. Elle aide à l’exécution, mais décider quoi construire, fixer ce qui compte comme juste et le faire durer restent l’affaire de l’humain. Savoir où se trouve désormais la barrière, c’est pouvoir juger, avant de se lancer, si l’on est prêt à la franchir.

Écrire du code ne coûte presque plus rien

Dans un billet publié début février 2026, Nicholas Carlini, chercheur chez Anthropic (l’entreprise qui développe l’IA Claude), raconte avoir confié à une équipe d’agents d’IA, des IA à qui l’on donne une tâche et qui enchaînent seules les étapes, l’écriture d’un compilateur pour le langage de programmation C. Un compilateur est le programme qui traduit le code écrit par un humain en instructions que la machine exécute. Celui-ci compte cent mille lignes et sait compiler Linux, un système d’exploitation (le logiciel de base qui fait fonctionner un ordinateur). Il a fallu deux semaines et un peu moins de 20 000 dollars de calcul.

Moins de trois semaines plus tard, dans un récit publié sur le blog de Cloudflare, une entreprise de services pour les sites web, Steve Faulkner, qui dirige une équipe d’ingénieurs, raconte avoir reconstruit avec l’IA l’équivalent de Next.js, à ses yeux le plus populaire des outils qui servent à bâtir l’interface des sites web. Une seule personne, moins d’une semaine, environ 1 100 dollars. « Un projet comme celui-ci demanderait normalement des mois, voire des années, à une équipe d’ingénieurs », écrit-il (je traduis, comme pour les citations qui suivent).

Le grand public a même un mot pour la forme la plus extrême de cette façon de faire. En février 2025, dans un message publié sur X que cite la page que Martin Fowler consacre à cette pratique sur son site dédié au génie logiciel (la discipline qui étudie la manière de construire des logiciels), Andrej Karpathy, membre fondateur d’OpenAI (l’entreprise de ChatGPT) puis directeur de l’intelligence artificielle chez Tesla, a parlé de vibe coding : on décrit ce qu’on veut, on accepte tout ce que la machine propose et l’on finit par « oublier que le code existe ». Fowler le distingue de ce qu’il appelle l’ingénierie agentique : l’IA écrit le code, mais le programmeur s’en soucie, le relit et veille à sa structure. Carlini et Faulkner, qui vérifient de près ce que produit la machine, relèvent à mes yeux de la seconde.

Le cas de Cloudflare va plus loin : l’IA y sait réécrire un logiciel existant à partir de sa documentation et des programmes qui en vérifient le comportement, sans en copier le code. Si la barrière tenait d’abord à l’argent, ou au temps passé à écrire des lignes de code, elle serait donc en grande partie tombée. Ce serait une mauvaise nouvelle pour beaucoup d’éditeurs de logiciels, mais une excellente pour tous ceux qui rêvent d’un outil taillé pour eux. Ces deux exploits racontent pourtant autre chose, à condition de les lire jusqu’au bout.

Ce que ces exploits ne racontent pas

Ni le compilateur ni le nouveau Next.js ne se sont écrits tout seuls. Carlini le dit lui-même : « L’essentiel de mon effort est allé à concevoir l’environnement autour de Claude : les tests, l’environnement, les retours, pour qu’il puisse s’orienter sans moi. » Un test, c’est un petit programme qui vérifie qu’un autre fait bien ce qu’on attend de lui.

Carlini a rassemblé des batteries de tests de qualité et en a écrit de nouvelles à mesure qu’il repérait les erreurs de la machine. Pour compiler Linux, il s’est servi d’un compilateur de référence afin de repérer les fichiers que le sien compilait mal. Quand le projet a grossi, chaque nouvelle fonction cassait souvent quelque chose qui marchait la veille. Il a alors mis en place une vérification automatique, relancée à chaque modification.

Chez Cloudflare, même constat, avec des mots plus directs. L’IA proposait parfois, avec assurance, des modifications qui semblaient justes et ne l’étaient pas. « Les décisions d’architecture, les priorités, savoir quand l’IA partait dans une impasse : tout cela, c’était moi », écrit Faulkner, l’architecture désignant ici la manière dont les pièces d’un logiciel s’organisent et dépendent les unes des autres. Et plus loin : « l’humain doit encore tenir la barre ».

Il ajoute que tous les projets ne se dérouleraient pas ainsi. Il nomme les conditions qui ont tout rendu possible :

• une cible dont le comportement était déjà décrit en détail ;
• une batterie de tests complète, reprise en partie du projet d’origine ;
• un outil solide pour assembler le projet ;
• un modèle d’IA capable de tenir la complexité.

« Retirez-en une seule et cela marche beaucoup moins bien. » Autrement dit, à mes yeux, il a refait quelque chose dont la forme exacte était connue d’avance, avec une bonne part des vérifications d’un autre. C’est loin du cas où l’on part d’une idée encore floue.

Enfin, à leur publication, aucun des deux n’était terminé. Le compilateur n’était « pas encore un remplaçant direct » d’un vrai compilateur ; même avec toutes ses optimisations, il produisait un code moins efficace que celui de l’outil de référence privé des siennes. Son propre code, selon Carlini, était d’une qualité « raisonnable », mais « loin de ce qu’écrirait un expert » du langage Rust qu’il employait. Le nouveau Next.js est présenté comme expérimental, sans avoir encore été éprouvé par un trafic important, même si quelques clients l’utilisaient déjà.

Ces réalisations ne montrent pas que n’importe qui peut construire un logiciel. Elles montrent que des experts, munis des bons garde-fous, vont désormais beaucoup plus vite.

La partie difficile n’a jamais été d’écrire

Une distinction ancienne aide à lire ce qui se passe. Elle vient de Frederick Brooks, professeur à l’université de Caroline du Nord à Chapel Hill, qui avait auparavant dirigé chez IBM le développement de System/360, une famille de grands ordinateurs. En 1986, il publie un texte resté célèbre, « No Silver Bullet », qu’on pourrait traduire par « pas de remède miracle ».

Il y distingue deux sortes de difficultés. Les difficultés accidentelles tiennent aux outils, comme traduire une idée dans un langage de programmation ou se plier aux contraintes de la machine. Les difficultés essentielles tiennent à la nature même du logiciel : concevoir la structure d’idées qui le compose, décider ce qu’il doit faire, prévoir ses cas particuliers, vérifier que tout s’emboîte.

Pour Brooks, le plus dur se trouve du second côté. « La partie la plus difficile dans la construction d’un logiciel, c’est de décider précisément quoi construire. » Il en tirait une conséquence simple. Même ramené à rien, le travail accidentel ne change pas l’ordre de grandeur de l’effort, tant que l’essentiel pèse plus d’un dixième de l’effort.

Brooks ne pensait pas à l’IA d’aujourd’hui (celle de son époque n’avait rien à voir). Mais sa distinction éclaire ce qui vient de se produire. L’IA a avalé une très grande part de l’accidentel ; l’essentiel, lui, est resté à la charge de l’humain, même quand elle y prête la main.

C’est ce que j’appelle un esprit d’architecture : la capacité de découper un problème en pièces, de décider ce qui dépend de quoi et de trancher tôt ce qui coûtera cher à défaire. Les décisions prises au départ et jamais réexaminées sont celles qui se paient le plus cher, je l’ai appris en automatisant des chaînes de travail entières. Une IA qui écrit vite propage une mauvaise décision aussi vite qu’une bonne, sans remettre d’elle-même en cause l’idée de départ.

Une première version n’est pas un outil

Admettons que la première version fonctionne. Le plus long commence. Meir Lehman, professeur d’informatique à l’Imperial College de Londres, a passé une vingtaine d’années à observer comment évoluent les grands logiciels.

Sa première loi, formulée dès les années 1970 et qu’il reprend dans « Laws of Software Evolution Revisited », dit qu’un programme qu’on utilise doit être adapté sans cesse, sinon il devient de moins en moins satisfaisant. Les besoins changent, les menaces aussi. Un outil qu’on n’entretient pas paraît se dégrader, lentement, sans prévenir, parce que le monde autour de lui change.

L’IA n’abolit pas cette loi. Je crois même qu’elle la rend plus pressante. Carlini a vu ses agents réécrire des fonctions qui existaient déjà, au point de devoir en charger un de traquer les doublons. Chaque doublon est un endroit de plus à corriger le jour où quelque chose change.

Il y a ensuite la sécurité, que l’on ne voit pas tant qu’elle tient. Dans la présentation de son rapport 2026, l’éditeur Veracode indique tester depuis quatre ans plus d’une centaine de modèles d’IA sur des tâches de programmation choisies pour leur risque. Le taux moyen de réussite aux tests de sécurité y plafonne à 56 %, sans avoir bougé.

Veracode vend des outils de sécurité et ses tâches sont choisies exprès : le chiffre ne dit pas qu’un code sur deux est dangereux. Il dit que la sécurité ne vient pas toute seule, même quand le code fonctionne.

Le cas de Lovable, un service qui fabrique des applications à partir d’une simple description, le montre sur le terrain. Dans une déclaration publiée fin mai 2025, Matt Palmer, qui travaille chez un concurrent, raconte avoir passé au crible avec un collègue, en mars, 1 645 applications construites avec cet outil. Environ une sur dix avait des réglages d’accès insuffisants pour protéger ses données. Beaucoup de leurs auteurs, selon eux, ignoraient le risque qu’ils faisaient courir à leurs utilisateurs ; ils en accusent d’abord les réglages par défaut de l’outil.

Fowler résume l’ensemble sans détour. Le vibe coding est à la portée de quelqu’un qui ne sait pas programmer, mais le logiciel qui en sort pose souvent des problèmes de maintenance, de justesse et de sécurité ; elle vaut mieux pour des programmes jetables, destinés à peu de monde. Karpathy lui-même ne disait pas autre chose, puisqu’il jugeait le procédé « pas trop mal pour des projets jetables du week-end ».

Un outil, c’est une première version qu’on entretient, qu’on protège, qu’on répare et qu’on fait évoluer pendant des années.

Ce que je vois en automatisant mes protocoles

Les mesures sérieuses dont on dispose se rejoignent sur un point. Selon l’annonce qu’en a faite Google, le rapport DORA 2025, consacré aux équipes qui développent des logiciels et tiré d’une enquête auprès de près de 5 000 professionnels, tient en une phrase : « l’IA ne répare pas une équipe, elle amplifie ce qui s’y trouve déjà ». Son adoption va de pair avec davantage de nouvelles versions livrées et, selon l’analyse du cabinet RedMonk, un code de meilleure qualité, mais aussi, en moyenne, avec moins de stabilité. Sans tests solides ni retours rapides, ce surcroît de changements tourne à l’instabilité.

Dans la mise à jour de son étude, en février 2026, METR, qui mesure depuis 2025 l’effet de ces outils sur des développeurs chevronnés, estimait qu’ils sont probablement plus rapides qu’un an plus tôt, tout en reconnaissant que ses données ne suffisent plus à dire de combien. L’IA semble donc accélérer ceux qui savent déjà ; ce qu’elle fait pour les autres, je n’en ai trouvé aucune mesure sérieuse.

C’est aussi ce que je constate. Les outils qui automatisent mes protocoles comptent aujourd’hui plus d’un millier de fichiers de tests. L’IA les écrit avec moi ; ce qu’elle ne fait pas seule, c’est décider ce qu’il faut vérifier.

Ce qui me prend le plus de temps, c’est de décider ce que chaque pièce doit faire, de vérifier qu’elle le fait et de revenir sur des choix de départ qui ne tiennent plus. L’IA écrit ; moi, je décide et je corrige le cap.

Alors, tout le monde peut-il créer ses propres logiciels avec l’IA ? Non. Mais beaucoup plus de monde qu’hier.

Selon l’exploration qu’en ont tirée ses organisateurs, lors d’un marathon de programmation de neuf heures dans une université publique du Brésil, des étudiants, dont certains n’étaient pas informaticiens, ont livré des démonstrations qui fonctionnent, avec un code inégal qu’il fallait reprendre. Ce qu’on exigeait autrefois, connaître un langage et ses pièges, l’IA le prend en charge.

Ce qu’elle laisse, c’est un métier d’architecte et de gardien : dire précisément ce qu’on veut, découper, vérifier, accepter d’entretenir. Ce métier-là s’apprend, mais pas en un week-end. Il demande du temps devant soi pour aller au bout, ainsi qu’une constance que la facilité apparente des démonstrations fait oublier. Les moyens comptent encore, sans être le premier obstacle : 20 000 dollars de calcul, c’est, selon Carlini, une fraction de ce que le projet lui aurait coûté à lui seul, mais ce n’est pas rien pour un particulier.

Devant chaque protocole que j’envisage d’automatiser, je ne me demande plus si je saurai le coder. Je me demande si je sais dire exactement ce que j’en attends, si j’accepterai de vérifier ce que la machine me livre même quand tout a l’air de marcher et si je serai encore là, dans un an, pour le réparer.

Il y a quelque chose de rassurant dans cette barrière-là : elle ne s’achète pas, elle se travaille. Si écrire ne coûte presque plus rien, quel outil seriez-vous prêt à penser, puis à entretenir pendant des années ?

Sources de cet article 11 références

1. Nicholas Carlini, « Building a C compiler with a team of parallel Claudes », Anthropic, 5 février 2026.
2. Steve Faulkner, « How we rebuilt Next.js with AI in one week », blog de Cloudflare, 24 février 2026.
3. Martin Fowler, « Vibe Coding », martinfowler.com, 21 mai 2026 (cite le message d’Andrej Karpathy publié sur X en février 2025).
4. Frederick P. Brooks, « No Silver Bullet: Essence and Accident in Software Engineering », actes de la dixième conférence mondiale de l’IFIP, 1986 ; repris dans The Mythical Man-Month, édition anniversaire, 1995.
5. M. M. Lehman (Imperial College, Londres), « Laws of Software Evolution Revisited », 1996.
6. Veracode, « 2026 GenAI Code Security Report: 100+ Models Tested », page de présentation du rapport, 2026.
7. Matt Palmer, « Statement on CVE-2025-48757 », 29 mai 2025.
8. Rachel Stephens, « DORA 2025: Measuring Software Delivery After AI », RedMonk, 18 décembre 2025.
9. Nathen Harvey et Derek DeBellis, « Announcing the 2025 DORA Report: State of AI-Assisted Software Development », Google Cloud, 23 septembre 2025.
10. Joel Becker, Nate Rush, Tom Cunningham, David Rein et Khalid Mahamud, « We are Changing our Developer Productivity Experiment Design », METR, 24 février 2026.
11. Kiev Gama et cinq coauteurs, « “Can you feel the vibes?”: An exploration of novice programmer engagement with vibe coding », arXiv, 2 décembre 2025.