Explosion et démocratisation du logiciel à l'ère de l'IA

Prenons une responsable des opérations qui ouvre Lovable un vendredi soir pour remplacer les trois fichiers Excel et la dizaine d'emails hebdomadaires qui servent à suivre les retours fournisseurs. Le lundi matin, son équipe utilise déjà la nouvelle application, sans que la DSI ait été consultée et sans que personne sache vraiment où sont stockées les données.

Ce genre de scène n'a plus rien de fictif, et c'est une très bonne nouvelle, parce que le vibe coding est en train de faire pour le logiciel ce que le tableur a fait pour le calcul en le mettant entre les mains de tout le monde.

Mais sortir une première version d'une application, ce n'est pas encore avoir fait un logiciel, et c'est justement cette différence que cet article explore.

Le logiciel change d'échelle : un mois de 2026 pèse plus que toute l'année 2025

Il y a encore deux ans, le code était une ressource rare : il fallait des développeurs, du temps, un budget et une place dans la roadmap pour obtenir le moindre outil.

Aujourd'hui, un seul mois de commits sur GitHub représente plus que toute l'année 2025, et cette accélération ne montre aucun signe de ralentissement.

Source : Kyle Daigle, COO de GitHub, avril 2026. Seul avril est mesuré, les autres mois sont projetés au même rythme.

On a commencé par appeler ça vibe coding, quand on décrivait ce qu'on voulait à une IA en regardant simplement si le résultat fonctionnait, puis on a parlé de vibe engineering et d'ingénierie assistée par agents pour désigner un usage plus professionnel et plus rigoureux.

Les termes évoluent tous les six mois, mais ce qui se joue au quotidien ressemble surtout à une industrialisation : comme beaucoup d'autres industries avant lui, le logiciel est en train de passer de l'artisanat à la production à grande échelle.

Il y a pourtant un chiffre qui devrait nous mettre la puce à l'oreille. Les développeurs qui utilisent ces outils écrivent environ 25 fois plus de lignes de code, mais ne mettent en production que 1,3 fois plus de versions, ce qui montre bien que l'écriture du code n'est plus le goulot d'étranglement.

Source : NBER Working Paper 35275, Demirer, Musolff et Yang, révision de septembre 2026.

Plus de logiciel, c'est moins d'Excel et moins d'erreurs

Ce mouvement est d'abord une opportunité. Dans la plupart des entreprises, une part énorme du travail repose encore sur des tableurs partagés, des échanges d'emails et des copier-coller, non pas par choix mais parce que développer un vrai outil coûtait beaucoup trop cher pour répondre au besoin d'une équipe d'une dizaine de personnes.

Quand le coût du logiciel s'effondre, ces besoins deviennent enfin rentables à outiller, et même une application très simple apporte ce qu'un fichier Excel n'apportera jamais :

• des règles métier écrites noir sur blanc, plutôt que gardées dans la tête d'une seule personne ;
• une trace de qui a fait quoi ;
• des données qu'on peut croiser sans avoir à les ressaisir.

Au bout du compte, on fait moins d'erreurs, on perd moins de temps, et le savoir de l'équipe ne disparaît plus quand quelqu'un s'en va.

Le Royaume-Uni en a fait l'expérience à grande échelle en 2020, quand près de 16 000 cas positifs de Covid n'ont pas été remontés à temps parce qu'un fichier Excel avait atteint sa taille maximale, et chaque entreprise a sa propre version, plus modeste, de ce genre d'incident.

Le terrain idéal : forte complexité métier, faible complexité technique

Toutes les applications ne profitent pas de la même façon du vibe coding. Celles qui en tirent le plus de bénéfices sont les logiciels métiers, qui combinent une forte complexité métier et une faible complexité technique. Concrètement, il s'agit de :

• saisir des données dans des formulaires ;
• les transformer avec des règles métier ;
• les réafficher dans des tableaux de bord ;
• envoyer des emails et lancer des tâches planifiées ;
• importer et exporter des fichiers Excel.

Rien de tout cela n'est difficile sur le plan technique. La vraie difficulté consiste plutôt à comprendre le métier, à écrire les bonnes règles, à anticiper les cas particuliers et à vérifier que l'ensemble fonctionne correctement, et c'est précisément sur ce terrain que les coding agents et les derniers modèles de raisonnement sont devenus vraiment performants.

Sur ce périmètre, on observe sur le terrain un logiciel 5 à 10 fois moins cher et 5 à 6 fois plus rapide à construire qu'avec une équipe de développement classique. Ce n'est évidemment pas une loi universelle, mais sur ce type d'application l'écart est bien réel.

Le piège : l'illusion de maîtrise

Il existe pourtant un piège, et il dépasse largement le code. Quand on utilise un LLM, on a très vite l'impression de devenir expert du sujet qu'on aborde : on lui pose une question juridique, il répond avec beaucoup d'assurance et on a le sentiment d'avoir compris.

Sauf que le modèle commet souvent de petites erreurs qu'on est incapable de repérer, tout simplement parce qu'on ne sait pas ce qu'on ne sait pas.

Dans le logiciel, ce piège prend une forme très concrète. Une personne qui n'a jamais développé ouvre Claude Code ou Lovable, décrit son besoin et obtient en un après-midi une application jolie et fonctionnelle, si bien qu'elle a l'impression d'avoir fait un logiciel qu'elle peut déployer, sans toujours savoir ce que déployer veut dire.

Plus préoccupant encore, l'outil a tendance à renforcer le problème qu'il crée, puisque plus on délègue à l'IA, moins on développe les compétences qui permettraient de vérifier ce qu'on lui a délégué.

