La checklist indispensable pour obtenir un site web propre, sécurisé et optimisé SEO avec Claude Code ou Codex

Tu as envie de créer un site web ou une petite web app avec Claude Code, Codex ou Kimi Code. Tu décris ton idée, l’agent écrit les fichiers, corrige deux erreurs et te sort une interface qui a franchement bonne mine. À ce moment-là, le réflexe est simple : mettre en ligne et passer à la suite.

Sauf qu’un site peut être joli, fonctionner pendant ta démo et rester très loin d’être prêt. Une clé secrète peut se retrouver dans le navigateur. Le formulaire peut accepter n’importe quoi. Toutes les pages peuvent avoir le même titre. La sauvegarde automatique peut exister uniquement dans ta tête. Rien de tout ça ne saute aux yeux sur une belle page d’accueil.

Ce n’est pas une raison pour laisser tomber les agents de code. Au contraire. Ils sont très bons pour inspecter un projet, retrouver les fichiers concernés, appliquer des corrections et lancer des tests. Mais il faut leur donner les bons critères. Si tu demandes seulement « crée-moi un site propre », chacun mettra ce qu’il veut derrière le mot propre.

J’ai donc regroupé ici 40 points concrets à faire vérifier par ton agent IA. Les 20 premiers concernent surtout la sécurité d’une web app. Les 20 suivants couvrent le SEO, la conversion et la confiance sur les pages publiques. Tu peux utiliser l’ensemble sur un projet complet ou ne garder que les parties qui correspondent vraiment à ton site.

Pourquoi ton agent IA ne pense pas forcément à tout

Un agent de code travaille à partir de ce que tu lui demandes et de ce qu’il trouve dans le dépôt. Si ton brief parle d’une connexion par email et mot de passe, il va construire une connexion. Il ne va pas forcément ajouter tout seul une limitation des tentatives, une expiration de session, une confirmation par email et des tests pour vérifier qu’un utilisateur ne peut pas lire les données d’un autre.

Ce n’est pas qu’il ignore ces sujets. Ils ne faisaient simplement pas partie de la définition du travail terminé.

Le même problème existe côté SEO. Tu peux demander une page pour chacun de tes services et obtenir dix pages très propres visuellement. Si tu n’as rien précisé, elles peuvent partager le même <title>, la même méta-description et la même image de partage. Pour le visiteur, ça ressemble à un site fini. Pour Google, ça ressemble surtout à dix pages difficiles à distinguer.

La checklist sert donc de filet. Elle rappelle les contrôles invisibles et oblige l’agent à te montrer ce qu’il a réellement vérifié. Le mot important ici, c’est « montrer ». Un « tout est sécurisé » sans fichier, sans test et sans résultat observable ne vaut pas grand-chose.

Comment donner cette checklist à Claude Code, Codex ou Kimi Code

Évite de coller les 40 points au milieu d’une conversation déjà longue en demandant « vérifie tout ». Tu risques de recevoir une réponse rapide, très sûre d’elle, avec quelques cases cochées un peu généreusement.

Le plus simple est d’enregistrer la liste dans ton projet, par exemple dans docs/release-checklist.md. Ensuite, ajoute une consigne courte dans CLAUDE.md pour Claude Code ou dans AGENTS.md pour Codex et Kimi Code. La documentation de Claude Code, celle de Codex sur AGENTS.md et celle de Kimi Code décrivent ce principe d’instructions conservées dans le dépôt.

Voici une règle suffisante :

## Vérification avant mise en production

- Lire `docs/release-checklist.md` avant toute livraison.
- Commencer par un audit en lecture seule.
- Pour chaque point, donner un statut et une preuve vérifiable.
- Ne pas modifier les secrets, la base de production ou l’hébergement sans accord.

Si tu veux construire un fichier d’instructions plus complet sans le transformer en roman, j’ai détaillé la méthode dans le guide sur le CLAUDE.md d’un projet.

Demande ensuite quatre réponses possibles pour chaque contrôle :

• conforme, avec le fichier, la configuration ou le test qui le prouve ;
• non conforme, avec le risque et la correction proposée ;
• non applicable, avec une vraie raison ;
• à vérifier manuellement, si l’information se trouve chez l’hébergeur, dans Google Analytics ou dans un autre service externe.

