Comment fonctionnent le presse-papiers et le glisser-déposer — traiter correctement le transfert de données OLE dans les applications métier

« Lorsque nous collons un tableau d’Excel, la mise en forme se défait. » « Le contenu copié dans notre application n’arrive pas dans Word sous la forme voulue. » « Nous voulons recevoir des fichiers par glisser-déposer. » — De telles demandes reviennent souvent lors de la révision d’applications métier.

Toutes sont des opérations quotidiennes, mais si l’on pense le presse-papiers comme « une boîte qui tient un seul morceau de données », on se trompe sur le mécanisme. En réalité, il place le même contenu dans plusieurs formats à la fois et laisse le côté collage choisir le format qu’il comprend. C’est pourquoi la même copie produit des résultats différents selon l’endroit où on la colle.

Le problème du collage qui échoue une fois la source fermée met en jeu le « rendu différé », qui ne produit les données que lorsqu’elles sont nécessaires. Et le glisser-déposer OLE (D&D) transmet IDataObject, la même représentation de données que le presse-papiers OLE, à travers des interfaces COM. Copier-coller et D&D sont des fonctions liées : elles partagent le format des données et diffèrent par la façon de les transporter.

Cet article s’adresse aux responsables informatiques des PME et aux développeurs d’applications Windows. Il commence par le fonctionnement des formats, examine ensuite les mises en œuvre côté collage, côté copie et côté surveillance, puis passe à la gestion de l’historique, de la synchronisation et de RDP, et aux pièges du D&D OLE.

1. D’abord la conclusion

Trois axes à retenir.

1. Le côté copie offre plusieurs formats, et le côté collage choisit parmi eux. Les bases sont CF_UNICODETEXT pour le texte, CF_HDROP pour une liste de chemins de fichiers, et le format enregistré « HTML Format » pour le texte mis en forme.¹²³⁴
2. Concevoir non seulement le format des données, mais aussi leur validation et leur durée de vie. Valider les données collées comme une entrée externe non fiable. Un côté copie qui utilise le rendu différé implémente aussi la matérialisation à la sortie. Surveiller avec AddClipboardFormatListener et WM_CLIPBOARDUPDATE, et se préparer à la concurrence en lecture par des nouvelles tentatives.⁵⁶⁷⁸
3. Rendre clair jusqu’où les données voyagent et ce qui se passe une fois transmises. L’historique, la synchronisation cloud et la redirection RDP sont des objets de gestion. Le D&D OLE exige une initialisation STA par OleInitialize, et un dépôt depuis un privilège ordinaire vers une application élevée est bloqué par UIPI. De plus, Move est un contrat sous lequel les données d’origine disparaissent.^910111213

