Ctrl+V dans Word perd les couleurs et les tailles de police ? Les données sont intactes : c'est un réglage par défaut qui a changé
2026-10-27
Tags: Windows · Presse-papiers · Tutoriel
Il y a quelques mois, nous avons publié RDP Clipboard Anchor. C'est un outil d'historique du presse-papiers spécialisé dans les scénarios de bureau à distance : tout ce qui est copié dans une session RDP est mis en cache et ancré localement, survit donc aux déconnexions et peut être retiré par glisser-déposer à tout moment. Sa liste d'historique est conçue autour de ce scénario de pont.
En mai dernier, un utilisateur a déposé une demande sur notre dépôt feedback : il voulait que l'historique du presse-papiers gère des catégories, avec les entrées fréquemment utilisées mises en favoris. Les catégories et les favoris sont des besoins de gestion de presse-papiers à usage général, au-delà du périmètre d'un outil de pont RDP. La demande pointait en réalité vers un autre produit : un gestionnaire de presse-papiers pour l'usage local quotidien. C'est dans cette direction que nous avons lancé ClipLab.
Puis, pendant les tests, nous sommes tombés sur le problème dont cet article parle.
Le symptôme qui n'avait aucun sens
Copier depuis Word un texte avec couleurs, tailles de police, gras et italique, laisser le presse-papiers être écrasé entre-temps par autre chose, puis retrouver cette entrée dans l'historique de ClipLab et la recoller dans Word. Les couleurs et les tailles ont disparu ; le gras et l'italique sont toujours là.
Le premier suspect, c'était nous : une partie des données s'est perdue au moment du stockage, ou au moment de la réécriture. Le métier même d'un gestionnaire de presse-papiers, c'est de stocker le contenu tel quel et de le restituer tel quel — si on n'y arrive pas, c'est un bug.
Nous avons donc d'abord audité les données sur toute la chaîne.
D'abord, vérifier que les données sont encore là
Le presse-papiers Windows permet au même contenu d'exister simultanément sous plusieurs formats. Quand Word copie un texte, il dépose une douzaine de formats à la fois : Rich Text Format, HTML Format, texte brut, plus une pile de formats natifs OLE (Embed Source, Native, etc.).
Nous avons écrit un script sonde qui utilise l'API Win32 brute (OpenClipboard / GetClipboardData) pour saisir les octets bruts de chaque format un par un, calculer leur hachage et les archiver. Puis nous avons fait une comparaison en trois étapes.
Étape une : après la copie, sortir les octets stockés de la base de l'outil et les comparer aux octets originaux du presse-papiers. HTML Format correspondait octet pour octet.
Étape deux : vider le presse-papiers, laisser l'outil réécrire l'entrée, ressonder. Les hachages correspondaient — toujours identiques octet pour octet.
Étape trois : contourner l'outil, faire remettre par la sonde les octets originaux de Word directement dans le presse-papiers, et coller dans Word.
L'étape trois perdait toujours les couleurs. Pas un octet ne manquait, et Word collait toujours de la même façon.
Les quatre options de collage de Word
Les données étaient saines ; place au comportement de Word. Le collage par clic droit fait apparaître les quatre options de collage de Word, et en les essayant une par une, le schéma devient clair :
| Option de collage | Couleur/taille | Gras/italique |
|---|---|---|
| Conserver la mise en forme source | ✅ | ✅ |
| Utiliser le thème de destination | ✅ | ✅ |
| Fusionner la mise en forme | ❌ | ✅ |
| Conserver le texte uniquement | ❌ | ❌ |
Les données sont complètes, et Word est parfaitement capable de les coller telles quelles — il suffit de choisir explicitement « Conserver la mise en forme source ». Mais lors d'un Ctrl+V ordinaire, Word décide tout seul et part sur « Fusionner la mise en forme » : gras et italique survivent ; police, couleur, taille et famille de police sont abandonnées. Cela correspond exactement à notre symptôme.
Alors, sur quoi Word se base-t-il pour décider de l'option par défaut ? Nous avons fait plusieurs tours d'élimination. D'abord l'angle des données : les 16 formats déposés par Word lors de la copie (y compris les natifs OLE comme Embed Source et Native), saisis octet par octet et rejoués à l'identique — couleurs perdues quand même. RTF seul, HTML seul — pareil. Ensuite l'angle de la source : le presse-papiers enregistre un « propriétaire », et Windows ne vérifie pas à qui appartient le handle de fenêtre passé à OpenClipboard. Nous avons donc passé directement le handle de la fenêtre principale de Word, rejoué tous les formats, puis confirmé avec GetClipboardOwner que le propriétaire était désormais la propre fenêtre de Word. Ctrl+V ordinaire — toujours Fusionner la mise en forme.
Il y a eu un détour en chemin : nous avons d'abord soupçonné le RTF de manquer de son terminateur NUL habituel — comblé, recollé, perdu quand même. Nous voulions WordPad comme témoin, mais Win11 l'a supprimé ; à la place, nous avons enregistré le RTF dans un fichier et l'avons ouvert directement dans Word — la mise en forme était complète.
À ce stade, la direction était claire : tout ce qui était testable côté données et côté source était épuisé, et Word restait systématiquement sur Fusionner la mise en forme. Ce n'est pas un problème de données ; c'est la politique permanente de Word face au « contenu provenant d'autres programmes ». Quant à ce qui lui permet de distinguer son propre contenu du contenu étranger, nous n'avons pas creusé — cela n'affectait pas la conclusion.
Le vrai interrupteur est un réglage
Cette politique se loge dans un réglage visible de l'utilisateur : Fichier → Options → Options avancées → Couper, copier et coller → « Coller à partir d'autres programmes ».
En mai 2024, l'équipe Word a annoncé sur le blog officiel Microsoft 365 ce changement de valeur par défaut pour Word 2405 : « Coller à partir d'autres programmes » est passé de « Conserver la mise en forme source » à « Fusionner la mise en forme ». Autrement dit, nous n'avions rien mal configuré — Word est ainsi dès l'installation : tout ce qui est classé comme « provenant d'autres programmes », ce qui inclut tout ce qu'un outil tiers réécrit, est dégradé sans exception par Ctrl+V.
Que faire
- Changer le réglage de Word (recommandé) : Fichier → Options → Options avancées → Couper, copier et coller, remettre « Coller à partir d'autres programmes » sur « Conserver la mise en forme source ». On change une fois, c'est réglé pour de bon. C'est la préférence de l'utilisateur lui-même ; un outil n'a pas à la décider à sa place.
- Coller par clic droit : si vous ne touchez pas au réglage, choisissez explicitement « Conserver la mise en forme source » dans le menu contextuel — un clic de plus à chaque fois.
- Aucune solution côté outil, et il n'en faudrait pas : tous les gestionnaires de presse-papiers, dans leur configuration par défaut, déclenchent la même dégradation. Les données sont déjà fidèles à l'octet près ; la seule marche au-dessus consisterait à se faire passer pour Word lui-même. Ce n'est pas une amélioration du collage, c'est une attaque par usurpation d'identité.