Écrire un blog technique avec l’IA : recherche, validation du code et relecture humaine

Un article technique contient trois blocs de code, mais aucun n’a été exécuté. Les lecteurs les copient, rencontrent des erreurs et découvrent que le problème n’était pas le style : les faits et le code n’avaient franchi aucun contrôle.

Un brouillon produit par l’IA peut sembler complet tout en devinant des versions, des arguments de commande et des formats de sortie. Un projet déclare par exemple "type": "module" dans package.json, alors que l’exemple appelle directement require. Un autre texte annonce « 2 000 minutes GitHub Actions par mois » sans préciser qu’il s’agit du quota d’un forfait donné pour les dépôts privés.

Écrire un article technique ne consiste donc pas à donner un sujet à un modèle puis à polir sa réponse. On commence par des sources et des preuves exécutables, l’IA organise l’explication, puis une personne vérifie les faits, le code et la forme. Le processus ci-dessous attribue un contrôle et une responsabilité à chaque étape afin de garder des affirmations exactes, des exemples exécutables et des conclusions reproductibles.

Rechercher avant de demander un brouillon à l’IA

Ce qu’il faut rechercher et ce que l’IA peut rédiger

La première décision consiste à séparer les faits qui doivent venir de sources externes des éléments que le modèle peut seulement organiser.

Trois catégories facilitent ce tri.

Les versions, champs d’API modifiés, limites documentées, tarifs ou quotas et configurations de sécurité sont recherchés en premier. Une erreur peut casser le projet d’un lecteur ou provoquer une facture inattendue. La documentation Next.js actuelle utilise par exemple la clé turbopack, tandis que les versions 13.0.0 à 15.2.x utilisaient experimental.turbo. Écrire simplement « configurer Turbopack » sans indiquer la version peut conduire à copier une configuration incompatible.

L’IA peut proposer un brouillon sur les concepts généraux, l’usage d’un framework, les bonnes pratiques et les erreurs courantes, mais une vérification reste nécessaire. Une explication sur les React hooks peut sembler juste ; le nombre de règles, les conventions de nommage et les différences de version doivent tout de même être comparés à la documentation officielle.

La structure, la reformulation et la mise en forme peuvent être confiées à l’IA. Rendre une explication plus claire ou regrouper des paragraphes liés ne demande généralement pas de nouvelle recherche.

Comparaison des trois catégories :

Type de recherche	Contenu typique	Niveau de contrôle	Étape concernée
Recherche préalable	Versions, champs d’API, tarifs ou quotas, sécurité	Élevé : extraire de la documentation officielle et marquer [VERIFY]	Préparer pendant la planification, revérifier le jour de rédaction
Brouillon IA + vérification	Concepts généraux, framework, bonnes pratiques	Moyen : comparer le brouillon à la documentation officielle	Rédiger puis vérifier pendant la relecture
Organisation par l’IA	Structure, formulation, formatage	Faible : aucune recherche supplémentaire en général	Étape de rédaction

Arbre de décision :

Un contenu de type X apparaît
  ↓
Concerne-t-il une version, une API, un tarif ou la sécurité ?
  ├─ Oui → Extraire la donnée de la documentation officielle, marquer [VERIFY], revérifier le jour de rédaction
  └─ Non → Concerne-t-il une règle technique ou une bonne pratique ?
      ├─ Oui → Laisser l’IA rédiger, puis comparer à la documentation officielle pendant la relecture
      └─ Non → Laisser l’IA organiser l’explication

Transmettre les résultats de recherche à la rédaction

Après la recherche, les résultats sont enregistrés dans un format directement exploitable par l’étape de rédaction.

On extrait de research.md les sources très fiables, notamment la documentation officielle marquée high. Il peut s’agir des recommandations de Google Search Central sur le contenu utile, de l’exemple officiel GitHub Actions pour Node.js ou de la documentation Astro Content Collections.

Les faits changeants reçoivent [VERIFY], par exemple : « Le quota GitHub Actions inclus pour les dépôts privés dépend du forfait du compte [VERIFY] » ou « Vérifier si la version cible de Node est encore prise en charge [VERIFY] ».

Les fiches de sources, sorties de commandes et résultats de vérification sont placés dans source_cards et risk_notes :

{
  "source_cards": [
    {
      "url": "https://developers.google.com/search/docs/fundamentals/creating-helpful-content",
      "type": "official/docs",
      "confidence": "high",
      "usable_info": "Le contenu doit apporter des informations originales et une explication complète au lieu de dépendre surtout d’une automatisation massive"
    }
  ],
  "risk_notes": [
    {
      "fact": "Quota GitHub Actions inclus",
      "status": "[VERIFY]",
      "check_date": "2026-06-24",
      "source": "https://docs.github.com/en/billing/managing-billing-for-github-actions"
    }
  ]
}

