Aller au contenu
Antoine Le LouëtDéveloppeur senior indépendant (Accueil)
← Revenir au Journal

Conseils16 min de lecture

Créer un site vitrine avec l’IA : accompagner chaque étape

Accompagner la création d’un site vitrine avec l’IA, du premier échange à la prise en main, et vérifier le résultat avant la mise en ligne.

L’IA propose une première page à partir du besoin. Le propriétaire et son accompagnant la relisent : les corrections repartent vers la proposition, la version validée avance vers les vérifications.
Schéma de principe : une proposition devient une version retenue après une validation explicite avec le propriétaire du site.

Commencer par ce que le visiteur doit pouvoir faire

Un particulier veut montrer ses photographies et être contacté pour une exposition. Une entreprise de rénovation souhaite présenter ses prestations et recevoir des demandes dans sa zone d’intervention. Tous deux demandent un site vitrine. Pourtant, leurs visiteurs ne cherchent pas les mêmes informations, et les décisions à prendre seront différentes.

Un site vitrine présente une personne, une activité ou une organisation. Il peut proposer un contact et renvoyer vers un service de réservation. Si le projet comprend un paiement, un espace client ou des documents confidentiels, il faut préciser ces usages et revoir le périmètre technique. Les obligations et les vérifications augmentent avec les fonctions ajoutées.

L’IA peut aider à structurer les pages, reformuler un texte et produire une première interface. France Num décrit la création de sites parmi les usages accessibles aux petites entreprises. Le guide de Wix sur la création avec un modèle de langage insiste aussi sur la préparation du projet et les ajustements après génération. Il présente le parcours d’un éditeur commercial ; ses promesses ne constituent pas une évaluation indépendante.

Je propose ici une méthode d’accompagnement, applicable à un projet personnel comme à une petite entreprise. Les situations décrites sont fictives. Le but est de rendre les choix compréhensibles pour la personne qui commande le site, jusqu’au moment où elle devra le modifier elle-même ou demander une intervention.

Répartir les décisions entre le propriétaire, l’accompagnant et l’IA

Le propriétaire connaît son activité et décide de ce qu’il souhaite rendre public. L’accompagnant traduit les besoins en pages, explique les compromis et vérifie le résultat. L’IA fournit des propositions dans ce cadre. Une réponse bien rédigée peut encore contenir un service inexistant, une photographie trompeuse ou un formulaire sans destinataire.

Pour un particulier, je commencerais par son degré d’aisance : veut-il apprendre en construisant le site avec quelqu’un, déléguer la réalisation, ou simplement faire relire une première version obtenue seul ? Pour une entreprise, il faut aussi désigner une personne qui arbitre. Des retours contradictoires entre direction et équipe commerciale risquent de multiplier les versions sans faire avancer le projet.

  • Le propriétaire valide les faits : coordonnées, prestations, prix affichés, références et autorisations de publication.
  • L’accompagnant présente les choix qui engagent la suite : outil, abonnements, modifications possibles et organisation de la maintenance.
  • L’IA reçoit une demande délimitée. Ses propositions sont relues avant leur intégration et confrontées aux informations disponibles.
  • À chaque étape, la décision retenue est consignée dans un document partagé. Une conversation avec l’IA ne suffit pas à retrouver ce qui a été accepté.

Je prévoirais des validations courtes sur des éléments visibles : un brief, un plan de pages, une page représentative, puis le site complet. Chaque validation ferme une question précise. Le client peut ainsi signaler une prestation mal décrite avant qu’elle soit répétée sur toutes les pages.

Écrire un brief que le client peut corriger

Le premier échange doit faire émerger une situation concrète. D’où vient le visiteur ? Que sait-il déjà ? Quelle hésitation l’empêche de contacter la personne ou l’entreprise ? Un portfolio envoyé après une rencontre n’a pas le même rôle qu’un site découvert en cherchant un artisan à proximité.

  • Objectif principal : recevoir une demande de devis, présenter un travail ou permettre de trouver une information fiable.
  • Public visé : les personnes concernées, leurs questions et les éléments qui les aideront à choisir.
  • Contenu disponible : textes existants, photographies, identité visuelle, références autorisées et informations encore manquantes.
  • Périmètre : pages attendues, langue, mode de contact et fonctions expressément reportées.
  • Contraintes : budget de création, dépenses récurrentes acceptables, échéance et temps que le propriétaire peut consacrer au projet.
  • Vie du site : qui modifie les textes, à quelle fréquence, et qui intervient si une fonction cesse de marcher.

