TL;DR
Quand on entend « créer un site d’articles avec l’IA », on imagine facilement :
Je demande 100 articles à l’IA, je les mets en ligne, terminé.
Non.
C’est comme acheter une photocopieuse et annoncer que l’on a construit une bibliothèque.
Un vrai site doit rester compréhensible quand il grandit. Le lecteur ne doit pas se perdre. Une vieille traduction ne doit pas se faire passer pour la version actuelle. Les 12 langues ne doivent pas se croiser. Les liens ne doivent pas casser. Deux automatisations ne doivent pas écraser le travail l’une de l’autre. Et, lorsqu’un incident arrive, le système doit pouvoir le détecter puis revenir à un état sûr.
Il faut donc utiliser l’IA non seulement comme une « machine à écrire », mais comme une équipe de rédacteurs, éditeurs, inspecteurs, bibliothécaires, constructeurs de routes et techniciens de maintenance.
Le système entier tient en dix étapes :
- Définir à quoi sert le site.
- Préparer le terrain et l’entrepôt du contenu.
- Donner à chaque article une identité stable et une empreinte de version.
- Construire d’abord un bon article dans une langue source.
- Faire le QA avant la traduction.
- Étendre à 12 langues sans multiplier les erreurs.
- Construire les liens internes et les hubs comme des routes et des bureaux d’information.
- Faire tourner l’usine selon l’état, pas seulement selon l’heure.
- Ne pas dire « publié » avant d’avoir vérifié la vraie page de production.
- Comparer continuellement le site à un état idéal de 100 points et réparer les écarts.
Si on dit seulement « IA, fais-moi un bon site », le conseil de quartier des IA peut construire trois maisons identiques et six routes vers nulle part.
Le plus important n’est pas une IA plus intelligente.
C’est un système plus sûr.
Modèle mental : site = bibliothèque + réseau routier + usine
- Article = livre
- Site = bibliothèque
- Catégorie = étagère
- Article hub = bureau d’information
- Lien interne = route
- URL = adresse
- ID d’article = numéro d’enregistrement stable
- SHA / hash = empreinte digitale d’une version
- GitHub = entrepôt de fichiers et d’historique
- QA = correction au stylo rouge du professeur
- Déploiement = ouverture réelle de la bibliothèque
- Routine de surveillance = gardien de nuit
- CAS / mise à jour conditionnelle = « remplace seulement si c’est toujours l’édition 3 »
- Token d’étape = tampon « cette version exacte a validé cette étape »
Avec cette image, beaucoup de mots techniques deviennent simplement des règles de circulation.
1. Définir le problème que le site doit résoudre
1-1. Ne pas faire du nombre d’articles l’objectif
Mauvais objectif :
Publier 100 articles par jour.
Si 30 répondent à la même question, que les liens sont cassés et que les traductions sont anciennes, on n’a pas créé du savoir.
On a produit 100 sacs-poubelle à grande vitesse.
Un meilleur objectif décrit ce que le lecteur peut faire :
- trouver rapidement une réponse
- savoir où commencer
- aller naturellement vers une explication plus détaillée
- comprendre les relations entre les articles
- atteindre le même sens dans sa propre langue
1-2. Définir les règles que l’IA ne peut jamais violer
Par exemple :
- ne pas exposer de données personnelles
- ne pas changer silencieusement des dates ou des chiffres
- ne pas inventer des sources
- ne pas considérer une vieille traduction comme current
- ne pas publier une URL cassée
- ne pas envoyer un lecteur japonais vers un article anglais sans rapport en fallback de contenu
- ne pas laisser deux workers écraser le même travail
- ne pas prendre « l’IA dit que c’est fini » comme preuve
Ces règles sont les barrières de sécurité de l’usine.
1-3. Écrire l’état idéal à 100 points
Quand l’idéal est clair, le système peut demander :
Quelle est la note maintenant ?
Où perd-on des points ?
Que peut-on réparer sans risque ?
Quelle est la note après réparation ?
C’est la boucle QC de base.
2. Préparer le terrain et l’entrepôt
2-1. Configuration minimale
Pour commencer :
- domaine
- GitHub
- framework web
- hébergement
- analytics
Astro, Next.js, Eleventy ou un autre framework peuvent convenir. Le principe est plus important que le nom :
séparer les données de contenu du programme qui les affiche.
2-2. Séparer la source des résultats générés
Ne laissez pas tous les processus automatiques réécrire directement le fichier source.
Séparez si possible :
- article source
- version éditée
- traductions
- overlays de liens internes
- preuves QA
- état de publication
Dans une cuisine, tous les cuisiniers ne versent pas leur sauce directement sur la viande crue dans le réfrigérateur.
Préparation, cuisson, dressage et inspection sont des étapes différentes.
2-3. Utiliser Git comme machine à remonter le temps
L’automatisation doit :
- faire des changements petits et explicables
- enregistrer la raison
- éviter le force push
- garder des checkpoints dans les longs lots
3. Donner à chaque article une identité stable et une empreinte
3-1. Ne pas dépendre uniquement de l’URL
URL et titre peuvent changer.
Utilisez un ID logique stable :
articleFamilyId = article_000123
Les versions japonaise, anglaise et coréenne du même contenu partagent le même family ID.
3-2. Traiter locale comme une dimension séparée
article_000123 + ja
article_000123 + en
article_000123 + ko
Le système peut alors dire :
- anglais stale
- coréen manquant
- japonais modifié aujourd’hui
- français toujours current
3-3. Le hash est une empreinte digitale
Si le contenu change, le hash change.
On peut donc répondre à la question :
De quelle version japonaise cette traduction anglaise vient-elle ?
Si le japonais a changé mais que l’anglais pointe encore vers l’ancienne empreinte, l’anglais est stale.
Pas besoin de débattre avec l’IA.
La preuve décide.
3-4. Garder des états explicites
Par exemple :
- brouillon
- QA source validé
- traduction en cours
- QA traduction validé
- navigation validée
- éligible à la publication
- publié
- stale
La machine à états devient l’ossature de l’automatisation.
4. Construire d’abord un bon article source
4-1. Ne pas traduire une mauvaise source
Traduire une mauvaise source en 11 langues, c’est internationaliser le bug.
Félicitations : l’erreur a maintenant une distribution mondiale.
Terminez d’abord une langue source.
4-2. Minimum d’un bon article
- titre clair sur le problème résolu
- ouverture qui répond à la question
- structure compréhensible avec les seuls headings
- termes difficiles expliqués
- exemples concrets
- chiffres, dates, noms et incertitude préservés
- faits et opinions séparés
- sources quand elles sont nécessaires
- aucune donnée personnelle
- peu de répétitions
- moins de prose générique « template IA »
4-3. L’humour doit renforcer le sens
Exemple :
Traduire une source cassée en 11 langues, c’est cloner onze fois une maison penchée.
La blague aide à mémoriser la règle.
Une blague sans rapport, c’est un spectacle de rue au milieu d’un chantier.
5. Faire le QA avant de traduire
5-1. « Généré » ne veut pas dire « terminé »
La sortie de l’IA est une copie rendue, pas une note de passage.
Vérifiez :
- titre et corps cohérents
- faits inchangés
- dates, prix et unités corrects
- URL existantes
- citations et sources intactes
- Markdown/HTML valide
- hiérarchie des headings logique
- données personnelles supprimées
- aucune certitude dangereuse ajoutée
- pas de duplication majeure d’intention avec un autre article
5-2. Garder des preuves, pas seulement un voyant vert
Enregistrez :
- ID de l’article
- hash source
- hash de sortie
- résultat QA
- ce qui a changé
- la règle utilisée
« Tu as fait tes devoirs ? »
« Oui. »
Preuve faible.
« Montre le cahier. »
Beaucoup mieux.
5-3. Une erreur ne doit pas arrêter toute l’usine
Si 1 article sur 100 ne peut pas être traité :
- différer cet article
- conserver la raison
- continuer avec un autre élément éligible
Une vis desserrée ne nécessite pas de couper l’électricité de toute la ville.
6. Étendre à 12 langues
6-1. Fixer la liste des locales
Par exemple :
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
Une liste fixe simplifie URL, QA, hreflang, sitemap et liens.
6-2. Utiliser une URL différente par langue
/ja/articles/...
/en/articles/...
/ko/articles/...
Utilisez hreflang pour indiquer que ces URL sont des variantes linguistiques du même article.
6-3. Réutiliser les traductions encore current
- current → réutiliser
- stale → mettre à jour uniquement ce locale
- missing → créer
Tout retraduire à chaque fois coûte plus cher et multiplie les surfaces de bugs.
6-4. Ne pas copier l’ordre des mots japonais
Traduire ne consiste pas à remplacer des mots.
Adaptez selon la langue :
- longueur des phrases
- titres
- transitions
- humour
- texte d’ancrage
- ordre des explications
Conservez le sens, pas la forme.
6-5. QA par article × locale
Un anglais validé ne prouve rien pour le thaï.
Une erreur locale doit pouvoir différer seulement ce locale.
7. Construire des routes avec les liens internes et les hubs
7-1. Ne pas ajouter des liens pour atteindre un quota
Un bon anchor décrit la destination.
Bon :
Les débutants peuvent commencer par le guide pour choisir la concentration de rétinol.
Mauvais :
Cliquez ici.
Un panneau qui dit « par là » n’aide pas beaucoup.
7-2. Séparer les types de liens
Au minimum :
- Hub structural — bureau d’information → article détaillé
- Body contextual — référence naturelle dans le texte
- Related recommendation — lecture suivante
- Language alternate — même article, autre langue
- Breadcrumb — retour dans la hiérarchie
Si tout est juste « un lien », les règles finiront par entrer en collision.
7-3. La navigation de contenu doit rester dans la même langue
Si la cible japonaise n’existe pas, ne faites pas de fallback automatique vers l’anglais.
Changer de langue et changer de sujet sont deux actions différentes.
7-4. Un hub n’est pas un entrepôt d’URL
Un bon hub explique :
- ce que couvre le thème
- à qui il s’adresse
- où un débutant doit commencer
- les principaux sous-thèmes
- quel article détaillé répond à quelle question
Vingt URL nues, c’est un bureau d’information dont l’employé est parti en laissant une carte sur la chaise.
7-5. Promouvoir un article large existant avant de créer un nouveau hub
Sinon vous finirez avec :
- Guide complet
- Guide ultime
- Guide total
- Tout ce qu’il faut savoir
qui se battent pour la même intention.
Ce n’est pas de l’architecture de l’information.
C’est un battle royale SEO.
7-6. Candidats machine + revue sémantique
La génération de candidats peut utiliser :
- sens du texte
- graphe de liens
- parcours utilisateur
- intention de recherche
- risque de duplication
Mais avant l’application, le système doit expliquer pourquoi la relation est utile.
8. Faire tourner l’usine selon l’état, pas seulement l’horloge
8-1. Le planning est un réveil
On peut planifier :
- minute 02 : hub
- 07 : source
- 27 : traduction
- 37 : liens
- 58 : publication
Mais la minute 27 ne prouve pas que la source est terminée.
L’heure réveille le worker.
L’état lui donne l’autorisation.
8-2. Vérifier les tampons amont
Avant traduction :
- source current
- QA current
- ID correct
- hash correct
Avant liens :
- locale current
- route current
- qualité current
Avant publication, ajoutez SEO et validation.
8-3. Utiliser des tokens basés sur le contenu
done=true est trop faible.
Un token solide peut représenter :
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
Si l’amont change, l’ancien token aval devient stale.
8-4. Utiliser CAS / mise à jour conditionnelle
Deux IA lisent la version 3.
A écrit la version 4.
B tente ensuite d’écrire un résultat basé sur la version 3.
Sans protection, B efface le travail de A.
Règle sûre :
écrire seulement si la ressource est encore la version que j’ai lue.
Sinon, relire ou différer.
8-5. Garder des checkpoints
Si un batch vise 50, sauvegardez tous les quelques succès.
S’il s’arrête à 20, repartez de 21.
Les jeux vidéo ont résolu ce problème depuis longtemps : sauvegardez la partie.
9. Un commit GitHub n’est pas une publication
9-1. La publication est une chaîne
contenu complet
↓
traductions current
↓
navigation validée
↓
validation passée
↓
publication autorisée
↓
deploy
↓
HTML de production vérifié
↓
production verified
9-2. Ne pas forcer les locales incomplets
Un locale stale peut attendre.
Les autres n’avancent que si la politique formelle l’autorise.
9-3. Vérifier la plomberie SEO
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- structured data
- 404/redirect
- liens internes
Les routes multilingues sont faciles à câbler de travers.
9-4. Charger la vraie URL de production
Commit présent, build passé, deploy réussi : toujours insuffisant.
Vérifiez sur la vraie URL :
- HTTP 200
- contenu actuel
- bonne langue
- title/meta
- canonical/hreflang
- liens fonctionnels
Ne dites pas « livraison terminée » si la boîte repas est encore devant votre propre porte.
10. Faire revenir le site à 100 points en permanence
10-1. Boucle QC
observer
↓
noter
↓
trouver les écarts
↓
classer la cause
↓
réparer sans risque
↓
re-tester
↓
re-noter
10-2. Hard gates contre le maquillage de score
Même si la somme donne 100, impossible de déclarer 100 avec :
- lien cassé
- lien de contenu vers le mauvais locale
- traduction stale traitée comme current
- membre de hub inexistant
- succès formel compté deux fois
- lost update
- fausse preuve de validation
10-3. Un incident répété doit améliorer l’usine
Si le même problème revient :
- contrat insuffisant ?
- validator manquant ?
- modèle d’état faible ?
- protection de concurrence insuffisante ?
- collision de planning ?
- infrastructure externe ?
L’objectif passe de « réparer le produit » à « produire moins de défauts ».
10-4. Ne pas couper la surveillance à 100
Aujourd’hui 100, demain 98 après un nouvel article.
C’est normal.
La routine doit ramener 98 à 100.
L’absence de voleur hier n’est pas une raison pour jeter la serrure.
Tout le système en 30 secondes
Humain définit objectif + limites
↓
état idéal 100
↓
IA crée la source
↓
QA + preuves
↓
extension 11 langues
↓
QA par locale
↓
liens + hubs
↓
state/hash/token
↓
validation
↓
politique de publication
↓
deploy
↓
URL/HTML réel
↓
mesure comportement utilisateur
↓
comparaison à l’idéal
↓
réparation sûre
└────→ répétition
Dix accidents classiques
- 100 articles, 30 répondent à la même question
- Une erreur source distribuée dans 12 langues
- La traduction existe mais elle est stale
- Une page japonaise saute soudain vers un article anglais
- Trop de hubs jusqu’à ce que le bureau d’information devienne la destination
- Tous les anchors disent « cliquez ici »
- Deux IA écrasent le même article
- Objectif 50, un succès puis « terminé »
- Confondre commit et production
- La surveillance trouve un problème, donc quelqu’un coupe la surveillance
Le numéro 10 revient à débrancher le détecteur de fumée parce qu’il a détecté de la fumée.
Checklist minimale
Conception
- ☐ objectif lecteur
- ☐ idéal 100 points
- ☐ interdictions
- ☐ ID stable
- ☐ locale séparé
- ☐ content hash
Contenu
- ☐ QA source
- ☐ confidentialité
- ☐ faits/chiffres/URL protégés
- ☐ exemples concrets
- ☐ moins de template IA
Multilingue
- ☐ URL par langue
- ☐ hreflang
- ☐ empreinte source
- ☐ mettre à jour seulement stale
- ☐ QA par locale
- ☐ pas de fallback cross-locale de contenu
Liens/hubs
- ☐ hub structural séparé des body links
- ☐ anchors descriptifs
- ☐ audit orphan
- ☐ broken/self/duplicate/cross-locale
- ☐ vérifier la promotion avant nouveau hub
- ☐ audit de hubs en doublon
Automatisation
- ☐ gates state/hash/token
- ☐ claim/CAS
- ☐ checkpoints
- ☐ exactly-once formal success
- ☐ une erreur ne bloque pas tout
Publication
- ☐ validation
- ☐ canonical/hreflang/sitemap
- ☐ politique de publication
- ☐ vraie URL
- ☐ vrai HTML
Maintenance
- ☐ audit régulier à 100 points
- ☐ hard gates
- ☐ réparer les causes racines
- ☐ surveiller même après 100
Leçon finale
Le meilleur site d’articles avec IA n’est pas celui qui utilise le modèle le plus cher.
C’est celui qui peut détecter une erreur et revenir à un état correct lorsque l’IA se trompe, que le contenu devient stale, que plusieurs processus tournent en parallèle ou qu’un service externe tombe.
L’humain définit l’objectif, l’idéal, les limites et la responsabilité finale.
L’IA génère, compare, inspecte, répare et consigne.
La preuve de réussite repose sur :
- hashes
- tests
- historique Git
- vraies URL
- vrai HTML
- comportement des lecteurs
À ce stade, vous n’avez plus seulement un blog.
Vous avez une mini maison d’édition + bibliothèque + service des routes + usine QC à l’intérieur d’un dépôt.
Commencez par un seul article.
Donnez-lui un ID.
Ajoutez le QA.
Ajoutez une langue.
Ajoutez des liens sûrs.
Ajoutez les états.
Construisez couche par couche.
Pas besoin de bâtir une station spatiale le premier jour.
Mais n’achetez pas 100 photocopieuses en annonçant « station spatiale terminée ».