Avec ce passage de relais, la rédaction ne répète pas toute la recherche. Elle revérifie seulement les informations variables identifiées.

Les exemples de code doivent fonctionner, pas seulement paraître corrects

Quatre cas de validation du code

Les exemples techniques semblent souvent plausibles et échouent dans un vrai projet. Dès qu’un lecteur copie le code et obtient une erreur, l’article perd sa crédibilité.

La validation se divise en quatre cas.

L’exécution locale couvre les commandes d’installation, les configurations et les petits scripts, comme npm install, git clone ou une modification de configuration. On exécute réellement ces commandes et on conserve leur sortie.

Les tests CI couvrent les builds, les tests et les dépendances d’environnement, comme npm ci, npm run build et npm test dans GitHub Actions. La CI rend l’environnement reproductible.

Le contrôle des versions couvre Node, les dépendances et les versions d’API, par exemple .nvmrc, package.json et les changements d’endpoint. La version est indiquée et les différences utiles sont expliquées. La cohérence des environnements concerne le développement, la production et la CI : variables, images Docker et systèmes d’exploitation. L’environnement exécuté doit être nommé.

Les quatre cas :

Cas de validation	Contenu typique	Méthode	Preuve nécessaire
Exécution locale	Installation, configuration	Exécuter localement	Sortie de commande ou capture
Test CI	Build et tests	GitHub Actions ou autre CI	Journal CI ou résultat de build
Contrôle de version	Version de Node ou des dépendances	Commande de version	Sortie de node --version et note de version
Cohérence des environnements	Variables, Docker	Tester plusieurs environnements ou nommer celui qui a été testé	Environnement et conditions

Enregistrer les preuves d’exécution

Chaque exemple de code a besoin d’une preuve. « Exécuté avec succès » ne suffit pas. Les commandes et sorties ci-dessous illustrent uniquement le format d’un enregistrement ; elles ne constituent pas des résultats réutilisables. Il faut les remplacer par les versions et journaux du projet cible.

Exemple pour une tâche CI Node.js :

# Environnement local : macOS + Node 18.20.0 LTS
$ node --version
v18.20.0

# Environnement CI : GitHub Actions
$ npm ci
added 245 packages in 12s

$ npm run build
✓ Built in 1.23s

$ npm test
✓ 12 tests passed

Un bon exemple fournit le texte ou la capture de la sortie, la version et le résultat utile.

Un mauvais exemple indique seulement « tout fonctionne » sans sortie.

Le code utilise des fenced code blocks avec une langue comme bash ou typescript. Une longue sortie est repliée ou limitée aux lignes importantes. Pour plusieurs commandes, on indique local, CI ou Docker. Les contrôles de version conservent la sortie de node --version ou npm --version.

Exemple :

# Environnement d’exécution : macOS + Node 18.20.0
$ npm install
added 124 packages in 8s

$ node --version
v18.20.0

Pour une sortie de build longue, on ne montre que la partie utile :

$ npm run build
✓ Built in 1.23s
  ├─ dist/index.html
  ├─ dist/assets/index.js
  └─ dist/assets/index.css

GitHub documente les blocs de code délimités et la coloration syntaxique dans Creating and highlighting code blocks. Un article technique doit conserver un code copiable et vérifiable, plutôt que le déguiser en prose.

La relecture humaine vérifie les faits, le code et la structure

Contrôle des faits : remonter aux versions, paramètres et tarifs

La relecture humaine n’est pas une simple correction stylistique. Elle examine trois couches : faits, code et structure. Une passe limitée aux mots rate les mauvaises versions, les paramètres inexistants et les conclusions qui ne correspondent pas au code.

Le principe central est la traçabilité. Chaque version, champ d’API, paramètre, valeur de configuration, tarif ou quota et date de publication est comparé à une documentation officielle ou à une exécution réelle.

Tableau de contrôle :

Élément	Méthode	Signal d’échec	Preuve acceptable
Version	Comparer à une version ou documentation officielle	Version inexistante ou fonctionnalité mal décrite	Lien officiel et sortie de node --version
Paramètre	Comparer à la documentation CLI officielle	Paramètre absent ou format incorrect	Lien officiel et sortie réelle
Champ d’API	Comparer à la documentation API officielle	Champ absent ou mauvais type	Lien officiel et requête réelle
Tarif ou quota	Comparer à la page tarifaire officielle	Tarif faux ou condition public/privé absente	Lien officiel et conditions
Date de sortie	Comparer à l’annonce officielle	Date ou événement erroné	Lien vers l’annonce