Pour le photographe amateur de notre exemple, une première version pourrait regrouper une sélection de séries, une présentation et une adresse de contact dédiée. Pour l’entreprise de rénovation, elle pourrait expliquer les prestations, montrer des chantiers autorisés, préciser la zone d’intervention et proposer une demande de devis. Ces périmètres servent à discuter ; ils ne décrivent ni un devis réel ni un nombre de pages obligatoire.

L’IA peut transformer des notes anonymisées en questions de clarification. Je lui demanderais de relever les informations manquantes, puis de les distinguer des faits fournis. Le propriétaire corrige cette synthèse avant de passer à la maquette. Un manque reste indiqué comme tel, au lieu d’être comblé par une invention plausible.

Choisir l’outil en partant des futures modifications

La question qui départage souvent les solutions est simple : comment changera-t-on un horaire ou une photographie dans six mois ? Une démonstration de génération donne peu d’informations sur cette opération. Je proposerais de réaliser cette modification pendant l’essai, avec la personne qui s’en chargera ensuite.

  • Un constructeur visuel peut convenir lorsque le propriétaire veut modifier ses pages dans une interface. Vérifier sur l’offre envisagée le domaine personnalisé, les fonctions utiles, les limites de l’éditeur et les possibilités de récupération.
  • Un CMS, c’est-à-dire un outil de gestion de contenu, peut convenir à des publications régulières ou à plusieurs contributeurs. Prévoir son hébergement, ses mises à jour et la maintenance des extensions retenues.
  • Un site développé sur mesure peut répondre à une présentation particulière ou s’intégrer à un environnement existant. Pour quelques pages rarement modifiées, des pages statiques peuvent suffire. Définir comment les changements seront publiés et qui saura les prendre en charge.
Le besoin de modification oriente l’essai : modifier visuellement mène vers un éditeur, publier souvent vers un CMS, et confier les changements à un intervenant permet d’envisager des pages statiques. Des besoins mixtes imposent de comparer les compromis.
Repères de choix, sans classement des solutions : tester une modification réelle permet d’évaluer l’autonomie proposée. Plusieurs besoins peuvent coexister.

Des services comme Wix associent génération et édition visuelle. Cela ne permet pas de conclure qu’une offre particulière répond à tous les besoins. Les tarifs, les possibilités d’export et les intégrations évoluent : il faut les vérifier au moment du choix. Pour une solution produisant du code, demander une démonstration de récupération du projet et de reconstruction hors de la conversation initiale.

Le devis doit séparer la création des dépenses récurrentes : nom de domaine, hébergement ou abonnement, messagerie éventuelle, services de formulaire et suivi technique. Ajouter les coûts de génération s’ils sont facturés à l’usage. Un site construit avec l’IA n’a pas nécessairement besoin d’une IA en fonctionnement après sa livraison.

Je préciserais aussi les contenus attendus du client, les étapes de validation et la manière de chiffrer une demande supplémentaire. La date dépend notamment de la disponibilité des photographies et des retours. L’apparition rapide d’une maquette ne permet pas de promettre le même délai pour un site prêt à être exploité.

Rassembler les preuves avant de générer les textes et les images

Un texte générique parle facilement de qualité et de proximité. Pour présenter une activité, il faut savoir ce qu’elle propose réellement, à qui elle s’adresse et comment se passe un premier contact. Je demanderais au propriétaire de répondre avec ses mots aux questions que lui posent déjà ses visiteurs ou ses clients.

L’IA peut ensuite raccourcir une présentation, proposer des titres ou rendre une explication plus accessible. Chaque affirmation reste reliée à une information validée. Les années d’expérience, certifications, témoignages et noms de clients ne doivent jamais apparaître parce qu’ils rendent la page plus convaincante. Une référence sans autorisation peut être remplacée par une description anonymisée, après vérification de ce qu’elle permet encore d’identifier.