Le statut « non applicable » est utile. Un site vitrine sans compte utilisateur n’a pas besoin de sessions ni de RLS. À l’inverse, dès que tu ajoutes un espace client, un upload ou un webhook, de nouveaux contrôles deviennent nécessaires. Ce petit schéma reste dans l’article parce qu’il permet de choisir ces contrôles en quelques secondes, sans relire les 40 lignes au hasard.

Une web app avec une page d’accueil publique suivra plusieurs branches. C’est normal. La sécurité et le SEO ne vivent pas dans deux mondes séparés dès que ton produit possède à la fois des comptes et des pages visibles sur Google.

Checklist sécurité d’une web app créée avec un agent IA

Cette première moitié couvre ce qui peut exposer tes secrets, tes comptes ou tes données. Certains points se corrigent dans le code. D’autres demandent un réglage sur la plateforme de déploiement. Ton agent doit faire la différence au lieu de deviner.

Les secrets et la configuration

1. Les clés API sont stockées dans un fichier .env. Demande à l’agent de rechercher les clés, les jetons et les mots de passe écrits directement dans le code. En local, ils vont dans les variables d’environnement. En production, ils doivent être enregistrés dans le gestionnaire de secrets ou les réglages de l’hébergeur.

2. Le .env est présent dans .gitignore. Vérifier le fichier actuel ne suffit pas. Si une clé a déjà été envoyée sur GitHub, elle reste compromise même après sa suppression. L’agent doit chercher sa présence dans l’historique sans afficher sa valeur. Si elle a fuité, tu la révoques et tu en crées une nouvelle.

Un fichier .env.example peut rester dans le dépôt pour documenter les variables attendues :

DATABASE_URL=
EMAIL_PROVIDER_API_KEY=
WEBHOOK_SIGNING_SECRET=

3. Seule la clé publique arrive côté client. Une variable préfixée par PUBLIC, NEXT_PUBLIC ou VITE peut être intégrée au JavaScript envoyé au navigateur. C’est prévu pour certaines clés publiques, jamais pour une clé d’administration, un secret de paiement ou une clé de service. Demande à l’agent d’inspecter aussi le bundle de production, pas uniquement les fichiers sources.

La connexion et les droits

4. La page de connexion possède un rate limiting. Désactiver le bouton après trois clics ne protège rien, puisqu’un script peut appeler directement l’API. La limite doit être appliquée côté serveur. L’agent doit préciser le nombre de tentatives, la durée du blocage et la façon dont il identifie la source des requêtes.

5. Les mots de passe sont hachés et jamais lisibles. Si tu utilises un service d’authentification, le stockage doit lui être délégué. Si le projet gère les mots de passe lui-même, demande quel algorithme est utilisé et avec quels paramètres. La fiche OWASP sur le stockage des mots de passe détaille les fonctions adaptées comme Argon2id, scrypt, bcrypt ou PBKDF2 selon le contexte.

6. Les droits sont contrôlés côté serveur. Masquer le bouton « Supprimer » dans le navigateur ne retire pas le droit de supprimer. Pour chaque route sensible, l’API doit vérifier qui fait la demande et si cette personne possède la ressource. Fais tester le cas le plus parlant : l’utilisateur A tente d’ouvrir ou de modifier les données de l’utilisateur B.

7. La RLS est activée lorsque la base la propose. Sur Supabase, par exemple, la Row Level Security permet de limiter l’accès directement au niveau des lignes. Demande les politiques appliquées à SELECT, INSERT, UPDATE et DELETE, puis des tests avec un visiteur, le propriétaire et un autre compte. La documentation Supabase sur la RLS donne les bases à contrôler.

8. Les sessions expirent. L’agent doit retrouver la durée maximale, l’expiration après inactivité et la révocation après un changement de mot de passe. Les cookies de session doivent aussi utiliser les attributs adaptés, notamment Secure et HttpOnly lorsque l’architecture le permet. Une session éternelle sur un ordinateur partagé, c’est une porte qu’on a oublié de refermer.

