Audit algorithmique vs audit IAG : pourquoi ce ne sont pas la même chose

Dernière mise à jour : juin 2026 · Temps de lecture : 8 minutes

---

Deux expressions se sont imposées dans les discussions sur la gouvernance de l'IA en Europe : « audit algorithmique » et « audit IAG » (pour intelligence artificielle générative). Elles apparaissent dans les mêmes présentations, les mêmes appels d'offres, et parfois les mêmes feuilles de route de conformité — comme si elles décrivaient la même activité. Ce n'est pas le cas.

Les confondre n'est pas une simple imprécision sémantique. Cela crée de vraies lacunes de conformité, des budgets mal orientés et une documentation qui ne couvre pas ce que les régulateurs examineront effectivement. Cet article trace une ligne précise entre les deux, les cartographie sur les dispositions pertinentes de l'AI Act européen, et explique ce qui se passe lorsqu'un même système relève simultanément des deux cadres.

Qu'est-ce qu'un audit algorithmique ?

Un audit algorithmique examine un système d'IA construit sur des techniques classiques d'apprentissage automatique : modèles supervisés, systèmes de scoring, moteurs de décision automatisée, classificateurs à base de règles. Ces systèmes reçoivent des entrées structurées, leur appliquent une fonction apprise ou programmée, et produisent une sortie — un score de crédit, une note de risque, une recommandation d'embauche, une décision d'éligibilité à une prestation.

L'audit évalue quatre dimensions fondamentales :

Biais et équité. Le système produit-il des résultats systématiquement différents selon les groupes démographiques ? Cela nécessite des tests sur les caractéristiques protégées (sexe, âge, nationalité, origine) à l'aide de métriques d'équité : parité démographique, égalité des chances, parité prédictive.

Performance et robustesse. Le système fonctionne-t-il comme annoncé ? Se dégrade-t-il proprement sous un glissement de distribution ou des entrées adversariales ? Précision, rappel, AUC-ROC et tests de stress sur les cas limites sont les outils standard.

Explicabilité. Les sorties du système peuvent-elles être expliquées dans des termes qu'un être humain peut comprendre et contester ? Cela compte à la fois techniquement (valeurs SHAP, LIME, importance des variables) et juridiquement (droit à l'explication RGPD article 22 et exigences de transparence AI Act article 13).

Gouvernance et documentation. Le système a-t-il été développé avec un contrôle de version adéquat, une gouvernance des données, des mécanismes de supervision humaine et un suivi post-commercialisation ?

Le cadre légal de l'audit algorithmique

Disposition	Ce qu'elle exige
RGPD article 22	Droit de ne pas être soumis à des décisions entièrement automatisées à effet significatif ; droit à l'explication
AI Act Annexe III	Identifie les cas d'usage à haut risque (crédit, emploi, éducation, maintien de l'ordre, migration…) nécessitant une évaluation de conformité
AI Act articles 9–17	Gestion des risques, gouvernance des données, documentation technique, transparence, supervision humaine pour les systèmes à haut risque
AI Act article 27	Évaluation de l'impact sur les droits fondamentaux (FRIA) pour les déployeurs dans certains cas à haut risque
Recommandations CNIL	Systèmes algorithmiques utilisés dans l'administration publique et les décisions aux consommateurs

Sorties typiques d'un audit algorithmique : rapport de biais avec métriques par groupe, évaluation d'équité par rapport à des seuils définis, documentation d'explicabilité, analyse des lacunes de documentation technique et feuille de route de remédiation.

Exemples : un modèle de scoring crédit utilisé par une banque française. Un outil de présélection de CV d'un distributeur européen. Un système de classification automatique du risque chez un assureur. Un outil de prédiction de récidive utilisé dans le cadre judiciaire.

Qu'est-ce qu'un audit IAG ?

Un audit IAG — ou audit IA générative — examine des systèmes construits autour de grands modèles de langage (LLM), de générateurs d'images, d'outils de génération de code ou d'autres architectures génératives. Ces systèmes ne scorent ni ne classifient dans un espace de sorties borné : ils génèrent du contenu inédit, et leurs modes de défaillance sont fondamentalement différents de ceux du ML classique.

L'audit évalue des dimensions qui n'existent pas dans l'audit algorithmique :

Hallucinations et fiabilité factuelle. Le système génère-t-il des affirmations fausses présentées avec confiance ? Dans quelles conditions ? Quelles protections existent pour les détecter ou les supprimer ?

Sécurité et robustesse adversariale. Le système peut-il être manipulé par injection de prompt, jailbreaking ou instructions indirectes ? Ce ne sont pas des préoccupations académiques — ce sont des vecteurs d'attaque actifs dans les déploiements LLM en production.

Transparence des données d'entraînement et propriété intellectuelle. Sur quelles données le modèle a-t-il été entraîné ? Reproduit-il du contenu protégé par droits d'auteur ? Peut-on lui faire restituer des données personnelles issues de son corpus d'entraînement ? Ces questions touchent à la fois la conformité et la responsabilité juridique.