Pour un portfolio, les images sont souvent le contenu principal : il faut choisir celles que leur auteur souhaite diffuser et vérifier les droits nécessaires. Pour l’entreprise fictive de rénovation, une image générée ne doit pas passer pour un chantier réalisé. Une illustration d’ambiance peut être identifiée comme telle, mais elle ne remplace pas une preuve du travail effectué.

Je préparerais un dossier partagé avec une version validée des textes, les fichiers originaux et leurs conditions d’utilisation. Les documents transmis à un outil d’IA doivent être limités à ce qui est utile et autorisé. Une liste de clients, un devis nominatif ou des identifiants d’accès n’ont pas leur place dans une demande de maquette. Vérifier les conditions de traitement des données du service utilisé avant tout envoi.

Faire valider le parcours avant de décliner les pages

Le plan du site relie les questions des visiteurs aux informations qui y répondent. L’accueil présente l’activité et donne une direction. Une page de prestation peut ensuite préciser les cas pris en charge, les limites et le déroulement d’une demande. Les références fournissent des éléments vérifiables ; le contact indique comment poursuivre.

Une page unique peut suffire à un projet personnel simple. Des pages distinctes deviennent utiles lorsque les services ou les publics demandent des explications différentes. Je limiterais la première version aux contenus que le propriétaire peut relire et entretenir, plutôt que de générer d’emblée un blog et des dizaines de pages locales.

La première maquette doit contenir de vrais textes, même encore courts. Une belle composition remplie de phrases provisoires cache les problèmes de place et de compréhension. Je commencerais par une page représentative sur téléphone, puis je vérifierais sa déclinaison sur un écran large.

Pendant la relecture, demander à une personne qui découvre le projet d’expliquer ce qu’elle comprend et de chercher comment prendre contact. Observer où elle hésite fournit un retour plus exploitable que lui demander si elle trouve le site joli. Ses remarques aident à corriger le vocabulaire, l’ordre des informations et la visibilité des actions.

Donner à l’IA une demande précise et des limites explicites

Voici un exemple fictif de demande pour préparer une première page. Les informations entre crochets sont à fournir ou à laisser en attente. Cette consigne sert à obtenir une proposition à relire ; elle ne garantit pas la qualité du résultat.

Texte · exemple de brief pour l’IA
Prépare une proposition de page d’accueil pour un site vitrine.

Projet fictif : entreprise de rénovation intérieure.
Public : propriétaires cherchant un prestataire dans [zone validée].
Objectif : comprendre les prestations puis demander un devis.
Prestations confirmées : [liste fournie par le propriétaire].
Preuves autorisées : [photos et références validées].
Contact : [canal décidé avec le propriétaire].

Commence par relever les informations manquantes.
Propose ensuite l’ordre des sections et un premier texte court.
Indique ce que chaque section aide le visiteur à décider.
Prévois une lecture sur téléphone et des intitulés explicites.
N’invente aucun avis, prix, délai, label ou chiffre d’expérience.
Signale les éléments à compléter, sans les présenter comme acquis.
N’ajoute ni paiement, ni espace client, ni chatbot.
Attends la validation du plan avant de produire les autres pages.

Pour un particulier, on remplace l’activité commerciale par le projet personnel et les prestations par les travaux à présenter. L’objectif peut être de parcourir une sélection puis d’écrire à son auteur. Il faut aussi préciser les informations que la personne accepte de rendre publiques.

Les demandes suivantes gagnent à rester ciblées : raccourcir la présentation, rendre les intitulés plus compréhensibles ou améliorer une galerie sur mobile. Conserver une version connue avant une modification importante permet de comparer. Si une correction change aussi le menu et les couleurs sans que cela ait été demandé, l’accompagnant peut repérer cet élargissement et revenir au périmètre prévu.

Vérifier les fonctions derrière la maquette

Lorsque le parcours est validé, la réalisation peut avancer dans l’outil retenu. Si du code est généré, je prévoirais des modifications revues dans un dépôt et les vérifications adaptées avant leur intégration. Avec un constructeur visuel, utiliser les aperçus et les possibilités de restauration disponibles. Dans les deux cas, contrôler la version qui sera réellement publiée.

