En quelques jours seulement, le site que vous lisez est passé d’un prototype Claude Design à un site ASP.NET Core en ligne et prérendu sur IIS. Il obtient 100 en SEO et 91 en performance mobile dans Lighthouse. Personne dans notre équipe n’a tapé une ligne de code. Chaque ligne de C#, de MSBuild et de Node a été écrite par Claude Cowork.

C’est le guide que nous aurions aimé avoir au départ. Si vos sites tournent sur Windows, IIS et .NET et que vous voulez utiliser Claude pour créer un site rapide et bien référencé, voici comment nous avons procédé, ce qui a mal tourné et ce que nous referions.

Cet article explique comment nous avons fait. Pour savoir pourquoi nous avons construit notre site ainsi, lisez Les cordonniers sont les plus mal chaussés.

À retenir

Pas besoin de coder, mais il faut connaître le terrain

Claude a écrit chaque ligne de code. Notre rôle était de décrire ce que nous voulions, de relire les résultats et de les tester. Cela ne fonctionne que si vous connaissez assez bien les outils concernés, comme Visual Studio, IIS, Cloudflare, le DNS, l’envoi d’e-mails et Google Search Console, pour repérer ce qui cloche. Voyez-le comme diriger le chantier plutôt que le réaliser.

Deux Claude, deux couloirs

La décision la plus utile a été de répartir le travail entre deux outils et de garder chacun dans son couloir.

La stack

Nous sommes partis d’un projet ASP.NET Core vide dont le seul code affichait « Hello World! », et avons copié l’export Claude Design dans wwwroot.

Étape 1 : servir le site statique

La première correction était simple. L’application ne servait pas wwwroot, donc chaque visite affichait « Hello World! ». Claude Cowork a activé les fichiers statiques pour que l’index.html de chaque dossier se charge à une adresse propre comme /work/alliance-wine/, réglé un cache sensé, masqué les fichiers de travail comme les notes de design et les scripts de build, et ajouté une redirection HTTPS pour la production.

Étape 2 : un formulaire de contact qui fonctionne

Claude Design a défini le formulaire et rédigé un court contrat qui le décrit. Claude Cowork a construit le côté serveur en conséquence.

Étape 3 : une vraie page 404 et des redirections

Les pages manquantes affichent désormais notre page 404 avec un vrai statut 404, pour que les moteurs de recherche n’indexent pas les liens cassés. Les anciennes adresses du site précédent redirigent définitivement vers leurs nouvelles pages, et ajouter une redirection tient en une ligne dans une liste.

Étape 4 : le prérendu pour le SEO

C’était l’étape la plus importante. Les pages Claude Design sont des modèles remplis par JavaScript dans le navigateur. Google s’en sort, mais Bing, les aperçus LinkedIn, les robots d’IA comme ChatGPT, Perplexity et Claude, et la plupart des outils SEO voyaient des espaces réservés bruts entre accolades au lieu de titres et de texte.

Étape 5 : la publication en un clic

Mettre à jour le site tient désormais en deux actions :

Les étapes supplémentaires s’exécutent automatiquement à chaque build Release, donc le débogage normal reste rapide. La seule configuration ponctuelle consiste à installer Node.js dans l’environnement de développement et à laisser la première publication télécharger le navigateur de Playwright.

Étape 5a : l’alternative en équipe, Git et un runner

Publier depuis Visual Studio convient à une petite équipe. Si plusieurs personnes travaillent sur le site, publiez plutôt vers un dépôt Git et installez un runner sur votre serveur, comme un runner auto-hébergé GitHub Actions ou GitLab. À chaque envoi de modifications, le runner compile, prérend et déploie le site automatiquement, donc tout le monde travaille sur la même source et chaque version est tracée.

Étape 6 : ajuster avec Lighthouse

Nous avons lancé Lighthouse dans une fenêtre de navigation privée et collé le rapport dans les deux outils. Claude Design a corrigé le côté contenu : la langue de la page, un H1 en page d’accueil et la taille des images. Claude Cowork a corrigé le côté serveur : cache longue durée avec noms de fichiers versionnés, script principal non bloquant, React servi depuis notre propre serveur, Google Tag Manager chargé après la page, et scripts minifiés à environ la moitié de leur taille d’origine.

Conseils pour faire de même

Ce que cela signifie pour nos clients

Ce site est volontairement simple : peu de pages, modifiées par ceux qui l’ont construit. Pour les clients qui ont besoin d’éditeurs, de workflows et d’intégrations, Umbraco reste la bonne réponse. Mais la même approche, avec l’IA pour le travail de routine et des personnes expérimentées qui relisent chaque modification, s’applique désormais aussi à nos projets clients. C’est plus rapide, moins cher, et cela laisse à nos développeurs plus de temps pour les problèmes qui ont besoin d’eux.

Si vous souhaitez de l’aide pour créer quelque chose de similaire sur votre propre environnement .NET et IIS, contactez-nous.