Conformité par le code pour les systèmes IA

Comment la conformité par le code s’applique aux articles 9 à 15 : ce qu’une règle peut tester, ce qui reste à une personne et ce que les analyses à base de règles de Scanara couvrent ou non.

Mis à jour 22 octobre 2026

La conformité par le code consiste à écrire des parties des exigences légales sous forme de règles qui s’exécutent avec votre code. Pour les fournisseurs de systèmes d’IA à haut risque, certaines exigences des articles 9 à 15 peuvent être testées ainsi. La plupart demandent un jugement humain.

Les obligations s’appliquent à partir du 2 décembre 2027 (annexe III) et du 2 août 2028 (annexe I) . L’article 2 énumère des exclusions. Les amendes peuvent atteindre 15 millions d’EUR ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (article 99(4)). Prochaine étape : choisissez un article et listez celles de ses exigences qu’une règle peut tester.

Une règle peut tester si quelque chose existe ; une personne doit juger si c’est adéquat

Les exigences du règlement parlent de ce qui est approprié à la finalité prévue. Les règles transforment la partie vérifiable en tests et laissent le reste aux personnes.

Ce qu’une règle peut tester

Si du code de journalisation existe autour des appels au modèle (article 12).
Si les documents exigés existent et contiennent les sections attendues (articles 11, 13, 17 et 47).
Si une classe de risque est consignée pour chaque système.
Qui a modifié une règle ou un document, et quand (historique git).

Ce qui exige une personne

Si l’analyse des risques est adéquate et le risque résiduel acceptable (article 9(5)).
Si le système est à haut risque, ce qui dépend de sa finalité prévue (article 6).
Si le contrôle humain fonctionne en pratique et dispose de personnel (articles 14 et 26(2)).
Si les documents sont exacts et complets. Une analyse vérifie que le contenu est présent.

Trois briques : règles de code, politiques de documents, documentation versionnée

Règles de code

Des règles d’analyse statique (Semgrep) détectent les schémas standard des frameworks de ML dans votre code source.

Détection de schémas: Les règles signalent les opérations d’IA sans journalisation, validation ou point d’intervention humaine reconnaissables.
Rattachement aux articles: Chaque règle correspond à un article du règlement.
Limites: La fiabilité de la détection varie selon le niveau du langage de programmation, et les niveaux expérimentaux ont plus de faux positifs et de faux négatifs. Les surcouches maison et le code obscurci peuvent passer inaperçus.

Politiques de documents

Des politiques Open Policy Agent (OPA) vérifient le contenu exigé des documents de conformité en huit langues : EN, DE, FR, IT, ES, NL, PL et PT.

Sections de la documentation technique: Les politiques vérifient que la documentation technique contient les huit sections qu’exigent les règles de Scanara, fondées sur l’annexe IV. Elles vérifient que le contenu est présent, pas qu’il est bon.
Documents GPAI: Une analyse de documents couvre la documentation des fournisseurs de modèles d’IA à usage général (article 53). La génération de dossiers rédige des brouillons des documents des annexes XI et XII.

Documentation versionnée

La documentation de votre dépôt est versionnée avec votre code.

Documentation comme code: Les évaluations des risques et les descriptions du système sont des fichiers structurés. Votre historique git montre qui a changé quoi et quand. L’article 11 exige de tenir la documentation technique à jour.
Brouillons générés: Scanara rédige des documents alignés sur l’annexe IV à partir de vos données et de vos réponses d’évaluation. Le pré-remplissage est partiel, et des données erronées donnent des documents bien mis en forme mais faux.

De l’article au contrôle : ce qu’une règle couvre et ce qui reste à vous

Cinq articles montrent comment une exigence se divise en un contrôle à base de règles et une tâche humaine. La couverture diffère selon l’article : certains ont des règles de code, d’autres des analyses de documents, d’autres une évaluation guidée.

Article 9 : gestion des risques

Exigence: Établir, mettre en œuvre, documenter et tenir à jour un système de gestion des risques pendant tout le cycle de vie (article 9(1) et (2)).
Contrôle dans Scanara: Règle de code : signale les points de décision d’IA sans code reconnaissable d’évaluation des risques ou de validation. Une évaluation guidée consigne votre analyse des risques comme preuve.
Reste à vous: Identifier et apprécier les risques, et décider que le risque résiduel est acceptable (article 9(5)).

Article 11 : documentation technique

Exigence: Établir la documentation technique avant la mise sur le marché ou la mise en service et la tenir à jour, avec au moins les éléments de l’annexe IV.
Contrôle dans Scanara: Analyse de documents : vérifie que les huit sections obligatoires que les règles de Scanara définissent pour la documentation technique, fondées sur l’annexe IV, sont présentes. La génération de dossiers rédige la documentation de l’annexe IV à partir de vos données.
Reste à vous: Rédiger un contenu exact et le tenir à jour. Une analyse vérifie la présence, pas l’exactitude.

Article 12 : enregistrement

