URL:     https://linuxfr.org/users/dedesite/journaux/c-est-historique-le-developpement-logiciel-est-entierement-automatisable
Title:   C'est historique, le développement logiciel est entièrement automatisable
Authors: Andréas Livet
Date:    2026-10-14T18:18:41+02:00
License: CC By-SA
Tags:    adobe, vibe, coding, grand, remplacement et libre
Score:   -9


Depuis le début de la semaine je suis sous le choc suite à [ce tweet](https://x.com/echelon/status/2106387247234752762?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E2106387247234752762%7Ctwgr%5E%7Ctwcon%5Es1_c10&ref_url=) de Brandon Thomas qui date du 03 octobre 2026 : 

> I've vibe coded replacements to 7 of Adobe's apps in Rust. They're open source (links below)

On peut retrouver toutes ces applications (il y en a maintenant 13) [sur le site d'ArtCraft](https://getartcraft.com/apps).

J'aimerai développer en quoi je trouve cet instant historique pour tout le secteur du développement logiciel qu'il soit propriétaire ou libre.

## Ces applications ne sont pas "mal codées"

_Note_ : Je base mon analyse sur PhotoCraft, le clone de Photoshop, mais à ce que j'ai vu tous les projets suivent peu ou prou la même architecture.

A priori on pourrait se dire : "bah c'est encore un énième gars qui a vibe codé un truc tout pourri comme tout ce qui est vibe codé", mais je crois qu'on est en train de voir la naissance d'une toute nouvelle manière de faire des logiciels : une manière entièrement automatisée.

A regarder [tous ces dépôts](https://github.com/storytold/) d'un peu plus près, les projets ont l'air cohérents, bien organisés, bien écrit (je n'ai pas trop d'expérience en Rust mais au moins ça n'a pas l'air d'être d'un code totalement immaintenable) et, au moins en parti, testé.

Il y a tout un set de [librairies sous-jascentes](https://github.com/storytold/craft-libs) qui sont partagées entre les applications.

Les applications ont l'air bien [architecturées](https://github.com/storytold/photocraft/blob/main/docs/architecture.md) avec notamment une séparation très clair entre le coeur des fonctionnalités et l'interface utilisateur, ce qui est une très bonne pratique.

L'[historique des commits](https://github.com/storytold/photocraft/commits/main/) est propre, on ne voit pas des commits genre "dev 1", "fix truc" etc. et ça ne donne pas l'impression que les nouvelles fonctionnalités rajoutent du chaos comme on pourrait se l'imaginer sur un projet de cette taille développé aussi rapidement.

Les fonctions sont bien nommées, pas trop grosses, pas plein de commentaires inutiles (comme on voit souvent avec le code fait par LLM), bien découpées en fichiers eux mêmes pas trop gros, mis dans [des dossiers qui font sens](https://github.com/storytold/photocraft/tree/main/crates).

Bref, je ne suis pas expert Rust, je n'ai pas passé des heures à scruter les différents dépôts, mais ce que je peux dire c'est que ça ne _sent_ pas le truc coder à l'arrache juste pour que "ça marche".

Voilà pour la première objection que l'on pourrait faire à ces projets

## Ces applications ne sont pas issue d'un travail de décompilation

Beaucoup de personnes pensent que cette suite d'application est le fruit d'une décompilation des produits Adobe (et maintenant [Microsoft](https://getartcraft.com/apps/wordcraft), [AutoDesk](https://getartcraft.com/apps/cadcraft) et [Figma](https://getartcraft.com/apps/figcraft)) et d'une simple _retranscription_ en Rust.

Il est très clair que ce n'est pas du tout le cas : les choix architecturaux et de librairies sont sans aucun doute extrêmement différents de comment ont été codés ces différents logiciels. De plus, comme je l'ai dit ils partagent tous le même socle là où une décompilation/transcription porterai sa propre architecture et ses propres librairies pour chaque projet.

Autre "indice" si je puis dire, le fichier [AGENTS.md](https://github.com/storytold/photocraft/blob/main/AGENTS.md) (sans doute la pièce maîtresse de ce projet vu que tout a été fait par un agent de codage) précise bien que les fonctionnalités codées [ne doivent pas être issues d'un processus de décompilation](https://github.com/storytold/photocraft/blob/706638b2842a330cfc5c305c7860d0b7c9921960/AGENTS.md#never-crash-outranks-feature-work) (Point "3. Clean Room").

Donc il est très peu probable que ce projet soit juste une sorte de clone illégale de la suite Adobe et autres.

## Ces applications ne sont pas non plus des copies des logiciels libres existants

J'ai lu a plusieurs endroits que vu qu'il existait beaucoup de logiciels libres comparables à ces logiciels (Gimp, Krita, LibreOffice, Inkscape etc.), il était facile pour une IA de les refaire en se basant sur ce qu'elle a appris.

Mais, je crois que ce raisonnement est tout aussi erroné. Il s'agit réellement d'une nouvelle contribution. Alors, bien sûr certains algorithmes doivent être repris (peut-être entièrement) d'implémentation existantes, mais qui ferait autrement ? 
Honnêtement, vous devez recoder une librairie qui fait du dessin vectoriel, vous allez réinventer les algos efficaces et autre ?

Bon, en fait vous allez sûrement utiliser une librairie optimisée qui le fait déjà, car c'est la chose la plus naturelle à faire.

Mais par exemple Google ont bien recoder leur [propre librairie de rendu 2D](https://) pour faire flutter, Chrome, etc.

Ici, j'ai l'impression (je n'ai pas encore vérifié) que beaucoup de choses assez bas niveau sont recodées : codecs, rasterisation etc.

C'est visiblement une volonté des auteurs qui précisent par exemple que [FFmpeg n'est pas utilisé](https://github.com/storytold/filmcraft#formats-and-codecs) pour leur logiciel d'édition vidéo et que leur implémentation se base uniquement sur les spécifications publiques (et bien sûr les données d'entraînement des LLM...).

Il faudrait comparer sérieusement les implémentations de FFMpeg et celles de FilmCraft pour trancher, mais quand bien même les grands principes de ces libriairies seraient repris, l'agencement de tous les composants est inédit. Rien que le fait que ces logiciels libres sont souvent écrit en C ou C++ avec des librairies différent fait que le résultat est très différent.

Donc, même s'il y a forcément énormément d'inspiration venant des autres logiciels libres, la suite Artcraft n'en est pas une pâle copie, mais bien quelque chose de nouveau et _original_ au moins dans le langage et les librairies sous-jascentes utilisées.

## Ces applications sont fonctionnelles

C'est la plus grosse critique qu'on peut faire à ces applications : ça à l'air de marcher, mais en fait c'est du flan, une sorte de chateau de carte qui s'effondre dès que l'on touche quelque chose.

Et bien, peut-être qu'aujourd'hui elles sont encore un peu bugguées, peut-être que certaines fonctionnalités ne fonctionnent pas comme elles devraient, mais je suis prêt à parier que d'ici quelques semaines, tout le monde sera d'accord pour dire que ces applications fonctionnent très bien et sont sans doute meilleures que leur alternatives libres ou propriétaires.

Je n'ai jamais utilisé la suite Adobe, j'ai vu quelques tests et discuté avec des pros qui ont testé et qui sont déjà très étonné du résultat, même si bien sûr ils constatent quelques fonctionnalités manquantes, quelques bugs etc.

Des milliers de personnes sont déjà en train de s'emparer de ces outils et réalisent des choses avec. Si c'était juste une sorte de _façade_ ou de coquille vide, ça se verrait tout de suite.

## Ces applications sont libres et multiplateformes

Un point important est le côté multi plateforme de cette suite : dès le premier jour il y avait des builds Windows, Mac, Linux, FreeBSD mais aussi Web (via WebAssembly) et des ports vers Android et iOs sont en cours. Bref, du rarement vu pour des logiciels propriétaires et pas toujours le cas pour des logiciels libres (je crois me souvenir que le port Windows de Gimp a pas toujours été à la hauteur faute de mainteneur, un exemple parmi d'autres).

Tous les ingrédients sont là pour une adoption massive.

## Ces applications sont codées en Rust

On voit tellement souvent pointer ce nom de langage récemment que beaucoup voit cela uniquement comme un argument marketing (coder en Rust = bien).

Mais, il y a tout de même une réalité : les programmes écrit en Rust sont excempt d'une bonne partie des problèmes de mémoire des programmes écrit en C/C++.

De plus, et c'est un élément important : ils bénéficient aussi d'un éco système moderne et riche de plein de librairies efficientes en terme de mémoire et de ressources CPU/GPU.

L'aspect _moderne_ n'est pas juste pour dire "c'est récent donc c'est mieux", c'est plutôt lié au fait que ces librairies tirent profit de la parralélisation et de la généralisation des GPU sur nos machines du quotidien.

Aussi, en ce qui concerne les interfaces utilisateurs, les librairies sont encore jeunes mais sont parties sur des bases neuves en terme de conception.

Qt est très complet et a su évoluer mais est tout de même basé sur du C++ maison (ça a peut-être changé), GTK est un librairie C avec tout ce que ça implique en terme de conception etc. Pas forcément bien adapté à Rust et surtout c'est une couche qui ne bénéficie pas de la protection mémoire de Rust.

La suite ArtCraft [utilise](https://github.com/storytold/photocraft/blob/main/Cargo.toml#L56) la librairie [egui](https://www.egui.rs/) qui offre une accélération matérielle et un côté multiplateforme avec un rendu identique de partout (à ce que j'ai compris). Ce n'est peut-être pas la librairie la plus complète, mais vu ce que les logiciels ArtCraft font en terme d'interface utilisateur, ça ne les a pas trop arrêté.
Ils [ont une librairie](https://github.com/storytold/photocraft/blob/main/Cargo.toml#L13C5-L13C9) codée par dessus egui qui s'appelle [craft-ui](https://github.com/storytold/craft-libs/blob/main/crates/ui/README.md) et qui fait partie des [librairies partagées](https://github.com/storytold/craft-libs) entre les applications. C'est un ensemble de composants réutilisables à ce que j'ai compris.

## Ces applications sont codées de manière (quasi) automatisée

Maintenant que l'on sait tout ça, l'aspect le plus _choquant_ dans cette histoire est que toute cette activité de génie logiciel, de construction de briques fondamentales, puis d'applications extrêmement variées et complexes, s'est faite en quelques semaines ! Oui pas quelques mois, pas quelques années, quelques semaines (pour certains logiciels [visiblement 2 semaines](https://github.com/storytold/soundcraft/graphs/code-frequency)) !

Et beaucoup des commits sont crédités de echelon (Brandon Thomas, le gars qui a eu l'idée au départ), cela nous indique quoi ?

Il a forcément automatisé la quasi totalité de son flux de travail.
Et je ne parle pas d'avoir automatisé la boucle de analyse=>code=>review=>commit, non ça c'est _so septembre 2026_, non je veux dire qu'il a tout automatisé ! Le découpage en étape, l'analyse de l'existant (comment fonctionne l'interface, mais aussi comment font les autres), les mesures de performance, les tests de non regression, la gestion des PR (quand on fait une demande de fusion de branche dans GitHub), les réorganisations de code nécessaire (refacto) etc.

Je suis persuadé que ce qu'il a fait, un non informaticien aurait quasiment pu le faire. Au sens où, il y a évidemment tellement peu de travail humain face à la quantité astronomique (on parle de plusieurs centaines de milliers de lignes de code pondu en même pas un mois) de code qu'il est évident que l'IA utilisée à jouer le rôle principale dans toute cette affaire.

Attention, je ne veux pas dire que Brandon Thomas n'est pas doué ou qu'il n'a pas fournit des efforts pour en arriver là, juste qu'il y a une telle disproportion entre les efforts fournit et le résultat qu'il est inconevable qu'un humain soit derrières chaque décision architecturales prisent. Puis il est de toute manière inconcevable que quelqu'un puisse s'y connaître dans l'ensemble des domaines traités par ces logiciels (bon peut-être un de mes anciens collègues - bien le bonjour Daniel au passage - mais c'est une autre histoire).

Donc au mieux, il a donner les grandes lignes (les contraintes si on veut) : codé en Rust, multi plateforme, pas de décompilation, fidélité avec l'interface originale etc. et il a laissé l'IA s'auto organiser.
J'exagère à peine...

## Nous sommes comme les mathématiciens

Aujourd'hui, je me sens comme les mathématiciens qui voient déferler une montagne de papiers prouvant des théorèmes ou trouvant des solutions a des problèmes vieux de plusieurs siècles pour certains.

A quoi sert mon expérience, ma _petite_ maîtrise technique si une IA, même pas forcément dirigée peut produire 100 à 1000 fois plus rapidement que moi des logiciels qui seront d'une plus grande qualité ?

## Comment cela est-ce possible ?

J'ai beau utiliser intensivement des LLM et des outils agentiques depuis des mois, je ne voyais toujours pas comment une telle productivité puisse être possible.

Les modèles que j'ai testé sont bons, rapides, mais pas bon à ce point et pas rapides à ce point.

Or, il semblerait qu'il y a eu une sorte de "saut quantique" avec les très récentes versions de Claude et de ChatGPT. Précisément Opus 5.5 ou Fable et GPT Astra.

J'ai arrêté d'utiliser les IA américaines depuis quelques semaines alors je n'avais pas vu ce changement. J'avais bien vu ces vidéos qui vous disent que "tout à basculer", que cette dernière IA est un truc de ouf etc. mais comme ça fait 3 ans qu'on nous dit ça toutes les semaines, je n'y avais pas prêter plus attention que ça.

Sauf, que là je crois qu'on a atteind un point particulier : le point où le métier d'analyse/développeur ou d'ingénieur en développement est _entièrement_ automatisable.

Et on voit que c'est visiblement reproductible, car plein d'autres personnes contribuent, très probablement toutes avec une IA (comment suivre humainement le développement de ces logiciels qui n'existaient pas il y a 2 semaines ?), de manière effrénée.

Les commits s’enchainent à la vitesse de l'éclaire sur tous les logiciels de la suite.

Chaque jour, c'est l'équivalent de mois de travail qui sont commits, vraiment je n'en reviens pas.

J'aimerai me tromper et me rassurer en me disant que ça va se casser la gueule, que c'est un effet de mode, mais que bientôt nous verrons la triste réalité qui est que ces logiciels sont inmaintenables, qu'ils ne font rien comme il faut et qu'il faut tout jeter à la poubelle. Mais, je crois que ça n'arrivera pas.

## La naissance d'une nouvelle forme de logiciel libre

Comme je le disais dans [mon commentaire](https://linuxfr.org/users/pazelty/journaux/vers-la-fin-du-logiciel-proprietaire#comment-2035961) sur l'article parlant de la fin du logiciel propriétaire.

Je crois qu'on est à l'aube d'une nouvelle façon de faire du logiciel libre. Une façon entièrement pilotée par des IA qui va accélérer le développement de solutions d'un facteur 100 ou 1000.

Encore une fois, je fais le pari que si ça continue comme ça (c'est à dire si les IA d'Antropic et d'OpenAI restent relativement abordables pendant quelques mois), on va voir arriver des OS entièrement fait de zéro. Je ne serai pas étonné de voir un vrai clone de MacOS par exemple, mais libre et non verrouillé.

Peut-être même que cet OS pourra être compatible avec les drivers Linux et Android et pourra être porté sur n'importe quelle machine. Cela, au prix de quelques euros et de quelques heures/jours d'interaction avec ces LLMS.

Si vous ne pensez pas que c'est possible, regardez les [dernières](https://www.phoronix.com/news/Linus-Torvalds-Claude-Code) [expérimentations](https://www.phoronix.com/news/Linus-Torvalds-Assoc-Array) de Linus Torvalds au sujet du dev assisté par IA sur le noyau Linux. 

Vous allez me dire : "mais c'est parce qu'il a la maitrise, il comprend ce qu'il fait et l'IA ne fait que l'aider". Non, en fait, j'aurai dit la même chose il y a 2 mois peut-être. Mais, là je crois que n'importe qui qui aurait dit à l'IA : "Analyse moi ce patch, optimise le ou trouve des bugs" aurait eu les mêmes résultats.

En gros, ces outils se suffisent à eux-mêmes.

On peut maintenant créer une sorte de boucle, sans humain au milieu, qui dirait en essence : "refait moi Linux mais en mieux et en Rust et je veux que les drivers Linux soient compatibles".

L'humain n'aurait qu'à gérer peut-être qu'une étape dans la boucle : merger le code et relancer une nouvelle itération, peut-être répondre à quelques questions si des choix sont à faire, mais on pourrait entièrement automatiser le truc.

En fait, la taille du contexte gérer par ces LLM est maintenant assez grande pour avoir la vision sur toute une base de code énorme.

Les outils (harnais) tels que Claude Code, Opex, DSH et compagnie sont assez matures pour optimiser l'usage de ces LLMs, les orchestrer, limiter le contexte etc. ce qui les rend beaucoup plus performants et autonomes.

Et si vous pensez qu'un LLM ne peut pas pondre du code _nouveau_ au sens original, qu'il ne fait que recracher ce qu'il a vu, c'est que vous n'avez pas suivi ce qu'il se passe dans le domaine.
Une IA du niveau d'Astra ou de Fable est parfaitement capable de lire les spécifications d'un codec et de produire un code qui sera potentiellement plus optimisé que le code écrit par un humain au prix de journées passées à optimiser telle ou telle partie.

Alors peut-être qu'on a pas encore des IA complètement "génies" comme Fabrice Bellard qui fait toute sortes de prouesses sur des programmes extrêmement rapides, petits et performants ? Peut-être que certaines idées vraiment novatrices n’émergeraient pas d'un LLM ? Par exemple, est-ce qu'une IA aurait pu inventer l'[opérateur pipe d'unix](https://en.wikipedia.org/wiki/Pipeline_(Unix)#History) ? Ou l'idée bien commode que "[tout est fichier](https://en.wikipedia.org/wiki/Everything_is_a_file)" ?

On ne peut plus rien affirmer, l'histoire récente nous a montrer que ces IA étaient capable d'énormément de choses que l'on ne soupconnait pas.

## La fin du code propriétaire et la fin du logiciel libre tel que nous le connaissons ?

Comme [le remarque](https://linuxfr.org/users/pazelty/journaux/vers-la-fin-du-logiciel-proprietaire#comment-2035997) très judicieusement NicolasP, si ArtCraft marque la fin du logiciel propriétaire et que l'IA aussi sonne le glas du logiciel libre car il n'y aura plus personne pour le financer et que l'IA détruit aussi les communautés autour de ces logiciels. Que reste-t-il ?

Il va rester ces nouveaux types de logiciels. Des sortes de "monstres" qu'on fera évoluer à coup d'abonnement ou de frais d'API.
La nouvelle façon de contribuer à ces nouveaux logiciels sera de payer du temps de computation pour créer ce nouveau type de commun (oui car cela reste du commun selon moi). Ou alors remplir un rapport de bug ou une demande de fonctionnalité qui sera par la suite analysée et implémentée ou refusée par une IA.

Ces outils seront très certainement plus performants, plus portable et plus sécurisés que leurs équivalent libres ou propriétaires.

Ils vont rapidement s'imposer chez les particuliers, peut-être un peu plus tarder chez les entreprises. Tout dépend du nombre de failles et d'attaques  que le secteur privé va subir _faute_ de ne pas utiliser des systèmes robustes créé entièrement par IA.

Je ne crois pas que ce que je viens d'écrire est de la science fiction, ce que je dis n'est pas basé sur une évolution probable de ces systèmes, mais sur le constat de leur fonctionnement et capacités actuelles.

Vous avez le droit de ne pas souhaiter un tel futur et peut-être qu'il n'arrivera pas, mais ça ne sera pas à cause d'une limitation des IA. Le risque que cela n'arrive pas est selon moi extérieur à la technique elle même, il est plutôt économique et géo politique.

On le sait tous, l'IA est une bulle économique qui risque d'éclater à tout moment, si cela arrive, déjà l'économie réelle va en subir de grave conséquence et ensuite l'accès à ces LLM va sans doute devenir bien plus cher. Ce qui limiterait leur usages à de rare privilégiés. Et donc construire de tels édifices pourrait simplement devenir trop couteux.

## La fin d'un métier

J'ai l'impression d'assister, impuissant, à la fin de mon métier.
Ok, on aura toujours besoin de personnes qui sont plus versées dans la technique et qui veulent "mettre les mains dans le cambouis". Mais en gros, n'importe qu'elle personne qui aime bidouiller pourra coder (ou plutôt assister la production de code) en très peu de temps des logiciels d'une très grande complexité et d'une grande qualité aussi.

Peut-être que si on regardera les détails, certaines choses ne seront pas "bien" pensées au sens ou un humain n'aurait pas passer autant d'énergie à tester telle fonctionnalité ou que telle donnée n'était pas utile à stocker, ou encore que la technologie utilisée était peut-être pas la plus adaptée (si c'est une personne qui n'y connait rien qui à fait le demande c'est un cas probable). Mais bon qu'est ce que ça changera ?
Combien de projets libre ou propriétaire sont des exemples de clarté, de bons choix architecturaux, de bons choix techniques ? La plupart des logiciels que je connaisse et sur lesquels j'ai travaillé souffraient tous d'une dette technique plus ou moins importante.
Quand tu transmets à un nouveau collègue les connaissances sur une base de code c'est extrêmement fréquent de dire des choses comme : "bon là on a fait comme ça car on avait pas le temps" ou encore "on a commencer le projet avec cette architecture/dépendance/librairie/langage mais c'était une erreur mais c'est trop couteux de l'enlever".

Les projets entièrement pilotés par IA ne seront pas exempts de ces problématiques de conception initiale, juste il sera tellement plus aisé de tout refaire, d'enlever une librairie, de changer de langage que la notion même de dette technique ne sera plus pertinente.

Prenons l'exemple de PhotoCraft, le clone de PhotoShop. Il suffira de lancer de manière hebdomadaire une IA qui analysera l'ensemble du code et proposera des modifications structurelles (refacto) du code pour l'améliorer et éviter la dette technique. Et c'est ce qu'ils font déjà...

## Conclusion

Je ne sais vraiment pas quoi en penser. Je suis abassourdi par la vitesse à laquelle vont les choses. L'année dernière je me disais : "l'ia c'est pas mal, ça aide beaucoup mais bon y a encore besoin de relire ce qu'elle produit, elle comprend rien parfois etc.", il y a quelques mois j'ai commencé à utiliser les outils agentiques et j'ai arrêté de coder manuellement, mais j'ai passé énormément d'énergie à tenter de maîtriser ces systèmes, rester en maîtrise malgré la vitesse, faire des revues de code, mettre en place des flux de travail vérifiables etc. Je sentais que mon expertise améliorait de manière significative la qualité de ce que produit l'IA.
Aujourd'hui, cette expertise est entièrement intégrée à ces outils et dans les données d'entraînement de LLM qui se comportent maintenant "comme il faudrait".
La boucle est bouclée et je n'ai plus besoin d'en faire partie.

Ça c'est pour ma petite personne. Concernant l'avenir du développement logiciel et du logiciel libre, je crois qu'on est pas prêt et qu'il va se passer des choses que l'on pensait impossibles ou inateignables il y a seulement quelques années et d'une certaine manière c'est enthousiasmant.