Non, pas par défaut. Toutes les juridictions fédérales américaines qui ont tranché frontalement la question depuis 2021 ont jugé qu’un hyperlien vers un fichier stocké dans le cloud n’est pas une pièce jointe traditionnelle, et que les fichiers liés n’héritent pas de la relation de famille documentaire du message qui les porte. Ce principe tient parce que la résolution massive des liens a été jugée irréalisable ou disproportionnée, pas parce que les fichiers liés seraient dénués de pertinence. Ils restent communicables sur demande ciblée, et le principe s’inverse totalement dès lors que vous stipulez le contraire dans un protocole ESI. Deux parties productrices l’ont déjà appris à leurs frais.
Une pièce jointe moderne (aussi appelée pièce jointe cloud, pièce jointe liée ou pointeur) est une URL contenue dans un email, un message Teams ou un message Slack, qui pointe vers un fichier hébergé sur SharePoint, OneDrive, Google Drive ou Box. Les octets ne voyagent jamais avec le message. Ce que le destinataire a reçu, c’est un pointeur et une autorisation, et comme le fichier cible reste vivant et modifiable après l’envoi du lien, le document réellement partagé par l’expéditeur peut ne plus exister au moment où quelqu’un le collecte.
Ce que ce n’est pas
Une pièce jointe moderne n’est pas une pièce jointe traditionnelle. Une pièce jointe traditionnelle est une copie : figée à l’instant de l’envoi, transportée dans le message et rattachée à lui par une relation parent-enfant que toute plateforme de revue comprend. Une pièce jointe moderne est une référence sans copie figée et sans relation de famille intrinsèque, ce qui est précisément la faille dont la jurisprudence débat depuis cinq ans.
Ce n’est pas non plus la même chose qu’un lien vers une page web publique. Un lien vers un article de presse ou vers la page tarifaire d’un fournisseur échappe à votre possession, garde ou contrôle, et n’ouvre donc aucune obligation de production. Le critère qui fait d’un lien une pièce jointe moderne, c’est de savoir si le fichier lié réside dans un système contrôlé par la partie productrice. Et ce ne sont pas des données de messagerie courte, même si les deux vont de pair, parce que les mêmes protocoles ESI régissent désormais les deux et que les messages Slack et Teams sont l’endroit où les pièces jointes modernes sont les plus denses.
Enfin, cela ne se règle pas en collectant l’intégralité du Drive. La collecte du stockage de fichiers d’un dépositaire vous livre les fichiers ; elle ne vous dit pas quel message pointait vers quel fichier, or c’est exactement l’association que réclame la partie demanderesse.
Ce que les juridictions ont jugé
| Affaire | Juridiction / date | Décision |
|---|---|---|
| Nichols v. Noom Inc., 2021 WL 948646 | S.D.N.Y., 11 mars 2021 (Parker, M.J.) | Refuse d’ordonner la production comme pièces jointes des fichiers Google Drive hyperliés ; la proposition de collecte des demandeurs n’était pas proportionnée |
| In re Meta Pixel Healthcare Litig., No. 22-cv-03580-WHO | N.D. Cal., 2 juin 2023 (DeMarchi, M.J.) | Le protocole ESI doit préciser que les documents hyperliés ne sont pas des pièces jointes classiques au regard de la famille ; les demandes ciblées s’apprécient au cas par cas |
| In re Uber Techs. Passenger Sexual Assault Litig., 2024 WL 1772832 | N.D. Cal., 23 avril 2024 (Cisneros, M.J.) | Le protocole définit les pièces jointes modernes, mais dispense de produire la version contemporaine lorsque c’est irréalisable |
| In re StubHub Refund Litig., 2024 WL 2305604 | N.D. Cal., 20 mai 2024 | Le protocole exigeait les hyperliens comme pièces jointes ; l’exécution était impossible ; protocole modifié et sanctions rejetées |
| In re Insulin Pricing Litig., 2024 WL 2808083 | D.N.J., 28 mai 2024 (Singh, M.J.) | Les hyperliens ne sont pas des pièces jointes traditionnelles ; les outils disponibles sont “soit absolument irréalisables, soit indûment contraignants” |
| James v. Cerebras Systems Inc., No. 4:25-cv-09361-AMO | N.D. Cal., 7 juillet 2026 | Les documents hyperliés “ne seront pas réputés faire partie d’une famille documentaire” ; instaure un mécanisme de demande ciblée avec plafond et délai |
Le fil conducteur n’est pas que les fichiers liés seraient sans importance. C’est que les juridictions ont constamment refusé d’imposer aux parties productrices la reconstitution massive des familles tant que l’outillage ne peut pas la fournir, et qu’elles ont poussé les parties vers un échange ciblé. Meta Pixel énonce cette séparation le plus clairement : le protocole dit qu’il n’y a pas de familles, et séparément les parties traitent les demandes spécifiques raisonnables au fur et à mesure.
StubHub est l’affaire à lire avant de signer quoi que ce soit. StubHub a stipulé un protocole définissant les fichiers enfants comme incluant les hyperliens vers des documents internes, a ensuite découvert qu’elle ne pouvait pas s’y conformer, et a violé l’ordonnance dès sa première production. La juridiction a modifié le protocole et rejeté les sanctions, mais a désigné sans détour l’origine du dommage : le préjudice “a été causé par la décision insensée de StubHub de stipuler l’exigence relative aux hyperliens au départ”. Une stipulation transforme une limite technique en une décision de justice que vous êtes déjà en train d’enfreindre.
Le modèle Cerebras
James v. Cerebras Systems (N.D. Cal., 7 juillet 2026) est le premier protocole ESI stipulé qui traite les pièces jointes modernes et la gouvernance de la revue par IA générative dans une seule ordonnance, et ses clauses sur les hyperliens sont ce qu’il y a de plus reproductible aujourd’hui au dossier :
- Les documents hyperliés ne sont pas membres de la famille documentaire aux fins de production des pièces jointes.
- La partie demanderesse identifie des documents produits précis contenant des liens pertinents et réclame ces fichiers, dans la limite de 100 hyperliens pertinents et non couverts par le privilège pour une collecte ciblée.
- La partie productrice dispose de 14 jours pour produire la version telle qu’elle existait au moment de la collecte, ou la version telle qu’elle existait lors de l’envoi de l’hyperlien lorsque c’est possible.
Cette répartition est l’essentiel. Le demandeur supporte le coût de décider ce qui compte ; le producteur supporte le coût d’aller le chercher. Aucune des deux parties ne se voit imposer la collecte de tout par défaut qui rendait ce sujet ingérable. La même ordonnance fixe par ailleurs la validation de la revue par IA à un niveau de confiance de 95% pour l’échantillonnage de l’ensemble nul, avec un taux d’élusion n’excédant pas 3%, et exige les données de messagerie courte par blocs de conversation d’au moins 24 heures, points traités dans l’entrée eDiscovery.
Ce que les outils savent réellement faire
La réponse juridique est suffisamment stabilisée. C’est sur la réponse opérationnelle que les équipes continuent de se blesser, parce que les deux grandes suites collectent les pièces jointes modernes et que toutes deux le font avec des limites faciles à manquer.
Microsoft Purview eDiscovery collecte les pièces jointes cloud au niveau eDiscovery Premium, qui exige Microsoft 365 E5 ou le module complémentaire E5 Compliance et se licencie par dépositaire dont vous collectez les données. Il peut collecter la version en direct, la version existant au moment du partage, ou toutes les versions, et il regroupe le fichier lié avec son message parent au moyen d’un GroupID commun et d’une propriété Is modern attachment.
Le piège, c’est que la version partagée n’existe que si vous l’avez configurée à l’avance. Par défaut, le flux collecte la version en direct actuelle. Récupérer la version réellement envoyée exige une étiquette de rétention paramétrée pour s’appliquer automatiquement aux pièces jointes cloud, qui capture un instantané de la copie au moment du partage. Si cette étiquette n’était pas active avant que le partage n’ait lieu, la version envoyée n’a jamais été conservée et aucun réglage de collecte ne la fera revenir.
Les limites documentées de Purview, à jour de sa révision du 11 juin 2026 :
| Limite | Effet |
|---|---|
| Les 50 premiers liens par message | Les liens au-delà du 50e sont ignorés silencieusement |
| URL de plus de 2 048 caractères | Ignorées |
| Corps de message de plus de 100 000 caractères | Les liens au-delà ne sont pas pris en compte |
| Taille totale des propriétés supérieure à 1 Mo | Abandonnée |
| Emails HTML uniquement | Les emails en texte brut ne sont pas traités |
| Emails et messages chiffrés | Aucune extraction de pièce jointe moderne |
| Transferts et réponses | Les liens de la partie citée ne sont pas extraits : collectez le message d’origine |
| Canaux partagés Teams | Non pris en charge ; ajoutez manuellement le site du canal partagé |
| Liens vers des dossiers et vers OneNote | Non collectés ; fichiers individuels uniquement |
| Indexation avancée et OCR | Non appliquées au contenu du fichier lié |
L’attribution du dépositaire fonctionne elle aussi à l’envers : le fichier lié est attribué au dépositaire du message, pas à la personne propriétaire du fichier. Si l’utilisateur A partage avec l’utilisateur B un fichier issu du OneDrive de l’utilisateur C, et que vous collectez depuis la boîte de l’utilisateur B, le fichier atterrit sous l’utilisateur B.
Google Vault exporte les fichiers Drive liés via l’option Export linked Drive files des exports Gmail. Il ne renvoie que la version actuelle : Vault n’a pas d’équivalent de la version à l’instant de l’envoi comme l’instantané par étiquette de rétention de Purview. Les hyperliens publics, tels que les pages Google Sites publiées et les liens de formulaires Google soumissibles, ne peuvent pas être exportés, pas plus que certains formats hérités de liens Drive ni les liens contenus dans des messages chiffrés. Les fichiers exportés arrivent séparés de leurs messages parents, si bien que l’association doit être reconstituée en aval à partir du fichier de correspondance drive-links exporté, avant la revue.
Comment le négocier avant la collecte
Faites-le dans le protocole ESI, avant d’avoir collecté un seul dépositaire :
- Énoncez explicitement la règle de famille. Écrivez que les fichiers hyperliés ne sont pas membres de la famille documentaire, dans la formulation de Meta Pixel / Cerebras. Le silence est pire que l’une ou l’autre réponse, parce qu’il reporte le combat à un moment où vous avez déjà produit.
- Fixez le mécanisme de demande ciblée avec un chiffre et un délai. Cerebras vous donne 100 hyperliens et 14 jours. Choisissez des valeurs adaptées à l’affaire, mais choisissez des valeurs : des “demandes raisonnables” sans plafond reproduisent le problème de la collecte massive sous un autre nom.
- Nommez la version due. Celle de la date de collecte ou celle de la date d’envoi. Ne promettez la date d’envoi que si l’étiquetage de rétention des pièces jointes cloud tournait déjà sur les sites concernés au moment de l’envoi des messages. Vérifiez la date de configuration, pas le document de politique.
- Découpez les exclusions dont vous disposez réellement. Reportez dans le protocole les limites réelles de votre plateforme : le plafond de 50 liens, les messages chiffrés, les parties citées des transferts, les canaux partagés Teams. “Dans la mesure techniquement réalisable” est une formule qu’il vous faudra plaider ; une liste énumérée est une formule que vous pouvez montrer.
- Rendez le plafond réciproque. Dans une affaire opposant deux parties riches en documents, la partie demanderesse devient la partie productrice sur la demande reconventionnelle.
- Faites le test de faisabilité avant de signer. Prenez un échantillon de quelques centaines de messages dans le périmètre, passez-les dans la plateforme que vous utiliserez réellement, et comptez combien de liens aboutissent à un fichier que vous pouvez produire. C’est ce chiffre, et non la fiche technique du fournisseur, qui sert de base à la négociation.
Écueils fréquents
- Stipuler hyperlien-comme-pièce-jointe sans l’avoir testé. C’est exactement l’échec de StubHub, et la compréhension de la juridiction ne s’est pas étendue à la stipulation elle-même. Garde-fou : traitez toute clause sur les hyperliens comme un engagement technique exigeant une collecte d’échantillon avant signature, au même titre que l’acceptation d’un format de production.
- Supposer que la version envoyée est récupérable. Purview comme Vault renvoient par défaut la version en direct actuelle, et l’instantané à l’instant de l’envoi de Purview n’existe que là où une étiquette de rétention a été appliquée par anticipation. Garde-fou : activez l’étiquetage de rétention des pièces jointes cloud comme contrôle permanent de préparation aux conservations, pas comme étape du moment de la collecte : à ce stade la question est déjà tranchée.
- Lire un rapport de collecte propre comme s’il était complet. Le plafond de 50 liens, la coupure à 2 048 caractères d’URL et l’exclusion des parties citées écartent des liens sans lever d’erreur. Garde-fou : signalez au traitement les messages comportant plus de 50 liens et orientez-les vers une revue manuelle ; rapprochez le décompte des liens présents dans le corps des messages de celui des liens effectivement résolus.
- Conserver la boîte mail mais pas le fichier. Une conservation portant sur la boîte d’un dépositaire ne gèle pas un fichier lié situé dans le OneDrive d’une autre personne, et l’attribution de dépositaire de Purview ne vous dira pas à qui il appartenait vraiment. Garde-fou : cadrez la conservation légale sur les emplacements de fichiers autant que sur les dépositaires, et conservez les collections de sites depuis lesquelles les équipes concernées partagent réellement.
- Produire des fichiers liés qui n’ont jamais été filtrés au titre du privilège. Un fichier lié entre parce que son parent a répondu à un terme de recherche, y compris, selon la documentation Purview, lorsque le fichier lui-même n’aurait pas répondu et même s’il se trouve hors du périmètre de conformité. Garde-fou : faites passer le corpus des fichiers liés par la revue de privilège en tant que population distincte avec ses propres termes de recherche, avant qu’il ne rejoigne le lot de production.
Voir aussi
- eDiscovery — le processus environnant, les étapes EDRM et le reste du protocole Cerebras
- Processus de conservation légale — là où la conservation des pièces jointes cloud doit être décidée
- Revue de privilège — le filtre que les fichiers liés contournent par défaut
- Microsoft Purview eDiscovery — le versant collecte pour les tenants Microsoft 365
- Relativity — où atterrissent pour revue les familles reconstituées