WebInnovant

Comment j'ai construit un pipeline qui écrit des livres tout seul

Retour technique sur un projet R&D : un pipeline Python qui génère des romans et essais complets, de l'idée brute au DOCX prêt pour Amazon KDP.

Le projet🔗

Il y a quelques mois, je me suis posé une question simple : est-ce qu'on peut automatiser entièrement l'écriture d'un livre ? Pas générer quelques chapitres à la volée — produire un roman de 200 pages, cohérent du début à la fin, prêt à être publié sur Amazon KDP.

La réponse est oui. Mais ça demande beaucoup plus de travail que ce qu'on imagine.

Cet article raconte comment j'ai construit le pipeline, quels problèmes j'ai rencontrés, et ce que ça m'a appris — sur l'IA, sur l'automatisation, et sur la construction de systèmes robustes.

Le vrai défi🔗

Quand on parle d'IA générative, on pense tout de suite au modèle. Le modèle n'est pas le problème. NVIDIA Nemotron 3 Ultra, que j'utilise, produit du texte de très bonne qualité. Le défi est ailleurs.

Trois problèmes à résoudre :

  1. La cohérence sur 200 pages — un LLM qui écrit chapitre par chapitre perd la continuité : il répète des informations, oublie ce qu'il a révélé plus tôt, contredit ses propres personnages
  2. La qualité objective — comment savoir si un chapitre est bon, sans le lire ? Comment détecter automatiquement les formules répétitives, les clichés, les incohérences ?
  3. La robustesse — un pipeline qui tourne plusieurs heures doit survivre aux erreurs d'API, aux timeouts, aux crashs

C'est ces trois problèmes que le pipeline résout — pas la génération de texte en elle-même.

L'architecture du pipeline🔗

Brief IA (titre, contexte, persona)
    ↓
Plan critiqué (3 tours max)
    ↓
Carte des révélations + canon de continuité
    ↓
Écriture chapitre par chapitre (avec détecteurs)
    ↓
Relecture chapitre (continuité + qualité)
    ↓
DOCX KDP 6x9 pouces
    ↓
Relecture finale (note, catégories, mots-clés)
    ↓
Export PDF + EPUB + couverture

Sept étapes, chacune avec ses propres défis.

Étape 1 : Le brief🔗

Le pipeline ne demande qu'une chose à l'utilisateur : une idée de livre, ou rien du tout. Si rien n'est fourni, l'IA invente tout — titre, sous-titre, auteur, type (roman ou essai), contexte, persona, longueur cible.

C'est le point d'entrée : python ecrire_livre.py --sujet "mon idée" ou juste python ecrire_livre.py pour une génération 100% autonome.

Étape 2 : Le plan critiqué🔗

Un premier LLM génère un plan chapitre par chapitre. Un second LLM joue le rôle de script-doctor : il relit le plan, identifie les problèmes (rythme, structure, redondances), et propose des corrections. Jusqu'à 3 tours de critique.