Le formulaire mérite une attention particulière. L’affichage d’un message de succès ne prouve pas que la demande arrive chez son destinataire. Il faut suivre un envoi fictif jusqu’à sa réception, puis vérifier ce que voit le visiteur lorsque le service refuse l’envoi. Une clé de service doit rester protégée côté serveur ; la cacher visuellement dans la page ne la rend pas confidentielle.

Un message fictif part du formulaire vers le service d’envoi puis vers la boîte de réception. Une réponse positive du service et la réception effective sont deux vérifications distinctes ; en cas d’échec, le visiteur doit voir un message utile.
Schéma de principe : vérifier la réception complète un contrôle du formulaire. Un accusé technique ne garantit ni la livraison en boîte principale ni la lecture par le destinataire.

Un formulaire public demande aussi une validation des champs côté serveur et une protection adaptée contre les envois abusifs. On peut décider de commencer avec une adresse de contact dédiée si cela répond au besoin. Ce choix simplifie certaines opérations, tout en laissant au propriétaire la gestion des messages et des courriers indésirables.

Pour une refonte, inventorier les anciennes adresses avant la bascule. Les pages utiles doivent être conservées ou redirigées vers leur équivalent. Le changement de domaine ou d’hébergement doit aussi préserver les réglages de messagerie nécessaires. Une modification du site ne devrait pas faire disparaître les demandes qui arrivaient déjà.

Travailler la visibilité et l’accessibilité sur le contenu réel

Pour être trouvé, le site doit d’abord décrire clairement ce qu’il présente. Les titres des pages, leurs adresses et les liens internes doivent aider à comprendre l’activité. Pour une entreprise locale, les coordonnées et la zone annoncée doivent être cohérentes avec la réalité. Éviter de produire des pages de villes où elle n’intervient pas.

Google Search Central indique que l’IA peut aider à rechercher et structurer un contenu. Générer de nombreuses pages sans valeur ajoutée peut en revanche relever de sa politique contre les contenus produits à grande échelle pour manipuler les résultats. Je privilégierais des réponses précises aux questions des visiteurs et des exemples que le propriétaire peut documenter. Aucune rédaction ni configuration technique ne garantit une position dans les moteurs.

L’accessibilité se prépare pendant la conception : titres hiérarchisés, contrastes suffisants, libellés de formulaire compréhensibles et alternatives pertinentes aux images. Une photographie informative demande une description adaptée à son rôle. Une image purement décorative peut recevoir une alternative vide. Le texte ne doit pas être enfermé dans une image pour obtenir une belle composition.

Les Easy Checks du W3C proposent des premiers contrôles, notamment au clavier et sur les formulaires. Ils ne constituent pas un audit complet de conformité. Je vérifierais aussi le site avec un texte agrandi et sur un téléphone réel. Une image trop lourde ou une animation encombrante peut gêner la consultation, même si la maquette paraît réussie sur l’écran de son créateur.

Adapter les informations légales et les données au projet

Un site personnel et un site professionnel demandent un examen de leur situation réelle. Service Public Entreprendre rappelle que les sites professionnels doivent afficher des mentions légales accessibles. Leur contenu dépend notamment du statut de l’éditeur. Les informations d’immatriculation, l’hébergeur et les coordonnées doivent venir de documents vérifiés. Un texte généré ne doit pas transformer une donnée manquante en information publique.

Pour le particulier de notre exemple, décider quelles coordonnées seront publiques, puis vérifier les obligations applicables à son cas. Le simple mot « personnel » ne suffit pas à trancher toutes les questions : la publication, l’usage des images et la collecte de messages doivent être examinés. Pour l’entreprise, les règles propres à l’activité ou à une vente éventuelle complètent ce travail.

Lorsqu’un formulaire collecte des données personnelles, la CNIL fournit des exemples pour informer les personnes. Prévoir notamment l’objectif de la collecte, les destinataires, la conservation et l’exercice des droits, avec une information adaptée au traitement réel. Demander uniquement les champs utiles. Une demande de contact et une inscription à une prospection commerciale ont des objectifs différents ; les réunir silencieusement crée une ambiguïté à corriger.