9. Le formulaire de connexion affiche un seul message d’erreur. Utilise « Email ou mot de passe incorrect » que l’adresse existe ou non. Un message différent permettrait de tester une liste d’emails et de découvrir les comptes inscrits. Les logs internes peuvent garder une cause plus précise, mais elle ne doit pas être renvoyée au navigateur.

10. L’inscription demande une confirmation par email. L’agent doit vérifier que le lien expire, qu’il ne fonctionne qu’une fois et que le renvoi du message est limité. Il doit aussi contrôler ce qu’un compte non confirmé peut faire. La confirmation prouve que la personne reçoit les emails à cette adresse, rien de plus.

Ces points se tiennent. Le mot de passe aide à reconnaître l’utilisateur, la session conserve cette reconnaissance et les autorisations décident ce qu’il a le droit de faire. Si l’une des trois couches manque, les deux autres ne rattrapent pas le trou.

Les formulaires et les fichiers

11. Tout ce que l’utilisateur saisit est validé côté serveur. Les champs obligatoires dans le navigateur améliorent l’expérience, mais ils se contournent facilement. Avant la base, vérifie le type, la longueur, le format et les valeurs autorisées. L’identifiant du propriétaire doit venir de la session quand c’est possible, pas d’un champ caché que l’utilisateur peut changer.

12. Les fichiers uploadés ont une taille maximale. La limite doit exister côté serveur ou dans le stockage. Demande aussi à l’agent de relever les limites du framework, du proxy et de l’hébergeur. Si ton application accepte 10 Mo mais que le proxy coupe à 2 Mo, c’est lui qui aura le dernier mot.

13. Le type réel des fichiers est vérifié. Renommer un exécutable en photo.jpg ne doit pas suffire. L’agent doit contrôler les extensions autorisées, le type détecté et, pour les usages sensibles, la signature du fichier. La checklist OWASP sur l’upload recommande aussi de renommer les fichiers et de les stocker hors de la racine publique.

Pour ces trois points, demande des tests qui échouent volontairement : texte trop long, fichier trop lourd, extension falsifiée et requête envoyée sans passer par le formulaire. C’est beaucoup plus utile qu’un regard rapide sur le composant React.

La production et les services externes

14. HTTPS est actif partout. Il faut tester le vrai domaine, sa variante avec ou sans www et les redirections. Les ressources appelées par la page doivent aussi utiliser HTTPS. Ce contrôle dépend souvent de l’hébergeur, donc l’agent peut devoir le classer « à vérifier manuellement » tant que le site n’est pas déployé.

15. Le CORS est configuré pour les bonnes origines. Demande la liste exacte des domaines, méthodes et en-têtes autorisés en développement et en production. Mettre * pour faire disparaître une erreur est tentant, mais ce n’est pas un réglage sérieux pour une API privée. Et même bien configuré, le CORS ne remplace jamais l’authentification.

16. Les erreurs détaillées sont coupées en production. Une trace complète, une requête SQL ou un chemin local aide à déboguer. Ils n’ont rien à faire sur l’écran d’un visiteur. L’interface affiche un message compréhensible et un identifiant de suivi. Le détail reste dans des logs protégés.

17. Les console.log et les logs restent sobres. Demande une recherche des mots de passe, jetons, cookies, clés API, corps de formulaire et objets de session affichés dans les journaux. Ils doivent être supprimés ou masqués. Garde tout de même les erreurs utiles et les opérations sensibles. Un log propre sert à comprendre un problème, pas à recopier toute la vie de l’utilisateur.

18. Les webhooks sont protégés par une signature. Un endpoint public ne doit pas accepter une requête simplement parce que son JSON ressemble à celui de Stripe, GitHub ou ton outil d’emailing. L’agent doit vérifier la signature selon la documentation du fournisseur, contrôler l’âge de l’événement et éviter de traiter deux fois le même identifiant.

19. Les dépendances sont à jour. Demande d’abord un inventaire des vulnérabilités connues et des paquets obsolètes. Évite la consigne « mets tout à jour » sans limite : une montée de version majeure peut casser le projet. Fais corriger par petits lots, avec les tests et le build après chaque lot.

20. La base de données est sauvegardée automatiquement. La fréquence, la durée de conservation et l’emplacement des sauvegardes vivent souvent hors du dépôt. L’agent peut vérifier les scripts et préparer la procédure. La vraie preuve reste un test de restauration dans un environnement isolé. Une sauvegarde qu’on n’a jamais essayé de restaurer, c’est surtout un pari.