Évaluation du risque systémique. Pour les modèles les plus grands (entraînés sur un calcul supérieur à 10^25 FLOPs), le modèle présente-t-il des risques pour la sécurité publique, le discours public, les infrastructures critiques ou les processus démocratiques à grande échelle ?

Gouvernance de la qualité des sorties. Comment les sorties sont-elles surveillées ? Quels mécanismes humains dans la boucle existent ? Comment les incidents sont-ils détectés et signalés ?

Le cadre légal de l'audit IAG

Disposition	Ce qu'elle exige
AI Act articles 51–55	Obligations des modèles GPAI : documentation technique, conformité droit d'auteur, résumé de transparence, évaluation du risque systémique (pour les modèles à plus grande échelle)
AI Act article 53	Obligations GPAI de base : documentation technique et droits d'auteur, résumé des données d'entraînement, coopération avec l'AI Office
AI Act article 55	Obligations supplémentaires de risque systémique : tests adversariaux, signalement d'incidents, mesures de cybersécurité
Code de pratique GPAI	Exigences opérationnelles détaillées pour les signataires GPAI : évaluation, red teaming, transparence des capacités
AI Act article 50	Obligations de transparence : les chatbots et contenus générés par IA doivent être étiquetés ; les médias synthétiques doivent comporter un marquage lisible par machine

Sorties typiques d'un audit IAG : rapport d'évaluation adversariale (red teaming), benchmarks de taux d'hallucination, évaluation des vulnérabilités à l'injection de prompt, résumé de transparence des données d'entraînement, cartographie du risque systémique (pour les modèles qualifiants), et dossier de documentation article 53.

Exemples : un chatbot interne de service client construit sur une API LLM. Un outil de rédaction de documents juridiques alimenté par un modèle de fondation. Un assistant de complétion de code déployé auprès de développeurs. Un système d'information médicale LLM accessible aux patients.

Comparaison : les différences structurelles

Dimension	Audit algorithmique	Audit IAG
Type de système ciblé	ML classique, scoring, décisions automatisées	LLM, modèles génératifs, modèles de fondation
Mode de défaillance principal	Biais, discrimination, classification erronée	Hallucinations, jailbreaks, fuite de données d'entraînement
Espace de sorties	Borné (score, label, décision)	Non borné (texte, image, code)
Cadre légal principal	RGPD art. 22, AI Act Annexe III / arts. 9–17	AI Act articles 51–55, Code de pratique GPAI
Méthode d'explicabilité	SHAP, LIME, attribution de variables	Recherche en interprétabilité, surveillance des sorties
Tests adversariaux	Robustesse, glissement de distribution	Red teaming, injection de prompt, jailbreaking
Question de risque systémique	Non (spécifique au système)	Oui (pour les modèles à plus grande échelle)
Profil d'auditeur type	Ingénieur ML + chercheur en équité	Chercheur en sécurité IA + spécialiste red team

Quand les deux cadres s'appliquent : le cas composé

C'est là que la planification de conformité peut déraper. Un système peut être soumis aux deux types d'audit simultanément — non pas par chevauchement réglementaire, mais parce qu'il combine réellement les deux architectures.

Prenons un outil RH qui utilise un LLM pour analyser et résumer des CV, puis transmet des sorties structurées à un modèle de scoring qui classe les candidats. Ce système est à la fois :

• À haut risque selon l'Annexe III (article 6, cas d'usage : gestion de l'emploi et des travailleurs) — ce qui entraîne l'intégralité des obligations articles 9–17 et les exigences d'audit algorithmique
• Un système aval intégrant un modèle GPAI — ce qui signifie que le fournisseur du système doit comprendre les obligations GPAI du fournisseur du modèle de fondation et ne peut pas s'appuyer sur la conformité de ce fournisseur pour s'acquitter de ses propres obligations en tant que fournisseur de système à haut risque

Un audit algorithmique de la couche de scoring sans examiner les risques d'hallucination et les vulnérabilités à l'injection de prompt du LLM ne couvre qu'une moitié du système. Un audit IAG qui ignore les propriétés d'équité du modèle de scoring aval manque l'autre moitié.

Autres exemples composés : un outil d'imagerie médicale qui utilise un modèle génératif pour l'amélioration d'image avant qu'un modèle de classification ne formule une suggestion diagnostique ; un chatbot LLM déployé dans un contexte de crédit à la consommation ; un système IA juridique qui génère des projets de contrats puis en classifie le niveau de risque.

L'allocation des responsabilités dans ces cas composés est claire dans l'AI Act : si vous êtes le fournisseur du système global et qu'il répond à un cas d'usage de l'Annexe III, vous portez les obligations du fournisseur à haut risque quelle que soit la partie du pipeline alimentée par un modèle de fondation.

La place de DILAIG dans ce paysage

