Ce que les CAC français se trompent sur le périmètre du RIA
Première idée reçue : "le RIA vise les fournisseurs". Non. L'Article 3 distingue "fournisseur" (celui qui met l'IA sur le marché) et "déployeur" (celui qui l'utilise sous sa propre autorité dans un cadre professionnel). Un commissaire aux comptes (CAC) qui branche Cegid Audit, MindBridge ou Kira sur le fichier des écritures comptables (FEC) est déployeur. Point.
Deuxième idée reçue : "notre outil n'est pas à haut risque, donc rien ne s'applique". Faux. L'Article 50 impose aux déployeurs, pour les systèmes à risque limité, des obligations de transparence envers les personnes concernées (ce qui inclut les équipes du client lorsque l'outil traite leurs données personnelles).
Troisième idée reçue, la plus dangereuse : "l'outil a été acheté chez un gros éditeur, il est forcément conforme". Chez nos clients, le marquage CE n'a été produit que par un fournisseur sur quatre sollicités. Les autres renvoient un PDF commercial qui ne tient pas la route face à l'Article 13.
Le cabinet comme déployeur : ce que personne ne lit
L'Article 26 liste les obligations du déployeur d'un système à haut risque. Utiliser le système conformément à la notice. Assurer une supervision humaine conforme à l'Article 14. Surveiller le fonctionnement et notifier les incidents au fournisseur. Conserver les journaux automatiquement générés pendant au moins six mois.
Dans les faits, aucune de ces obligations ne figure dans le plan de mission type des cabinets de taille moyenne que nous auditons. Le dossier est trop léger sur ce volet. Et ce n'est pas par négligence : c'est parce que la NEP 230 (documentation d'audit) et l'ISA 220 Revised (qualité de mission) ne référencent pas encore le RIA. Le praticien ne voit pas la passerelle.
Ce que le RIA exige réellement
Classification : Article 6 et Annexe III, lus ensemble
Le RIA établit quatre niveaux : minimal, limité, haut risque, inacceptable. Pour les outils d'audit, le débat se joue entre limité et haut risque, et la ligne passe par l'Annexe III.
L'Annexe III, point 5 (b), couvre les systèmes utilisés pour "évaluer la solvabilité des personnes physiques ou établir leur score de crédit". Un outil qui analyse les écritures pour détecter la fraude n'y entre pas directement. En revanche, le point 8 (a) vise les systèmes destinés à l'administration de la justice et aux processus démocratiques (hors champ). Aucun point de l'Annexe III ne nomme explicitement l'audit légal.
Sur le papier, les outils d'audit sortent donc du périmètre haut risque par défaut. Ce qui les y ramène, c'est l'Article 6, paragraphe 2 : un système devient haut risque s'il est un composant de sécurité d'un produit couvert par la législation d'harmonisation de l'Union. La plupart des outils d'audit n'en sont pas.
Chez nos clients, le vrai arbitrage porte donc sur l'Article 50 (transparence) et non sur le Titre III complet. C'est une nuance que les premières checklists de conformité commercialisées ont écrasée.
Sur le terrain : la supervision humaine de l'Article 14
L'Article 14 exige qu'une personne physique puisse "comprendre correctement les capacités et les limites pertinentes du système", "rester consciente de la tendance potentielle à se fier automatiquement ou trop fortement aux sorties" (le "biais d'automatisation"), et "décider de ne pas utiliser le système".
Ce qui se passe réellement : l'associé signataire regarde une liste de 23 transactions "à risque élevé", valide 19, écarte 4. Dans 80 % des dossiers que nous voyons, rien n'est documenté sur le raisonnement derrière ces écartements. Le dossier conserve la liste de l'IA comme si c'était un élément probant autonome. C'est le problème. La supervision humaine, au sens de l'Article 14, ne se prouve pas par la présence d'un humain : elle se prouve par la trace de son désaccord.
Article 13 : la transparence vers le fournisseur, pas vers le régulateur
L'Article 13 oblige le fournisseur à remettre au déployeur une documentation technique et un mode d'emploi compréhensibles. Chez nos clients, cette documentation arrive rarement spontanément. Il faut la demander par écrit, et souvent l'obtenir via un addendum contractuel.
Le point de friction avec l'ISA 500
Là où le RIA crée un vrai problème pour la profession, c'est dans l'articulation avec l'ISA 500 (éléments probants). L'ISA 500.7 exige que l'auditeur évalue la pertinence et la fiabilité des informations utilisées comme éléments probants, y compris les informations produites par un expert de la direction ou par le cabinet lui-même.
Une sortie d'IA (par exemple les 23 transactions remontées par l'outil de détection d'anomalies) est-elle un élément probant au sens de l'ISA 500, ou un simple orienteur de procédures ? Deux positions coexistent, et elles divisent les associés.
Position A : c'est un élément probant. L'outil produit une inférence sur les données. L'ISA 500.A1 s'applique : il faut tester la fiabilité de la source, donc des algorithmes et du jeu d'entraînement. Cela impose au cabinet de mener une forme de "due diligence modèle" (audit de l'auditeur, au sens littéral).
Position B : c'est un outil d'orientation, pas un élément probant. Les 23 transactions ne prouvent rien par elles-mêmes. Ce qui prouvera, ce sont les procédures substantives menées sur ces transactions. L'ISA 500 ne s'applique pas à l'outil, seulement à ses sorties une fois retestées manuellement.
Nous penchons pour la position B, parce que l'ISA 500 vise les informations utilisées comme preuve à l'appui de la conclusion, et qu'un tri initial n'est pas une preuve à l'appui. C'est un moyen de sélection, comparable à l'échantillonnage statistique. Mais la question n'est pas tranchée, et la CNCC n'a publié aucune position formelle à fin mars 2026.
Un angle mort : le biais d'automatisation
Le RIA évoque explicitement le biais d'automatisation à l'Article 14, paragraphe 4 (b). La littérature d'audit, elle, le traite à peine. L'ISA 200.A22 (scepticisme professionnel) parle de ne pas accepter sans remise en cause, mais sans viser spécifiquement les sorties algorithmiques.
Pourquoi c'est un problème spécifique à notre profession : le CAC est structurellement incité à la confirmation. Lorsqu'un outil classe 23 transactions "à risque" et qu'il en reste 5 000 non flaguées, la pression budgétaire pousse à considérer les 5 000 comme propres. Le RIA demande l'inverse, et ne fournit aucune méthode pratique pour y parvenir. C'est là que se joue la prochaine génération de constats H2A.
L'IA n'aura pas la peau des auditeurs. Elle aura celle des dossiers insuffisamment documentés sur la supervision humaine.
Exemple pratique : Durand Analytics SARL
Contexte client : Durand Analytics SARL, société de services informatiques basée à Lyon, 85 salariés, chiffre d'affaires 12,4 M EUR. L'équipe d'audit utilise un outil d'IA pour analyser les 47 000 écritures comptables de l'exercice et identifier les transactions à risque de fraude.
Étape 1 : Qualification RIA de l'outil L'outil est utilisé en soutien à la planification (orientation des tests substantifs), pas pour générer une opinion. Classification retenue : risque limité au sens de l'Article 50, avec obligation d'information transparente sur l'usage de l'IA envers les personnes dont les données personnelles sont traitées (les collaborateurs du client apparaissant dans le FEC). Documentation : note de classification signée par l'associé, versée au dossier permanent.
Étape 2 : Documentation fournisseur Demande écrite au fournisseur de la notice Article 13 et, le cas échéant, du marquage CE. Le fournisseur fournit la notice mais pas de marquage CE (non obligatoire pour un système à risque limité). Le dossier versant comprend la notice, la correspondance, et la clause contractuelle couvrant la confidentialité des FEC traités.
Étape 3 : Supervision humaine tracée L'associé examine les 23 transactions flaguées. Il valide 19, écarte 3 (écritures de clôture standard, justification normale), et identifie 4 transactions suspectes non détectées par l'outil lors d'un sondage indépendant sur 200 écritures non flaguées. Documentation : mémo détaillant chaque écartement avec le raisonnement (pas seulement "validé" ou "écarté").
Étape 4 : Complication L'associé n'est pas d'accord avec l'outil sur une 24e transaction que l'IA a classée "faible risque" mais qui porte un motif de compte inhabituel (charge exceptionnelle de 180 k EUR passée le 31/12). Il la teste manuellement. La pièce est régulière, mais le désaccord est tracé au dossier. C'est cette trace qui vaut supervision humaine au sens de l'Article 14 (pas la validation des 19).
Conclusion : L'outil est utilisable pour la mission. Les 4 transactions non détectées représentent 0,3 % du total analysé, sous le seuil de matérialité individuelle. L'impact sur la stratégie d'audit reste non significatif, mais le dossier porte désormais une justification robuste de la supervision humaine, ce qui changera le jour où H2A inspectera.
Checklist de conformité
1. Qualifier chaque outil d'IA selon le RIA : risque minimal, limité (Article 50), haut risque (Article 6 + Annexe III). Documenter le raisonnement, pas seulement la conclusion.
2. Exiger la documentation Article 13 par écrit auprès du fournisseur, dès la phase d'acceptation de la mission. Ne pas se contenter d'un PDF commercial.
3. Intégrer la supervision humaine au programme de travail. La trace n'est pas "j'ai regardé" : c'est "j'ai été d'accord sur X, en désaccord sur Y, et voici pourquoi".
4. Tracer les écartements et les désaccords avec l'IA. C'est le point que la NEP 230 ne dit pas encore explicitement, mais qui constituera le cœur des inspections à venir.
5. Documenter les limites connues de l'outil (types d'anomalies non détectées) et les contrôles compensatoires manuels mis en place.
6. Conserver les journaux générés automatiquement par l'outil pendant au moins six mois (Article 19 et Article 26, paragraphe 6).
Erreurs courantes
Liens connexes
- Évaluation du risque de fraude - Comment intégrer les outils IA dans votre évaluation ISA 240 - Calculateur de matérialité - Outil de calcul traditionnel sans IA pour comparer avec vos outils automatisés - Documentation d'audit - Exigences de documentation pour les nouvelles technologies d'audit