Avec ces 20 contrôles, tu as traité la partie la moins visible de la web app. Il reste maintenant ce que les visiteurs et les moteurs de recherche vont réellement rencontrer sur les pages publiques.

Checklist SEO et conversion d’un site créé avec un agent IA

Ici, ne demande pas seulement à l’agent de retrouver un composant SEO.tsx. Fais-lui inspecter le HTML généré pour chaque page importante. Un composant peut être impeccable et recevoir exactement le même texte partout.

Les pages que Google doit comprendre

21. Chaque page possède un titre unique. L’agent doit dresser la liste des URL avec leur balise <title> et signaler les doublons, les titres vides ou trop génériques. Le guide de Google sur les liens de titre recommande des titres descriptifs, concis et propres à chaque page.

22. Chaque page stratégique a sa propre méta-description. Elle doit résumer la page, pas recopier la même promesse sur tout le site. Google peut choisir un autre extrait dans le contenu, donc ne demande pas une garantie impossible. Demande plutôt à l’agent de repérer les descriptions absentes, dupliquées ou sans rapport avec la page.

23. Le fichier robots.txt autorise les bonnes pages. Une règle de préproduction oubliée peut bloquer tout le site. L’agent doit lire le fichier réellement servi, vérifier le lien vers le sitemap et repérer les dossiers interdits par erreur. robots.txt ne protège pas une donnée privée. Une page sensible a besoin d’une authentification, pas d’une consigne polie adressée aux robots.

24. Le fil d’Ariane suit l’arborescence du site. Il aide le visiteur à revenir d’une page précise vers une catégorie plus large. Sur un site avec plusieurs niveaux, l’agent peut aussi ajouter les données structurées BreadcrumbList et les tester avec les outils Google.

25. Les images de partage social sont présentes. Vérifie og:title, og:description, og:image et les métadonnées équivalentes utiles au projet. L’image doit être accessible avec une URL absolue. Teste plusieurs types de pages, car une belle image globale peut cacher l’absence d’une image adaptée aux articles ou aux études de cas.

26. Les images ont une balise alt utile. L’agent peut retrouver les images sans texte alternatif. Il faut ensuite relire leur description. Une photo informative mérite un texte qui explique ce qu’elle montre. Une décoration peut avoir un alt vide pour ne pas encombrer les lecteurs d’écran.

27. Les pages importantes reçoivent des liens internes. Demande les pages sans aucun lien entrant, les liens cassés et les ancres trop vagues comme « cliquez ici ». Le maillage doit suivre le chemin naturel du lecteur. Si une personne termine un article sur Claude Code, un lien vers la comparaison entre vibe coding et no-code a du sens. Dix liens posés au hasard pour faire plaisir à Google, beaucoup moins.

28. Le schéma Google Business correspond à l’activité réelle. Pour une entreprise locale, les données structurées LocalBusiness peuvent reprendre le nom, l’adresse, le téléphone et les horaires visibles sur la page. L’agent doit vérifier que les informations concordent. Il ne doit jamais inventer une note, une zone desservie ou des horaires. La documentation Google sur LocalBusiness donne les propriétés à utiliser.

29. La FAQ répond à de vraies questions. Ton agent peut créer l’accordéon et les données structurées. C’est à toi de fournir les objections et les questions que les clients posent réellement : délais, prix, déroulement, zone d’intervention ou conditions. Une FAQ inventée uniquement pour placer des mots-clés se lit exactement comme une FAQ inventée pour placer des mots-clés.

30. La page 404 est personnalisée et renvoie bien le statut 404. Elle doit expliquer ce qui s’est passé, garder la navigation et proposer une sortie utile. Demande à l’agent de tester une URL inexistante sur le site déployé. Une jolie page d’erreur renvoyée avec 200 OK reste une fausse 404.

Ces dix premiers points aident les moteurs à lire le site et les visiteurs à s’y repérer. Une fois la bonne personne arrivée sur la bonne page, encore faut-il lui donner une suite claire.

Les éléments qui transforment une visite en action

