Votre site généré par IA : l'addition arrive douze mois plus tard

Générer un site en un week-end ne coûte presque rien le lundi matin. La dépense existe pourtant, elle est simplement décalée. En 2026, GitClear a mesuré le taux de duplication le plus élevé de son histoire et le taux de réorganisation du code le plus bas, sur 623 millions de changements de code analysés depuis 2023 (opens in a new tab). Le code s'écrit plus vite qu'avant. Il se range beaucoup moins.

Cet article n'est pas un procès de la génération assistée par IA. Ces outils règlent un vrai problème et il existe des situations où ils sont le choix le plus rationnel. La question utile porte sur autre chose : qui paie, quand et à quelle occasion, une fois passé l'enthousiasme de la première semaine.

Deux familles d'outils très différentes sont rangées sous la même étiquette. Elles ne produisent pas la même dette. Les pages qui suivent séparent ces familles, mesurent ce que les données publiques disent de chacune, puis proposent un cadre de décision. La conclusion n'est pas qu'il faut tout coder à la main. Elle tient en une phrase : un site généré demande une décision explicite sur sa durée de vie, prise avant la génération elle-même.

D'un côté, les générateurs de code. Lovable, v0, Bolt ou Replit Agent produisent un vrai dépôt Git, du React ou du Next.js, une base de données. Le code existe, il vous appartient et sa maintenance aussi. De l'autre, les générateurs hébergés. Wix, Squarespace, Framer ou Durable assemblent un site à partir de modèles et le publient sur leur propre infrastructure. Il n'y a pas de code à reprendre pour la raison simple qu'aucun code ne vous est livré.

Les deux familles ne laissent pas la même chose entre vos mains

Cette distinction commande tout le reste. Un abonnement Wix et un projet Lovable n'ont presque rien en commun, sinon de sembler gratuits au départ.

L'expression "dette technique" circule beaucoup et se vérifie rarement. Deux travaux publiés depuis fin 2025 rendent cette dette chiffrable.

GitClear suit l'évolution du code sur 623 millions de changements analysés entre 2023 et 2026 (opens in a new tab). Trois indicateurs se sont dégradés au rythme de l'adoption des assistants.

Ces trois courbes décrivent la même chose sous trois angles. Le code produit aujourd'hui se recopie au lieu d'être mis en commun. Concrètement, changer un numéro de téléphone, un tarif ou une règle de calcul ne se fait plus à un seul endroit. Il faut retrouver les cinq copies, les corriger toutes les cinq et découvrir la sixième trois semaines plus tard en production.

Deux autres signaux du même rapport méritent l'attention. Les constructions qui masquent une erreur au lieu de la traiter progressent de 47 %. Le code réécrit dans les deux semaines suivant son écriture progresse de 15 %. Un site qui avale ses erreurs en silence ne tombe pas. Il produit des résultats faux sans prévenir personne.

La seconde mesure vient du monde académique. Des chercheurs de la Singapore Management University et de l'université Huazhong ont analysé 302 600 contributions attribuées à une IA dans 6 299 dépôts GitHub publics (opens in a new tab), en passant des analyseurs statiques avant et après chaque contribution.

Ce dernier chiffre est le plus parlant. Près d'un problème sur quatre n'a jamais été corrigé, non par négligence mais parce que personne ne l'a vu. Un défaut introduit dans du code que son propriétaire n'a pas écrit n'a aucune raison d'être remarqué avant de provoquer quelque chose de visible.

La dette ne se paie pas à la génération. Elle se paie à la première modification demandée par quelqu'un d'autre, plusieurs mois plus tard, sur un code que plus personne ne peut expliquer.

LinearB a comparé 8,1 millions de demandes de fusion issues de 4 800 équipes dans 42 pays (opens in a new tab). L'écart entre code humain et code assisté par IA ne porte pas sur la vitesse d'écriture.

Code humain et code assisté par IA, comparés sur 8,1 millions de demandes de fusion

Sur trois propositions de code assistées par IA, deux ne sont jamais intégrées. Elles ont pourtant coûté du temps de génération, du temps de relecture, puis du temps d'abandon. Le gain de vitesse à l'écriture se paie plus loin dans la chaîne, là où personne ne le compte.

Un essai contrôlé mené par METR en 2025 (opens in a new tab) a mesuré l'écart de perception qui accompagne ce phénomène. Seize développeurs expérimentés ont traité 246 tâches réelles sur des projets qu'ils connaissaient depuis des années. Avec les outils d'IA, ils ont mis 19 % de temps en plus. Interrogés après coup, ils estimaient avoir gagné 20 %. METR classe aujourd'hui ce résultat comme historique, les outils ayant beaucoup changé depuis. L'écart entre le ressenti et la mesure, lui, n'a aucune raison d'avoir disparu.

Les développeurs eux-mêmes ne s'y trompent pas. Dans l'enquête Stack Overflow menée auprès de plus de 49 000 personnes (opens in a new tab), 84 % utilisent ou prévoient d'utiliser des outils d'IA. Seuls 3,1 % déclarent une confiance élevée dans l'exactitude des réponses, contre 45,7 % qui s'en méfient. La frustration la plus citée, par 66 % des répondants, tient en une formule : des solutions presque justes, jamais tout à fait.

"Presque juste" est précisément le registre le plus coûteux sur un site. Un formulaire qui échoue franchement se répare dans la journée. Un formulaire qui envoie le message sans la pièce jointe passe des mois avant d'être repéré. Ce qui a été perdu entre-temps ne se rattrape pas.

La sécurité suit un autre calendrier. L'addition peut arriver dès la mise en ligne.

