Agents de code et DORA : ce qui s’applique déjà, ce qu’il faut demander

Le règlement DORA s’applique depuis le 17 janvier 2025[1]. Il vise notamment les gestionnaires de fonds d’investissement alternatifs et les sociétés de gestion, à l’exception de certains petits gestionnaires de fonds alternatifs visés à l’article 3, paragraphe 2, de la directive AIFM[1]. Ses règles se lisent avec le principe de proportionnalité : taille, profil de risque, nature et complexité des activités[1].

Le prestataire, lui, est défini largement : « une entreprise qui fournit des services TIC », ces services étant des services numériques et de données fournis de manière permanente par l’intermédiaire des systèmes de TIC[1]. Le modèle de registre fixé par la Commission prévoit d’ailleurs un type de service « Développement des TIC », qui couvre l’analyse, la conception et le développement de logiciels, ainsi que les essais[2]. Une agence ou un indépendant qui développe et maintient le code d’une société de gestion entre donc en principe dans ce cadre. La qualification revient à l’entité financière, pas au prestataire.

La responsabilité, elle, ne se délègue pas : les entités financières « restent à tout moment pleinement responsables » de leurs obligations[1]. Or l’AMF relève, dans son rapport sur 2025, que certains prestataires refusent d’être identifiés comme prestataires tiers de services TIC pour ne pas avoir à se conformer à DORA, que d’autres imposent des contrats standardisés ou facturent en supplément le droit d’audit, les tests d’intrusion et la coopération avec les autorités[3].

Aucun de ces incidents n’est attribué à un agent d’IA. Le chiffre dit autre chose : pour une société de gestion, le maillon faible est déjà le prestataire, et un prestataire qui code avec des agents ajoute des fournisseurs et des accès à la chaîne.

Les normes techniques de gestion du risque lié aux TIC, adoptées en 2024, ne mentionnent pas l’intelligence artificielle[4]. Elles décrivent pourtant, avec précision, ce que doit traverser un code avant la production. Le tableau les rapproche du travail d’un agent ; la colonne de droite est notre lecture, pas une position du superviseur.

La dérogation pour des données de production vise des tests spécifiques, pendant une durée limitée, après approbation de la fonction compétente et notification à la fonction de gestion du risque TIC[4]. Pour le contexte des agents, nous recommandons une règle interne plus stricte.

Trois précisions pèsent lourd. D’abord, ces règles valent aussi pour les systèmes « développés ou gérés par des utilisateurs extérieurs à la fonction TIC », selon une approche fondée sur les risques[4] : l’outil qu’un analyste aura fait écrire par un agent n’y échappe pas. Ensuite, le texte demande l’identification unique des personnes et des systèmes qui accèdent aux informations, et le maintien de la responsabilité pour les actions menées via des comptes génériques[4]. Un agent qui pousse du code sous le compte partagé de l’équipe brouille exactement ce que le texte veut garder lisible. Enfin, la journalisation couvre le contrôle des accès et la gestion des changements, et protège les journaux contre les manipulations, la suppression et l’accès non autorisé[4] : les actions d’un agent n’ont aucune raison d’y échapper.

Avant de conclure, l’entité financière détermine si le service soutient une fonction critique ou importante, identifie les risques, y compris de concentration, fait « preuve de toute la diligence requise » à l’égard du prestataire et évalue les conflits d’intérêts[1]. Elle tient à jour un registre de tous les accords portant sur l’utilisation de services TIC. Elle communique au moins une fois par an à son autorité les informations prévues par l’article 28, paragraphe 3, lui remet le registre sur demande et l’informe en temps utile de tout projet d’accord portant sur une fonction critique ou importante[1].

Le contrat, écrit, décrit au minimum les services et la sous-traitance autorisée, les lieux de fourniture des services et de traitement des données, la protection des données, l’accès et la restitution, l’assistance en cas d’incident, la coopération avec les autorités et la résiliation[1]. Pour une fonction critique ou importante s’ajoutent des plans d’urgence et des mesures de sécurité, la participation aux tests de pénétration fondés sur la menace, des « droits illimités d’accès, d’inspection et d’audit » et une stratégie de sortie avec période de transition[1].

C’est ici que l’agent de code compte. Si le prestataire envoie le code de son client à un modèle hébergé, le fournisseur de ce modèle participe au service. Le registre doit recenser les sous-traitants qui sous-tendent de fait les services soutenant des fonctions critiques ou importantes[2]. Pour ces services, le prestataire doit pouvoir identifier tous ses sous-traitants, le contrat dit ce qui peut être sous-traité et à quelles conditions, et tout changement significatif est notifié avec un préavis qui permet à l’entité de s’y opposer[5]. L’ANSSI rappelle de son côté que toute donnée transmise à un modèle hébergé peut être accessible à son fournisseur[6].

Le 3 juin 2026, l’AMF a estimé que les progrès de certains modèles d’IA sont « susceptibles d’accélérer l’identification de vulnérabilités » et d’en faciliter l’exploitation[7]. Parmi les bonnes pratiques qu’elle rappelle : maintenir une cartographie des systèmes, des données et des prestataires critiques, maîtriser les accès, appliquer les correctifs « dans des délais désormais fortement accélérés », intégrer les risques liés à l’IA dans les scénarios de cybersécurité[7]. Elle a aussi annoncé une enquête auprès des sociétés de gestion sur leurs mesures face aux risques propres aux modèles d’IA, avec des résultats attendus à l’automne 2026[7]. Au 7 novembre, nous n’avons pas retrouvé de publication de ces résultats : nous ne leur attribuons donc aucune conclusion.

Le 31 juillet 2026, les trois autorités européennes de surveillance ont publié une déclaration commune sur les risques TIC liés aux modèles d’IA les plus avancés[8]. Parmi leurs exemples : des inventaires d’actifs qui incluent les composants d’IA, des pratiques de développement sécurisé éventuellement assistées par l’IA, la protection de la confidentialité du code source. L’annexe précise qu’elle n’établit pas d’exigences supplémentaires et qu’elle se lit comme une série d’exemples, y compris pour le dialogue avec les prestataires[8].

Le rapport de l’AMF sur les incidents de 2025 range enfin l’intelligence artificielle parmi les technologies dont l’adoption constitue « une source de risque à encadrer »[3]. Aucun de ces textes ne crée d’obligation propre aux agents de code. Tous relisent les obligations existantes avec l’IA en tête, et c’est ainsi qu’un contrôle les lira.

Côté entité financière, l’objectif est d’obtenir des réponses écrites et vérifiables, qui alimentent le registre, le contrat et l’analyse de risque. Côté prestataire, c’est le miroir : préparer ces réponses avant qu’on les demande, sur une page, avec les preuves. Une équipe interne qui code avec des agents gagne à se poser les mêmes questions.

Ces réponses ne valent pas conformité. Elles donnent à l’entité de quoi mener sa propre analyse, proportionnée à sa taille et à ses risques[1].

Le prestataire qui répond à ces sept questions en une page ne prouve pas qu’il est sûr. Il prouve qu’on peut le vérifier, et c’est précisément ce que DORA attend de son client.