Publier un site créé avec l’IA : un cas pratique vérifié

Publié le 14 octobre 2026.

Le projet : rendre un site accessible et vérifiable

Ce cas porte sur ia-money-club.com : un domaine acheté chez Namecheap et un site statique hébergé sur Netlify. Il documente les contrôles du 14 octobre 2026, après la première série de corrections SEO. À cette étape, douze pages étaient publiées. Le présent guide a été ajouté ensuite.

Le résultat observé est une mise en ligne fonctionnelle et des défauts précis corrigés. Ce cas ne démontre ni une vente, ni un revenu, ni une première place sur Google. Il n’est pas attribué à un cours suivi ou à la réussite d’un membre.

1. Vérifier le domaine, HTTPS et les variantes d’adresse

Le domaine fournit l’adresse, l’hébergement sert les fichiers et HTTPS protège leur transfert. Acheter un domaine ne publie pas les pages à lui seul. Sur ce projet, le contrôle a porté sur le vrai domaine et sur une page intérieure, pour éviter de valider uniquement l’accueil.

Résultat : les douze pages répondaient en HTTPS avec le statut 200. Les variantes HTTP et www conduisaient au domaine principal. Le sous-domaine public Netlify a également été redirigé vers celui-ci. Un paramètre ajouté à l’URL a été conservé pendant le contrôle des redirections des fichiers index.html.

Pour ton projet, note l’adresse de départ, le statut reçu et l’adresse finale. Une redirection vers l’accueil n’est pas correcte si le lecteur demandait une page intérieure. La documentation Netlify sur les redirections explique les statuts et les règles utilisés.

2. Corriger un lien dont le résultat ne correspondait pas au texte

Avant : le bouton « Explorer les 8 modules » rechargeait le haut de la page Formation. Après : il pointe vers /formation/#premier-client et place le lecteur au début des modules. Le clic a été vérifié dans un navigateur, y compris sur téléphone.

Ce contrôle illustre une méthode simple : annoncer l’action attendue, cliquer, puis comparer l’arrivée. Elle s’applique aussi aux boutons de contact, aux formulaires et aux vidéos.

3. Comparer le HTML et ce que le navigateur affiche

Le serveur fournissait la bonne formation à l’adresse /formation/index.html, mais le script affichait ensuite l’accueil. Un simple contrôle du code reçu ne suffisait donc pas.

La correction associe les variantes connues à la bonne page et les redirige vers l’adresse canonique. Les douze variantes index.html ont été testées : elles répondaient en 301 vers leur page correspondante. Les URL inconnues restent des pages introuvables, sans être transformées en accueil.

À reproduire : comparer le titre, le contenu principal et la canonical avant et après le rendu JavaScript. Google décrit cette distinction dans sa documentation SEO JavaScript.

4. Lire le contenu sur téléphone

L’article sur les erreurs de livraison a été contrôlé à une largeur de 390 pixels. Le texte restait dans la largeur de l’écran, sans défilement horizontal. La capture ci-dessous montre ce contrôle réel, pas une maquette.

Ce test ne prouve pas que tous les appareils offrent le même confort. Pour livrer un site, parcours aussi le menu, les éléments fixes, les commandes vidéo et les liens au clavier. La checklist des cinq erreurs avant livraison complète ces vérifications.

5. Distinguer publication, découverte et indexation

Le sitemap des douze pages avait été accepté dans Search Console. Pourtant, l’inspection de l’accueil consultée le 14 octobre indiquait encore « Détectée, actuellement non indexée ». Le site était accessible et Google connaissait son adresse ; son apparition dans les résultats n’était pas confirmée.

Une fois une page indexée, sa visibilité sur une recherche précise reste une autre question. Garde ces étapes séparées dans ton compte rendu : accessible, découverte, indexée, puis impressions et clics observés. Google précise qu’une demande d’exploration ne garantit pas l’indexation.

6. Conserver les conditions d’un test de vitesse

Le rapport PageSpeed consulté pendant l’audit affichait 90 en performance mobile, avec un LCP d’environ 2,95 secondes, et 100 en performance sur ordinateur. Ce sont les valeurs d’un test de laboratoire de cette version du site, pas des mesures des visiteurs ni une garantie pour la version actuelle.

Le score SEO automatique de 100 ne signifiait pas que le site était indexé ou bien classé. Pour une optimisation suivante, il faudra mesurer de nouveau dans des conditions comparables et isoler ce qui retarde l’affichage principal. Consulter le rapport de l’audit.

Une checklist de publication réutilisable

• Ouvrir le domaine principal en HTTPS.
• Tester les variantes et une page intérieure.
• Vérifier qu’une adresse inconnue renvoie une vraie réponse 404.
• Contrôler les boutons et leurs destinations.
• Comparer HTML et rendu après JavaScript.
• Parcourir les pages sur téléphone et au clavier.
• Vérifier titres, canonicals, robots et sitemap.
• Noter le statut exact dans Search Console et sa date.
• Conserver les mesures, les limites et les corrections à poursuivre.

Télécharger la checklist de publication au format texte. Chaque point doit être vérifié sur ton propre projet ; cette liste n’effectue pas un audit automatique.

Méthode et limites du cas

Ce guide a été préparé avec une assistance IA à partir de contrôles HTTP, de tests de construction et de vérifications dans le navigateur. Les captures proviennent du site public ; aucune information privée de compte n’est reproduite. Les constats décrivent la version et la date étudiées. L’auteur du programme IA Money Club n’est pas présenté comme l’auteur de ces tests.

Pour situer la création de sites parmi les autres sujets du club, consulte le module consacré au premier client. Pour préparer une proposition après la démonstration, lis la méthode pour construire une première offre de service IA.