Exemple incorrect :

Le projet déclare "type": "module" dans package.json, mais l’exemple utilise directement require sans passer à .cjs ni expliquer la frontière entre modules.

Autre exemple incorrect :

Le texte affirme que GitHub Actions ne propose que « 2 000 minutes gratuites par mois » sans rappeler que les runners GitHub-hosted standard sont gratuits pour les dépôts publics et que les minutes incluses des dépôts privés dépendent du forfait du compte.

Formulation plus précise :

« Node 18 prend en charge les ES modules et CommonJS. .mjs, .cjs et le champ type de package.json déterminent l’interprétation du fichier. Cet enregistrement utilise Node 18.20.0 et conserve la sortie de node --version. »

« Au 26 juillet 2026, les runners GitHub-hosted standard sont gratuits pour les dépôts publics. Les dépôts privés reçoivent un quota selon le forfait, par exemple 2 000 minutes avec GitHub Free et 3 000 avec GitHub Pro (source : GitHub Actions billing). »

Contrôle du code : exécution, sortie cohérente et environnement nommé

Le contrôle du code pose trois questions : la commande fonctionne-t-elle, la sortie confirme-t-elle le texte et l’environnement est-il explicite ?

Élément	Méthode	Signal d’échec	Preuve acceptable
Commande exécutable	Exécuter localement ou en CI	Erreur ou dépendance manquante	Journal ou capture
Sortie cohérente	Comparer sortie et texte	La sortie contredit l’article	Le texte et le journal concordent
Environnement nommé	Vérifier la note d’environnement	Version de Node ou OS absent	Node 18.20.0 + macOS
Version de dépendance	Vérifier package.json	Version incompatible avec le texte	package.json ou sortie de version

Exemple incorrect :

Le texte annonce trois fichiers, mais npm run build en affiche cinq.

Le texte dit « exécuté localement », alors que l’exemple dépend de Docker sans le préciser.

Exemple correct :

Le texte et le journal concordent : « npm run build a généré index.html, index.js et index.css. »

L’environnement est clair : « Testé sous macOS avec Node 18.20.0. Linux ou Windows peut demander une adaptation des chemins. »

Contrôle de structure et de style : H2/H3, liens internes et résidus d’IA

Cette passe compare les H2/H3 à la structure approuvée, vérifie les liens internes et retire les formulations génériques produites par l’IA.

Élément	Méthode	Signal d’échec	Résultat attendu
Cohérence H2/H3	Comparer à outline.md	Section absente ou ajout inattendu	Documenter la raison du changement
Liens internes	Comparer au plan de liens	Lien absent ou ancre trompeuse	Placer le lien avec une ancre descriptive
Formulations d’IA	Comparer à anti-ai-words.json	Promesse vide ou attribution vague	Remplacer par un fait concret ou supprimer

Le fichier anti-ai-words.json du site regroupe les expressions à éviter. Les promesses vides, attributions vagues et exagérations sont remplacées ou supprimées.

Une mauvaise ouverture se contente d’invoquer une tendance.

« Cet article propose une analyse complète » constitue aussi une promesse vide.

Une meilleure ouverture commence par la décision : « Lors d’une rédaction technique avec l’IA, il faut d’abord distinguer les faits qui viennent de sources externes. »

Une promesse vérifiable devient : « Ce processus place un contrôle sur la recherche, la validation et la relecture. »

Fermer le processus avec la QA avant publication

Checklist de QA avant publication

Un brouillon terminé n’est pas encore publiable. Le dernier contrôle porte sur les marqueurs de recherche, les preuves de code, les sources, la structure, les liens internes, les résidus d’IA et les images.

Élément	Contrôle	Condition de réussite	Réponse à l’échec
Marqueurs résolus	Rechercher [VERIFY]	Aucun marqueur ouvert	Retourner à la recherche
Exemples validés	Comparer aux journaux	Chaque exemple possède une preuve	Retourner à la validation
Faits traçables	Comparer aux fiches de sources	Chaque fait important possède source ou réserve	Ajouter une source ou retirer l’affirmation
Structure cohérente	Comparer à outline.md	H2/H3 identiques ou changements expliqués	Mettre à jour la trace de structure
Liens internes placés	Comparer au plan	Liens et ancres corrects	Ajouter le lien ou revoir le plan
Résidus d’IA retirés	Comparer à anti-ai-words.json	Aucune formule creuse	Réécrire ou supprimer
Images disponibles	Comparer inventaire et chemins Markdown	Tous les éléments référencés existent	Ajouter l’image ou corriger le chemin

