Test DOCX d’un AI humanizer : Track Changes et commentaires

Lors d’un test HumanPen mené le 31 août 2026, oui : un paragraphe sélectionné de 133 mots a changé, alors qu’une insertion suivie, une suppression suivie, un commentaire de relecteur, un contrôle de contenu, un signet avec champ REF et un tableau sont restés présents dans la DOCX retournée. HumanPen publie cet article et a mené le test sur son propre produit. Il s’agit d’un fichier et d’une exécution, pas d’une garantie pour tout document Word.

Nous n’avons utilisé aucun détecteur dans ce test. La question était plus étroite : lorsqu’un paragraphe précis est réécrit, que deviennent les objets Word situés en dehors de ce paragraphe ?

Nous avons examiné le fichier à trois niveaux. D’abord, nous avons compté ses structures Word internes. Ensuite, nous avons comparé chaque partie du paquet DOCX. Enfin, nous avons rendu l’entrée et la sortie et comparé les pages. Une vérification restait impossible : nous n’avons pas pu ouvrir, enregistrer, fermer et rouvrir manuellement la sortie dans Microsoft Word, faute d’autorisation de contrôle de l’ordinateur local. Cette lacune compte, et elle reste ouverte.

L’entrée était un document synthétique de deux pages, créé pour cette expérience. Il ne contenait aucun travail étudiant, aucune donnée de recherche, aucun matériel client. La page 1 portait les objets Word que nous voulions compter. La page 2 contenait un paragraphe ordinaire, désigné comme seule zone de réécriture.

Les marqueurs comprenaient `TRACK-ANCHOR-23`, `COMMENT-ANCHOR-47`, `CONTROL-TABLE-91`, `37.5%` et `12.40 mg`. L’étiquette du signet apparaissait deux fois par conception : une fois au signet et une fois comme résultat REF affiché.

Ce montage a une limite importante. Chaque objet instrumenté se trouvait en dehors du paragraphe sélectionné. L’exécution teste la conservation en dehors d’une zone de réécriture confirmée. Elle ne dit pas ce qui se passerait si une ancre de commentaire, une modification suivie, un champ ou un contrôle de contenu se trouvait à l’intérieur du paragraphe réécrit.

L’entrée intacte pesait 40 191 octets, avec ce SHA-256 :

`cccbac04cf9742037b16c453b54ae3c8a2300e7491ba31a213566c979c6fe4f1`

Ce hash identifie l’entrée exacte utilisée pour cette exécution. Un fichier différent, même identique à l’œil dans Word, produirait un hash différent.

Nous avons téléversé la DOCX vers HumanPen le 31 août 2026 à 20:00, heure standard de Chine. Nous avons choisi la stratégie Balanced v3 et le mode contenu spécifié, puis confirmé avant de lancer que la zone contenait un paragraphe et 133 mots anglais.

La durée de 32 secondes et les 14 crédits facturés sont le relevé de cette tâche, pas une promesse pour un autre fichier. Le temps de traitement et le coût peuvent varier selon le texte sélectionné et l’état du produit.

Le hash de sortie diffère du hash d’entrée, comme il se doit : le paragraphe sélectionné a changé. Un hash portant sur le fichier entier peut prouver que deux fichiers diffèrent, mais il ne peut pas dire si la différence se limite au paragraphe voulu. Il fallait pour cela une comparaison partie par partie.

Une DOCX est un paquet ZIP contenant des parties XML, des relations, des médias, des styles et d’autres ressources. L’entrée et la sortie contenaient chacune 20 parties, et les ensembles de noms de parties correspondaient exactement.

Les sept groupes de marqueurs ont aussi conservé leurs comptes d’entrée. Le pourcentage est resté `37.5%`, la mesure est restée `12.40 mg`, et aucune ancre protégée n’a gagné ni perdu d’occurrence.

Nous avons ensuite haché chaque partie interne. Dix-huit hash de parties étaient identiques, et deux différaient.