L’ajout d’une mesure d’audience, d’une vidéo intégrée ou d’une carte peut introduire des traceurs. D’après la CNIL, les traceurs soumis au consentement doivent attendre ce consentement ; certaines exemptions existent sous conditions. Un bandeau affiché par défaut ne prouve pas que les services sont effectivement bloqués. Examiner ce que le site charge et configurer le choix des visiteurs selon les outils retenus.

Faire une recette avec le propriétaire avant la mise en ligne

La recette consiste à vérifier ensemble que le site répond au brief. Je préparerais une liste courte de parcours à effectuer sur la version prête à publier. Les contrôles automatiques peuvent repérer des défauts techniques ; la relecture du propriétaire reste nécessaire pour confirmer le contenu et le fonctionnement attendu.

  1. Depuis un téléphone, identifier l’activité et trouver la prestation ou le travail recherché sans devoir deviner les intitulés.
  2. Ouvrir chaque page et contrôler les liens, les images et les coordonnées. Relire les faits et retirer tout contenu provisoire.
  3. Effectuer une demande fictive et en confirmer la réception. Essayer aussi un champ invalide et un échec d’envoi, sans transmettre de données réelles de client.
  4. Parcourir le menu et le contact au clavier, vérifier le focus visible, l’agrandissement du texte et les principaux contrastes.
  5. Contrôler le domaine, HTTPS et les titres de pages. Vérifier que l’environnement de test reste exclu de l’indexation et que le site public ne l’est pas par erreur.
  6. Vérifier les informations légales applicables et le comportement des services tiers, y compris avant tout choix de consentement.
  7. Faire réaliser une modification courante par son futur responsable, puis vérifier la procédure de sauvegarde ou de restauration adaptée à l’outil.

Chaque point bloquant doit avoir une correction ou une décision explicite de report avec ses conséquences. Je distinguerais les retouches de présentation d’un défaut qui empêche de contacter l’entreprise. La validation finale doit porter sur une version identifiée. Après la mise en ligne autorisée, refaire les contrôles essentiels sur le vrai domaine, car la configuration peut différer de l’aperçu.

Livrer les accès et organiser la suite

Le propriétaire doit maîtriser les comptes qui assurent la continuité du site : domaine, hébergement ou plateforme, messagerie et éventuels services de contact. Je prévoirais des comptes à son nom ou à celui de l’entreprise, avec des invitations adaptées pour l’intervenant, une authentification renforcée quand elle est disponible et des moyens de récupération conservés par le propriétaire.

La livraison comprend les contenus et les fichiers récupérables, les dépenses récurrentes et leurs échéances, ainsi qu’un mode d’emploi pour les modifications courantes. Pour du code sur mesure, ajouter le dépôt, les instructions nécessaires à sa reconstruction et la configuration des services sans exposer les secrets. Pour une plateforme, documenter ses limites de récupération et ce qu’un départ demanderait de refaire.

Une courte prise en main peut porter sur une tâche réelle : remplacer une image et publier une correction. Le propriétaire doit savoir où demander de l’aide et ce que couvre l’accompagnement après livraison. Les mises à jour, la vérification du contact et la correction d’un incident demandent un responsable, même si le contenu change rarement.

Après une période convenue, examiner les demandes reçues et les difficultés observées. Une demande qualifiée ou une question récurrente donne une piste d’amélioration plus concrète qu’un compteur de visites isolé. S’il y a peu de trafic, compléter avec quelques échanges avec les visiteurs plutôt que tirer des conclusions de pourcentages fragiles.

Pour préparer un premier échange, rassemblez une présentation de votre projet, les contenus dont vous disposez et un exemple de modification que vous voudriez pouvoir faire seul. Ajoutez votre budget et votre échéance, même approximatifs. Ces éléments permettront de choisir un périmètre et une manière de travailler avant de lancer la première génération.

Sources et liens utiles

Partager sur LinkedIn (nouvel onglet)

Poursuivre la lecture
Tous les articles de la catégorie →