Maintenance d'un site IA : 6 trucs qui cassent

Le problème ne se voit pas le jour de la livraison

Un site généré par IA, le jour J, ça marche. Les pages s’affichent, le formulaire envoie, le bouton “Payer” fait son job. C’est précisément ce qui piège tout le monde : la panne d’un site IA n’arrive presque jamais à la livraison. Elle arrive trois, six, douze mois plus tard, sur des points que personne ne surveillait — parce que personne n’avait été désigné pour les surveiller.

La différence avec un site fait main, ce n’est pas la qualité du code initial (l’IA produit du code souvent propre). C’est l’absence de filet. Un développeur humain qui livre un projet sait ce qui va vieillir, ce qui va casser et où regarder dans six mois. Un outil de génération, lui, fige une photo à l’instant T et passe à autre chose. Voici les six endroits où ça lâche en silence — et pourquoi l’IA, contrairement à ce qu’on croit, ne se rattrape pas toute seule.

1. La dépendance qui périme (et que l’IG régénère mal)

Symptôme : au début, rien. Puis un jour, une faille de sécurité est publiée sur un package que ton site utilise. Ou une dépendance refuse de s’installer parce que sa version est trop ancienne pour l’environnement actuel. Le site continue de tourner, mais il est exposé.

C’est le risque le plus sous-estimé. Selon le State of Open Source Security 2024 de Snyk, 84 % des bases de code analysées contiennent au moins une vulnérabilité dans leurs dépendances open source. Et la durée médiane de correction dans un projet sans maintenance active est de 218 jours. Sept mois pendant lesquels la porte reste entrouverte.

Le problème spécifique aux sites IA : les dépendances sont figées à la date de génération. L’outil a installé les versions qu’il connaissait à l’instant T, et plus personne ne les touche. Pire, comme le note l’OWASP Dependency-Check, un LLM à qui on demande de “régénérer” un composant peut réintroduire le pattern vulnérable parce qu’il a été entraîné sur des versions obsolètes. L’IA ne détecte pas qu’une CVE a été publiée après son entraînement — elle ne sait pas ce qu’elle ne sait pas.

Mettre à jour une dépendance, ce n’est pas remplacer un numéro de version. C’est tester l’effet de bord dans le contexte applicatif réel. Ça, ni l’outil de génération ni un script automatique ne le font à ta place.

2. Le plugin custom collé au duct-tape

Symptôme : une fonctionnalité spécifique (un sélecteur de produits sur mesure, un calcul de prix, une intégration maison) qui marche jusqu’au jour où elle bugue de façon incompréhensible — et personne ne sait par où commencer.

Quand tu demandes à une IA une fonctionnalité qui n’existe pas en standard, elle assemble. Elle colle des bouts de code ensemble pour obtenir le résultat demandé. Ça fonctionne à l’écran, mais sans architecture sous-jacente : pas de séparation des responsabilités, pas de tests de régression, parfois des hacks qui dépendent d’un comportement non documenté d’une autre librairie.

L’ANSSI souligne précisément que l’absence de tests de régression sur les composants custom rend invisible la dégradation progressive. Tant que rien ne bouge autour, le bricolage tient. Le jour où une dépendance change de comportement (voir point 1), le château de cartes s’effondre — et l’IA qui a généré le tout ne le “comprend” pas mieux que toi, parce qu’elle ne l’a jamais structuré.

C’est exactement le genre de situation détaillée dans notre article sur les 5 cas où l’IA seule te met dans le mur : le custom, c’est là que ça lâche en premier.

3. L’intégration paiement qui drift

Symptôme : le plus vicieux de la liste. Un client clique sur “Payer”, voit un écran de confirmation… et l’argent n’arrive jamais sur ton compte. Côté interface, tout est vert. Côté serveur, le paiement n’a jamais été capturé.

Les API de paiement évoluent en permanence. Stripe déprécie ses anciennes versions d’API avec un préavis de 24 mois. Passé cette date, les appels peuvent échouer silencieusement ou retourner des comportements inattendus — pas une grosse erreur rouge, juste un paiement qui passe à l’UI mais n’est jamais finalisé côté serveur.

Le piège pour un site IA : l’outil a généré l’intégration avec la version la plus récente qu’il connaissait au moment de son entraînement — potentiellement déjà obsolète au déploiement. Et il y a souvent pire : les webhooks Stripe non vérifiés (absence de vérification de signature) exposent à des fraudes par replay attack. Un détail technique qu’une IG oublie volontiers, parce que rien à l’écran ne le rend visible.

Une intégration paiement, ça se monitore. Il faut des logs côté serveur, des alertes sur les écarts entre transactions UI et captures réelles, une veille sur les dépréciations d’API. Aucun de ces mécanismes ne se met en place tout seul. Si tu vends en ligne, c’est non négociable — on en parle dans le contexte des verticales premium et e-commerce où une transaction perdue = un client perdu.