États :

Réussi : le texte peut avancer vers la publication.

En attente : une source ou une affirmation doit encore être vérifiée.

Échoué : retour vers l’étape responsable.

Chaque élément est vérifié séparément et marqué dès qu’un problème apparaît. Le statut « prêt à publier » n’est appliqué qu’après réussite de tous les éléments.

Renvoyer un échec à l’étape responsable

Une erreur de QA retourne à l’étape qui en est responsable. Elle n’est pas ignorée.

Une erreur factuelle retourne à la recherche : on ajoute une source officielle, retire une affirmation non étayée ou revérifie une donnée variable.

Une erreur de code retourne à la validation : la commande est relancée, la sortie conservée, l’exemple corrigé et l’environnement indiqué.

Une différence de structure exige une mise à jour de la trace ou une explication des H2/H3 modifiés.

Un lien interne manquant retourne au plan de liens. On cherche l’article réel dans l’inventaire et on utilise une ancre descriptive.

Les résidus d’IA retournent à l’édition. Une expression signalée devient un fait concret ; si la phrase reste vague, elle est entièrement réécrite.

Exemple :

La QA détecte qu’un quota GitHub Actions ne précise pas la condition public/privé
  ↓
Marquer l’élément comme échoué
  ↓
Retourner à la recherche
  ↓
Ajouter la source de facturation officielle et les conditions
  ↓
Relancer la QA

Ce chemin de retour rend les responsabilités visibles. La personne qui effectue le contrôle final ne doit pas hériter d’une modification inexpliquée.

Sept signes qu’un article s’éloigne des faits

Les sept signes

Les écarts factuels s’accumulent progressivement. Ces signaux permettent de les trouver avant publication.

Signe 1 : une affirmation sans source. Le texte parle de « dernière version », de « recommandation officielle » ou de « bonne pratique » sans lien. Il peut par exemple prétendre qu’une clé Turbopack fonctionne dans toutes les versions de Next.js sans citer leur documentation.

Signe 2 : un code jamais exécuté. Il n’existe ni sortie ni journal, seulement « cela fonctionne ».

Signe 3 : une version ou un paramètre mal classé. La version peut exister, mais sa branche ou son support est faux ; les paramètres et endpoints changent aussi. Node 20.1.0, par exemple, était une version Current et non LTS.

Signe 4 : l’environnement ne correspond pas. La preuve nomme un environnement alors que le comportement n’a été vérifié que dans un autre.

Signe 5 : la conclusion n’est pas reproductible. Le texte annonce une amélioration sans méthode, jeu de données ni procédure.

Signe 6 : un lien interne est cassé. L’article pointe vers /posts/ai/ai-xxx, mais cette route n’existe pas.

Signe 7 : une formule vague masque le manque de preuve. « Analyse complète » remplace une source ou un résultat concret.

Exemples :

Signe	Mauvais exemple	Problème
Affirmation sans source	« Cette clé Turbopack fonctionne dans toutes les versions de Next.js »	Aucune documentation officielle pour les versions
Code non exécuté	« Exécuter npm install : cela fonctionne »	Aucune preuve d’exécution
Mauvaise version	« Node 20.1.0 LTS »	20.1.0 était Current, pas LTS
Environnement incohérent	Ancien environnement indiqué, comportement vérifié ailleurs	Version et environnement de validation divergent
Conclusion non reproductible	« Les performances progressent fortement »	Aucune méthode ni donnée
Lien interne cassé	Lien vers /posts/ai/ai-xxx	Route absente
Résidu d’IA	« Analyse complète de la rédaction avec l’IA »	Promesse vague

Lorsqu’un signe apparaît, on ajoute [VERIFY] et on renvoie le point à l’étape responsable.

Une affirmation sans source retourne à la recherche ; le code non exécuté à la validation ; une mauvaise version à l’annonce officielle. Un environnement incohérent demande des conditions correctes ou la suppression de l’affirmation. Une conclusion non reproductible exige méthode, données et étapes, sinon elle est retirée. Un lien cassé est remplacé par une route réelle. Une formule vague devient concrète ou disparaît.

Le retour doit être immédiat. Sinon, plusieurs petites incertitudes forment un article impossible à retracer.

Écrire honnêtement sans environnement de test complet

Trois approches honnêtes

L’environnement complet peut manquer : service payant, cluster complexe, système précis ou matériel particulier. Il ne faut pas inventer une preuve. Trois solutions restent possibles.

