Contexte et objectifs

Paper Office est une suite de paquets Python conçue pour permettre aux agents d’IA de modifier des documents Word, PowerPoint et Excel tout en garantissant sécurité, correction et couverture fonctionnelle. Elle s’appuie sur les bibliothèques open source python‑docx, python‑pptx et OpenPyxl, qui, bien que matures, n’ont pas reçu de mises à jour majeures depuis plusieurs années et présentent des lacunes de fonctionnalité et d’assurance de conformité. Le format OOXML (ZIP contenant XML, images et ressources) impose une cohérence stricte entre les parties du fichier ; toute modification visible peut nécessiter des mises à jour multiples et synchronisées.

import docx
from pptx import Presentation
import openpyxl

Architecture et extensions des bibliothèques

Paper Office fork les bibliothèques d’origine, réécrit leurs API et ajoute des couches « agent‑first ». Les nouvelles fonctions exposent la structure interne du package sous forme de données typées, valident les cibles avant toute modification et offrent des chemins de sauvegarde qui préservent les parties non touchées. En cas d’opération non supportée, la bibliothèque refuse explicitement l’action au lieu de recourir à du code brut OOXML, évitant ainsi les régressions silencieuses (perte d’ancrages de commentaires, corruption de graphiques, dépendances de formules, etc.).

Les modules Paper DOCX et Paper PPTX illustrent ces principes : docx.search permet une recherche de texte à travers les fragments de run, docx.package.compare génère des modifications suivies au format natif Word, et pptx.inspect restitue la chaîne d’héritage de mise en forme (placeholder, layout, master, thème) avec provenance. Chaque modification est suivie d’une relecture du fichier sérialisé pour vérifier que l’effet attendu persiste.

Évaluation expérimentale

Sur un benchmark de cinq modèles d’IA et 61 tâches de manipulation de documents, les paquets Paper combinés à un guidage spécialisé ont atteint un taux de réussite de 92,5 %. En comparaison, les bibliothèques d’origine, sans compétences supplémentaires, ont obtenu 80,7 %, tandis que les compétences Office d’Anthropic ont atteint 69,5 %. Un autre indicateur clé est le recours au code brut : les agents ont écrit du code interne OOXML dans seulement 1,6 % des exécutions avec Paper, contre 78,7 % sans compétences et 50,5 % avec les compétences Anthropic. Ces chiffres démontrent que la couche d’abstraction de Paper réduit la dépendance aux scripts ad‑hoc et améliore la fiabilité des modifications.

Analyse des limites et perspectives

Malgré les gains, l’adoption en milieu professionnel reste limitée. Les agents peinent à reproduire les flux de travail humains, ce qui place les documents générés dans une « uncanny valley » peu adaptée à la consommation client. De plus, la suite ne couvre pas encore l’ensemble des scénarios complexes (ex. : macros VBA, intégration de contenus multimédias avancés). Le modèle de validation actuel repose sur des comparaisons de paquets et ne garantit pas l’absence totale de corruption dans les cas où le format OOXML évolue. Les prochains développements devront enrichir la prise en charge des extensions Office, améliorer la détection des régions non lisibles et fournir des métriques de conformité plus fines.