31. Le formulaire mène vers une page de remerciement. La page confirme que la demande est partie et annonce la prochaine étape. Elle permet aussi de mesurer une conversion proprement. Si elle n’a aucun intérêt dans Google, l’agent peut la passer en noindex.

32. Le CTA peut rester visible sur mobile. Sur une longue page de service, un bouton sticky évite de remonter tout en haut pour demander un devis. Il ne doit pas cacher le contenu, le bandeau de consentement ou les commandes du téléphone. Ce point reste conditionnel : sur une page courte, un bouton collé à l’écran peut surtout devenir agaçant.

33. Une activité locale propose Google Maps ou un lien d’itinéraire. Le lien vers l’itinéraire suffit souvent et charge moins de ressources qu’une carte intégrée. Si tu choisis l’embed, demande à l’agent de vérifier la performance, la confidentialité et la cohérence entre l’adresse affichée, la carte et les données LocalBusiness.

34. Le CTA principal est clair et visible sans scroller. Sur le premier écran, le visiteur doit comprendre ce que tu proposes et ce qu’il peut faire ensuite : demander un devis, réserver un appel, tester le produit ou voir tes réalisations. Fais vérifier le rendu sur mobile et ordinateur avec le vrai contenu. Le faux texte très court est toujours sage. Le vrai titre de huit mots, beaucoup moins.

35. Le délai de réponse ou de livraison est annoncé. « Réponse sous un jour ouvré » rassure davantage qu’un formulaire qui part dans le vide, à condition de tenir la promesse. L’agent peut afficher ce délai près du formulaire et sur la page de remerciement. Il ne peut pas choisir le bon délai à la place de ton équipe.

36. Google Analytics mesure les actions utiles. Demande quels événements partent lors d’un envoi de formulaire, d’un clic important ou d’une prise de rendez-vous. Vérifie qu’ils ne sont pas envoyés deux fois et qu’aucune adresse email ou donnée de formulaire ne se retrouve dans les paramètres. En France, beaucoup de traceurs demandent un consentement préalable. La CNIL explique les règles applicables aux cookies, avec des exemptions encadrées qui ne doivent pas être supposées automatiquement.

Le suivi te dit ce que les visiteurs font. Il ne crée pas la confiance à leur place. Les quatre derniers points demandent donc du contenu que ton agent peut mettre en forme, mais qu’il ne doit surtout pas inventer.

Les preuves qui rendent le site crédible

37. Les avis clients sont vrais. Donne à l’agent les citations autorisées, les noms affichables et leur source si elle est publique. S’il n’y a pas encore d’avis, retire la section. Trois personnages fictifs avec une photo de banque d’images ne rassurent personne.

38. La politique de confidentialité correspond au site. L’agent peut inventorier les formulaires, les traceurs et les prestataires utilisés, puis repérer ce qui manque dans le document. Il ne remplace pas une validation juridique adaptée à ton activité. Copier la politique d’un autre site est une très mauvaise base si vous n’utilisez pas les mêmes outils.

39. Les études de cas s’appuient sur des faits. Une bonne page explique le problème, le travail réalisé et le résultat obtenu. L’agent peut structurer le récit, optimiser les images et améliorer la lecture. Les chiffres, les captures, les dates et les citations doivent venir de toi.

40. La page équipe montre une vraie photo. L’agent peut recadrer l’image, la compresser et ajouter un texte alternatif. Il ne doit pas générer de faux collaborateurs pour remplir la section. Une illustration IA peut expliquer un concept. Elle ne prouve pas qui répondra au téléphone lundi matin.

Le prompt à copier pour faire auditer ton site

Tu peux maintenant donner la checklist à l’agent. Je te conseille de commencer sans l’autoriser à corriger. Tu lis le rapport, tu choisis les urgences, puis tu lui demandes de travailler par lots. Cette séparation paraît un peu plus lente au départ. Elle évite surtout le grand mélange où l’agent change l’authentification, met à jour douze dépendances et réécrit les titres de pages dans le même diff.

Audite ce projet avant sa mise en production.