4. Le formulaire qui fuit (spam-leak)

Symptôme : ta boîte mail se remplit de spam envoyé via ton propre formulaire. Ou pire, tu reçois un jour un courrier de la CNIL parce que des données personnelles ont fuité par un endpoint mal protégé.

Un formulaire de contact, ça paraît trivial. Un champ nom, un champ email, un bouton. L’IA le génère en deux secondes. Sauf qu’un formulaire qui collecte des données personnelles doit être sécurisé côté serveur : rate-limiting, CAPTCHA, validation, logs d’audit. La CNIL est explicite — l’absence de ces protections constitue une non-conformité au titre de l’article 32 du RGPD, et plusieurs entreprises ont été sanctionnées en 2023-2024 pour défaut de sécurisation de leurs formulaires de contact.

L’IA qui génère le formulaire s’occupe de l’affichage. Elle ne configure pas les protections côté serveur, ni les logs. Résultat : un formulaire peut devenir un relais de spam ou un canal d’exfiltration sans que tu en saches rien. Pas d’alerte, pas d’écran rouge. Juste une faille ouverte que tu découvres trop tard.

Si tu veux creuser le volet conformité, notre guide RGPD et site web en 2026 détaille les obligations concrètes — la sécurisation des formulaires en fait partie.

5. La perf qui se dégrade en silence

Symptôme : ton site était rapide. Un an plus tard, il rame, ton SEO baisse, ton taux de conversion s’effrite — et tu n’as “rien touché”.

C’est le drame le plus discret. Selon Google web.dev, un site peut perdre 20 à 40 points de score Lighthouse en 12 mois sans aucune modification intentionnelle, uniquement par accumulation de scripts tiers, d’assets non optimisés et de dette technique. Chaque outil marketing ajouté, chaque pixel de tracking, chaque image balancée sans compression grignote la performance.

Le code généré par IA est fonctionnel, mais rarement optimisé pour le long terme : pas de lazy loading systématique, bundles non splittés, images non compressées. Au départ, ça ne se voit pas — le site est léger. La dégradation est cumulative. Et avec l’arrivée d’INP (Interaction to Next Paint) comme Core Web Vital en 2024, ces lenteurs d’interaction pèsent désormais directement sur ton classement.

Surveiller la perf demande un monitoring continu (CrUX, Lighthouse CI). L’IA ne met pas ça en place toute seule et, surtout, elle ne “sait” pas que ton site était à 95 il y a six mois et qu’il est tombé à 60. Il n’y a pas de mémoire, pas de seuil d’alerte. On détaille tout l’enjeu dans Performance web : pourquoi ton site doit charger en moins de 2 secondes — et l’impact direct sur tes ventes dans l’article sur le taux de conversion.

6. Les sauvegardes qui n’existent pas

Symptôme : le pire de tous. Une mise à jour qui tourne mal, une erreur de manipulation, un piratage — et tu réalises qu’il n’existe aucune copie récupérable de ton site. Tout est à refaire.

C’est le point aveugle absolu des projets IA. Un site généré n’est quasiment jamais livré avec une stratégie de backup opérationnelle et documentée. Et contrairement à une croyance répandue, les plateformes d’hébergement cloud ne garantissent pas de sauvegarde automatique par défaut : c’est la responsabilité du propriétaire du site, comme le rappelle Backblaze.

Les chiffres font froid dans le dos : 60 % des PME qui perdent leurs données sans backup ferment dans les 6 mois. La règle 3-2-1 (3 copies, 2 supports différents, 1 hors site) reste le standard minimal — et elle est ignorée dans la grande majorité des projets vibe-codés ou no-code IA.

L’IA peut générer un script de backup si tu le lui demandes explicitement. Mais elle ne le planifie pas, ne vérifie pas que les sauvegardes tournent réellement, et ne teste jamais la restauration. Un backup qu’on n’a jamais testé n’est pas un backup, c’est une supposition.

Récapitulatif : symptôme, cause, et pourquoi l’IA ne rattrape pas

FAQ

Le takeaway

Les six pannes décrites ont un point commun : elles sont silencieuses jusqu’au moment où elles ne le sont plus. L’IA est un excellent outil de génération, un piètre gardien dans le temps — parce qu’elle n’a ni mémoire de l’état de ton site, ni seuil d’alerte, ni responsabilité.

Action concrète aujourd’hui : vérifie une seule chose, l’existence d’une sauvegarde récente et restaurée avec succès de ton site. Si tu ne peux pas répondre oui en cinq minutes, tu as déjà identifié le maillon le plus urgent. Le reste — dépendances, paiement, formulaires, perf — relève d’une maintenance active et structurée, exactement ce qu’un site livré “et puis débrouille-toi” n’inclut jamais.