Investir et choisir
Peut-on faire reprendre un site créé avec l’IA par un professionnel sans repartir de zéro ?
Un professionnel peut souvent reprendre une partie d’un site créé avec l’IA, mais il doit d’abord vérifier ce qui existe réellement et ce qui peut être maintenu. La bonne décision n’est ni de tout conserver par économie, ni de tout reconstruire par principe. Elle repose sur les usages, les accès, la qualité du code et les risques observés.
L'essentiel.
- Une apparence terminée ne prouve pas que les formulaires, les données et les permissions fonctionnent correctement.
- Séparez ce qui est utilisable, ce qui doit être corrigé et ce qui exige une autre architecture.
- Demandez un diagnostic documenté et un plan de reprise avant un devis de refonte globale.
Un prototype peut contenir des actifs précieux
Les textes, la hiérarchie des pages, certaines interactions ou une première direction visuelle peuvent déjà avoir de la valeur. Le travail réalisé vous a peut-être aussi permis de clarifier votre offre et d’identifier ce que vous ne voulez pas.
Cette matière ne doit pas être écartée simplement parce qu’elle a été produite avec un outil génératif. Inversement, le temps déjà investi ne suffit pas à justifier la conservation d’une architecture inadaptée.
L’origine du code ne tranche pas le diagnostic. Un site généré peut être correctement structuré ; un site écrit manuellement peut présenter des défauts. Il faut examiner le résultat et les conditions de reprise.
Préparez les éléments à transmettre
Rassemblez les accès au projet, au dépôt de code lorsqu’il existe, à l’hébergement, au domaine, aux données et aux services connectés. Transmettez les secrets par un moyen sécurisé, jamais dans un document public ou une capture destinée au portfolio.
Ajoutez la liste des fonctions attendues, les problèmes connus et les contraintes à conserver. Une démonstration vidéo peut montrer un comportement, mais elle ne remplace pas l’accès nécessaire pour vérifier son fonctionnement.
| Dimension | Question de reprise |
|---|---|
| Contenus | Sont-ils exacts, autorisés et récupérables ? |
| Interface | Les parcours restent-ils utilisables sur téléphone ? |
| Code et dépendances | Le projet peut-il être installé et construit de façon reproductible ? |
| Données et droits | Qui peut accéder à quoi, et où les contrôles sont-ils appliqués ? |
| Exploitation | Qui saura publier, surveiller et corriger ? |
Exemple : un site de présentation avec formulaire
Une entreprise fictive a créé une vitrine convaincante et un formulaire qui affiche « Message envoyé ». L’examen révèle que le message n’est pas transmis au destinataire prévu. Le défaut est important, mais il ne prouve pas que tous les écrans doivent être refaits.
Le professionnel peut conserver les contenus utiles, corriger le traitement du formulaire et vérifier les confirmations. Il peut ensuite améliorer la navigation et les médias sans remplacer toute l’architecture.
Dans un autre scénario, le site comporte un espace client dont les données privées sont insuffisamment isolées. La priorité devient la protection des informations et l’examen de l’accès aux données. Une amélioration graphique ne constitue pas une réponse à ce risque.
Demandez un diagnostic à plusieurs niveaux
Le diagnostic doit distinguer les défauts bloquants, les fragilités de maintenance et les améliorations souhaitables. Chaque observation doit être accompagnée d’un exemple ou d’un test, pas seulement d’un jugement général sur la qualité du projet.
Pour la sécurité, le périmètre doit être défini avec une compétence adaptée. OWASP ASVS fournit un cadre d’exigences et de vérifications applicatives ; mentionner ce référentiel ne signifie pas que le site a été audité ni qu’il est exempt de vulnérabilités. OWASP — Application Security Verification Standard
L’article sur les espaces clients explique pourquoi l’authentification visible et les permissions réelles sont deux sujets différents. Un bouton masqué n’est pas, à lui seul, un contrôle d’accès.
Classez les décisions : conserver, corriger, reconstruire
Pour chaque partie, demandez une recommandation justifiée. Conserver un composant stable peut réduire le travail. Corriger une fonction isolée peut préserver l’ensemble. Reconstruire un périmètre peut être préférable lorsque les dépendances ou les règles ne permettent pas une évolution fiable.
Évitez les devis qui transforment toutes les inconnues en refonte totale sans explication. Méfiez-vous aussi d’une promesse de correction rapide si le prestataire n’a pas pu examiner les données et les intégrations.
La comparaison doit inclure la maintenance après reprise. Une solution un peu moins coûteuse au départ peut laisser une organisation difficile à faire évoluer. L’objectif est un fonctionnement compréhensible, pas seulement une nouvelle version qui démarre une fois.
Stabilisez avant d’enrichir
Préservez une copie des éléments existants, définissez un environnement de test et documentez les changements. Rejouez les parcours essentiels : navigation, recherche, formulaire, connexion, paiement si présent et reprise après erreur.
Le plan peut ensuite distinguer une remise en état, une amélioration de l’expérience et de nouvelles fonctions. Cette progression évite de mélanger correction urgente et ambition créative dans une seule opération opaque.
Notre article sur le rôle d’un studio face aux outils IA traite le choix initial. Ici, le travail commence après la première création. LVX peut en reprendre le cadrage, les contenus et le design, avec les compétences techniques nécessaires au périmètre réellement constaté.
Faites cadrer avec LVX la reprise de votre site pour conserver sa valeur réelle et traiter les fragilités avant d’ajouter de nouvelles fonctions.
