Audit algorithmique : méthode, preuves et décisions

Un fournisseur annonce une précision élevée ; les utilisateurs signalent pourtant des erreurs sur certains dossiers. Un audit algorithmique doit permettre de comprendre cet écart, d’en mesurer les conséquences et de décider ce qui doit changer. Son résultat utile est un ensemble de constats vérifiables et de décisions suivies, pas seulement une note de conformité.

La démarche associe le fonctionnement technique, les conditions d’utilisation et les exigences juridiques. Il faut distinguer les contrôles imposés par un texte de la méthode d’audit que l’organisation choisit pour les réaliser.

Déterminer ce que la loi exige réellement

Le RGPD impose de pouvoir démontrer le respect de ses principes et d’adapter les mesures aux risques. L’Art. 32(1)(d) prévoit notamment une procédure régulière pour tester, analyser et évaluer l’efficacité des mesures de sécurité. Il n’impose pas, à toute entreprise utilisant un algorithme, un audit externe annuel portant sur toutes les dimensions de l’IA. Sources : RGPD, Art. 5(2), Art. 24(1) et 32(1)(d).

L’AIPD répond à une question distincte : les risques du traitement pour les droits et libertés, sa nécessité, sa proportionnalité et les garanties envisagées. Les résultats de l’audit peuvent l’alimenter, mais une AIPD relative à l’intelligence artificielle n’est pas simplement le chapitre « données personnelles » d’un rapport technique. Elle obéit aux conditions et au contenu de l’Art. 35. Source : RGPD, Art. 35(1), 35(7) et 35(11).

Pour les systèmes à haut risque, l’AI Act prévoit notamment gestion des risques, documentation, contrôle humain, évaluation de conformité et surveillance après commercialisation. Le calendrier doit être établi disposition par disposition. Le règlement 2026/1744 reporte les sections 1 à 3 du chapitre III, sauf l’Art. 6(5), au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I. Il ne reporte pas indistinctement tout le règlement. Source : règlement 2026/1744, Art. 1(40).

Des régimes sectoriels peuvent ajouter leurs propres contrôles. Ainsi, l’Art. 37 du DSA prévoit un audit indépendant au moins annuel des très grandes plateformes et des très grands moteurs de recherche concernés. Son champ porte sur les obligations du chapitre III et certains engagements : il ne se limite pas à leurs algorithmes de recommandation et ne s’étend pas à toute PME utilisant l’IA. Source : DSA, Art. 37(1).

Cadrer le système et la décision à auditer

Définissez une version, une finalité et un environnement. « Auditer notre IA » est trop large si le même modèle sert à rédiger des messages, classer des candidatures et produire une synthèse juridique.

La fiche de cadrage devrait préciser :

• l’usage autorisé, ses utilisateurs et les personnes affectées ;
• le modèle, ses composants, ses paramètres et les sources documentaires ;
• les étapes humaines et automatisées jusqu’à l’action finale ;
• les exigences applicables, leur date et le rôle de l’entreprise ;
• les accès disponibles, les exclusions de périmètre et leurs conséquences ;
• les responsables de l’audit, de la décision et de la correction.

L’auditeur doit pouvoir signaler une limite d’accès. S’il ne dispose que d’un rapport commercial et d’une démonstration choisie par le fournisseur, il ne peut pas conclure comme s’il avait examiné les données, la configuration et les résultats en situation réelle. Reportez ces limites dans la conclusion.

Examiner les preuves avant de lancer les évaluations

Rassemblez les instructions d’utilisation, les spécifications, l’inventaire des données, les historiques de versions, les évaluations déjà réalisées et les incidents. Pour un fournisseur relevant de l’Art. 11 et de l’annexe IV de l’AI Act, vérifiez la documentation technique requise, en tenant compte de son champ et de son calendrier. Source : AI Act, Art. 11.

Comparez les usages annoncés aux usages effectifs. Un système évalué sur des textes courts peut être utilisé sur des dossiers volumineux ; une restriction contractuelle peut être inconnue de l’équipe métier. Ces écarts peuvent expliquer une dégradation ou créer un risque que les évaluations initiales ne couvrent pas.

Conservez un relevé de preuves simple : document, date, version, auteur, exigence concernée, constat et pièce justificative. Une déclaration du fournisseur reste une déclaration tant qu’aucune pièce ne permet d’en vérifier la portée.

Choisir des mesures adaptées au dommage possible

Toutes les mesures ne sont pas pertinentes pour tous les systèmes. Pour un classement, on pourra examiner les faux positifs et faux négatifs ; pour une réponse documentaire, l’exactitude des affirmations et la pertinence des sources ; pour une extraction, les omissions et les erreurs de champs. Fixez les critères avant d’observer le résultat, puis documentez les éventuels changements.

La moyenne globale peut masquer un problème local. Présentez les effectifs, les conditions de mesure et les incertitudes ; ne transformez pas une absence d’erreur dans un petit échantillon en garantie générale. Ces recommandations méthodologiques servent à rendre les résultats contrôlables.

Des bibliothèques comme Fairlearn facilitent les mesures ventilées par groupes et certaines comparaisons. Elles calculent des indicateurs ; elles ne déterminent pas seules si une différence est juridiquement discriminatoire. La documentation du projet explique notamment le fonctionnement de MetricFrame. Source : documentation officielle Fairlearn, Assessment.

