AI Act, RGPD, NIS2 et DORA : le calendrier réglementaire de l’externalisation

Cinq textes européens encadrent désormais une même mission externalisée : traitement de données, usage de l’IA, cybersécurité, résilience financière et accès aux données. Leurs échéances ne coïncident pas, et l’omnibus numérique de juillet 2026 en a déplacé plusieurs. Voici la chronologie 2026-2028, processus par processus.

Une banque française confie son support client de premier niveau à un prestataire installé hors de l’Union européenne. Le prestataire déploie un agent conversationnel qui trie les demandes avant de les router vers un opérateur humain. Quatre cadres se superposent sur cette seule mission : le RGPD pour les données des clients, l’AI Act pour l’agent conversationnel, DORA pour la dépendance technologique de l’établissement, le Data Act pour la réversibilité de l’outil.

Aucun de ces textes ne se lit à la place des autres. Aucun ne suit le même calendrier. Et depuis le 27 juillet 2026, une partie du calendrier de l’AI Act a bougé.

Cet article n’est pas un avis juridique. Il propose une chronologie datée, une matrice reliant chaque texte à un processus externalisé, et un plan d’action trimestriel. Toute décision contractuelle doit être validée par un juriste ou un DPO compétent.

Quels textes peuvent s’appliquer simultanément à une mission externalisée ?

La question posée par les directions juridiques n’est presque jamais « quel texte s’applique ». Elle est « lesquels s’appliquent en même temps, et lequel impose l’exigence la plus stricte ». Un même flux de tickets clients peut relever de quatre régimes distincts sans qu’aucun ne prime sur les autres.

Données personnelles, IA, cybersécurité et services financiers

Chaque texte découpe la réalité selon son propre critère. Le RGPD raisonne par traitement de données personnelles. L’AI Act raisonne par système d’IA et par niveau de risque. NIS2 raisonne par secteur et par taille d’entité. DORA raisonne par fonction critique dans le secteur financier. Le Data Act raisonne par service de traitement de données et par produit connecté.

Un support client assisté par IA, opéré depuis Casablanca pour une banque de détail, coche les cinq cases. Le prestataire n’a pas à choisir : il doit répondre à l’ensemble.

Responsable, sous-traitant, fournisseur et déployeur

Les qualifications ne se recouvrent pas, et la confusion coûte cher en négociation. Sous le RGPD, le donneur d’ordre est généralement responsable de traitement, le prestataire sous-traitant au sens de l’article 28. Sous l’AI Act, la grille est différente : on distingue le fournisseur du système et le déployeur.

Un prestataire BPO qui achète un agent conversationnel du marché et l’exploite pour son client est déployeur, pas fournisseur. S’il entraîne son propre modèle et le commercialise sous sa marque, il devient fournisseur, avec des obligations sans commune mesure. La frontière se déplace dès qu’un prestataire personnalise sensiblement un système existant.

Le contrat doit donc nommer les rôles dans chaque référentiel, pas dans un seul. Le sujet rejoint la question plus large du choix d’un prestataire BPO, où les qualifications juridiques comptent autant que les tarifs.

Sous-traitance ultérieure et chaîne de dépendance

Le point aveugle des cahiers des charges reste le rang 2. Votre prestataire marocain héberge chez un fournisseur cloud américain, utilise un outil de transcription indien, et sous-traite les pics de volume à une structure malgache. Trois dépendances que votre contrat ne mentionne peut-être pas.

Le RGPD impose une autorisation écrite du responsable pour tout sous-traitant ultérieur. DORA va plus loin pour les fonctions critiques : la sous-traitance en chaîne doit être identifiée dans le registre et les exigences contractuelles doivent se répercuter en cascade. NIS2 place la sécurité de la chaîne d’approvisionnement dans les mesures obligatoires de son article 21.

Quelles échéances de l’AI Act concernent les donneurs d’ordre et prestataires ?

Le 2 août 2026 a été présenté pendant deux ans comme la bascule complète de l’AI Act. La réalité est plus fragmentée, et le raccourci qui circule depuis l’été (« l’AI Act est reporté ») est faux.

Le règlement (UE) 2026/1744, dit omnibus numérique sur l’IA, a été publié au Journal officiel de l’Union européenne le 24 juillet 2026 et est entré en vigueur trois jours plus tard. Il ne touche ni à l’architecture du texte ni à son approche par les risques. Il déplace des dates, et seulement pour le haut risque.

Pour un acheteur de prestations, trois conséquences pratiques se dégagent.