Premièrement, indiquer les conditions et les limites. On nomme la version testée et les différences possibles, ou le fait que seul le forfait gratuit a été testé. Exemple : « L’exemple a été validé uniquement avec Node 18.20.0 ; d’autres versions peuvent différer. »

Deuxièmement, proposer une validation alternative : reproduction minimale, données Mock ou issue officiel. Exemple : « Aucun cluster Kubernetes n’était disponible ; seule une reproduction minimale est fournie et doit encore être testée dans un vrai cluster. »

Troisièmement, reconnaître ce qui n’a pas été vérifié. On écrit « Cette conclusion de performance n’a pas été reproduite dans l’environnement actuel » ou on supprime l’affirmation.

Comparaison :

Situation	Formulation trompeuse	Formulation honnête
Différence de version	« Toutes les versions le permettent »	« Validé avec Node 18.20.0 ; d’autres versions peuvent différer »
Différence d’environnement	« Fonctionne en local »	« Testé sous macOS avec Node 18.20.0 ; Linux, Windows ou une autre version peuvent demander des adaptations »
Service payant	« Utilisation gratuite »	« Seul le forfait gratuit a été testé ; les fonctions payantes peuvent différer »
Affirmation non vérifiée	« Les performances progressent fortement »	« L’environnement actuel n’a pas reproduit cette conclusion de performance »

Exemples acceptables :

« Le test utilise le forfait gratuit de Cloudflare Workers, qui comprend actuellement 100 000 requêtes par jour. Les conditions payantes peuvent différer ; consulter la page tarifaire officielle. »

« Aucun cluster Kubernetes n’était disponible. La reproduction minimale doit encore être testée dans un vrai cluster avec ses limites de ressources Pod et ses paramètres réseau. »

« Aucun benchmark de grand projet n’est disponible ici. Aucune conclusion n’est donc tirée sur les performances de build de Turbopack ; il faut mesurer une référence et une comparaison dans son propre projet. »

Exemples inacceptables :

« Cloudflare Workers est gratuit. » Le quota manque.

« Cela fonctionne partout. » L’environnement manque.

« Les performances augmentent fortement. » La méthode et les données manquent.

Google Search Central recommande des informations originales, une explication complète et une analyse utile dans Creating helpful, reliable, people-first content. Préciser honnêtement une limite n’abaisse pas le niveau : cela sépare ce qui a été vérifié de ce que le lecteur doit encore tester.

Quand publier et quand reprendre le texte

Arbre de décision de publication

La décision ne dépend ni du nombre de mots ni d’une apparence terminée, mais de la réussite de la recherche, de la validation, de la relecture et de la QA.

Recherche : si toutes les sources fiables sont présentes et les faits variables marqués, on passe à la validation. Si une source essentielle manque, on poursuit la recherche.

Validation du code : si tous les exemples fonctionnent, on passe à la relecture. Un exemple erroné est corrigé ou retiré. Un exemple invérifiable reçoit des limites explicites ou disparaît.

Relecture humaine : si les faits sont traçables, on passe à la QA. Une affirmation sans source est étayée ou supprimée. Une modification de structure expliquée peut avancer ; une dérive inexpliquée retourne à la planification.

QA avant publication : si tout réussit, l’article avance. Un point en attente est revérifié ; un échec retourne à son étape.

Un article avance lorsque la recherche et les vérifications de fraîcheur sont terminées, que le code possède des traces d’exécution, que la relecture confirme faits et structure, que les formules creuses ont disparu et que la QA réussit.

Une source, un journal, un lien interne ou un nettoyage stylistique manquant demande encore du travail.

Une version, un paramètre, un tarif ou autre fait central erroné, une conclusion principale non reproductible ou une structure qui quitte l’objectif sans explication impose une reprise.

Chaque étape possède un contrôle. L’échec retourne à sa cause au lieu d’atteindre la publication.

Ordre de priorité :

Corriger ou supprimer d’abord les erreurs factuelles, puis les erreurs de code que les lecteurs peuvent copier. Les écarts de structure et liens manquants sont moins urgents, mais doivent être résolus avant publication.

Pour aller plus loin

Pour donner d’abord le contexte du projet à l’IA, lire comment CLAUDE.md limite les erreurs de code. Pour transformer rédaction et relecture en étapes réutilisables, voir les workflows avec Claude Code Skills.

Le site propose aussi un workflow de rédaction avec l’IA pour des contenus généralistes. Il privilégie la vitesse ; cette page privilégie les faits techniques, les preuves d’exécution et les contrôles de publication. Les deux approches sont complémentaires.