Bonjour à toutes et à tous, Suite aux échanges récents sur la maintenabilité, la conversion et la pérennité des documents ODT, je souhaite partager **un retour d’expérience strictement technique**, documenté, reproductible, issu d’un cas réel.
L’objectif n’est pas de polémiquer, mais de **documenter précisément une situation où un document ODT est parfaitement lisible dans LibreOffice Writer, tout en étant structurellement impropre comme source documentaire** (conversion, versionnement, audit). --- ## 1. Contexte Document analysé : * *LibOBasic_01_IDE_Flat_A4_FR_v200.odt* * Aide-mémoire LibreOffice Basic (document réel, diffusé) * Visuellement correct et exploitable dans Writer Problème constaté : * Échec de conversion vers Markdown avec Pandoc * Impossibilité d’exploiter le document comme source textuelle structurée --- ## 2. Vérification du conteneur (niveau ZIP / ODT) Un ODT est un conteneur ZIP. Première étape : vérifier le conteneur, hors éditeur. ```bash zip -T LibOBasic_01_IDE_Flat_A4_FR_v200.odt ``` Résultat : **OK** Vérification de la conformité ODT minimale : ```bash unzip -lv LibOBasic_01_IDE_Flat_A4_FR_v200.odt | head ``` Points vérifiés : * `mimetype` présent * `mimetype` en première position * `mimetype` non compressé (`Stored`) ➡️ Le fichier est **conforme au niveau conteneur**. Le problème n’est **ni le ZIP, ni le renommage, ni l’outil de test**. --- ## 3. Test de conversion structurelle (Pandoc) ```bash pandoc -f odt -t native LibOBasic_01_IDE_Flat_A4_FR_v200.odt --verbose ``` Résultat : ``` [ Para [] , Para [] ] ``` Interprétation : * Pandoc parvient à lire le conteneur * Mais ne trouve quasiment **aucun contenu textuel exploitable** * Le document est donc **structurellement vide du point de vue d’un parseur strict** --- ## 4. Inspection de la structure XML (content.xml) Extraction : ```bash unzip LibOBasic_01_IDE_Flat_A4_FR_v200.odt content.xml ``` Recherche des zones de texte : ```bash grep -n "<draw:text-box" content.xml | head ``` Résultat : nombreuses occurrences. Recherche des cadres principaux : ```bash grep -n '<draw:frame' content.xml | head grep -n 'draw:name="CadrePage' content.xml ``` Constat clair : * Le texte est stocké majoritairement dans des **`draw:frame / draw:text-box`** * Cadres ancrés à la page (`text:anchor-type="page"`) * Cadres **chaînés** (`draw:chain-next-name`) * Absence de flux texte logique (`office:text` structuré) ➡️ Il s’agit d’une **composition graphique** (maquette), pas d’un document textuel structuré. --- ## 5. Extraction bas niveau du contenu (hors éditeur) Extraction du texte contenu dans les cadres : ```bash xmlstarlet sel -t \ -m '//draw:frame[draw:text-box]' \ -o '--- ' -v '@draw:name' -o ' (page ' -v '@text:anchor-page-number' -o ')' -n \ -m './/draw:text-box//text:p' -v 'normalize-space(.)' -n \ -n \ content.xml > extracted.txt ``` Résultat : * Texte intégral récupéré * Contenu présent, mais **hors structure documentaire** --- ## 6. Conclusion technique Ce document est : * ✔️ lisible dans LibreOffice Writer * ✔️ valide au niveau conteneur ODT * ❌ non exploitable comme source documentaire * ❌ non convertible proprement * ❌ non versionnable finement * ❌ non traduisible automatiquement **Cause unique** : > le contenu principal est stocké dans des objets graphiques (`draw:text-box`) > et non dans le flux texte ODF. --- ## 7. Conclusion générale > Un document peut être parfaitement lisible dans un éditeur tout en étant > structurellement impropre comme source. Ce constat : * n’est pas une critique de LibreOffice, * n’est pas une question d’opinion, * n’est pas visible depuis l’interface graphique, * **n’apparaît qu’au niveau structure XML**. C’est précisément ce niveau qu’il est nécessaire de documenter lorsqu’on parle de pérennité, de conversion et de maintenance. --- Cordialement, Bernard Schoenacker Rédaction technique / analyse documentaire -- Envoyez un mail à [email protected] pour vous désinscrire Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/ Privacy Policy: https://www.documentfoundation.org/privacy