• L’obligation de transparence s’applique déjà. Si votre prestataire opère un chatbot pour vos clients, celui-ci doit indiquer qu’il n’est pas humain. Sans période de grâce.
• Le sursis de décembre 2026 est étroit. Il ne couvre que le marquage technique des contenus générés par des systèmes antérieurs au 2 août 2026, pas la déclaration des agents conversationnels.
• Le report du haut risque n’est pas une dispense. Un outil de présélection de CV opéré par un prestataire RH reste dans l’annexe III. Le délai porte sur l’échéance, pas sur la qualification.

L’omnibus a aussi assoupli l’obligation de littératie en IA. Fournisseurs et déployeurs ne doivent plus « assurer » un niveau suffisant, mais prendre des mesures pour soutenir son développement. Le texte précise qu’aucun niveau spécifique n’est imposé pour une personne donnée. La clause de formation reste utile dans un contrat, elle n’est plus une obligation de résultat.

Les sanctions de l’article 50 atteignent 15 millions d’euros ou 3 % du chiffre d’affaires mondial. Le choix entre un traitement humain et un traitement automatisé se pose donc aussi en termes d’exposition, sujet traité dans notre comparatif IA ou externalisation humaine.

Comment NIS2 modifie-t-elle le contrôle de la chaîne fournisseur ?

Voici l’anomalie française. La directive NIS2 devait être transposée avant le 17 octobre 2024. Au 20 août 2026, elle ne l’est toujours pas. Le véhicule législatif, la loi relative à la résilience des infrastructures critiques et au renforcement de la cybersécurité, a été adopté par le Sénat le 12 mars 2025 puis s’est enlisé. Son examen à l’Assemblée nationale, annoncé pour juillet 2026, a glissé à la rentrée.

Cette loi transpose trois textes d’un coup : REC sur la résilience des entités critiques, NIS2 sur la cybersécurité et le volet directive de DORA. L’ampleur du chantier explique une partie du retard.

L’effet cascade rend le retard sans importance pratique

Une entreprise qui attend la promulgation pour agir se trompe de calendrier. Les grands donneurs d’ordre soumis à NIS2 dans d’autres États membres sont déjà tenus de sécuriser leur chaîne d’approvisionnement. Leurs directions achats envoient des questionnaires sécurité et insèrent des clauses cyber dans les contrats depuis des mois.

Un prestataire BPO de quarante personnes peut rester hors du champ légal de NIS2 et se voir imposer les mêmes exigences par contrat. C’est le mécanisme dominant d’exposition pour les petites structures.

L’ANSSI a ouvert la plateforme MonEspaceNIS2 pour le pré-enregistrement et le diagnostic. Le périmètre français annoncé porte sur quinze à vingt mille entités selon les estimations publiées, contre environ cinq cents sous NIS1. Les sanctions envisagées atteignent 10 millions d’euros ou 2 % du chiffre d’affaires mondial.

La difficulté opérationnelle la plus documentée par l’ENISA reste la continuité d’activité et le risque de chaîne d’approvisionnement. Elle recoupe directement les questions d’implantation géographique et d’infrastructure locale d’un prestataire.

Que demande DORA pour les prestations ICT et leurs sous-traitants ?

DORA est applicable depuis le 17 janvier 2025 et ne souffre d’aucun retard de transposition : c’est un règlement. Il vise les entités financières, mais son effet réel porte sur leurs fournisseurs. Toute entreprise qui fournit des services numériques, des services de données ou une assistance matérielle de manière continue entre dans la définition du prestataire TIC.

Un BPO qui opère un back-office de gestion de sinistres pour un assureur est un prestataire TIC au sens de DORA, même s’il se perçoit comme un pur opérateur de processus.

Le registre d’informations est devenu l’outil de contrôle central

L’article 28(3) impose aux entités financières de tenir un registre documentant chaque accord contractuel avec un prestataire TIC : identification du fournisseur, fonctions supportées, localisation des données, évaluation de criticité, chaîne de sous-traitance et stratégie de sortie.

La remise attendue par l’ACPR pour la collecte 2026 était fixée au 31 mars, au format xBRL-CSV. Les autorités européennes de surveillance utilisent ces registres agrégés pour désigner les prestataires TIC critiques placés sous supervision directe.

Concrètement, votre client financier vous demandera des données que vous n’avez peut-être jamais formalisées : identifiant légal, pays de traitement effectif, liste des sous-traitants de rang 2, délai de restitution des données en cas de sortie. La phase de démarrage est le bon moment pour construire ce socle, comme le montre notre méthode d’onboarding d’un prestataire externalisé.

• Fonction critique ou importante : clauses renforcées, droits d’audit proportionnés, plan de sortie activable et testé.
• Sous-traitance de rang 2 : notification obligatoire, approbation préalable lorsque la fonction est critique.
• Concentration : l’entité financière doit évaluer sa dépendance à un fournisseur unique et documenter les alternatives.
• Résiliation anticipée : modalités prévues, y compris sur injonction d’une autorité.

