Les erreurs que je faisais en codant mes sites avec l'IA

Vérifie mon site en suivant ce guide : https://alexisamz.com/agents/audit-site.md

Lis-le en entier avant d'agir, puis demande-moi l'adresse de mon site.

Coder avec une IA, c'est rapide. Mais elle ne vérifie pas ce qu'on ne lui demande pas. Voici les erreurs que j'ai faites ou trouvées sur mes propres sites, ce qu'elles coûtent, et comment je les attrape maintenant.

Côté Google

Le Disallow oublié

Un de mes sites bloquait tous les moteurs depuis le développement : une ligne Disallow: / dans robots.txt. Le site marchait parfaitement. Il était juste invisible, et rien ne vous prévient.

La canonical qui pointe vers l'accueil

La balise canonical dit à Google « la vraie page, c'est celle-là ». Sur le site du salon, les pages réservation et annulation pointaient toutes vers l'accueil. Google ne les indexera jamais comme ça. L'IA met souvent la même canonical partout quand on ne lui dit rien.

Le noindex « temporaire »

J'avais mis 9 langues en noindex le temps de les améliorer. Je l'ai enlevé, mais Google avait gardé l'ancienne version : 28 pages restaient bloquées dans ses résultats. Enlever un noindex ne suffit pas, il faut redemander le passage de Google (comment je l'ai vu).

Le site en 11 langues traduit trop vite

C'est tentant : l'IA traduit tout en une minute. Mais Google voit des quasi-doublons et n'en garde qu'une partie. Mieux vaut moins de langues, vraiment relues.

Le changement de domaine sans redirections page par page

Rediriger tout l'ancien site vers l'accueil du nouveau, c'est perdre chaque page. Chaque ancienne adresse doit mener à son équivalent.

Côté design

Mon portfolio était noté 35 % « fait IA » par un détecteur en ligne. Le plus gros coupable : des emoji et des flèches utilisés à la place de vraies icônes, que ces détecteurs comptent très lourd. Après un passage d'Impeccable et de mes règles, 12 %.

Le plus traître, ce sont les chiffres. L'IA invente volontiers un « +2 000 utilisateurs » ou un avis client pour remplir une section. Sur un vrai site, c'est un mensonge. Je relis maintenant chaque chiffre et chaque promesse avant de publier.

Côté sécurité

La clé collée au mauvais endroit

Je l'ai fait : coller une clé API dans un chat. Une clé qui passe dans un chat, un fichier versionné ou un message doit être considérée comme exposée, et régénérée.

La clé supprimée mais toujours dans Git

Supprimer une clé du code ne l'efface pas de l'historique Git. Si elle a été commitée un jour, elle est lisible par quiconque a accès au dépôt. Il faut la changer.

Le skill qui vérifie avant chaque mise en ligne

Pour tout ça, j'ai écrit amz-security-audit. Il fait un audit complet sans rien casser :

• il repère les points d'entrée du projet (pages, API, webhooks, tâches planifiées) et vérifie que l'autorisation est contrôlée côté serveur sur chaque route sensible ;
• il passe les dépendances au crible avec l'outil d'audit du projet (npm audit ou équivalent), en distinguant ce qui est vraiment exploitable de ce qui ne sert qu'au build ;
• il cherche les secrets dans le code et dans tout l'historique Git ;
• sur le site en ligne, et seulement si c'est le vôtre, il fait des tests en lecture seule : en-têtes de sécurité, cookies, routes privées sans connexion, CORS, fichiers sensibles.

Deux principes que j'y ai mis. Il ne classe un problème comme « confirmé » que s'il l'a vraiment reproduit : un /.env qui répond 200 n'est souvent que la page d'accueil renvoyée par le routeur, il vérifie le contenu avant de crier au loup. Et il dit ce qu'il n'a pas pu vérifier, au lieu de faire croire que tout est couvert.

Ma checklist avant chaque mise en ligne

1. robots.txt n'interdit rien d'important.
2. Chaque page importante a une canonical vers elle-même et pas de noindex.
3. Le sitemap contient toutes ces pages, et seulement elles.
4. Aucun chiffre, avis ou fonction inventé dans les textes.
5. Aucune clé dans le code ni dans l'historique, et l'audit de sécurité est passé.

Dernier article de la série : mes bons plans pour les outils SEO payants.