C'est une excellente conclusion. Le fait d'avoir externalisé la configuration rend le script **générique** et **réutilisable** pour n'importe quel projet futur.

Voici le **Prompt Expert Ultime**. Il capitalise sur toutes les itérations (V1 à V105) et spécifie explicitement l'architecture "Moteur + Configuration" pour qu'une IA puisse recréer cette solution parfaite du premier coup.

---

# Prompt Expert : Convertisseur Universel ODT vers MkDocs (Configurable)

**Rôle :** Tu es un Architecte Logiciel Senior, expert en Python, XML (ODF) et Générateurs de Sites Statiques.

**Objectif :** Créer un moteur de conversion robuste (`convert.py`) capable de transformer n'importe quel document technique `.odt` (structuré ou issu de Word) en un site MkDocs professionnel.

**Philosophie d'Architecture :**
Le script doit être **agnostique** du contenu. Toutes les spécificités du projet (URLs, langage de programmation, mots-clés des styles) doivent être chargées depuis un fichier externe `config.json`.

* **Usage :** `python convert.py <document.odt> <config.json>`

**Règles Techniques Impératives :**

### 1. Gestion de la Configuration (JSON)

Le script doit charger un fichier JSON contenant deux sections :

* `mkdocs` : Métadonnées (site_name, site_url, repo_url, author...).
* `code` : Paramètres de syntaxe (`language`: ex "python" ou "vbscript", `style_keywords`: liste des styles ODT à considérer comme du code).

### 2. Algorithme de Détection des Titres (Mode "Strict & Sûr")

Pour éviter les faux positifs (comme "Remarque :" en gras), la détection doit être conservatrice :

* **Oui :** Balises `<text:h>`, styles contenant "Heading"/"Titre"/"Chapitre", ou attribut `outline-level` explicite.
* **NON ABSOLU :** Si le style est identifié comme "Normal", "Standard", "Text body" ou "Corps de texte", il ne doit **JAMAIS** être converti en titre, même s'il est en gras, court ou souligné.

### 3. Gestion Avancée des Tableaux ("Aplatissement Visuel")

Le Markdown gère mal les blocs complexes (code + listes) dans les cellules de tableau HTML.

* **Stratégie :** Dans les cellules (`<td>`), ne **jamais** générer de balises de liste HTML (`<ul>`, `<li>`).
* **Pour le Code :** Extraire le texte brut et créer un bloc de code Markdown (````lang ... ````). Fusionner les lignes consécutives en un seul bloc.
* **Pour les Listes :** Simuler visuellement la liste en ajoutant une entité HTML `&bull; ` devant le texte du paragraphe.

### 4. Traitement du Texte et Images

* **Images :** Lire les dimensions (`width`, `height`) sur le cadre parent (`draw:frame`) et générer une balise `<img>` avec attributs `style`. Ignorer le texte contenu dans le cadre (ex: "Image1").
* **Échappement Markdown :** Dans le texte courant (hors code), échapper systématiquement les astérisques (`*`  `\*`) pour éviter l'interprétation italique/liste accidentelle.

### 5. Intégrité du Projet

* Générer un fichier `mkdocs.yml` complet basé sur les données du JSON.
* Copier automatiquement les fichiers racines critiques (`robots.txt`, fichiers de validation Google) s'ils existent.
* Générer les assets CSS/JS pour le mode "Focus" et le footer personnalisé (`overrides`).

**Structure attendue du fichier de configuration (`config.json`) :**

```json
{
    "mkdocs": {
        "site_name": "Titre du site",
        "site_url": "https://...",
        "repo_url": "https://github.com/..."
    },
    "code": {
        "language": "python",
        "style_keywords": ["code", "consolas", "source"]
    }
}

```

**Livrable :** Le script Python complet et commenté, utilisant `odfpy`, sans aucune constante "en dur" liée au contenu spécifique.