DORA prévaut sur NIS2 pour les entités entrant dans son périmètre. C’est une lex specialis : inutile d’empiler deux dispositifs concurrents sur le même contrat bancaire.

Comment le RGPD et le Data Act complètent-ils ce cadre ?

Le RGPD reste la base. Il fixe les rôles, encadre les transferts hors Union européenne, impose des mesures de sécurité proportionnées et exige une autorisation pour toute sous-traitance ultérieure. Pour une mission opérée depuis le Maroc, la Tunisie ou Madagascar, le mécanisme de transfert est le sujet central et mérite un traitement dédié, développé dans notre guide sur l’externalisation hors Union européenne et le RGPD.

Le raccourci à éviter : croire que des clauses contractuelles types suffisent en toutes circonstances. Elles doivent être accompagnées d’une évaluation du droit local et, le cas échéant, de mesures supplémentaires techniques ou organisationnelles.

Le Data Act touche la réversibilité, pas les données personnelles

Le Data Act est entré en application le 12 septembre 2025. Son chapitre VI encadre le changement de fournisseur de services de traitement de données, du IaaS au SaaS. Le calendrier reste échelonné.

Pour un acheteur de prestations, l’apport est direct : le verrouillage technique et tarifaire d’un outil imposé par un prestataire devient difficilement défendable. En France, la loi SREN du 21 mai 2024 avait déjà intégré une partie de ces règles, avec des amendes ARCEP pouvant atteindre 3 % du chiffre d’affaires mondial et 5 % en cas de récidive.

Un piège de lecture revient souvent : le Data Act ne remplace pas le RGPD. Un même jeu de données peut relever des deux régimes, avec des logiques opposées. Le premier organise la circulation, le second la restreint.

Quelles actions planifier entre 2026 et 2028 ?

La chronologie ne sert à rien sans affectation. Chaque échéance doit porter un nom de responsable interne et une preuve attendue. Voici une trame trimestrielle, à ajuster selon le secteur et le nombre de contrats concernés.

Trois écueils reviennent dans les projets observés.

• Confondre entrée en vigueur et date d’application. Un texte peut être en vigueur depuis deux ans sans qu’aucune obligation ne soit encore opposable.
• Écrire « conforme » dans un compte rendu sans avoir examiné l’ensemble du dispositif. La conformité s’apprécie texte par texte et processus par processus.
• Traiter la réglementation comme un sujet juridique isolé. Les preuves attendues sont opérationnelles : journaux, tests, registres, feuilles de présence.

Le coût de cette préparation reste rarement chiffré en amont. Il s’ajoute au budget de pilotage d’une externalisation et pèse sur le calcul de retour sur investissement, comme le rappelle notre analyse du coût réel de l’externalisation.

Le calendrier compte moins que la preuve que vous pouvez produire demain matin

Une direction juridique peut connaître par cœur les six dates de l’AI Act et rester incapable de dire, en cas de contrôle, qui a validé le dernier test de réversibilité de son prestataire. C’est cette seconde question qui décide de l’issue.

Le critère de décision unique tient en une ligne : pour chaque mission externalisée, savez-vous nommer le texte applicable, le responsable interne et la preuve manquante ? Tant que ces trois colonnes ne sont pas remplies, la chronologie reste un document de veille.

Téléchargez la matrice « texte, processus, obligation, preuve, responsable » et remplissez-la sur vos trois contrats les plus exposés. Les trous apparaissent en moins d’une heure.

SOURCES ET RÉFÉRENCES

Les dates de l’AI Act ont été recoupées avec le calendrier d’application publié par la Commission européenne et avec le texte du règlement (UE) 2026/1744 dit omnibus numérique sur l’IA, entré en vigueur le 27 juillet 2026. Les exigences de gestion du risque fournisseur et de continuité proviennent des guides techniques de mise en œuvre de NIS2 publiés par l’ENISA et de la directive (UE) 2022/2555 elle-même. Le volet financier s’appuie sur le règlement DORA (UE) 2022/2554 et sur les travaux de l’Autorité bancaire européenne relatifs à la sous-traitance TIC. Le calendrier de portabilité provient de la synthèse du Data Act publiée sur EUR-Lex. Les mécanismes de transfert hors Union européenne sont documentés par le Comité européen de la protection des données, notamment pour les clauses contractuelles types et les mesures supplémentaires. Suivi de la transposition française : dossier législatif de la loi relative à la résilience des infrastructures critiques et au renforcement de la cybersécurité, consulté le 20 août 2026.