Encadrer les données sensibles utilisées pour rechercher un biais

Ne constituez pas automatiquement un fichier de caractéristiques sensibles pour conduire l’audit. Identifiez d’abord les données nécessaires, la base légale et, lorsqu’il y a lieu, l’exception à l’Art. 9(1) du RGPD.

Le nouvel article 4 bis de l’AI Act, introduit par le règlement 2026/1744, prévoit un régime exceptionnel de traitement de catégories particulières de données pour détecter et corriger certains biais. Il est soumis à une stricte nécessité et à des garanties cumulatives, notamment lorsque les données synthétiques ou anonymisées ne permettent pas d’atteindre efficacement l’objectif. Il ne crée pas une obligation générale de collecter ces catégories. Source : règlement 2026/1744, Art. 1(6).

Ce régime interdit notamment de transmettre, transférer ou rendre ces données accessibles à d’autres parties ; il impose aussi des restrictions d’accès, des mesures de sécurité et une suppression encadrée. Le recours à un cabinet externe ne permet donc pas de lui ouvrir mécaniquement le fichier sur le fondement de cette exception. Déterminez l’architecture juridique et technique avant l’évaluation.

Vérifier l’intervention humaine en situation réelle

Examinez ce que l’utilisateur voit, ce qu’il comprend et ce qu’il peut modifier. Une procédure indiquant « contrôle humain obligatoire » ne suffit pas si l’interface impose le résultat ou si aucun temps d’examen n’est prévu.

Préparez des cas dans lesquels le système se trompe et observez le processus de vérification : détection, accès aux éléments utiles, possibilité de suspension, escalade et correction. Ne demandez pas à la personne de deviner une erreur invisible. L’Art. 14 de l’AI Act décrit, dans son champ, des capacités de compréhension des limites, d’interprétation, de décision contraire ou d’interruption. Source : AI Act, Art. 14(3) et 14(4).

Si le dispositif prend des décisions automatisées significatives, vérifiez également les conditions de l’article 22 du RGPD. Pour les réponses aux personnes, contrôlez que l’explication fournie correspond à leur dossier et aux traces disponibles.

Distinguer audit volontaire et évaluation réglementaire

Un audit indépendant peut améliorer la qualité du contrôle sans constituer l’intervention d’un organisme notifié au sens de l’AI Act. Inversement, une évaluation interne réglementaire ne signifie pas absence d’exigences documentaires.

L’Art. 43(2) prévoit une procédure de contrôle interne pour les systèmes des points 2 à 8 de l’annexe III. Pour ceux du point 1, l’Art. 43(1) organise le choix ou l’obligation d’intervention d’un organisme notifié selon les conditions d’application des normes harmonisées ou spécifications communes. Affirmer que toute identification biométrique impose toujours le même audit externe serait inexact. Pour les produits de l’annexe I, examinez la voie sectorielle, avec les modifications de 2026. Sources : AI Act, Art. 43(1) et 43(2), règlement 2026/1744, Art. 1(19).

Faire déboucher le rapport sur une décision

Pour chaque constat, indiquez l’exigence ou le critère évalué, la preuve, le risque, l’action, son responsable et son échéance. Séparez une non-conformité établie, un risque opérationnel et une information manquante. La direction doit savoir ce qui interdit la mise en service, ce qui impose une restriction et ce qui appelle une amélioration.

Prévoyez la vérification des corrections et les événements déclenchant un réexamen : nouvelle finalité, modification du système, changement de population, incident ou plainte. Il n’existe pas de fréquence trimestrielle universelle pour tout audit algorithmique. Adaptez la fréquence aux risques et aux textes sectoriels ; inscrivez les contrôles dans le registre interne des systèmes d’IA.

Une modification substantielle peut nécessiter une nouvelle évaluation de conformité selon l’Art. 43(4). Toute mise à jour n’est toutefois pas automatiquement substantielle : le texte prévoit notamment le cas des changements d’apprentissage prédéterminés et documentés lors de l’évaluation initiale. Source : AI Act, Art. 43(4).

Ce qu’il faut retenir

• Fixez un système, une version, un usage et des exigences applicables.
• Distinguez les mesures volontaires de la procédure réglementaire requise.
• Évaluez les erreurs et leurs effets dans le contexte réel, avec des données licites.
• Documentez les limites de l’audit et vérifiez les corrections décidées.

FAQ

Tout audit algorithmique doit-il être externe ?

Non. Le cadre applicable détermine les exigences d’indépendance et l’éventuelle intervention d’un organisme notifié. Une entreprise peut aussi choisir un audit externe pour renforcer son contrôle.

Un bon score technique prouve-t-il la conformité ?

Non. Il faut aussi examiner les usages, les données, les droits, la supervision et les obligations propres au système. Un résultat n’est interprétable qu’avec sa méthode et son périmètre.

Peut-on auditer sans accéder au code source ?

Certains contrôles sont possibles à partir des entrées, sorties, documents et usages. Le rapport doit préciser les limites d’accès et éviter des conclusions que ces éléments ne permettent pas d’établir.

Recevez nos analyses pratiques de conformité dans la newsletter.

À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.