Exigence: Permettre l’enregistrement automatique des événements (journaux) pendant la durée de vie du système.
Contrôle dans Scanara: Règle de code : signale les opérations d’IA sans journalisation reconnaissable.
Reste à vous: Choisir les événements à enregistrer pour les trois finalités de l’article 12(2) et conserver les journaux.

Article 13 : transparence

Exigence: Concevoir le système pour que les déployeurs puissent interpréter sa sortie et l’utiliser de manière appropriée, et fournir une notice d’utilisation.
Contrôle dans Scanara: Analyse de documents : vérifie que la notice d’utilisation existe et contient les sections exigées.
Reste à vous: Rendre la notice exacte et compréhensible pour les déployeurs.

Article 14 : contrôle humain

Exigence: Concevoir le système pour que des personnes physiques puissent le contrôler efficacement. De manière appropriée et proportionnée, elles doivent pouvoir intervenir ou interrompre le système, par exemple au moyen d’un bouton d’arrêt ou d’une procédure similaire (article 14(1) et (4) e)).
Contrôle dans Scanara: Règle de code : signale les chemins de décision sans point d’intervention humaine reconnaissable.
Reste à vous: Concevoir un contrôle qui fonctionne en pratique et affecter des personnes formées (article 26(2)).

Ce que Scanara ne fait pas

Scanara n’observe pas les systèmes en production, ne juge ni la finalité prévue ni le contexte commercial, ne donne pas de conseil juridique et ne remplace pas une évaluation de la conformité par un organisme notifié lorsqu’elle est exigée. Le même code peut présenter un risque minimal ou élevé, selon sa finalité prévue. Une analyse réussie ne prouve pas la conformité.

Démarrer en cinq étapes

1
Classifiez votre système d’IA
Déterminez si votre système est à haut risque (article 6, annexe III). Le résultat dépend de la finalité prévue et relève de votre décision.
2
Lancez une première analyse
Analysez votre code et vos documents pour obtenir un état initial des constats. Lisez-les comme des indications, pas comme un verdict.
3
Intégrez l’analyse à votre pipeline
Commencez en mode rapport seul, puis envisagez le mode bloquant. Le guide CI/CD décrit les étapes.
4
Traitez les constats par priorité
Faites d’abord examiner par une personne les constats qui désignent l’article 5 ou l’article 14.
5
Rédigez la documentation
Générez des brouillons des documents des annexes IV et V à partir de vos données, puis complétez-les et vérifiez-les.

Exclusions, systèmes plus anciens et plafonds des amendes

Le règlement ne s’applique pas aux systèmes d’IA utilisés exclusivement à des fins militaires, de défense ou de sécurité nationale (article 2(3)). Il ne s’applique pas aux systèmes d’IA développés et mis en service spécifiquement et à seule fin de recherche et développement scientifiques (article 2(6)), ni à la recherche, aux essais ou au développement avant la mise sur le marché ou la mise en service, sauf les essais en conditions réelles (article 2(8)). Les systèmes sous licences libres et ouvertes sont exclus, sauf s’ils sont mis sur le marché ou mis en service comme systèmes à haut risque ou relèvent de l’article 5 ou 50 (article 2(12)). Les personnes physiques qui utilisent un système dans le cadre d’une activité strictement personnelle à caractère non professionnel ne sont pas tenues comme déployeurs (article 2(10)). Pour les systèmes à haut risque liés à des produits relevant de la législation de l’annexe I, section B, comme les véhicules à moteur, l’aviation, le rail, les équipements marins, les véhicules agricoles et les machines, seuls l’article 6(1), l’article 60a et les articles 102 à 112 s’appliquent. Les articles 57 à 59 ne s’appliquent que dans la mesure où cette législation intègre les exigences (article 2(2)).

Les systèmes à haut risque mis sur le marché ou mis en service avant la date d’application ne sont couverts qu’après des modifications significatives de leur conception. En tout état de cause, les fournisseurs et les déployeurs de systèmes d’IA à haut risque destinés à être utilisés par des autorités publiques doivent prendre les mesures nécessaires pour se conformer au plus tard le 2 août 2030 (article 111(2)).

Pour les PME, chaque amende atteint au plus le pourcentage ou le montant le plus bas (article 99(6)). Pour les petites ETI (« petites entreprises à moyenne capitalisation », article 3, point 14b), le même plafond s’applique aux amendes de l’article 99, paragraphes 4 et 5 (article 99(6a)). Le niveau de 15 millions d’EUR couvre aussi les obligations des fournisseurs et des opérateurs de l’article 25, paragraphes 2 et 4 (article 99(4), point da)).

À lire ensuite : étapes du pipeline, pistes d’audit et documentation technique

Scanara prépare des preuves à partir de vos dépôts

Scanara lit vos dépôts GitHub connectés et exécute des analyses à base de règles pour repérer les schémas courants d'IA et d'apprentissage automatique. Il peut manquer du code non standard. Par ailleurs, il génère des projets de documentation à partir de modèles et de vos réponses aux évaluations, comme preuves pour votre travail de conformité. Vous décidez de la classification.

Voir comment Scanara analyse vos dépôts