Pour lire selon l’objectif, commencer par le chapitre ci-dessous.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (20 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Ce qu’est vraiment le presse-papiers — pas « un seul morceau de données » mais « le même contenu dans plusieurs formats »

Le presse-papiers est un mécanisme de partage de données entre applications. Les applications du même bureau peuvent l’utiliser, mais l’unité précise de partage est la station de fenêtres. Une session utilisateur différente ou une session RDP a chacune son propre presse-papiers. Que le copier-coller fonctionne sur RDP vient de ce que la redirection relie les deux (chapitre 7).

Le principe premier est que l’usage est piloté par l’utilisateur. La posture officielle de conception est de ne pas mettre de données ni d’en extraire à l’insu de l’utilisateur.¹

Après avoir vidé le presse-papiers, le côté copie place le même contenu dans plusieurs formats, du plus expressif vers le moins expressif.⁶ Conceptuellement, copier un tableau dans un tableur s’aligne ainsi.

Ce que le côté collage extrait, c’est le format qu’il comprend dans cette liste. Word obtient un tableau mis en forme et le Bloc-notes du texte séparé par des tabulations, parce que les deux ont choisi des formats différents.

Autrement dit, « le résultat dépend de la destination du collage » n’est pas en soi un bogue. Il faut regarder ensemble l’offre du côté copie et le choix du côté collage.

flowchart TB
    accTitle: Comment la même copie produit des résultats différents selon l'endroit où on la colle
    accDescr: Le côté copie place le même contenu sur le presse-papiers dans plusieurs formats et le côté collage choisit le format qu'il comprend, de sorte que Word obtient un tableau mis en forme et le Bloc-notes du texte séparé par des tabulations
    copy["Côté copie : tableur"] --> cb["Presse-papiers (le même contenu dans plusieurs formats)"]
    cb --> f1["Format privé de l'application"]
    cb --> f2["HTML Format"]
    cb --> f3["CSV"]
    cb --> f4["CF_UNICODETEXT"]
    f2 -->|"Word choisit celui-ci"| word["Tableau mis en forme"]
    f4 -->|"Le Bloc-notes choisit celui-ci"| notepad["Texte séparé par des tabulations"]

À l’inverse, les plaintes d’ouverture — « la mise en forme se défait », « quelque chose d’étrange se colle » — se ramènent presque toutes à la façon dont l’un des deux côtés choisit ou offre les formats. Le chapitre 4 traite le côté collage et le chapitre 5 le côté copie.

3. Formats standard et formats enregistrés — CF_UNICODETEXT, CF_HDROP, HTML Format

3.1. Formats standard — utiliser le côté Unicode pour le texte

Les formats que le système d’exploitation définit à l’avance s’appellent formats standard. Voici ceux qui reviennent le plus souvent dans les applications métier.²

CF_TEXT et CF_UNICODETEXT sont des « formats synthétisés » que le système convertit implicitement l’un en l’autre. La conversion utilise la page de codes associée à CF_LOCALE.²

Cependant, les caractères que l’ANSI ne peut pas représenter se perdent dans la conversion. Si l’on traite des symboles propres à Unicode, des caractères combinants et analogues, s’en remettre à la conversion mène au mojibake. La règle est de standardiser les lectures et écritures de l’application sur CF_UNICODETEXT, ou DataFormats.UnicodeText en .NET.

flowchart LR
    accTitle: Conversion implicite entre CF_UNICODETEXT et CF_TEXT
    accDescr: L'application ne lit et n'écrit que CF_UNICODETEXT ; le système synthétise CF_TEXT par conversion implicite avec la page de codes de CF_LOCALE. Les caractères que l'ANSI ne peut pas représenter sont abandonnés dans cette conversion
    apprw["Lectures et écritures de l'application"] --> uni["CF_UNICODETEXT (canonique)"]
    uni <-->|"Le système convertit implicitement (page de codes de CF_LOCALE)"| ansi["CF_TEXT (ANSI, dépendant de la page de codes)"]
    ansi -.-> loss["Les caractères non représentables sont abandonnés à la conversion (terreau de mojibake)"]

3.2. CF_HDROP — les fichiers voyagent comme « une liste de chemins »

CF_HDROP est ce que l’Explorateur de fichiers utilise pour les copies de fichiers et le D&D. La première chose à retenir est que ce qui voyage est une liste de chemins complets, pas les fichiers eux-mêmes.

Une structure DROPFILES se trouve au début du bloc mémoire, suivie de chaînes de chemins séparées par des caractères NUL. Une chaîne vide est placée en dernier, le bloc se termine donc par un « double NUL ». Dans l’en-tête, pFiles est le décalage de début de la liste de chemins et fWide indique si les chaînes sont en Unicode.³

[DROPFILES header: pFiles=start offset of the path list, fWide=1 (Unicode)]
C:\data\a.txt(NUL)C:\data\b.txt(NUL)(NUL)

En code natif on les récupère une par une avec DragQueryFile ; en .NET on les reçoit comme string[] via DataFormats.FileDrop. Le point que « seuls les chemins voyagent, pas les fichiers eux-mêmes » compte aussi pour le D&D aux chapitres 8 et 9.

flowchart TB
    accTitle: Structure du bloc mémoire de CF_HDROP
    accDescr: Une structure DROPFILES se trouve au début de la mémoire globale ; pFiles donne le décalage de début de la liste de chemins et fWide indique s'il s'agit d'Unicode. Suivent des chemins complets séparés par NUL, se terminant par une chaîne vide comme terminateur double NUL. Seuls les chemins voyagent, pas les fichiers eux-mêmes
    hdr["Structure DROPFILES (pFiles = décalage de début de liste / fWide = 1)"] --> p1["C:\\data\\a.txt + NUL"]
    p1 --> p2["C:\\data\\b.txt + NUL"]
    p2 --> tail["Chaîne vide terminale (double NUL)"]
    hdr -.-> note["Seuls les chemins voyagent, pas les fichiers eux-mêmes"]

3.3. Formats enregistrés — RegisterClipboardFormat et « HTML Format »

Les données que les formats standard ne peuvent pas exprimer se partagent comme format enregistré sous un nom que l’on choisit. On passe un nom à RegisterClipboardFormat et on reçoit un identifiant de format. Enregistrer le même nom depuis une autre application donne le même identifiant, s’accorder sur un nom entre applications est donc le point de contact.¹

Pour faire passer des données structurées dans sa propre suite d’applications, on utilise un nom qui ne collisionnera pas, par exemple KomuraSoft.Report.RowData.

HTML Format est « de l’UTF-8 avec un en-tête »

Le format enregistré représentatif est « HTML Format », un format de texte mis en forme qui se range aux côtés du RTF. Le corps est du texte UTF-8, mais un en-tête énumérant des décalages d’octets est attaché devant.⁴

Version:0.9
StartHTML:<byte position where the whole HTML starts>
EndHTML:<byte position where the whole HTML ends>
StartFragment:<byte position where the fragment starts>
EndFragment:<byte position where the fragment ends>
<html><body>
<!--StartFragment--><b>Gras</b> texte du fragment<!--EndFragment-->
</body></html>

Chaque décalage se mesure depuis le début des données, en-tête compris. StartHTML / EndHTML pointent vers l’ensemble du HTML, et StartFragment / EndFragment vers le début et la fin du fragment que l’utilisateur a sélectionné. L’unité est des octets, pas des caractères.

Pour le générer, on l’assemble dans cet ordre.

1. Réserver les champs de décalage à largeur fixe (par exemple 10 chiffres).
2. Construire le corps HTML et l’encoder en UTF-8.
3. Mesurer les positions d’octets après l’encodage et les réécrire dans l’en-tête.

En UTF-8 qui contient du japonais, le nombre de caractères et le nombre d’octets ne coïncident pas. Se tromper ici coupe le début ou la fin au collage dans une autre application.⁴

flowchart TB
    accTitle: Comment l'en-tête de HTML Format se rapporte aux décalages
    accDescr: Dans l'en-tête, StartHTML et EndHTML pointent vers l'ensemble du HTML et StartFragment et EndFragment vers le fragment sélectionné par l'utilisateur, tous comme positions d'octets depuis le début des données. Comme le nombre de caractères et le nombre d'octets divergent en UTF-8, on les remplit avec des positions d'octets mesurées après l'encodage
    header["En-tête (Version / StartHTML / EndHTML / StartFragment / EndFragment)"] --> html["HTML entier (StartHTML à EndHTML)"]
    html --> frag["Fragment sélectionné (StartFragment à EndFragment)"]
    header -.-> byte["Chaque décalage = position d'octet depuis le début des données (mesurée après encodage UTF-8 et réécrite)"]

Outre cela, CSV (DataFormats.CommaSeparatedValue en .NET) est aussi couramment utilisé pour les données tabulaires. Pour l’interopérabilité avec Excel, offrir ensemble HTML Format (mis en forme), CSV (valeurs seulement) et CF_UNICODETEXT (séparé par tabulations) convient quelle que soit la destination du collage.

4. Pratiques du côté collage — priorité des formats et validation

4.1. Chercher depuis les formats riches vers le bas

Le côté collage cherche parmi les formats qu’il sait traiter, en commençant par celui qui porte le plus d’information. On peut utiliser l’ordre dans lequel le côté copie a placé les formats, du plus expressif vers le bas, ou indiquer sa propre liste de priorités.⁶

En .NET, le branchement ressemble à ceci.

// Collage d'un tableau : chercher du riche vers le brut
var data = Clipboard.GetDataObject();
if (data is null) return;

// Annoncer un format ne garantit pas que la charge utile est un string. N'utiliser
// cette branche que si le type convient aussi ; sinon tomber sur le candidat suivant
if (data.GetDataPresent(DataFormats.Html)
    && data.GetData(DataFormats.Html) is string html)
{
    // Valider l'en-tête HTML Format, puis importer comme tableau
}
else if (data.GetDataPresent(DataFormats.CommaSeparatedValue))
{
    // Importer comme CSV
}
else if (data.GetDataPresent(DataFormats.UnicodeText))
{
    // Importer comme texte séparé par des tabulations
}

C’est la réponse à la plainte d’ouverture qu’un tableau Excel collé se défait. La structure de tableau n’atteint jamais une application qui ne lit que le texte brut. Jusqu’où l’on accepte la liste des formats est une décision de conception du côté collage.

flowchart TB
    accTitle: Branchement de collage qui cherche depuis les formats riches vers le bas
    accDescr: Si HTML Format est présent et que la charge utile est un string, importer comme tableau ; sinon CSV ; à défaut, texte séparé par des tabulations, en descendant depuis le format le plus expressif. Si aucun candidat n'est présent, refuser
    startsel["Démarrer le collage"] --> h{"HTML Format présent et charge utile un string ?"}
    h -->|"Oui"| useh["Valider l'en-tête et importer comme tableau"]
    h -->|"Non"| c{"CSV présent ?"}
    c -->|"Oui"| usec["Importer comme CSV"]
    c -->|"Non"| t{"UnicodeText présent ?"}
    t -->|"Oui"| uset["Importer comme texte séparé par des tabulations"]
    t -->|"Non"| giveup["Refuser"]

4.2. Les données collées sont une entrée externe

On l’oublie facilement, mais le contenu du presse-papiers est d’origine externe, et l’on ne sait pas quelle application l’a placé. Microsoft elle-même avertit dans la documentation du presse-papiers OLE que les données du presse-papiers ne sont pas fiables et qu’il faut les analyser avec soin avant de les utiliser dans l’application.⁵

La seule présence d’un format ne dit pas que les données peuvent être importées. Vérifier aussi le type de la charge utile réelle, et faire passer les contrôles suivants.

Noter que la matérialisation commence avant que l’on puisse vérifier la taille

Pour se défendre contre d’énormes données, on distingue quelle charge de quelle étape on peut empêcher. GetData en .NET déclenche aussi le rendu différé à l’appel, et pour le texte matérialise jusqu’à une chaîne managée. Vérifier la taille seulement après la récupération n’empêche pas la charge de cette matérialisation.

Si l’on examine avec GlobalSize le HGLOBAL renvoyé par GetClipboardData Win32, on peut se défendre contre le fait de pousser d’énormes données vers la conversion en chaîne managée et l’analyse. Pour les formats à rendu différé, cependant, GetClipboardData lui-même déclenche le rendu. On ne peut pas empêcher la source de copie de matérialiser les données elles-mêmes.

Pour que l’interface ne se fige pas, déplacer la récupération hors du thread d’interface et refuser les données qui dépassent la limite. Même alors, Clipboard en .NET exige STA. Utiliser un thread dédié réglé en STA, pas le pool de threads (MTA) de Task.Run (section 5.1).

L’idée qu’« une valeur qui vient de l’extérieur se valide avant usage, quel que soit son chemin » est la même que celle exposée dans « Ne jamais utiliser telle quelle la valeur décodée d’un QR code ». Le présupposé que coller est sûr parce que c’est une action de l’utilisateur est ce qui mène à l’accident.

flowchart LR
    accTitle: Valider les données collées avant de les utiliser
    accDescr: Les données prises du presse-papiers passent dans l'ordre par des contrôles de présence du format, de type de charge utile, de limite de taille et de contenu ; si un contrôle échoue, refuser ou tomber sur le format candidat suivant
    present["Vérifier que le format est présent (GetDataPresent)"] --> type["Vérifier le type de la charge utile (is string / string[])"]
    type --> size["Vérifier la limite de taille"]
    size --> content["Valider le contenu (en-tête, chemins, valeurs)"]
    content --> ok["Importer"]
    type -.->|"Mauvais type"| rej["Refuser / format candidat suivant"]
    size -.->|"Trop volumineux"| rej
    content -.->|"Invalide"| rej

5. Pratiques du côté copie — offrir plusieurs formats à la fois, et le rendu différé

5.1. Placer plusieurs formats à la fois

La pratique du côté copie est le miroir de 4.1 : offrir un format riche et un format brut en même temps. Avec le DataObject de WinForms/WPF, cela tient en quelques lignes.¹⁴

// WinForms (System.Windows.Forms). WPF a la même forme avec DataObject/Clipboard de System.Windows
var data = new DataObject();
data.SetData(DataFormats.Html, htmlFormatText);       // Chaîne HTML Format avec l'en-tête
data.SetData(DataFormats.CommaSeparatedValue, csv);   // CSV
data.SetData(DataFormats.UnicodeText, plainText);     // Texte brut
Clipboard.SetDataObject(data, copy: true);            // copy:true = conserver après la sortie de l'application

Ici on sépare la condition de thread et la durée de vie après la sortie.

Condition de thread : la classe Clipboard de .NET ne s’utilise que depuis un thread STA.¹⁴ Le thread d’interface WinForms/WPF est STA grâce à [STAThread], ce n’est donc en général pas un problème, mais on ne peut pas l’utiliser depuis un thread d’arrière-plan qui n’est pas STA. Le fond est expliqué dans « Les fondamentaux STA/MTA de COM ».

Durée de vie après la sortie : copy: true signifie « conserver après la sortie de l’application ». Le comprendre avec le rendu différé qui suit clarifie pourquoi cette indication est nécessaire.

5.2. Rendu différé — pourquoi « fermer et l’on ne peut plus coller »

Générer chacun de nombreux formats à chaque copie, c’est travailler même pour des formats qui ne sont jamais utilisés. Le mécanisme qui l’évite est le rendu différé (delayed rendering).⁶

À la copie, on passe NULL comme handle de données à SetClipboardData, en enregistrant non pas les données elles-mêmes mais une promesse de « les produire sur demande ». Lorsque ce format est demandé, WM_RENDERFORMAT arrive à la source de copie, et ce n’est qu’alors que les données sont générées.

À la sortie, transformer la « promesse » en données

Si la source de copie se termine en laissant des formats non rendus, le côté collage ne peut plus recevoir ces données. C’est le problème « fermer la source et l’on ne peut plus coller ».

Avant de se terminer, la source de copie a la responsabilité de répondre à WM_RENDERALLFORMATS et de matérialiser chaque format non rendu. Les formats qui n’ont pas été matérialisés sont perdus lorsque la source de copie se termine.⁶

flowchart TB
    accTitle: Le flux du rendu différé et « fermer et l'on ne peut plus coller »
    accDescr: La source de copie n'enregistre qu'une promesse avec un handle NULL et matérialise les données avec WM_RENDERFORMAT lorsqu'une demande arrive. À la sortie elle a la responsabilité de matérialiser chaque format avec WM_RENDERALLFORMATS ; négliger cela et le format est perdu
    promise["Source de copie : n'enregistrer qu'une promesse avec SetClipboardData(format, NULL)"] --> req["Le côté collage demande ce format"]
    req --> render["WM_RENDERFORMAT → générer les données sur place"]
    promise --> quit["La source de copie est sur le point de se terminer"]
    quit -->|"Matérialiser avec WM_RENDERALLFORMATS"| ok["Le collage fonctionne encore après la sortie"]
    quit -->|"Négliger la matérialisation"| lost["Ce format est perdu (fermer et l'on ne peut plus coller)"]

Sur le presse-papiers OLE, on place un IDataObject avec OleSetClipboard. À ce moment, ce que le presse-papiers détient est un pointeur vers l’objet de données.

Appeler OleFlushClipboard à la sortie matérialise les données sur le presse-papiers, de sorte que le collage fonctionne encore après la sortie.⁷ Clipboard.SetDataObject(data, copy: true) en .NET spécifie ce comportement « conserver après la sortie ».

Lorsque l’on copie une grande plage dans Excel puis que l’on quitte, l’invite demandant si l’on veut conserver la grande quantité d’informations sur le presse-papiers est la confirmation de cette matérialisation (le flush). Dans sa propre application aussi, concevoir le rendu différé et la matérialisation à la sortie comme un ensemble.

Différer ne garantit pas que l’interface reste réactive

Le rendu différé est une optimisation de performance, mais générer les données demandées s’exécute de façon synchrone dans le traitement des messages. Le compromis est que l’interface se fige si la génération prend du temps.⁶

6. Pratiques pour surveiller le presse-papiers — écouteur, nouvelle tentative et exclusion de l’historique

6.1. Utiliser AddClipboardFormatListener

Des exigences telles que « détecter la valeur d’un lecteur de codes-barres ou une copie du système métier central et l’importer automatiquement » appellent la surveillance des changements du presse-papiers. Historiquement il y a trois méthodes, mais aujourd’hui une seule bonne réponse.⁸

flowchart LR
    accTitle: Flux de surveillance du presse-papiers
    accDescr: S'enregistrer avec AddClipboardFormatListener à la création du handle, et WM_CLIPBOARDUPDATE arrive quelle que soit l'application qui copie. Lire avec des nouvelles tentatives, et se désenregistrer de façon symétrique avec RemoveClipboardFormatListener à la destruction du handle
    created["OnHandleCreated : AddClipboardFormatListener"] --> wait["Attendre"]
    anyapp["Une application copie"] --> notify["WM_CLIPBOARDUPDATE arrive"]
    wait --> notify
    notify --> readtry["Lire avec des nouvelles tentatives (section 6.2)"]
    readtry --> wait
    destroyed["OnHandleDestroyed : RemoveClipboardFormatListener"] -.->|"Se désenregistrer de façon symétrique"| created

// Implémentation minimale WinForms
public partial class MainForm : Form
{
    [DllImport("user32.dll", SetLastError = true)]
    static extern bool AddClipboardFormatListener(IntPtr hwnd);
    [DllImport("user32.dll", SetLastError = true)]
    static extern bool RemoveClipboardFormatListener(IntPtr hwnd);
    const int WM_CLIPBOARDUPDATE = 0x031D;

    protected override void OnHandleCreated(EventArgs e)
    {
        base.OnHandleCreated(e);
        AddClipboardFormatListener(Handle);
    }

    protected override void OnHandleDestroyed(EventArgs e)
    {
        // Se désenregistrer de façon symétrique, en phase avec destruction et recréation du handle
        RemoveClipboardFormatListener(Handle);
        base.OnHandleDestroyed(e);
    }

    protected override void WndProc(ref Message m)
    {
        if (m.Msg == WM_CLIPBOARDUPDATE)
        {
            // Lire Clipboard.GetDataObject() ici et importer si le format est l'un de ceux dont on a besoin
        }
        base.WndProc(ref m);
    }
}

6.2. Réessayer lorsqu’il ne peut pas être ouvert

Une seule fenêtre à la fois peut ouvrir le presse-papiers. Tant qu’un autre processus l’a ouvert, OpenClipboard échoue.⁶

Juste après WM_CLIPBOARDUPDATE aussi, la source de copie ou une autre application de surveillance peut encore y travailler. Traiter un échec de lecture temporaire comme un événement normal, et ajouter une logique qui attend quelques dizaines de millisecondes et réessaie quelques fois.

Un point à noter en .NET est que les surcharges qui permettent de spécifier un nombre de tentatives et un intervalle n’existent que du côté écriture, SetDataObject. Le côté lecture, GetDataObject et analogues, n’en a pas.

L’attente et la nouvelle tentative à la lecture s’implémentent côté application.

flowchart LR
    accTitle: Flux des nouvelles tentatives de lecture du presse-papiers
    accDescr: Une seule fenêtre à la fois peut ouvrir le presse-papiers, donc une lecture juste après la notification de changement peut échouer par concurrence avec un autre processus. Sur une exception, attendre quelques dizaines de millisecondes et réessayer ; une fois la limite atteinte, abandonner cette fois et le reprendre à la prochaine mise à jour
    upd["WM_CLIPBOARDUPDATE"] --> tryread["Tenter la lecture"]
    tryread -->|"Succès"| useok["Importer (validation du chapitre 4)"]
    tryread -->|"Échec (une autre fenêtre l'utilise)"| waitretry["Attendre quelques dizaines de millisecondes"]
    waitretry -->|"Réessayer jusqu'à quelques fois"| tryread
    waitretry -->|"Limite atteinte"| giveup2["Abandonner cette fois (le reprendre à la prochaine mise à jour)"]

6.3. Le garder hors de l’historique et de la synchronisation — précautions pour les fonctions de copie qui portent des secrets

Windows a un historique du presse-papiers (Win+V) et une synchronisation inter-appareils (presse-papiers cloud), et les données qu’une application place y sont soumises par défaut. Une application dont la fonction de copie porte des secrets tels que mots de passe ou numéros de compte place aussi un format enregistré qui exclut les données de l’historique et de la synchronisation.¹

Les gestionnaires de mots de passe tiennent les mots de passe copiés hors de Win+V grâce à ce mécanisme. Il suffit de passer le nom à RegisterClipboardFormat pour obtenir un identifiant de format et de le poser à côté des données ordinaires ; cela vaut la peine de l’implémenter dans les applications métier qui traitent des secrets.

7. Le presse-papiers du point de vue informatique — contrôler l’historique, la synchronisation cloud et RDP

Contrôler le contenu copié côté application et décider ce que l’organisation dans son ensemble autorise sont des questions distinctes. Ce qu’un administrateur examine, ce sont trois choses : l’historique, la synchronisation cloud et la redirection RDP.

L’historique du presse-papiers accumule le contenu récemment copié. Le presse-papiers cloud le synchronise entre les appareils connectés avec le même compte Microsoft ou compte Microsoft Entra.¹⁰

Aussi pratique que ce soit, cela mène à des résidus et à un débordement : des informations personnelles copiées du système métier central restent dans l’historique, ou le contenu copié sur un PC professionnel se synchronise vers un PC personnel.

7.1. Contrôler l’historique et la synchronisation inter-appareils

Les deux stratégies de contrôle organisationnel sont celles-ci.

Les deux sont disponibles à partir de Windows 10 version 1809 ; lorsqu’elles sont désactivées, les éléments correspondants de l’application Paramètres sont grisés, et la stratégie prend effet immédiatement.⁹¹⁰

7.2. Contrôler le transfert entre sessions RDP

La redirection du presse-papiers de RDP (Bureau à distance) relie le PC local et la session distante. Comme le copier-coller fonctionne par défaut, cela peut aussi devenir un chemin pour emporter des secrets hors d’un serveur.

Le paramètre qui bloque les deux directions est la stratégie « Ne pas autoriser la redirection du Presse-papiers » (valeur de Registre fDisableClip).¹¹

Les versions récentes de Windows Server et de Windows 11 ont aussi ajouté des stratégies de contrôle plus fin, comme limiter seulement la direction serveur vers client au texte. Interdire tout net ou restreindre direction et format par étapes est un équilibre entre exploitation et sécurité.

flowchart LR
    accTitle: Chemins par lesquels le contenu du presse-papiers se répand, et les points de contrôle
    accDescr: Le contenu copié est soumis par défaut à l'historique et à la synchronisation cloud, et sur RDP il passe vers une autre session par redirection. Chacun peut se contrôler par stratégie, et le côté application peut exclure le contenu de l'historique et de la synchronisation avec les formats d'exclusion
    cb["Presse-papiers"] --> hist["Historique (Win+V)"]
    cb --> cloud["Synchronisation cloud → autre appareil"]
    cb --> rdp["Redirection RDP → autre session"]
    hist -.-> p1["Contrôle : AllowClipboardHistory"]
    cloud -.-> p2["Contrôle : AllowCrossDeviceClipboard"]
    rdp -.-> p3["Contrôle : fDisableClip"]
    cb -.-> p4["Côté application : exclure avec ExcludeClipboardContentFromMonitorProcessing et analogues (section 6.3)"]

8. Le glisser-déposer est COM — IDataObject + IDropSource + IDropTarget

8.1. Les mêmes données que le presse-papiers, transportées autrement

Le glisser-déposer OLE s’appuie sur les trois parties suivantes.¹⁵

Le déroulement est le suivant.

1. La source de glissement appelle DoDragDrop, ce qui démarre la boucle de glissement.
2. Lorsque la souris entre dans une fenêtre cible de dépôt, IDropTarget est notifié.
3. La cible de dépôt déclare si elle accepte, et au dépôt récupère le format dont elle a besoin depuis IDataObject.

La documentation officielle explique aussi que le D&D offre la même fonctionnalité que le copier-coller du presse-papiers, et qu’une application qui implémente déjà le copier-coller n’a besoin que d’un petit ajout.¹⁵ Autrement dit, le DataObject multi-formats préparé aux chapitres 2 à 5 est aussi les données que le D&D transporte.

flowchart LR
    accTitle: Flux du glisser-déposer OLE
    accDescr: La source de glissement appelle DoDragDrop avec un IDataObject comme charge et la boucle de glissement commence ; l'IDropTarget de la cible de dépôt déclare l'acceptation dans DragEnter et DragOver, et au Drop choisit et récupère un format depuis l'IDataObject
    src["Source de glissement : IDataObject + IDropSource"] -->|"DoDragDrop"| loop["Boucle de glissement"]
    loop -->|"La souris entre dans la fenêtre"| enter["IDropTarget.DragEnter/DragOver (déclarer l'Effect à chaque fois)"]
    enter -->|"Bouton relâché"| drop["IDropTarget.Drop"]
    drop --> data["Choisir et récupérer un format depuis l'IDataObject"]

8.2. OleInitialize (STA) est obligatoire

Une fenêtre cible de dépôt s’enregistre avec RegisterDragDrop. Comme prérequis, vérifier deux choses : l’initialisation OLE et le traitement des messages.

Utiliser OleInitialize pour l’initialisation. Si l’on utilise CoInitialize / CoInitializeEx à la place, RegisterDragDrop échoue avec E_OUTOFMEMORY. OleInitialize initialise COM en STA.¹²

Le thread qui enregistre doit exécuter une pompe à messages. Le D&D OLE est une fonction enracinée dans les fenêtres et le traitement des messages ; le négliger et d’autres applications se bloquent pendant un glissement.¹² Le fond est le même modèle de threads que dans « Les fondamentaux STA/MTA de COM ».

En WinForms/WPF, recevoir par les événements

En WinForms/WPF, le framework prend en charge l’initialisation OLE et les implémentations d’interfaces. Le développeur écrit la déclaration d’acceptation et l’import réel dans les événements.

// WinForms : accepter des fichiers déposés
listView1.AllowDrop = true;
listView1.DragEnter += (s, e) =>
{
    // Vérifier aussi que la source autorise Copy (certaines sources n'autorisent que Move/Link)
    e.Effect = e.Data.GetDataPresent(DataFormats.FileDrop)
            && (e.AllowedEffect & DragDropEffects.Copy) == DragDropEffects.Copy
        ? DragDropEffects.Copy      // Accepter : recevoir comme une copie
        : DragDropEffects.None;     // Ne pas accepter
};
listView1.DragDrop += (s, e) =>
{
    // Les données de glissement sont aussi une entrée externe. Même si FileDrop est annoncé, la
    // charge utile peut être null ou d'un autre type, et la récupération elle-même peut échouer
    object data;
    try { data = e.Data.GetData(DataFormats.FileDrop); }
    catch (COMException) { return; }
    if (data is not string[] paths) return;
    foreach (var path in paths)
    {
        // Valider le chemin avant d'importer (section 9.3)
    }
};

Le tableau est le même en WPF. Recevoir avec AllowDrop="True" sur l’élément et les événements DragOver / Drop, et récupérer le tableau de chemins avec e.Data.GetData(DataFormats.FileDrop).

Déclarer l’acceptation (l’Effect) à chaque fois dans DragEnter / DragOver est la convention de IDropTarget. L’omettre et le curseur reste sur « non autorisé ». Vérifier non seulement si le format est présent mais aussi, comme dans l’exemple de code, si la source de glissement autorise Copy.

9. Pièges du D&D — élévation, Move et validation des chemins

9.1. On ne peut pas déposer sur une application élevée en administrateur

Déposer un fichier depuis l’Explorateur de fichiers sur une application lancée avec « Exécuter en tant qu’administrateur » et rien ne se passe — ce n’est pas une erreur d’implémentation mais une conception du système d’exploitation. UIPI (User Interface Privilege Isolation) bloque par défaut les messages d’un processus de plus basse intégrité vers une fenêtre de plus haute intégrité, donc les notifications de dépôt de l’Explorateur de fichiers à privilège ordinaire (intégrité moyenne) n’atteignent jamais une application élevée.¹³

flowchart LR
    accTitle: Comment UIPI bloque un dépôt sur une application élevée
    accDescr: UIPI bloque par défaut la notification de dépôt de l'Explorateur de fichiers d'intégrité moyenne vers une application élevée d'intégrité haute, donc elle n'arrive jamais. Garder l'interface à privilège ordinaire et isoler le travail privilégié, et le dépôt arrive
    explorer["Explorateur de fichiers (intégrité moyenne)"] -->|"Notification de dépôt"| uipi{"UIPI"}
    uipi -->|"Bloqué (par défaut)"| elevated["Application élevée (intégrité haute) : aucune réponse"]
    uipi -->|"Passe"| normal["Interface à privilège ordinaire : le dépôt arrive"]
    normal -.->|"Déléguer seulement le travail privilégié"| broker["Processus séparé isolant le travail qui a besoin d'élévation"]

Il existe aussi une solution de contournement qui autorise individuellement WM_DROPFILES et des messages analogues avec ChangeWindowMessageFilterEx.¹³ Cependant, c’est une contre-mesure pour l’ancienne notification de dépôt via WM_DROPFILES, et elle ne résout pas le D&D OLE dans son ensemble.

La ligne directrice de fond est de ne pas exécuter l’application élevée en permanence. Si l’on isole seulement le travail qui a besoin d’élévation dans un processus séparé, l’interface elle-même peut rester à privilège ordinaire et accepter le D&D. La conception de l’isolation est détaillée dans « Comment isoler concrètement, dans une application Windows, uniquement les opérations nécessitant des privilèges administrateur ».

9.2. Ce que signifie DragDropEffects — Move est un contrat selon lequel « l’original disparaît »

Copy / Move / Link dans DragDropEffects ne sont pas une décoration de curseur ; c’est un contrat entre la source de glissement et la cible de dépôt.

La source de glissement déclare dans DoDragDrop l’ensemble des effets qu’elle autorise, et la cible de dépôt choisit l’effet réel. Par convention, lorsque Move est convenu, la source de glissement supprime les données (le fichier).

Si le côté réception renvoie Move sans y penser, on aboutit à « j’ai déposé et le fichier d’origine a disparu ». Pour les imports dans les applications métier, faire du Copy explicite du côté réception la valeur sûre par défaut.

flowchart LR
    accTitle: Le contrat de DragDropEffects — avec Move, l'original disparaît
    accDescr: La source de glissement déclare dans DoDragDrop l'ensemble des effets qu'elle autorise, et la cible de dépôt choisit l'effet réel. Parce que la convention est que la source de glissement supprime le fichier lorsque Move est convenu, un côté réception qui importe devrait indiquer Copy explicitement
    srcdecl["Source de glissement : déclarer les effets autorisés (Copy | Move | Link)"] --> tgtsel["Cible de dépôt : choisir l'effet réel"]
    tgtsel -->|"Copy"| copyok["Le fichier d'origine reste (le côté sûr pour les imports)"]
    tgtsel -->|"Move"| moveact["La source de glissement supprime le fichier — d'où vient « l'original a disparu »"]

9.3. Valider les chemins déposés

Ce qui voyage dans CF_HDROP/FileDrop, ce sont seulement des chemins (section 3.2). Avant d’importer, les faire passer par la même validation qu’une entrée externe, comme pour le collage.

• Fichier ou dossier : Décider en spécification ce qui se passe lorsqu’un dossier entier est déposé (importer récursivement, ou refuser).
• Espaces réservés OneDrive : Si le chemin existe mais que le corps du fichier n’est pas local — un fichier à la demande —, un téléchargement démarre dès l’ouverture, et il échoue hors ligne. Pour le comportement et les contre-mesures, voir OneDrive « Fichiers à la demande » et applications métier.
• Chemins longs et particuliers : N’accepter les chemins au-delà de MAX_PATH, les chemins réseau (UNC) et les chemins sur support amovible qu’après confirmation que le traitement en aval peut les gérer.
• Nombre et taille totale : Pour qu’un dépôt de milliers de fichiers ne fige pas l’interface, rendre l’import asynchrone et ajouter une limite et un affichage de progression.

10. Synthèse

• Le presse-papiers est un mécanisme qui place le même contenu dans plusieurs formats à la fois dans une zone unique partagée au sein du même bureau (station de fenêtres). Parce que la destination du collage choisit le format, la même copie produit des résultats différents.
• Le texte est CF_UNICODETEXT, les fichiers sont CF_HDROP, et le texte mis en forme est le format enregistré HTML Format (en-tête de décalages d’octets + UTF-8).
• Le côté collage cherche les formats du riche vers le brut et valide le contenu comme entrée externe. Le côté copie offre plusieurs formats à la fois, et s’il utilise le rendu différé, implémente aussi la matérialisation à la sortie (WM_RENDERALLFORMATS / OleFlushClipboard).
• La surveillance est AddClipboardFormatListener + WM_CLIPBOARDUPDATE. Se préparer à la concurrence d’OpenClipboard par des nouvelles tentatives, et exclure les secrets de l’historique et de la synchronisation avec ExcludeClipboardContentFromMonitorProcessing et analogues.
• L’informatique peut contrôler l’historique du presse-papiers, la synchronisation cloud et la redirection RDP via GPO/Intune. Tous sont autorisés par défaut, donc décider délibérément dans les environnements qui traitent des secrets.
• Le D&D est COM : IDropSource/IDropTarget transmettent le même IDataObject que le presse-papiers. RegisterDragDrop exige OleInitialize (STA).
• Les dépôts sur une application élevée sont bloqués par UIPI. Move dans DragDropEffects est un contrat selon lequel « l’original disparaît », et les chemins déposés se valident avant l’import.

Pour les utilisateurs, copier-coller et D&D sont des fonctions aussi peu remarquables que l’air. C’est précisément pourquoi l’expérience souffre tant lorsque surviennent « impossible de coller », « ça se défait » ou « ça a disparu » — et inversement, une application qui offre plusieurs formats et traite les dépôts à fond rend à elle seule le quotidien plus fluide. J’espère que cela sert d’élément de jugement lorsque vous pesez la priorité des révisions.

Articles connexes

• Qu’est-ce que COM / ActiveX / OCX ? - Différences et relations expliquées ensemble
• Les fondamentaux STA/MTA de COM - modèles de threads et comment éviter les blocages
• L’intégration au shell Windows aujourd’hui ── menus contextuels, associations de fichiers et ce qui a changé sous Windows 11
• Le problème d’EXCEL.EXE qui reste actif lors de la manipulation d’Excel en C# — schémas de libération des références COM et décision de remplacement
• Conception UX des applications Windows - Priorités selon l’environnement d’utilisation
• OneDrive « Fichiers à la demande » et applications métier — les hypothèses que les espaces réservés brisent, et comment y faire face

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception et l’implémentation du copier-coller et du glisser-déposer dans les applications métier (offre de plusieurs formats, interopérabilité Excel, import de fichiers déposés), l’investigation des causes de défauts tels que « ça se défait au collage » ou « la copie disparaît », l’automatisation de saisie par surveillance du presse-papiers, et l’implémentation de protections d’informations confidentielles vis-à-vis de l’historique et de la synchronisation. Les dossiers qui touchent les couches basses de COM et d’OLE sont les bienvenus même s’ils commencent par isoler le symptôme.

• Développement d’applications Windows
• Développement de composants COM
• Conseil technique et revue de conception
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi la mise en forme se défait-elle lorsque je colle dans mon application un tableau copié depuis Excel ?

Parce que le presse-papiers ne détient pas « un seul morceau de données » : le même contenu est placé à la fois dans plusieurs formats (format privé de l'application, HTML Format, CSV, texte Unicode, etc.), et l'application de destination choisit le format qu'elle comprend et l'extrait. Lorsque la mise en forme se défait, la cause typique est que la destination ne lit que le texte brut (CF_UNICODETEXT). Si l'on veut aussi la structure du tableau, il faut implémenter le côté collage de sorte qu'il préfère HTML Format ou CSV. Inversement, si l'on veut que d'autres applications collent correctement depuis une copie faite dans sa propre application, on offre à la copie un format riche et un format brut en même temps.

Pourquoi ne puis-je plus coller après avoir fermé l'application depuis laquelle j'ai copié ?

Parce que la source utilise le rendu différé (delayed rendering). Les applications qui traitent de grandes données ne placent pas les données elles-mêmes à la copie ; elles n'enregistrent sur le presse-papiers qu'une promesse de « les produire sur demande ». Si la source se termine ensuite sans matérialiser les données en réponse à WM_RENDERALLFORMATS à l'arrêt, les formats non encore rendus sont perdus. Une application qui utilise le presse-papiers OLE (IDataObject) peut garder le collage possible après la sortie en appelant OleFlushClipboard à l'arrêt pour matérialiser les données.

Comment mon application peut-elle surveiller les changements du presse-papiers ?

La méthode actuellement recommandée est d'enregistrer sa fenêtre comme écouteur avec AddClipboardFormatListener et de traiter le message WM_CLIPBOARDUPDATE qui arrive à chaque changement de contenu. Interroger le contenu périodiquement avec un minuteur (polling) gaspille du travail, et l'ancienne chaîne de visionneuses basée sur SetClipboardViewer n'est conservée que pour la compatibilité ascendante, parce qu'un défaut dans une application de la chaîne casse toute la chaîne. OpenClipboard à la lecture peut aussi échouer par concurrence avec un autre processus ; une nouvelle tentative après une courte attente rend la lecture stable.

Y a-t-il un moyen de garder des secrets tels que des mots de passe hors de l'historique du presse-papiers (Win+V) ?

Il y a deux moyens, un côté application et un côté stratégie. Côté application, si l'on place aussi à la copie le format enregistré ExcludeClipboardContentFromMonitorProcessing, ce contenu n'est inclus ni dans l'historique ni dans la synchronisation inter-appareils. On peut aussi contrôler chacun séparément avec CanIncludeInClipboardHistory (historique seulement) et CanUploadToCloudClipboard (synchronisation seulement). C'est le mécanisme qu'utilisent les gestionnaires de mots de passe. Pour l'arrêter dans toute l'organisation, on peut désactiver l'historique et la synchronisation cloud eux-mêmes avec AllowClipboardHistory et AllowCrossDeviceClipboard via la Stratégie de groupe ou Intune (Policy CSP).

Pourquoi ne puis-je pas glisser-déposer un fichier sur une application qui s'exécute en tant qu'administrateur ?

Parce qu'un mécanisme de sécurité appelé UIPI (User Interface Privilege Isolation) bloque l'envoi de messages depuis un processus de plus basse intégrité vers une fenêtre de plus haute intégrité. L'Explorateur de fichiers s'exécute à privilège ordinaire (intégrité moyenne), donc les notifications de glisser-déposer n'atteignent pas la fenêtre d'une application élevée. Une solution de contournement qui autorise individuellement des messages tels que WM_DROPFILES avec ChangeWindowMessageFilterEx est connue, mais elle se limite à l'ancienne notification de dépôt. La voie de fond est de cesser de concevoir l'application pour qu'elle s'exécute élevée en permanence, et d'isoler dans un processus séparé seulement le travail qui a besoin d'élévation.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.