Écrire une fonction, brancher une API, générer un formulaire d’inscription avec validation et emails de confirmation : ces tâches prenaient des heures il y a trois ans. Elles prennent aujourd’hui quelques minutes à un développeur expérimenté équipé d’un assistant. Le coût de production d’une ligne de code a baissé, et il a baissé vite.
C’est un changement d’économie, pas un changement de mode. Et comme tout changement d’économie, il déplace des arbitrages que les entreprises tenaient pour acquis depuis quinze ans.
Le coût qui a bougé, et celui qui n’a pas bougé
L’assistant de code accélère la partie mécanique du métier : la syntaxe, le boilerplate, les migrations de base de données, les tests unitaires triviaux, la traduction d’une intention claire en implémentation. Sur ces tâches, le gain est réel et mesurable dans n’importe quelle équipe qui l’a adopté sérieusement.
Ce qui n’a pas bougé, c’est le reste. Comprendre le métier d’un client. Décider quelles données modéliser et lesquelles ignorer. Arbitrer entre deux façons de découper un workflow. Repérer qu’une règle métier énoncée en réunion contredit une autre règle énoncée trois semaines plus tôt. Choisir de ne pas construire une fonctionnalité. Ce travail-là résiste, parce qu’il porte sur des décisions et pas sur de la production.
Le résultat : dans un projet logiciel, la part du coût qui vient de la frappe au clavier a fondu, la part qui vient de la réflexion et de la vérification est devenue dominante.
L’arbitrage make-or-buy s’est déplacé
Pendant longtemps, la logique était simple pour une PME de 10 à 50 personnes. Développer un outil interne coûtait entre 60 000 et 200 000 euros, prenait six à douze mois, et supposait de recruter quelqu’un pour le maintenir. Face à ça, un SaaS à 300 ou 500 euros par mois était le choix rationnel, même s’il ne couvrait que 60 % du besoin et qu’il fallait bricoler le reste dans des tableurs.
Quand le coût de production tombe, la comparaison change de forme. Un abonnement à 400 euros par mois représente 4 800 euros par an, et 24 000 euros sur cinq ans, sans que l’entreprise ne possède quoi que ce soit à la fin. En face, un outil sur mesure qui couvre exactement le processus réel, dont le code appartient à l’entreprise, redevient atteignable pour des budgets qui étaient hors sujet il y a cinq ans.
Ça ne veut pas dire qu’il faut tout redévelopper. Une comptabilité, une paie, une messagerie : personne n’a de raison sérieuse de les réécrire. La règle utile est celle de la spécificité. Si le processus est standard dans votre secteur, achetez. S’il est précisément ce qui vous différencie de vos concurrents, et que vous passez votre temps à le tordre pour le faire rentrer dans un outil générique, l’équation a changé en faveur du sur mesure.
La question difficile devient “quoi construire”
Quand produire du code était cher, la discipline venait du budget. Personne ne demandait dix fonctionnalités quand chacune coûtait 8 000 euros. La contrainte financière faisait le travail de priorisation à la place des équipes.
Cette contrainte s’est relâchée, et les projets s’en ressentent. On voit des périmètres qui gonflent parce que “de toute façon l’IA le génère vite”. C’est vrai pour l’écriture. C’est faux pour tout le reste : chaque écran ajouté est un écran à maintenir, à tester, à faire évoluer, à expliquer à un nouvel utilisateur, à corriger quand la réglementation bouge.
La compétence qui prend de la valeur, c’est donc la capacité à découper. Savoir isoler le morceau de processus qui, mis en ligne seul, produit déjà un gain visible. Un seul type d’utilisateur, un seul flux principal, une seule mesure de succès. Le reste attend d’avoir été confronté à la réalité.
Le vibe coding marche, jusqu’au premier vrai utilisateur
L’autre effet de cette baisse de coût, c’est que des personnes qui ne programment pas génèrent désormais des applications entières en décrivant ce qu’elles veulent. Le prototype sort en un week-end, il est joli, il fonctionne sur les trois cas testés par son auteur. Et il part parfois directement en production.
Pour valider une idée devant cinq personnes, la démarche est excellente. Elle remplace avantageusement un cahier des charges de 40 pages que personne ne lira. Le problème commence quand cette même application accueille des vrais utilisateurs, des données personnelles, de l’authentification et des paiements.
L’architecture n’a jamais été décidée
Un assistant répond à la demande du moment. Prompt après prompt, il produit des solutions localement correctes qui ne partagent aucune logique commune. La même règle métier finit implémentée à quatre endroits, avec trois variantes. Le jour où la règle change, trois des quatre endroits sont oubliés. L’outil n’y est pour rien : c’est la conséquence mécanique d’un développement conduit sans vue d’ensemble.
L’autorisation est l’angle mort le plus fréquent
L’authentification, la partie “qui êtes-vous”, est bien gérée par les assistants : ils connaissent les bibliothèques standard. L’autorisation, la partie “avez-vous le droit d’accéder à cette ressource”, est presque toujours incomplète. Un endpoint du type GET /factures/1042 vérifie que l’utilisateur est connecté, puis renvoie la facture sans vérifier qu’elle lui appartient. N’importe quel utilisateur légitime qui change le numéro dans l’URL lit les factures des autres. Même mécanisme sur un identifiant de dossier client, de conversation ou de fichier téléchargé.
Une liste plus détaillée des modes de casse observés sur des applications générées puis mises en ligne est documentée ici : https://5000.dev/fr/blog/vibe-coding-danger
Sans tests, chaque modification est un pari
Une application générée par prompts contient rarement une suite de tests utile. Tant que rien ne change, ça tient. À la première évolution, plus rien ne garantit que la modification du calcul de remise n’a pas cassé la facturation. L’équipe découvre les régressions par les appels clients, ce qui est la façon la plus coûteuse de les découvrir.
Les dépendances vieillissent
Le code généré tire des bibliothèques, dont certaines sont abandonnées, obsolètes, ou hallucinées puis remplacées au hasard. Six mois plus tard, une faille est publiée sur l’une d’elles. Personne ne suit les avis de sécurité, personne ne sait quelle version est déployée, et la mise à jour casse deux autres choses.
On ne débogue pas un code qu’on ne comprend pas
C’est le point de blocage final. Quand la production tombe un mardi matin, il faut lire des logs, formuler une hypothèse, l’infirmer, remonter la chaîne. Redemander à l’IA de corriger sans comprendre la cause produit une couche supplémentaire de code par-dessus le problème. Beaucoup d’applications finissent abandonnées pour cette raison, bien avant d’avoir rencontré un bug grave : plus personne à l’intérieur n’est capable de les faire évoluer.
Le problème n’est pas l’outil
Il serait malhonnête d’en conclure que l’IA code mal. Entre les mains d’un développeur qui sait relire, elle est un accélérateur considérable, et les équipes sérieuses l’utilisent quotidiennement. Un senior lit le diff, repère l’appel qui ne filtre pas par utilisateur, refuse la dépendance douteuse, réécrit la partie qui duplique une logique existante.
Ce qui manque dans le vibe coding, c’est cette relecture. Le générateur est le même dans les deux cas. La différence tient entièrement à la présence de quelqu’un capable de dire non à ce qui sort.
Quand reprendre proprement un prototype généré
Voici les critères qui, dans la pratique, justifient une reprise sérieuse plutôt qu’une rustine de plus.
- L’application stocke des données personnelles, de santé, bancaires, ou des documents dont la fuite serait un incident réglementaire.
- Elle a plus d’un rôle utilisateur, ou des utilisateurs qui ne doivent pas voir les données des autres.
- Elle encaisse des paiements, émet des factures, ou déclenche une action irréversible chez un tiers.
- Vous ne pouvez pas répondre à la question de savoir quel utilisateur a modifié quoi, et quand.
- Modifier une fonctionnalité en casse une autre plus d’une fois sur trois.
- Aucune personne de l’entreprise ne peut expliquer comment les données sont organisées.
- Il n’existe ni sauvegarde restaurée au moins une fois, ni environnement de test séparé de la production.
- Le service est devenu nécessaire au travail quotidien d’une équipe : une panne de deux jours coûte réellement de l’argent.
Deux critères cochés justifient un audit. Quatre justifient une reprise du socle, en gardant le prototype comme spécification vivante, ce qu’il est de très loin le mieux placé pour être. Le travail de compréhension du métier a déjà été fait par la personne qui l’a généré, et il a de la valeur. Ce qui doit être refait, c’est la fondation : modèle de données, autorisations, tests, déploiement.
L’ordre inverse, construire proprement puis chercher ce que veulent les utilisateurs, reste le plus coûteux des deux.