Contexte :
- type de projet : [SITE VITRINE / WEB APP / LES DEUX]
- stack : [À COMPLÉTER]
- authentification : [À COMPLÉTER OU AUCUNE]
- base de données : [À COMPLÉTER OU AUCUNE]
- hébergement : [À COMPLÉTER]
- upload de fichiers : [OUI / NON]
- webhooks et services externes : [À COMPLÉTER OU AUCUN]

Lis `docs/release-checklist.md` puis réalise un audit strictement en lecture seule.
Ne modifie aucun fichier, n'installe rien et ne lance aucune migration.

Pour chaque point, donne :
1. le statut : conforme, non conforme, non applicable ou à vérifier manuellement ;
2. le niveau de risque ;
3. la preuve observée, avec le fichier et les lignes concernés ;
4. le test à lancer ;
5. la correction recommandée si nécessaire.

Ne marque jamais un point conforme sans preuve observable. Ne révèle aucune
valeur secrète dans le rapport. Vérifie aussi l'historique Git et le bundle de
production pour repérer les secrets exposés.

À la fin, regroupe les corrections par lots et classe-les par priorité.
Arrête-toi après le rapport et attends mon accord avant toute modification.

Quand le rapport te convient, envoie ce prompt de suivi :

Corrige uniquement le lot [NOM DU LOT] validé dans l'audit.

Préserve le comportement métier actuel. Après les modifications, exécute les
contrôles disponibles dans le projet : formatage, lint, types, tests et build.

Donne-moi ensuite les fichiers modifiés, la raison de chaque changement, les
résultats des contrôles et les vérifications manuelles encore nécessaires.
Ne commence pas le lot suivant sans mon accord.

Cette façon de travailler garde l’agent dans un périmètre clair. Elle est aussi plus simple à relire si tu alternes entre Claude Code, Codex et Kimi. Chacun repart du même fichier, des mêmes statuts et des mêmes preuves. Pour comparer plus largement leurs usages, tu peux aussi lire mon retour sur Claude Code, Codex et n8n.

Ce qui va probablement te bloquer

Une checklist propre n’empêche pas les erreurs. Elle permet surtout de savoir quoi faire quand elles arrivent. Voici quatre cas que ton agent ne doit pas « résoudre » en retirant la protection qui vient de se déclencher.

La RLS refuse aussi le propriétaire

new row violates row-level security policy for table "profiles"

La mauvaise correction consiste à désactiver la RLS. L’agent doit vérifier l’utilisateur présent dans la session, les rôles concernés, la condition WITH CHECK et les données réellement envoyées. Le test est réussi lorsque le propriétaire peut écrire et qu’un autre compte reste bloqué.

Le navigateur bloque la requête CORS

Access to fetch at 'https://api.exemple.com' from origin
'https://app.exemple.com' has been blocked by CORS policy.

Mettre * partout fait parfois disparaître le message, mais ouvre beaucoup trop la configuration. Il faut retrouver l’origine exacte, la requête OPTIONS, les en-têtes nécessaires et l’éventuel envoi de cookies. L’agent ajoute seulement ce dont l’application a besoin.

Le serveur refuse le fichier avant ton code

413 Payload Too Large

Ton formulaire peut accepter 10 Mo alors que le proxy s’arrête à 2 Mo. L’agent doit relever chaque limite, du framework au stockage en passant par l’hébergeur. La plus petite gagne. Ensuite seulement, tu choisis une taille cohérente et tu alignes les réglages.

Le build passe, mais le contrôle reste impossible

Un build réussi ne connaît pas forcément la configuration HTTPS du domaine, la politique de sauvegarde ou le statut servi par l’hébergeur sur une URL inconnue. Dans ce cas, « à vérifier manuellement » est la bonne réponse. Un agent sérieux reconnaît ce qu’il ne peut pas observer depuis le dépôt.

Le dernier tour avant la mise en ligne

Une fois les corrections appliquées, termine par quelques scénarios complets. Le but n’est plus de relire la configuration. Tu veux voir le comportement réel du site.

Garde la checklist dans le dépôt. Quand tu ajoutes un espace membre, un upload ou un nouveau formulaire, tu la relances. Ton agent IA pourra alors faire ce qu’il fait très bien : fouiller tout le projet sans se fatiguer. Et toi, tu gardes la partie qu’il ne faut pas déléguer, décider ce qui est prêt à partir en production.