C'est à cette étape qu'on définit :

  • Le budget de mots par chapitre (réparti intelligemment selon l'importance)
  • La carte des révélations — quel chapitre révèle quelle information, pour éviter que la même chose soit dite trois fois
  • Le canon de continuité — les personnages, les lieux, les dates, les règles du monde

Étape 3 : Écriture avec détecteurs🔗

Chaque chapitre est écrit section par section, avec des détecteurs qui n'utilisent pas d'IA :

  • Reprises textuelles (même phrase qui revient)
  • Formules mantra (expressions utilisées plus de X fois)
  • Clichés (liste pré-établie, extensible)
  • Longueur anormale (chapitre trop court ou trop long)

Si un détecteur déclenche, la section est régénérée avec un guidage — on dit au modèle quel problème corriger, pas juste « réécris ».

Pour les chapitres critiques (ouverture, climax, fin), deux versions sont écrites en parallèle, puis départagées par une note automatique.

Étape 4 : Relecture chapitre🔗

Une fois un chapitre écrit, un second LLM le relit pour vérifier :

  • Roman : continuité avec les chapitres précédents, réalisme, absence de répétitions
  • Essai : exactitude des sources citées (vérification Crossref / Open Library)

Si la note est trop basse, le chapitre est réécrit.

Étape 5 : DOCX KDP🔗

C'est ici qu'on passe du texte au livrable commercial. Le pipeline génère un fichier DOCX formaté aux normes Amazon KDP :

  • Format 6×9 pouces (le standard broché)
  • Marges correctes selon le nombre de pages
  • Numérotation des pages
  • Table des matières paginée
  • Notes de bas de page (essais)
  • Bibliographie et glossaire (essais)

Étape 6 : Relecture finale🔗

Le livre entier est relu par un LLM avec un mandat précis : donner une note globale, proposer 3 catégories KDP (le classement Amazon), suggérer 7 mots-clés optimisés pour la recherche Amazon.

Si la note est basse, une révision automatique est déclenchée — avec rollback si le livre s'est dégradé après la révision.

Étape 7 : Export🔗

Via LibreOffice en ligne de commande :

  • PDF final (pagination exacte)
  • EPUB (format ebook)
  • Couverture
  • Description Amazon optimisée

Les problèmes que j'ai dû résoudre🔗

Le problème de la continuité🔗

Un LLM qui écrit un chapitre voit uniquement ce qu'on lui donne en contexte. Sans mécanisme, il oublie ce qui s'est passé aux chapitres précédents.

Solution : un canon de continuité qui est mis à jour à chaque chapitre. À chaque itération, on redonne au modèle :

  • Les 2-3 derniers chapitres (résumés)
  • Le canon actuel (personnages, lieux, faits établis)
  • La carte des révélations (ce qui a déjà été révélé, ce qui reste à révéler)

C'est coûteux en tokens, mais c'est ce qui fait la différence entre un livre cohérent et un patchwork.

Le problème de la qualité objective🔗

Comment noter un chapitre automatiquement ? Sans accès à un humain, on ne peut pas mesurer « la beauté » d'un texte. Mais on peut mesurer des choses objectives :

  • Longueur (dans la cible ?)
  • Richesse lexicale (pas de répétitions anormales)
  • Densité d'information (pas de remplissage)
  • Présence des éléments narratifs attendus (personnage X, événement Y)

Le pipeline combine ces mesures pour calculer une note approximative. Ce n'est pas parfait, mais c'est suffisant pour détecter les chapitres problématiques.

Le problème de la robustesse🔗

Un pipeline qui tourne plusieurs heures doit survivre aux erreurs :

  • API qui timeout
  • Modèle qui renvoie du JSON malformé
  • Crash Python
  • Sauvegarde disque pleine

Solution : un système de sauvegarde d'état à chaque étape. Si le script plante, on le relance, il reprend exactement là où il s'était arrêté.

Le problème du mode pilote🔗

Avant de lancer une production complète (2-4 heures, potentiellement coûteuse en API), on veut tester la qualité du plan et de l'écriture.

Le mode --pilote N écrit N chapitres, mesure les résultats, calibre les seuils, puis s'arrête. On peut ensuite décider de continuer ou d'ajuster.

Ce que le pipeline produit🔗

Quelques livres auto-publiés sur Amazon KDP, sous pseudonymes (Ben Cob, Mila Jones). Romans et essais, format 6×9, couverture générée, description Amazon optimisée.

Le coût de production est proche de zéro :

  • Modèle Nemotron 3 Ultra : gratuit
  • Pas de stock, pas de logistique
  • Publication KDP : gratuite

Les revenus sont modestes — on ne parle pas de best-sellers. Mais ils sont passifs et réguliers, et surtout : le pipeline tourne tout seul.

Ce que ça m'a appris🔗

Trois leçons que j'applique maintenant à tous mes projets d'automatisation :

1. L'IA seule ne suffit jamais🔗

Un LLM génère du texte. Un système produit un livrable. La différence, c'est tout ce qu'on ajoute autour : détecteurs, contrôles, reprises, sauvegardes.

2. La robustesse se construit🔗

Les API tombent. Le disque se remplit. Le réseau coupe. Un système qui ne survit pas à ces aléas n'est pas un système — c'est une démo.

3. La qualité se mesure🔗

On ne peut pas tout mesurer. Mais on peut mesurer assez pour détecter les pires cas et les corriger automatiquement. C'est mieux que de ne rien mesurer du tout.

Ce que ça peut apporter à une PME🔗

Ce projet est un R&D personnel, mais il utilise exactement les mêmes compétences que je mets au service des PME qui veulent automatiser leurs processus :

  • Orchestration de modèles IA
  • Contrôle de qualité automatique
  • Gestion d'état et reprise sur erreur
  • Production de livrables conformes à des contraintes externes strictes

Le pipeline de livres pourrait être adapté à d'autres cas :

  • Génération automatique de fiches produits à partir d'un catalogue
  • Rédaction de newsletters personnalisées
  • Création de rapports techniques à partir de données
  • Production de contenus marketing répétitifs

C'est le même savoir-faire. Appliqué à d'autres problèmes.

Vous avez un processus de création répétitif dans votre PME ? Parlons-en. Ce que j'ai construit pour les livres peut probablement s'appliquer à votre cas.

→
← Tous les articles