En octobre 2025, les équipes d'Escape ont analysé plus de 5 600 applications publiquement déployées (opens in a new tab) depuis des plateformes de génération, dont plus de 4 000 issues de Lovable, complétées par des applications Create.xyz, Base44, Bolt.new et Vibe Studio. Le balayage a porté sur 14 600 ressources au total.

Les causes se répètent d'une application à l'autre. Des intégrations de base de données mal configurées, des jetons d'authentification laissés dans le paquet JavaScript envoyé au navigateur, des règles d'accès par ligne jamais activées. Aucune de ces erreurs n'est exotique. Toutes supposent de savoir qu'un réglage existe. Un générateur produit une application qui fonctionne, il ne produit pas la connaissance de ce qu'il a laissé ouvert.

Un incident d'avril 2026 illustre le mécanisme. Il est documenté par la plateforme elle-même. Dans sa réponse publique (opens in a new tab), Lovable explique qu'entre le 3 février et le 20 avril 2026, l'historique de conversation et le code source des projets publics ont pu être consultés par n'importe quel utilisateur connecté. Une évolution du produit avait rétabli par inadvertance un accès retiré des mois plus tôt. Des chercheurs avaient signalé le problème dès le 22 février via le programme de divulgation. Les signalements ont été fermés sans être transmis parce que la documentation interne remise aux personnes chargées du tri décrivait encore cette visibilité comme voulue.

La suite est à porter au crédit de l'éditeur. Le correctif a été livré dans les deux heures suivant la publication du problème, tous les anciens projets publics sont passés en privé et la procédure de tri des signalements a été revue. Reste le fond. Pendant onze semaines, des projets créés par des gens qui ignoraient que "public" signifiait "lisible par tout le monde" ont été lisibles par tout le monde.

Savoir si telle plateforme est sûre importe moins que savoir qui répondra le jour où elle cessera de l'être. Un site vitrine sans compte utilisateur ne risque pas grand-chose. Un formulaire de prise de rendez-vous chez un ostéopathe, un espace client de cabinet d'avocats ou un module de paiement changent complètement la nature du pari. Les obligations de conformité et de loyauté envers l'utilisateur (opens in a new tab) ne se délèguent à aucun générateur.

Les générateurs hébergés échappent à la dette technique parce qu'ils ne livrent aucun code. Ils créent une dépendance d'une autre nature, plus confortable au quotidien et plus difficile à défaire.

Wix indique dans sa propre documentation qu'un site créé avec son éditeur ne peut pas être exporté ni hébergé ailleurs (opens in a new tab), l'architecture reposant sur sa technologie propriétaire. Squarespace propose un export. Sa liste officielle des exclusions (opens in a new tab) est instructive. Les pages de boutique, de portfolio, d'index et de calendrier n'en font pas partie, pas plus que les menus déroulants, les blocs vidéo, les réglages de style ou le CSS personnalisé. Le contenu sort, la mise en page reste.

Cette dépendance ne coûte rien tant que rien ne change. Elle se rappelle au bon souvenir de l'entreprise le jour où celle-ci veut une fonctionnalité que la plateforme ne propose pas, une performance que son rendu ne permet pas ou simplement un site qui ne ressemble pas aux autres.

S'y ajoute un effet plus difficile à chiffrer. Un générateur produit ce que son modèle a le plus souvent rencontré. Sur des milliers de sites issus des mêmes modèles et des mêmes entraînements, les mises en page convergent, les rythmes de page se répètent, les mêmes sections reviennent dans le même ordre. Pour une entreprise dont le site constitue le principal point de contact avant le premier rendez-vous, ressembler à tout le monde annule précisément ce que ce site devait apporter.

Rien de ce qui précède ne condamne ces outils. Tout indique en revanche que la décision se prend sur la durée de vie attendue du site, pas sur son prix affiché. Un critère unique résume l'essentiel. Un site généré est un bon choix quand personne n'aura à le reprendre.

Le même outil devient un bon ou un mauvais choix selon ce qu'on lui demande

Les deux premières lignes ne sont pas des concessions polies. Une entreprise qui hésite entre deux positionnements a tout intérêt à générer deux versions dans la semaine plutôt qu'à commander une refonte de trois mois sur une hypothèse jamais vérifiée. Le générateur devient alors un instrument de décision. Il coûte peu, il tranche vite et son résultat n'a pas vocation à survivre. Reste ensuite à savoir ce que l'entreprise construit vraiment, question traitée dans l'article sur refonte ou nouveau site (opens in a new tab).

L'erreur classique ne consiste pas à générer. Elle consiste à laisser un prototype devenir le site officiel par simple inertie, parce qu'il fonctionnait suffisamment bien pour qu'aucune décision ne soit prise.

Ces six questions ne demandent aucune compétence technique. Une réponse floue à la deuxième ou à la quatrième suffit à écarter l'option pour un site d'entreprise.

La génération par IA a rendu quasi gratuite la partie du travail qui n'a jamais été la plus coûteuse. Écrire une page va vite depuis longtemps. La comprendre six mois plus tard, la faire évoluer sans casser le reste, la garder sûre et rapide, voilà où passe l'argent.

Le calcul de rentabilité d'un site ne se fait donc pas sur son coût de fabrication mais sur son coût de possession, sujet déjà traité sous l'angle du budget à défendre en interne (opens in a new tab). Un site généré en un week-end, repris deux fois dans l'année par des prestataires successifs qui ne comprennent pas le code livré, finit plus cher qu'un site conçu correctement une seule fois.

Le site reste la fondation sur laquelle tous les autres leviers s'appuient, la seule surface que l'entreprise contrôle entièrement. Le générer en une heure est parfaitement possible. Décider combien de temps il doit tenir demande plus d'une heure. C'est cette décision qui se paie douze mois plus tard.