En octobre, un dépôt de code appelé REA, pour Reverse Engineer Anything, a fait le tour d’Internet. Sur GitHub, le site où les développeurs publient leur code, il est passé de moins de 10 000 étoiles (la marque d’intérêt que les membres inscrits donnent à un projet) le 7 octobre à plus de 378 000 le 24 octobre 2026. La promesse qui circule avec lui est simple : grâce à un assistant d’IA, on pourrait désormais recréer n’importe quelle application. J’ai voulu savoir ce qu’il y avait de vrai là-dedans et ma conclusion tient en une phrase : l’IA ne clone pas n’importe quoi, elle refait ce qu’elle peut observer.
Ce qui disparaît, ce n’est pas le logiciel que l’on installe chez soi, c’est la protection que son code lui offrait. Cela déplace la question, pour un éditeur comme pour chacun de nous. Il ne s’agit plus de savoir si l’on peut copier un logiciel, mais de savoir ce qui, dans un logiciel, ne se copie pas.
Un plat dont on n’a pas la recette
Un logiciel installé commence par un texte lisible par un humain, le code source, que son auteur fait ensuite traduire dans une langue que seule la machine comprend. C’est ce produit traduit que vous recevez quand vous achetez un programme. Un plat cuisiné, en somme, livré sans sa recette.
La rétro-ingénierie consiste à retrouver la recette à partir du plat. On le goûte, c’est-à-dire qu’on observe ce que fait le programme et ce qu’il répond à chaque geste. On le démonte aussi, avec des outils appelés décompilateurs, qui retraduisent la langue de la machine en une approximation du texte d’origine.
Le travail est ancien et long. Il est resté l’affaire de spécialistes.
REA ne fait pas ce travail à leur place. Il le confie à un assistant d’IA capable d’écrire du code et lui met entre les mains les outils de ces spécialistes : des décompilateurs comme Ghidra ou IDA pour les programmes, de quoi observer une application de téléphone ou un site en fonctionnement. L’assistant étudie le programme, montre ce qu’il a trouvé, puis écrit sa propre version de ce qu’il a compris.
D’autres arrivent à un résultat voisin par un autre chemin. Début octobre, le projet ArtCraft a publié sept applications gratuites conçues pour faire ce que font celles d’Adobe (retouche photo, dessin vectoriel, montage vidéo, mise en page), écrites, selon celui qui les signe, avec l’aide d’une IA. Le projet dit n’avoir rien démonté et s’être appuyé sur les documentations publiques et sur le comportement observé des logiciels.
ArtCraft reconnaît aussi que ses applications sont inachevées. Deux d’entre elles seulement en sont au stade alpha, celui d’une version d’essai encore incomplète ; les autres sont toujours en développement. Quant à PhotoCraft, il n’est « pas encore » un remplaçant de Photoshop pour le travail professionnel de tous les jours.
Ce que l’IA refait et ce qui lui échappe
La promesse de « n’importe quelle application » bute sur une limite simple. L’IA ne refait que ce qu’elle peut observer. Un programme installé sur votre ordinateur ou votre téléphone est entièrement chez vous : on peut le faire tourner, le regarder, le démonter. Un site web, lui, montre surtout sa surface, ses pages, ses boutons, sa manière de réagir.
Le cœur d’un service en ligne reste sur ses serveurs, là où personne ne le voit tourner. Les calculs de votre banque, l’ordre dans lequel un moteur de recherche classe ses résultats, les prix qu’une compagnie aérienne recalcule en permanence, les données qu’un réseau social accumule : rien de tout cela ne passe par votre machine. L’IA peut reproduire l’apparence d’un service, pas ce qui fait sa valeur.
Les exemples que REA met en avant le montrent. Sa vitrine présente cinq études qui portent chacune sur une fonction : la manière dont un vieux jeu calcule le placement d’un son, ou dont une application de prise de notes copie un texte dans le presse-papiers. Pas une application entière. C’est déjà remarquable, mais c’est autre chose que la promesse.
Il y a une seconde limite, moins visible. Une copie n’est pas un produit. Le jour où l’on a reconstruit un logiciel, il faut encore le corriger, l’adapter aux nouvelles versions de son ordinateur, le protéger contre les failles qu’on y découvrira. Ce travail de l’éditeur d’origine, on le payait autant que le code.
J’écrivais en mars que les bons outils ne font pas le bon artisan, parce qu’un outil nous rend plus rapides sans nous rendre meilleurs. Un logiciel refait à toute vitesse obéit à la même règle. Il a été vite fait, mais il n’est pas forcément bien fait. Quelqu’un devra encore s’en occuper demain.
Ce que le droit vous autorise chez vous
Une question vient tout de suite : a-t-on seulement le droit de faire cela ? En Europe, la réponse tient dans quelques textes précis. Elle est plus généreuse qu’on ne le croit. Ce qui suit est ma lecture de ces textes, pas un avis juridique.
Une directive européenne de 2009 sur la protection des programmes d’ordinateur accorde un droit à toute personne qui détient légitimement une copie d’un logiciel, celui qu’elle a acheté par exemple.
« La personne habilitée à utiliser une copie d’un programme d’ordinateur peut, sans l’autorisation du titulaire du droit, observer, étudier ou tester le fonctionnement de ce programme afin de déterminer les idées et les principes qui sont à la base de n’importe quel élément du programme, lorsqu’elle effectue toute opération de chargement, d’affichage, d’exécution, de transmission ou de stockage du programme d’ordinateur qu’elle est en droit d’effectuer. »
Autrement dit, on peut observer le programme pendant qu’on s’en sert normalement. Le même texte précise qu’un contrat ne peut pas retirer ce droit, puisqu’une clause contraire est « nulle et non avenue » (article 8).
En 2012, dans l’affaire SAS Institute, la Cour de justice de l’Union européenne en a tiré la conséquence. Ni la fonctionnalité d’un programme, ni son langage de programmation, ni ses formats de fichiers ne sont protégés par le droit d’auteur propre aux logiciels. Celui qui, détenant une licence et sans accès au code source, s’est « limité à étudier, à observer et à tester ce programme afin de reproduire sa fonctionnalité dans un second programme » ne porte aucune atteinte au droit d’auteur sur ce programme.
La directive autorise aussi à décompiler, c’est-à-dire à démonter le programme jusqu’à une forme de code, mais dans des limites étroites. Seules les parties nécessaires pour qu’un programme écrit de son côté fonctionne avec d’autres sont concernées, si l’information n’est pas déjà accessible. Le texte exclut de s’en servir pour fabriquer un programme « dont l’expression est fondamentalement similaire » (article 6).
En 2021, dans une affaire belge qui opposait la société Top System à l’État belge, la même Cour a admis qu’on décompile un programme pour en corriger les erreurs, dans la mesure nécessaire et dans le respect du contrat. La Belgique, elle, a repris ces règles dans son Code de droit économique par une loi de 2014.
Ce que ces textes ne couvrent pas compte autant. Copier le code, ou le faire réécrire dans un autre langage, reste réservé au titulaire des droits. C’est à mes yeux le vrai risque quand on demande à une IA de reconstruire un programme à partir de ce qu’un décompilateur en a tiré.
Contourner une protection technique, une clé de licence ou un chiffrement, sort aussi de ce cadre. La directive vise même expressément la mise en circulation des moyens qui n’ont pas d’autre but que ce contournement. Surtout, tout cela suppose d’avoir une copie du programme.
Or un service en ligne ne vous remet aucune copie de ce qui tourne sur ses serveurs. Ces droits n’ont alors pas de prise sur cette partie : ce sont ses conditions d’utilisation qui décident. Celles de TradingView, un site de graphiques boursiers, n’autorisent par exemple aucun usage commercial de ses services sans accord séparé (ses conditions, en anglais).
Le droit dessine donc la même frontière que la technique. Ce qui est chez vous s’observe librement, ce qui reste chez l’éditeur lui appartient.
La valeur part vers le serveur
Un logiciel qu’on utilise en ligne, sans l’installer, c’est ce que les informaticiens appellent un SaaS, pour Software as a Service, le logiciel en tant que service. L’institut américain des normes et de la technologie, le NIST, l’a défini en 2011. Vous utilisez les applications du fournisseur, qui tournent sur une infrastructure en ligne, depuis différents appareils, par un navigateur web par exemple, sans gérer ni contrôler ce qui les fait fonctionner. Le NIST donne l’exemple de la messagerie en ligne (sa définition, en anglais).
La même année, le 20 août 2011, Marc Andreessen publiait dans le Wall Street Journal un texte resté célèbre, « Why Software Is Eating the World », pourquoi le logiciel dévore le monde. Andreessen avait cocréé le navigateur web Mosaic, sorti en 1993, puis cofondé Netscape et la société d’investissement Andreessen Horowitz. Il annonçait que les entreprises du logiciel s’apprêtaient à prendre de larges pans de l’économie et donnait pour exemple la chute de la chaîne de librairies Borders face à Amazon.
Quinze ans plus tard, le logiciel se dévore lui-même. Ce qui le protégeait tenait en deux choses. Il était difficile à écrire et, une fois traduit pour la machine, il devenait opaque. Les deux protections tombent ensemble.
En février 2026, Anthropic, l’entreprise qui développe l’assistant Claude, a confié à seize agents d’IA, des assistants qui avancent seuls sur leur part du travail, l’écriture d’un compilateur. C’est le programme qui fait justement cette traduction. Le leur compte 100 000 lignes, il sait compiler le cœur du système Linux et il a coûté environ 20 000 dollars d’usage de l’IA (son compte rendu).
Le même mois, chez Cloudflare, un ingénieur qui dirigeait une IA a refait en une semaine Next.js, un outil de fabrication de sites web, pour environ 1 100 dollars d’usage de l’IA (son récit). Aucun des deux n’est un produit fini : le compilateur n’est « pas encore » un remplaçant des compilateurs existants ; l’ingénieur de Cloudflare a dû garder la main sur l’IA. Mais le coût de départ a changé d’échelle. Quant à REA, il rend lisible, pour un assistant, ce qu’un programme installé tenait caché.
La conséquence me paraît logique. Si tout ce qui est livré chez le client se comprend et se réécrit, la valeur se réfugie là où on ne peut pas l’observer, sur le serveur. Les données accumulées, le calcul, le réseau des utilisateurs, la conformité aux règles d’un secteur ne se reconstruisent pas en regardant une interface.
Le précédent existe. Quand Adobe a remplacé en 2013 ses logiciels vendus à l’unité par un abonnement, un journaliste de The Next Web y voyait une réponse au piratage. Mais un programme installé reste un programme installé, abonnement ou pas. Seul ce qui demeure chez l’éditeur échappe vraiment à la copie.
Faut-il en conclure que tout finira en SaaS ? Je ne le crois pas, parce que la même cause frappe une partie des services en ligne. Fin janvier 2026, Anthropic a ajouté onze extensions à son assistant Claude Cowork et les valeurs du logiciel ont décroché en Bourse. Selon Cyber Daily (10 février 2026), elles avaient perdu environ 1 000 milliards de dollars depuis le 28 janvier, dans ce que certains ont baptisé la « SaaSpocalypse ».
Les services les plus fragiles me semblent être ceux qui ne sont qu’une interface. Une présentation de Fairmount Partners, un conseil en fusions et acquisitions, datée de juin 2026, le dit à sa façon. La couche applicative isolée, sans données propres en dessous ni intelligence capable d’agir au-dessus, est la plus exposée à voir sa valeur revue à la baisse.
Deux pôles plutôt qu’un monde tout en SaaS
Ce qui se dessine, je crois, ce sont deux pôles. D’un côté, les services qui gardent leur valeur sur un serveur parce qu’elle tient à ce qu’on n’y voit pas, des données, un réseau, une responsabilité. Il est normal que ceux-là restent en ligne. De l’autre, les outils que l’on peut de nouveau construire, adapter et garder chez soi, parce que les refaire coûte de moins en moins.
L’idée de garder chez soi ses outils et ses données n’est pas neuve. En octobre 2019, à Athènes, Martin Kleppmann présentait avec trois coauteurs du groupe Ink & Switch un essai intitulé « Local-first software ». Kleppmann, aujourd’hui enseignant-chercheur à l’université de Cambridge, est l’auteur de Designing Data-Intensive Applications, un livre consacré à l’architecture des bases de données.
Leur constat est simple. En centralisant les données sur des serveurs, les applications en ligne retirent à leurs utilisateurs la propriété de leur travail ; si le service ferme, le logiciel s’arrête et les données créées avec lui sont perdues. Ils proposaient des logiciels local-first, qui offrent à la fois la collaboration et la propriété.
Ce qui manquait, selon moi, c’était le prix. Construire son propre outil demandait des compétences rares et beaucoup de temps. C’est exactement ce que l’IA fait baisser.
Rester maître de ses outils redevient possible, pas seulement pour quelques passionnés. Chacun en est-il capable pour autant ? Je ne le crois pas : la barrière tient désormais à la structure qu’il faut penser et au temps qu’il faut y consacrer, comme je l’explique dans un article sur la création de ses propres logiciels avec l’IA.
Ce qui ne se copie pas
Demander si l’IA peut tout cloner, c’est regarder le logiciel comme un objet. Or ce que l’on achète, de plus en plus, c’est ce qui l’entoure : les données qu’il garde, les personnes qu’il relie, les règles qu’il respecte à notre place, le soin de quelqu’un qui le fait vivre. L’IA fait baisser le prix de l’objet. Tout le reste garde le sien.
Le jour où refaire un outil ne vous coûtera presque rien, qu’est-ce qui vous fera encore choisir de le louer ?
Transparence
Cet article reflète mon analyse personnelle, fondée sur mon expérience professionnelle. Aucun lien commercial.