Leaders d’opinion

Lorsque l’IA modifie le document, qui possède la modification ?

mm
Ajouter Unite.AI à vos sources préférées sur Google

Un document peut indiquer qui a modifié une phrase tout en vous laissant deviner qui a approuvé ce qu’il dit maintenant. Une fois que l’IA et les personnes ont toutes deux révisé le libellé, un nom à côté de la modification finale ne répond pas à cette question.

Considérez une politique de support hypothétique promettant une réponse sous deux jours ouvrables. Une réécriture par IA propose un jour ouvrable. Un éditeur humain la modifie à trois, et un responsable d’équipe approuve le document. Le fichier publié a l’air ordinaire. Son historique contient une proposition rejetée, une révision humaine, et une décision sur ce que les clients doivent attendre.

Qui possède cette modification ? Nous devons distinguer les contributions avant de pouvoir attribuer la responsabilité de leur diffusion. Sinon, « assisté par IA » nous indique très peu sur la façon dont le libellé final est arrivé là.

Séparer la modification de la décision

L’annonce de Microsoft du 29 septembre 2025 selon laquelle Agent Mode in Word commençait son déploiement Frontier a intégré l’édition conversationnelle dans l’application de traitement de texte, d’abord sur le web. Cette annonce fixe la date de déploiement, pas la manière dont une organisation particulière examine les changements résultants.

Pour une équipe utilisant l’IA de cette façon, le point de départ utile est la personne qui demande la modification. Enregistrez cette personne séparément du logiciel qui la génère. Si quelqu’un réécrit ensuite la suggestion, conservez également cette contribution. L’approbation constitue une autre action, rattachée à la version que le relecteur a réellement vue.

Ces rôles ne nécessitent pas des personnes distinctes pour chaque tâche. Un éditeur peut demander une réécriture, la réviser, et avoir l’autorité de l’approuver. La distinction reste importante : demander un paragraphe plus court ne signifie pas nécessairement approuver chaque modification apportée par le logiciel.

Le W3C PROV data model fournit un vocabulaire pour décrire cet historique. Les documents et leurs versions peuvent être représentés comme des entités ; les modifications et les approbations comme des activités ; les personnes et les logiciels comme des agents. Le modèle décrit les relations entre eux. Il ne détermine pas la responsabilité juridique ni n’authentifie la personne apparaissant dans le champ auteur.

Pour les flux de travail de documents assistés par IA impliquant la rédaction technique ou du matériel de support, cela signifie définir ce que représente chaque action enregistrée. Un commentaire identifie une contribution à la discussion. Une approbation doit identifier l’autorisation de publier une formulation particulière. Attribuer aux deux le même statut générique « revu » rendrait l’enregistrement moins utile.

Construire un enregistrement pour un passage modifié

Revenons à l’exemple du délai de réponse. Avant de générer une réécriture, conservez le libellé approuvé de deux jours ouvrables ainsi que la version du document. Attribuez à la modification proposée un identifiant, puis reliez les révisions et décisions ultérieures à celui-ci.

Ce qui suit est une conception illustrative, avec des identifiants inventés. Il ne s’agit pas d’une sortie d’un produit testé ni d’un schéma supporté par tous les outils de traitement de documents.

Élément d’enregistrement Ce qu’il faut conserver
Document et emplacement ID du document, version de base v12, et le passage concerné. Utilisez un identifiant de passage stable lorsqu’il est disponible ; la pagination peut changer.
Proposition d’IA C17 Libellé original et réponse proposée d’un jour ouvrable ; heure de génération, identité authentifiée de l’utilisateur demandeur et identité du logiciel. Enregistrez les détails du modèle lorsqu’ils sont exposés ; sinon indiquez-les comme inconnus.
Révision humaine C17b Modification de l’éditeur à trois jours ouvrables, son identité, et sa relation avec C17.
Décision de révision C17 rejeté ou remplacé ; C17b accepté. Identifiez l’approbateur et l’heure de la décision, avec une raison lorsque le changement en justifie une.
Version publiée v13 Le fichier publié, son propriétaire responsable, et une connexion conservée avec la révision acceptée.

Conservez la proposition d’IA après que la révision humaine l’ait remplacée. Si l’enregistrement ne conserve que le libellé final de trois jours ouvrables, un relecteur ultérieur ne pourra pas reconstituer la suggestion antérieure à partir de cette entrée. Les modifications rejetées font partie de l’historique même si elles n’appartiennent pas au texte publié.

Le Generative AI Profile de juillet 2024 du NIST décrit la provenance comme des informations sur l’origine et l’historique du contenu, incluant les modifications et les sources. Il recommande également d’évaluer la relation entre les processus de provenance et les relecteurs humains. Le tableau applique cette idée à un flux de travail de documents ; il ne s’agit pas d’une liste de contrôle de certification du NIST.

