Modèle de TIA : analyse d'impact du transfert (2026)

L’essentiel. La TIA (Transfer Impact Assessment, ou analyse d’impact du transfert) est l’évaluation que tout exportateur de données doit documenter avant un transfert hors de l’Espace économique européen fondé sur des clauses contractuelles types. Elle vérifie que la législation du pays destinataire n’empêche pas les garanties contractuelles de produire effet, et détermine les mesures supplémentaires éventuelles. Le modèle ci-dessous suit la structure en 6 étapes issue de l’arrêt Schrems II et des recommandations du CEPD.

Depuis l’arrêt Schrems II de la Cour de justice de l’Union européenne (2020), qui a invalidé le Privacy Shield, un transfert hors EEE fondé sur les clauses contractuelles types ne suffit plus à lui seul. L’exportateur doit vérifier, au cas par cas, que le droit du pays destinataire ne prive pas ces clauses de leur effectivité — notamment au regard des pouvoirs d’accès des autorités publiques locales. Cette vérification documentée porte un nom : la TIA.

Dans ma pratique, je constate que la TIA est l’un des documents les plus souvent absents des dossiers de conformité, alors qu’elle conditionne la licéité de tout transfert reposant sur les CCT. Beaucoup d’organisations signent les clauses et s’arrêtent là. Or les CCT elles-mêmes (module de la Commission européenne, clause 14) imposent contractuellement de conduire et documenter cette évaluation. Ce guide fournit un modèle structuré en 6 étapes, conforme aux recommandations 01/2020 du Comité européen de la protection des données (CEPD).

Quand une TIA est-elle exigée ?

La TIA n’est requise que pour les transferts fondés sur les garanties appropriées de l’article 46 du RGPD — principalement les CCT et les règles d’entreprise contraignantes (BCR). Elle n’est pas nécessaire lorsque le transfert repose sur :

• une décision d’adéquation (article 45) : le pays offre un niveau de protection jugé adéquat par la Commission ;
• le Data Privacy Framework (DPF) pour les transferts vers des entités américaines certifiées, qui fonctionne comme une adéquation partielle ;
• une dérogation de l’article 49 (consentement explicite, exécution d’un contrat), réservée aux transferts occasionnels et non systématiques.

En pratique, dès qu’un sous-traitant héberge ou accède à des données depuis un pays tiers sans adéquation, et que vous vous appuyez sur les CCT, une TIA est due.

Le cadre légal de la TIA

Trois sources structurent l’exercice :

• L’article 44 du RGPD pose le principe : aucun transfert ne doit compromettre le niveau de protection garanti par le règlement.
• L’article 46(1) exige des garanties appropriées et des droits opposables effectifs pour les personnes concernées — c’est ce mot « effectifs » qui fonde la TIA.
• La clause 14 des CCT de la Commission (décision d’exécution 2021/914) impose contractuellement aux parties de garantir « n’avoir aucune raison de croire » que le droit du pays tiers empêche l’importateur de respecter ses obligations, et de documenter cette évaluation.

Les recommandations 01/2020 du CEPD fournissent la méthode de référence en six étapes, reprise dans le modèle ci-dessous. La CNIL renvoie à cette méthodologie.

Modèle indicatif fourni à titre documentaire — ne constitue pas un conseil juridique. À adapter à votre contexte avant usage. Version 1.0 — 2 juillet 2026.

Modèle de TIA — analyse d’impact du transfert

ANALYSE D’IMPACT DU TRANSFERT (TIA) [Nom de l’exportateur] — Référence : TIA-[aaaa]-[n°] — Date : [jj/mm/aaaa] — Prochaine revue : [jj/mm/aaaa]

Étape 1 — Description du transfert

• Exportateur : [dénomination, rôle : responsable de traitement / sous-traitant]
• Importateur : [dénomination, pays, rôle]
• Finalité(s) du traitement transféré : […]
• Catégories de données : [ordinaires / sensibles au sens de l’article 9 ?]
• Catégories de personnes concernées : [clients, salariés, prospects…]
• Volume et fréquence : [ponctuel / continu / accès à distance]
• Chaîne de transfert (transferts ultérieurs, sous-traitants ultérieurs) : […]
• Format des données : [en clair / chiffré / pseudonymisé]

