Utiliser l'IA pour écrire : pourquoi l'architecture compte plus que le prompt

Il y a quelques semaines, j'ai demandé à plusieurs agents IA de traiter une dizaine de brouillons en parallèle. L'idée était simple : passer tous les anciens articles dans un pipeline de réécriture, récupérer des versions finales propres, gagner du temps.

Ce n'est pas ce qui s'est passé.

Les versions produites avaient l'air correctes au premier regard. Elles respectaient les grandes lignes des articles originaux, tenaient une structure, évitaient les fautes évidentes. Mais en les relisant attentivement, j'ai remarqué quelque chose : les exemples concrets n'étaient pas les miens. Des anecdotes vraisemblables, mais inventées. Des "j'ai testé" qui ne correspondaient à rien de réel. Une voix qui ressemblait à Romain de loin, et à n'importe qui de près[^1].

Le problème n'était pas l'IA. C'était moi. J'avais demandé à un outil générique de faire un travail qui demandait une architecture précise.

Pourquoi demander à l'IA de tout faire en même temps produit du générique

Quand on utilise l'IA pour écrire, la tentation est de tout regrouper dans une seule demande. Écrire un bon article sur ce sujet, dans cette voix, optimisé pour Google, qui corresponde à mes valeurs éditoriales, sans être générique. Une phrase, une vingtaine de contraintes implicites, et un espoir que le modèle les gère toutes simultanément.

Ce n'est pas différent de demander à un collaborateur d'être à la fois éditeur, correcteur, spécialiste SEO et gardien de la voix de la marque, dans le même souffle, sans leur donner de rôle distinct. Les rôles se contaminent. L'éditeur commence à optimiser les titres pour Google avant d'avoir trouvé l'angle. Le spécialiste SEO ramollit la thèse pour toucher un public plus large. Personne ne fait vraiment son travail parce qu'il essaie de faire celui des autres en même temps. C'est le même phénomène que la fragmentation de l'attention décrit dans deep-work-comment-apprendre-a-se-concentrer-et-reduire-les-distractions : diviser une tâche cognitive en plusieurs sous-rôles simultanés, c'est garantir que chacun est mal fait.

La décision qui a changé les choses, c'est la séparation. Pas "un prompt plus long et plus précis", mais deux skills distincts qui n'interviennent jamais en même temps[^2].

Éditorial d'abord : le premier rôle ne pense pas au SEO

Le premier skill a un seul rôle : produire un article qui ressemble à Parhélio. Angle précis, ancrage réel dans du vécu, voix sobre, position lisible, nuance exprimée une fois. Cinq filtres à passer avant de commencer à écrire. Un contrat de sortie à vérifier avant de livrer.

Ce skill ne se préoccupe pas de Google. Il ne regarde pas ce qui rankent sur les premières positions. Il n'essaie pas d'intégrer de mots-clés. Il écrit comme si le SEO n'existait pas, parce que mélanger les deux au même moment produit quelque chose qui rate les deux.

La séquence compte. On n'optimise pas ce qu'on n'a pas encore écrit.

Le SEO comme passe distincte : trouver l'intersection requête / angle

Une fois l'article écrit, un deuxième skill intervient. Il ne touche pas au fond, pas à la voix, pas aux exemples. Il fait une chose : trouver l'intersection entre ce que les gens cherchent vraiment et l'angle spécifique que l'article apporte.

Ce concept d'intersection est la décision la plus importante de ce workflow. Parhélio ne peut pas et ne cherche pas à ranker sur "analyse SWOT" en concurrence avec Asana ou Wikipedia. La question pertinente n'est pas "quel mot-clé a le plus de volume ?" mais "sur quelle requête l'angle spécifique de cet article constitue une vraie réponse différenciée ?"

Exemple concret : un article qui dit que l'analyse SWOT ne sert à rien si elle ne change pas de décision. La requête à cibler n'est pas "SWOT définition". C'est quelque chose comme "comment utiliser les résultats d'une analyse SWOT" ou "analyse SWOT comment en tirer des décisions". Le titre absorbe le mot-clé sans trahir la thèse. Le slug se raccourcit. L'excerpt répond à l'intention en moins de 160 caractères.

C'est tout ce que ce skill fait. Pas réécrire, pas reformater, juste ajuster les éléments de surface pour que Google comprenne de quoi il s'agit, et pour que le lecteur qui cherche cette chose précise reconnaisse qu'il est au bon endroit.

Un index d'articles pour des liens internes pertinents

Un problème pratique s'est posé à chaque passe SEO : pour suggérer des liens internes pertinents, il faut savoir ce qui est déjà publié. Parcourir trente fichiers à la recherche d'un article sur la routine ou sur l'attention prend du temps, charge du contexte inutilement et produit des oublis.

La solution est banale mais efficace : un fichier index. Trente articles publiés, classés par thème, avec pour chacun le slug, le titre, les thèmes principaux et l'angle en une ligne. Une ligne par article, une mise à jour manuelle à chaque publication.

Ce n'est pas glamour. Mais ça illustre quelque chose que j'observe à chaque fois qu'on construit un système avec l'IA : les outils simples et explicites surpassent les solutions sophistiquées et opaques. Un modèle qui lit un index bien structuré fait de meilleures suggestions qu'un modèle qui parcourt tout le vault en espérant trouver ce qui est pertinent. (voir aussi [[construire-parhelio-nextjs-obsidian]] pour les autres décisions d'architecture du site)

Ce que ce workflow ne résout pas

Ce workflow a deux points de fragilité.

Le premier est la densité des instructions. Chaque skill contient plusieurs centaines de mots de règles, d'exemples, de contre-exemples. C'est nécessaire pour produire quelque chose de calibré. Mais plus les instructions sont longues, plus elles consomment du contexte disponible, et plus il y a de risque qu'une règle soit ignorée parce qu'elle se retrouve trop loin dans la fenêtre d'attention. On a regardé une version compressée à 50% des deux skills. Elle tient presque autant, mais perd de la précision sur un ou deux points critiques, notamment la mécanique de décentrage progressif du "je". Ce n'est pas résolu.

Le second est la dépendance à l'ancrage. Si le brouillon source ne contient pas d'expérience réelle, de décision concrète ou d'observation vécue, les skills ne peuvent pas en fabriquer. Ils peuvent en revanche en inventer une qui sonne juste, et c'est exactement ce qu'il faut éviter. Le filtre "il y a-t-il un ancrage réel ?" est là pour ça, mais il ne marche que si on lui donne un matériau honnête à travailler.

Architecture plutôt que prompt : ce que ça change vraiment

Ce workflow n'est pas une solution universelle. Il est calibré pour un site précis, une voix précise, un volume de contenu qui reste gérable manuellement.

Ce qu'il m'a appris, c'est que la question n'est pas "est-ce que l'IA peut bien écrire ?" mais "à qui est-ce qu'on demande de faire quoi, dans quel ordre, avec quelles contraintes ?" Un modèle avec un rôle précis, des règles claires et un périmètre défini produit quelque chose de bien plus utilisable qu'un modèle auquel on demande de tout faire en une fois.

C'est une question d'architecture, pas de prompt.

Et comme pour la plupart des systèmes, le design compte plus que la puissance brute.

---

[^1]: Ce phénomène de contenu IA uniformisé est documenté par plusieurs praticiens du marketing de contenu. HubSpot — 12 outils d'IA pour la rédaction et comment éviter l'uniformité du contenu.

[^2]: Le principe d'assigner un rôle précis à un modèle (role prompting) est l'une des pratiques les plus efficaces pour orienter les sorties vers un résultat spécifique. OpenAI — Guide du prompt engineering.