L'audit en 50 questions de DILAIG est construit autour des obligations des systèmes à haut risque de l'AI Act — la dimension audit algorithmique du tableau de conformité. Il génère les quatre documents obligatoires que les fournisseurs de systèmes IA à haut risque doivent produire avant de mettre un système sur le marché européen : Documentation Technique (Annexe IV), Déclaration UE de Conformité, FRIA et Notice de Transparence.

DILAIG n'est pas un outil de red teaming ni une plateforme d'évaluation adversariale — il ne remplace pas un audit IAG dédié pour les systèmes à base de LLM. Ce qu'il fournit, c'est une base de conformité structurée et documentée couvrant les obligations fondamentales de fournisseur de l'AI Act, rapidement. Cette base est le préalable à tout engagement d'audit externe approfondi, qu'il soit algorithmique ou génératif.

→ Lancez votre audit de conformité AI Act — 50 questions, 4 documents prêts en quelques heures, sans équipe juridique requise.

Découvrir ce que DILAIG génère · Voir les tarifs

---

FAQ : audit algorithmique vs audit IAG

Q : L'AI Act exige-t-il un audit algorithmique ? L'AI Act n'utilise pas directement le terme « audit algorithmique ». Ce qu'il exige pour les systèmes à haut risque, c'est un processus d'évaluation de la conformité au titre de l'article 43 — ce qui est substantiellement équivalent à ce que les praticiens appellent un audit algorithmique. Il couvre la gestion des risques (article 9), la gouvernance des données (article 10), la documentation technique (article 11), la transparence (article 13), la supervision humaine (article 14), et la précision et robustesse (article 15).

Q : L'AI Act exige-t-il un audit IAG ? Pour les fournisseurs de modèles GPAI, les articles 53 et 55 exigent une documentation technique, des résumés de données d'entraînement, des mesures de conformité droit d'auteur et — pour les modèles à risque systémique — des tests adversariaux. Le Code de pratique GPAI traduit ces exigences en obligations opérationnelles détaillées qui ressemblent étroitement à ce que les praticiens appellent un audit IAG. Ces obligations s'appliquent depuis août 2025.

Q : Qui est responsable de l'audit IAG lors de l'utilisation d'une API LLM tierce ? Le fournisseur du modèle GPAI (OpenAI, Anthropic, Mistral, Google) est responsable de ses obligations articles 53–55. Mais si vous construisez un système IA à haut risque par-dessus leur API, vous êtes le fournisseur de ce système à haut risque et devez réaliser l'évaluation de conformité pour celui-ci. Les deux ensembles d'obligations sont indépendants et cumulatifs.

Q : Un seul outil peut-il couvrir les deux types d'audit ? Certaines plateformes adressent des parties des deux. Aucun outil unique ne remplace les éléments à forte dimension de jugement — red teaming, sélection des métriques d'équité, conception des scénarios adversariaux. Ce que fournit DILAIG, c'est la couche de documentation structurée qui ancre les deux types d'audit aux exigences de sortie obligatoires de l'AI Act.

Q : Et le report lié au règlement Omnibus ? La proposition de règlement Omnibus repousserait la plupart des obligations pour les fournisseurs à haut risque à décembre 2027. Les obligations GPAI (articles 51–55) ne sont pas affectées — elles s'appliquent depuis août 2025. Les obligations d'audit algorithmique pour les systèmes de l'Annexe I (produits couverts par la législation d'harmonisation existante) sont repoussées à août 2027 quoi qu'il en soit.

---

Points clés à retenir

• Les audits algorithmiques examinent les systèmes ML classiques et de décision automatisée sous l'angle des biais, de la performance, de l'explicabilité et de la gouvernance — ancrés dans le RGPD article 22 et l'AI Act Annexe III.
• Les audits IAG examinent les LLM et systèmes génératifs sous l'angle des hallucinations, des vulnérabilités adversariales, de la transparence des données d'entraînement et du risque systémique — ancrés dans les articles 51–55 de l'AI Act et le Code de pratique GPAI.
• Les deux types d'audit traitent des modes de défaillance différents, requièrent des méthodologies différentes et invoquent des cadres légaux différents.
• Un système intégrant un LLM dans un cas d'usage de l'Annexe III est soumis aux deux cadres ; n'auditer qu'une seule couche crée une exposition réelle à la non-conformité.
• DILAIG couvre les obligations documentaires structurées pour les fournisseurs de systèmes à haut risque — le point de départ obligatoire avant tout engagement d'audit externe approfondi.

---

Sources

• Règlement (UE) 2024/1689 — AI Act, Journal officiel de l'UE, 12 juillet 2024
• AI Act articles 6, 9–17, 22, 27, 43, 50, 51–55
• AI Act Annexe III (liste des cas d'usage à haut risque), Annexe IV (exigences de documentation technique)
• Code de pratique GPAI — AI Office de l'UE, 2025
• Règlement (UE) 2016/679 — RGPD, article 22
• CNIL — Recommandations sur les systèmes algorithmiques (2022, mis à jour 2024)
• Déclaration conjointe du Parlement européen, du Conseil et de la Commission sur la proposition de règlement Omnibus (2025)