Étape 2 — Instrument de transfert utilisé

• Base juridique du transfert : [CCT module __ / BCR / autre]
• Date de signature / version des CCT : […]
• Confirmation que l’instrument est adapté au scénario (rôle exportateur/importateur) : [oui/non]

Étape 3 — Évaluation du droit et des pratiques du pays tiers

• Le droit du pays tiers permet-il aux autorités publiques d’accéder aux données transférées ? [analyse fondée sur des sources publiques : lois, rapports, jurisprudence]
• Ces pouvoirs d’accès sont-ils encadrés (nécessité, proportionnalité, recours juridictionnel effectif) ?
• Existe-t-il des mécanismes de recours ouverts aux personnes concernées ?
• Sources consultées : [législation, rapports d’ONG, décisions, notes du CEPD]
• Conclusion intermédiaire : [le droit local compromet-il l’effectivité des garanties ? oui / non / à conditions]

Étape 4 — Mesures supplémentaires

Si l’étape 3 conclut à un risque, identifier les mesures supplémentaires :

• Techniques : chiffrement de bout en bout dont l’importateur ne détient pas les clés, pseudonymisation robuste, hébergement des clés dans l’EEE.
• Contractuelles : engagement de transparence sur les demandes d’accès, obligation de contestation, clause d’information de l’exportateur.
• Organisationnelles : politique interne de gestion des réquisitions, minimisation stricte des données transférées, journalisation des accès.
• Ces mesures suffisent-elles à ramener le niveau de protection à un standard essentiellement équivalent ? [oui / non]

Étape 5 — Décision

• [ ] Le transfert peut être réalisé en l’état (garanties suffisantes).
• [ ] Le transfert peut être réalisé sous réserve de la mise en œuvre des mesures supplémentaires listées à l’étape 4.
• [ ] Le transfert doit être suspendu / n’a pas lieu (aucune mesure ne ramène un niveau équivalent).
• Décision prise par : [DPO / direction] — Date : […]

Étape 6 — Réexamen

• Périodicité de la revue : [au moins une fois par an].
• Événements déclenchant une revue anticipée : évolution législative du pays tiers, nouvelle décision de justice, nouvelle demande d’accès reçue par l’importateur, modification de la chaîne de sous-traitance.
• Date de la prochaine revue : […]

Bien conduire l’étape 3 : le cœur de l’analyse

L’étape 3 est celle qui exige le plus de rigueur et qui fait la différence en cas de contrôle. Il ne s’agit pas d’affirmer que « le pays est sûr », mais de démontrer, sources à l’appui, que les pouvoirs d’accès des autorités locales sont encadrés et n’annulent pas les garanties contractuelles.

Trois critères doivent être appréciés :

Critère	Question à documenter
Existence de l’accès	Une loi permet-elle l’accès aux données par les autorités ?
Encadrement	L’accès est-il limité par la nécessité et la proportionnalité ?
Recours	La personne concernée dispose-t-elle d’un recours juridictionnel effectif ?

Lorsque les données sont des données sensibles au sens de l’article 9, le niveau d’exigence sur les mesures supplémentaires est renforcé.

Identifier le bon module de CCT

L’étape 2 du modèle suppose de retenir le module de clauses adapté à la configuration réelle du transfert. La décision d’exécution 2021/914 de la Commission organise quatre modules selon la qualité respective des parties :

Module	Exportateur	Importateur
1	Responsable de traitement	Responsable de traitement
2	Responsable de traitement	Sous-traitant
3	Sous-traitant	Sous-traitant ultérieur
4	Sous-traitant	Responsable de traitement

Se tromper de module fausse toute la chaîne d’obligations : les engagements de l’importateur, les modalités de sous-traitance ultérieure et les responsabilités en cas de demande d’accès diffèrent d’un module à l’autre. La TIA doit expressément confirmer que le module retenu correspond aux rôles réels des parties — sans quoi les garanties invoquées ne couvrent pas le transfert effectivement réalisé. Cette qualification s’appuie sur la même grille responsable/sous-traitant que celle du contrat de l’article 28.

Documenter les sources : la preuve de sérieux