Dans `word/document.xml`, où vit le paragraphe du corps, le diff formaté contenait un seul nœud de texte `w:t` modifié : le paragraphe sélectionné. Aucun autre nœud formaté de cette partie n’avait changé.

La deuxième différence de hash brut concernait `[Content_Types].xml`. Elle est restée à 2 125 octets et a conservé les mêmes entrées `Default` et `Override`. La sortie a déplacé l’override existant de `/word/comments.xml` de la fin de la liste vers les autres overrides de Word. Aucun type de contenu n’a été ajouté, supprimé ou modifié. Cette différence d’ordre passe facilement inaperçue si une comparaison ne rapporte que les noms de parties ou l’ensemble des entrées analysées.

C’est plus solide que de dire que le fichier comptait toujours 20 parties. Une partie peut garder son nom de fichier alors que son contenu change. C’est aussi plus solide qu’un coup d’œil visuel, car une relation de commentaire ou un contrôle de contenu peut être présent dans le fichier sans ressembler à du texte de corps ordinaire.

Cela ne remplace pas le fait d’exercer chaque objet dans Word. Des comptes égaux et des structures XML concordantes montrent ce qui est resté dans le paquet. Elles ne montrent pas qu’un relecteur a cliqué sur le commentaire dans le volet de révision, accepté l’ancienne insertion, rejeté l’ancienne suppression ou actualisé le champ REF dans Word pour ordinateur.

Les deux versions ont produit deux pages. La comparaison d’images a identifié la page 2 comme la seule page modifiée.

• La page 1, qui contenait les modifications suivies, l’ancre de commentaire, le contrôle de contenu, le signet, le champ REF et le tableau, était visuellement inchangée.
• La page 2 a changé à l’endroit où apparaissait le paragraphe sélectionné.
• Les nouvelles longueurs de phrase ont provoqué un reflux de lignes normal à la page 2.
• La sortie rendue ne montrait ni texte tronqué, ni texte superposé, ni tableau manquant, ni géométrie de tableau cassée.

Le diff du texte extrait a atteint la même limite : il montrait le paragraphe sélectionné en train de changer, tandis que la note de zone qui le suit restait en place.

Le rendu répond à une autre question que l’audit du paquet. L’audit du paquet vérifie la structure. Le rendu vérifie les pages que verrait un lecteur. Un fichier peut réussir l’un et échouer l’autre : aucun des deux résultats ne doit donc tenir lieu des deux.

Un compte inchangé n’est utile que si le compteur peut détecter une perte. Nous avons testé cela avec deux copies volontairement endommagées.

Dans la première copie, nous avons retiré les structures de commentaire. Le même auditeur a alors rapporté zéro corps de commentaire, zéro ancre de plage, zéro référence de commentaire, zéro relation de commentaire et zéro entrée de type de contenu de commentaire.

Dans la seconde copie, nous avons accepté les modifications suivies. L’auditeur a rapporté zéro insertion suivie et zéro suppression suivie.

Ces contrôles positifs montrent que la procédure d’audit peut détecter les deux pertes que nous avons créées. Ils ne certifient pas l’auditeur contre toute défaillance DOCX possible. Une relation de dessin cassée, une équation malformée ou une macro endommagée demanderait sa propre vérification et son propre contrôle défectueux connu.

Utilisez une copie jetable. Votre test doit contenir les objets dont la réparation coûterait cher dans le vrai document, pas un paragraphe générique sans structure Word.