Le vrai coût arrive après la première version

Ce qu'on voit d'une application, c'est son interface, alors que ce qui compte vraiment sur le long terme se trouve derrière : le back-end et surtout la base de données. On peut refaire un écran en une heure, mais un modèle de données mal pensé se traîne pendant des années et finit par dicter ce qu'il est possible ou non de faire évoluer.

Le coût réel d'un logiciel ne se trouve d'ailleurs pas dans sa première version mais dans tout ce qui vient ensuite, c'est-à-dire le faire évoluer avec les besoins du métier, corriger les bugs et appliquer les mises à jour de sécurité. Selon les études, cela représente entre 60 et 80 % de son coût total sur sa durée de vie.

Toutes les équipes de développement connaissent bien ce cycle : quand il faut créer un nouveau service, tout le monde est enthousiaste à l'idée de repartir sur des bases saines et propres, puis au bout d'un, deux ou trois ans ce service est devenu un legacy comme les autres, la dette technique s'est accumulée et la vélocité de l'équipe a nettement baissé.

C'est assez difficile à faire comprendre à quelqu'un qui ne travaille pas dans la tech, mais sortir la première version d'un logiciel, qui n'est souvent qu'un prototype, est la partie facile. Le vrai défi consiste à faire vivre ce prototype dans la durée, pour qu'il continue à fonctionner, qu'il reste à jour sur le plan de la sécurité et qu'il suive l'évolution des besoins de l'entreprise.

Les outils couvrent le code, beaucoup moins l'exploitation

Si l'on prend un peu de recul, le cycle de vie d'un logiciel se découpe en six grandes phases :

1. Cadrage métier et produit
2. Design de l'expérience utilisateur
3. Développement, c'est-à-dire le code et les tests
4. Recette
5. Déploiement
6. Exploitation, pendant laquelle on récupère les retours des utilisateurs, on corrige les bugs et on met à jour les dépendances

Les outils utilisés par les développeurs, comme Claude Code ou Codex, sont excellents, mais ils restent spécialisés et très techniques, et ne couvrent au mieux que le cadrage, le design et le code. Les app builders comme Lovable ou Replit vont un peu plus loin en prenant en charge le déploiement, mais ils restent assez faibles sur le code, la recette et l'exploitation. Une troisième catégorie, les AI software factories comme Maleus, vise à couvrir les six phases, exploitation comprise.

On se retrouve donc dans une situation paradoxale où l'essentiel de l'outillage s'est concentré sur les phases qui coûtaient déjà le moins cher, en laissant de côté l'exploitation, celle qui coûte le plus.

Selon Bain, écrire et tester le code ne représente que 25 à 35 % du délai entre l'idée et le lancement, ce qui explique en grande partie pourquoi on écrit 25 fois plus de code sans pour autant livrer 25 fois plus de logiciels.

La qualité se joue sur la maintenabilité et la sécurité

Reste enfin la question de la qualité du code généré, qui se joue sur deux plans.

Maintenabilité : éviter les régressions

La maintenabilité, c'est une architecture solide et surtout des plans de tests suffisants pour éviter les régressions. Les régressions sont vraiment ce qu'il y a de pire quand on itère sur un produit, puisque chaque nouvelle fonctionnalité risque d'en casser une ancienne et qu'on finit par passer plus de temps à réparer qu'à avancer.

Sécurité : ce qu'une première version oublie

Côté sécurité, une application métier doit au minimum :

• authentifier correctement ses utilisateurs ;
• appliquer un système de permissions fiable ;
• isoler les données entre les utilisateurs et entre les clients ;
• résister au déni de service.

Début novembre, une étude portant sur plus de 159 000 projets Lovable a ainsi trouvé des données personnelles lisibles sans connexion sur 7 403 sites, le plus souvent à cause d'une base de données mal configurée.

L'import de fichiers Excel, qui est pourtant la fonctionnalité la plus banale d'une application métier, en est un autre bon exemple : les librairies de l'écosystème Node.js qui lisent ces fichiers sont vulnérables au déni de service, et un simple fichier piégé suffit à faire tomber le serveur.

Chez Maleus, nous avons d'ailleurs fini par encapsuler des librairies Rust existantes pour nous en protéger, dans un package open source : @maleus/xlsx, qui lit des fichiers non fiables en mémoire bornée, sans bloquer le serveur. Une personne qui débute n'a pourtant aucune raison de connaître ce problème, et l'IA ne le lui signalera probablement pas.

Le contexte actuel rend cette question encore plus pressante, puisque les LLM ne servent pas seulement à écrire du code mais aussi à trouver des failles :

Sources : Google Threat Intelligence Group, BleepingComputer.

La sécurité doit donc être pensée dès la conception, selon le principe du secure by design, puis maintenue à jour en continu.

Outiller, mais sur tout le cycle de vie

Faut-il interdire, encadrer ou outiller le vibe coding dans l'entreprise ? Interdire ne fonctionnera pas, parce que les équipes métier ont goûté à cette autonomie et n'y renonceront pas, mais laisser faire reviendrait à accumuler en silence des dizaines d'applications que personne ne saura maintenir dans deux ans.

La bonne réponse consiste donc à outiller, à condition de juger les outils sur l'ensemble du cycle de vie du logiciel plutôt que sur la qualité de leur démonstration.

La question à se poser n'est pas tant de savoir si un outil génère une belle application, mais plutôt qui la fera tourner, la corrigera et la sécurisera dans deux ans.

C'est désormais la deuxième version d'un logiciel, bien plus que la première, qui représente le vrai défi.

---

Photo de couverture : Francesco Ungaro sur Unsplash.