L’appréciation du droit du pays tiers (étape 3) n’a de valeur que si elle repose sur des sources vérifiables. Une TIA qui affirme sans citer est une TIA fragile. En pratique, appuyez l’analyse sur : les textes législatifs pertinents du pays destinataire, les rapports d’autorités indépendantes et d’organisations reconnues, la jurisprudence disponible, et les prises de position du CEPD relatives à la zone concernée. Datez chaque source : le droit d’un pays tiers évolue, et une analyse fondée sur un état du droit périmé ne protège plus. C’est cette traçabilité des sources qui distingue une évaluation défendable en contrôle d’une affirmation générique.

Erreurs fréquentes

Erreur	Conséquence
Signer les CCT sans conduire de TIA	Transfert exposé, obligation de la clause 14 non respectée
TIA générique, non liée au traitement réel	Analyse non probante en contrôle
Ignorer les transferts ultérieurs (sous-traitants de l’importateur)	Chaîne de transfert non couverte
Confondre DPF et CCT	Application d’une méthode inadaptée au fondement retenu
Aucune revue périodique	TIA périmée après évolution du droit local
Mesures supplémentaires listées mais jamais mises en œuvre	Écart entre le document et la réalité

Une TIA n’est pas un document que l’on signe une fois. C’est une évaluation vivante : elle doit refléter l’état du droit du pays tiers et les mesures effectivement appliquées. Pour cartographier vos flux transfrontières et documenter chaque TIA de façon centralisée et versionnée, un logiciel RGPD permet de relier chaque transfert à son analyse et de tracer les réexamens.

La TIA s’articule enfin avec les autres briques documentaires : elle alimente le registre des traitements, peut nourrir une analyse d’impact (AIPD) lorsque le transfert présente un risque élevé, et doit rester cohérente avec les mentions d’information délivrées aux personnes.

FAQ

TIA et AIPD, est-ce la même chose ?

Non. L’AIPD (analyse d’impact relative à la protection des données, article 35) évalue les risques d’un traitement pour les droits des personnes. La TIA évalue spécifiquement si un transfert hors EEE fondé sur des garanties appropriées reste effectif face au droit du pays destinataire. Un même projet peut nécessiter les deux : l’AIPD pour le traitement, la TIA pour son volet transfert.

Faut-il une TIA si mon prestataire est certifié Data Privacy Framework ?

Non, pas pour la partie couverte par le DPF. Si l’importateur américain est certifié DPF et que le transfert entre dans le champ de sa certification, il repose sur un mécanisme d’adéquation partielle qui dispense de TIA. En revanche, si vous vous appuyez sur les CCT (par prudence ou parce que l’entité n’est pas certifiée), la TIA redevient nécessaire.

Qui doit rédiger la TIA, l’exportateur ou l’importateur ?

La responsabilité incombe à l’exportateur, car c’est lui qui décide du transfert. Mais l’importateur doit coopérer : lui seul connaît précisément le droit local applicable et les demandes d’accès qu’il reçoit. La clause 14 des CCT organise d’ailleurs cette coopération. En pratique, l’exportateur pilote, l’importateur alimente.

À quelle fréquence réviser une TIA ?

Au moins annuellement, et immédiatement en cas d’événement : nouvelle loi du pays tiers élargissant les pouvoirs d’accès, décision de justice pertinente, demande d’accès reçue par l’importateur, ou modification de la chaîne de sous-traitance. Une TIA figée est une TIA qui ne protège plus.

Que faire si l’analyse conclut à un risque non maîtrisable ?

Si aucune mesure supplémentaire technique, contractuelle ou organisationnelle ne permet de ramener la protection à un niveau essentiellement équivalent à celui de l’EEE, le transfert ne doit pas avoir lieu, ou doit être suspendu. Les alternatives : héberger dans l’EEE, changer de prestataire, ou restructurer le traitement pour éviter l’accès depuis le pays tiers.

Le chiffrement suffit-il comme mesure supplémentaire ?

Il peut suffire dans certains scénarios, à condition que l’importateur situé dans le pays tiers n’ait pas accès aux clés de déchiffrement et n’ait aucun moyen d’accéder aux données en clair. Si l’importateur doit traiter les données en clair pour rendre son service, le chiffrement en transit ou au repos ne neutralise pas le pouvoir d’accès local. La robustesse dépend du cas d’usage réel.