1. Ajoutez un exemple identifiable de chaque objet dont vous dépendez. Cela peut être une insertion suivie, une suppression suivie, un commentaire, un contrôle de gestionnaire de citations, un signet, un renvoi, une note de bas de page, un tableau, une équation ou une légende.
2. Placez une ancre unique à côté de chaque objet, comme `CHECK-COMMENT-01` ou un nombre avec son unité. Notez le compte attendu.
3. Gardez ces contrôles en dehors d’un paragraphe ordinaire. Ne sélectionnez que ce paragraphe pour la réécriture et confirmez la zone finale avant l’exécution.
4. Enregistrez l’entrée intacte. Notez sa taille en octets et son SHA-256. Une simple commande `shasum -a 256 your-file.docx` fonctionne sous macOS.
5. Après le téléchargement, notez les mêmes valeurs pour la sortie. Comparez les listes de parties de la DOCX, puis analysez les parties XML concernées pour compter les objets. N’allez pas fouiller les octets compressés de la DOCX et appeler cela un audit.
6. Rendez les deux fichiers avec le même moteur de rendu et comparez le nombre de pages, le texte et les images. Un reflux de lignes naturel n’a rien à voir avec une troncature, un chevauchement ou un objet manquant.
7. Ouvrez la sortie dans la version de Word pour ordinateur que vous utiliserez pour la remise. Inspectez All Markup et le volet Commentaires, exercez un contrôle de contenu, actualisez un champ, enregistrez sous un nouveau nom, fermez et rouvrez.
8. Faites une copie volontairement endommagée et vérifiez que votre contrôle signale la perte. Sans ce contrôle, un zéro propre peut simplement signifier que la mesure n’a jamais vu l’objet.

Ne regroupez pas ces vérifications en un pourcentage. Si le commentaire échoue alors que neuf autres lignes réussissent, le commentaire reste une exigence non satisfaite. La décision d’acceptation appartient à l’objet de document dont vous avez besoin.

Cette exécution ne permet pas d’affirmer une conservation universelle. Elle n’a pas testé :

• les commentaires ou modifications suivies à l’intérieur d’un texte réécrit ;
• des bibliothèques Zotero, EndNote ou Mendeley actives ;
• les notes de bas de page, équations, macros, fichiers intégrés, zones de texte ou images flottantes ;
• les en-têtes et pieds de page propres à une section ;
• une autre stratégie HumanPen ou la réécriture d’un document entier ;
• une autre version de Word ou un autre système d’exploitation ;
• la qualité factuelle du paragraphe réécrit ; ou
• un résultat de détecteur d’IA.

La réouverture manuelle dans Microsoft Word reste la plus grande vérification ouverte. Les résultats OOXML et de rendu sont des preuves, mais elles ne permettent pas d’affirmer que Word a ouvert le fichier sans avertissement de réparation, ni que chaque objet conservé est resté interactif.

La bonne conclusion est modeste et utile : dans cette unique exécution HumanPen en mode contenu spécifié, le paragraphe sélectionné a changé, les objets instrumentés en dehors ont conservé leurs structures de paquet mesurées, et le document rendu est resté intact. Votre propre DOCX a toujours besoin de son propre test d’acceptation.

HumanPen conserve-t-il Track Changes ? Dans cette unique exécution, une insertion suivie et une suppression suivie préexistantes sont restées présentes dans le paquet DOCX retourné. Nous ne les avons pas acceptées ni rejetées manuellement dans Microsoft Word : leur comportement dans Word pour ordinateur reste donc non vérifié.

HumanPen conserve-t-il les commentaires Word ? Dans ce fichier, le corps du commentaire, les ancres de début et de fin, la référence dans le document, la relation du paquet et l’entrée de type de contenu sont chacun restés présents. Le commentaire n’a pas été ouvert manuellement dans le volet Commentaires de Word après le téléchargement.

Un nombre de parties concordant prouve-t-il qu’une DOCX est sûre ? Non. Une partie peut garder le même nom alors que son contenu change. Comparez les hash de parties, inspectez le XML modifié, vérifiez les comptes au niveau des objets, rendez les pages et exercez les objets dans Word.

Dois-je attendre le même résultat pour ma thèse ou mon rapport ? Aucun montage de test ne peut couvrir tous les objets Word. Construisez un petit fichier de test qui reflète les structures de votre vrai document, lancez la même zone et les mêmes réglages que prévu, et conservez un original intact.