Vous pouvez conserver cet enregistrement dans le système de documents ou dans un référentiel connecté. Dans les deux cas, rendez la relation avec la version publiée suffisamment explicite pour qu’une personne puisse la récupérer sans dépendre de la mémoire de l’éditeur d’origine.

Vérifier ce qui survit au transfert

Un fichier exporté mérite sa propre vérification. L’historique disponible pendant l’édition peut différer de ce qu’un destinataire peut inspecter, selon l’application, le format et les paramètres d’exportation. Ne supposez pas que chaque PDF perd l’attribution, ou que la conservation des commentaires visibles préserve chaque décision de révision.

La documentation pour l’édition avec Copilot de Microsoft indique que ses modifications respectent le suivi des modifications lorsque cette fonctionnalité est activée. C’est une fonctionnalité utile. Cela n’établit pas que votre historique complet d’approbation survive à chaque conversion ou transmission ultérieure.

Testez le parcours réellement utilisé par votre équipe. Faites passer le document d’exemple par la révision puis l’exportation, puis essayez de récupérer la révision acceptée et son approbateur à l’aide des enregistrements conservés. Si le fichier publié ne peut pas contenir cet historique, conservez un enregistrement contrôlé ailleurs et préservez le lien entre les deux.

Les cas moins simples méritent également de l’attention. N’acceptez qu’une partie d’une suggestion et examinez ce que l’enregistrement indique. Faites travailler deux réviseurs sur la même version de base, puis déterminez quelles modifications ont atteint le fichier publié. Enfin, modifiez le passage après approbation et vérifiez que la décision antérieure ne s’est pas transformée silencieusement en approbation de la nouvelle formulation.

Un nom d’auteur affiché doit être traçable à un compte authentifié avant que vous ne vous fiez à lui pour identifier la personne. De même, un condensé de fichier peut aider à identifier l’artefact publié, mais il ne peut pas vous dire si l’engagement de délai de réponse est correct. Ce sont des contrôles distincts, et votre processus de révision doit préserver cette distinction.

Définir la frontière d’approbation avant la publication

Modifier le format d’un titre et modifier un engagement client ne doivent pas forcément suivre les mêmes voies de révision. Décidez quelles modifications peuvent être effectuées selon une politique établie et lesquelles nécessitent l’approbation d’une personne désignée. Ce choix doit refléter ce que le changement implique pour les utilisateurs du document.

L’argument en faveur de l’autorité explicite de décision IA devient pratique ici. Dans notre exemple, quelqu’un doit disposer de l’autorité pour approuver un engagement de réponse de trois jours ouvrés. Le simple droit de modifier le fichier ne doit pas être considéré comme une preuve de cette autorité.

Donnez à ce réviseur suffisamment de contexte pour décider. Montrez le texte original et la formulation proposée côte à côte, ainsi que toute révision humaine intermédiaire. Rendez les conflits non résolus visibles et identifiez la version destinée à la publication. Un réviseur qui ne voit qu’un paragraphe final poli peut ne pas remarquer que le délai de réponse a changé.

Déterminez qui possède la publication avant de confier le flux de travail aux utilisateurs. Cette personne n’a pas besoin d’effectuer chaque modification, mais elle doit disposer d’un moyen de vérifier que la révision requise a eu lieu et s’applique au fichier qu’elle publie. Laisser l’attribution vague complique la résolution d’un changement contesté lorsque le document est prêt à être diffusé.

Cela ne nécessite pas de conserver indéfiniment chaque invite confidentielle. Conservez les preuves nécessaires pour expliquer la décision conformément à la politique d’accès et de conservation de votre organisation. Si l’information sur la version du modèle n’est pas disponible, consignez cette limitation. Un historique utile doit rendre les informations manquantes apparentes plutôt que d’impliquer un niveau de détail que le système n’a jamais capturé.

Publier uniquement la version que vous pouvez justifier

Avant de publier une modification importante, essayez de la retracer dans les enregistrements. Trouvez la suggestion originale, déterminez ce que l’éditeur humain a modifié, et récupérez la décision d’acceptation de cette révision. Comparez ensuite la version approuvée avec le fichier livré.

Si ce lien fait défaut, suspendez la modification de révision. Le fait que quelqu’un se souvienne que le document a été « approuvé » ne suffit pas à établir quelle formulation il a approuvée.

Un éditeur doit pouvoir expliquer sa contribution sans être assigné à chaque suggestion générée par l’IA. Le responsable de la publication doit savoir précisément ce qu’il autorise. Nous ne pouvons pas demander aux personnes de soutenir des changements sans leur fournir un moyen fiable d’inspecter comment ces changements ont été effectués.

Gary est un écrivain expert avec plus de 10 ans d'expérience dans le développement de logiciels, le développement web et la stratégie de contenu. Il se spécialise dans la création de contenu de haute qualité et engageant qui stimule les conversions et renforce la loyauté de la marque. Il a une passion pour créer des histoires qui captivent et informent les publics, et il cherche toujours de nouvelles façons d'engager les utilisateurs.