Ce que fait réellement une conversion PDF vers Word, vu par son journal d’étapes

Convertir un PDF en document modifiable est généralement décrit comme une action. Ce n'en est pas une. Une exécution réelle de ce site comporte huit étapes enregistrées, dont deux échecs dont le pipeline se remet. Le journal vaut la lecture : il explique à la fois le prix et le comportement en cas d'échec.

Le journal d’une tâche réussie

inspect_document              pypdf-docx-editable     884 ms
  extract_document_content     pypdf-docx-editable     644 ms
  render_document_page         pypdf-docx-editable     482 ms  error: unsupported_renderer
  convert_to_editable_document compact_spacing         424 ms  error: strategy_requires_optimization
  convert_to_editable_document (retry)                1357 ms
  validate_editable_document                           4289 ms
  optimize_document_candidate  compact_spacing        1040 ms
  validate_editable_document (after optimise)          3875 ms

Deux de ces lignes sont des erreurs, et la tâche a pourtant réussi. C'est la conception : une erreur à une étape est une information que la boucle utilise, pas un verdict sur le document.

Pourquoi il rend sa propre sortie

L'étape la plus importante est validate_editable_document, et c'est la plus longue : 4,3 secondes ici. Elle rend le DOCX qui vient d'être produit sous forme d'image et la compare à la page source. Couverture du texte, nombres manquants, structure des tableaux, cellules fusionnées, bordures, texte hors des limites de la page.

C'est la différence entre « la conversion a tourné » et « la conversion a produit quelque chose d'utilisable ». Un pipeline qui s'arrête après avoir écrit le fichier ignore si le fichier est correct ; un contrôle qui lit seulement le XML du DOCX peut confirmer que les paragraphes existent alors que la page rendue a perdu la moitié du texte. Rendre à nouveau est la façon de le découvrir.

L'erreur unsupported_renderer à la troisième étape est la version honnête de la même idée : le moteur de rendu essayé ne pouvait pas faire le travail, le pipeline le dit au lieu de sauter la vérification et de prétendre que la sortie a été contrôlée.

La boucle de réparation

Quand la validation trouve un problème, le pipeline n'échoue pas immédiatement. Il optimise le candidat — ici une stratégie d'espacement compact pour faire tenir un contenu qui débordait — puis valide à nouveau. Les deux conversions du journal sont le même document converti deux fois avec des stratégies différentes, et la première tentative a été explicitement rejetée par la porte d'optimisation avant la seconde.

C'est pourquoi une tâche réussie prend 35 à 70 secondes sur ce site, contre 12 à 32 pour un échec. L'échec interrompt la boucle ; le succès la mène au bout, avec au moins un nouveau rendu complet et une comparaison. Payer le chemin lent est le but : le chemin rapide produit des documents qui semblent corrects et auxquels il manque une colonne.

Ce que signifie un échec ici

Sur les conversions enregistrées sur ce site, sept ont échoué et neuf ont réussi. Les sept échecs portent le même code agent_execution_failed : la boucle a épuisé ses tentatives de réparation, sans problème de facturation ni de réseau. Dans chaque cas aucun fichier n'a été publié et les crédits réservés ont été libérés.

Cette distinction compte quand vous décidez de réessayer. Ici, un échec est une affirmation sur le document — ce scan n'a pas survécu à la conversion dans les tentatives disponibles — pas sur une panne du service. Renvoyer le même fichier échouera généralement de la même façon. Un scan plus net, ou un PDF numérique plutôt qu'une photo, change le résultat.

Ce dont les réussites avertissent encore

Chaque conversion réussie sur ce site porte l'avertissement layout_approximate, et ce n'est pas un défaut excusé. Convertir une page à mise en page fixe en document fluide empêche les polices et espacements de correspondre à l'original : celui-ci n'avait aucune structure réorganisable à préserver. Une image de page correspondrait exactement, mais rien ne serait modifiable, ce qui en détruirait l'intérêt.

Savoir lequel des deux vous voulez fait l'essentiel de la décision. Si le document doit être identique, il vous faut un PDF, pas un Word. S'il doit être modifiable, une mise en page approximative est le prix, et la question utile devient : le texte, les nombres et les tableaux ont-ils survécu ? C'est exactement ce que mesure l'étape de validation.