Skip to main content

Conformité au règlement IA dans votre pipeline CI/CD

Ce que le règlement exige et qu’un pipeline CI/CD peut documenter, trois étapes de pipeline, le fonctionnement du merge gate GitHub de Scanara et les limites des analyses à base de règles.

Le règlement n’exige pas de CI/CD. Les fournisseurs de systèmes d’IA à haut risque doivent tenir à jour la documentation technique (article 11). Ils doivent aussi tester avant la mise sur le marché ou la mise en service (article 9(8)). Ils doivent enfin exploiter un système de gestion de la qualité (article 17). Un pipeline peut fournir des preuves de ces obligations.

Ces 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 : associez chaque étape du pipeline à l’article qu’elle documente.

Un pipeline peut fournir des preuves de ces obligations ; il ne décide pas de la conformité

  • La documentation technique reste à jour (article 11)

    La documentation technique est établie avant la mise sur le marché ou la mise en service et tenue à jour. Elle contient au moins les éléments de l’annexe IV. Une étape du pipeline peut vérifier que les documents exigés existent et évoluent avec le code.

  • Les tests ont lieu avant la mise sur le marché ou la mise en service (article 9(6) à (8))

    Les tests ont lieu à tout moment du développement et, en tout état de cause, avant la mise sur le marché ou la mise en service, sur la base de métriques et de seuils probabilistes définis au préalable et adaptés à la finalité prévue. Des étapes de test à seuils fixes produisent des résultats datés.

  • La gestion de la qualité couvre le contrôle des changements (article 17(1))

    Le système de gestion de la qualité documente le contrôle de la conception, le contrôle de la qualité du développement, les procédures d’examen, d’essai et de validation et la gestion des modifications. Les journaux du pipeline et les règles de relecture peuvent consigner ces étapes.

  • Les modifications substantielles exigent une nouvelle évaluation de la conformité (article 43(4))

    Un changement apporté à un système après sa mise sur le marché, que l’évaluation de la conformité initiale n’avait pas prévu et qui affecte la conformité aux exigences de la section 2 ou modifie la finalité prévue, est une modification substantielle (article 3, point 23). Un pipeline peut signaler les changements du modèle ou de la finalité prévue pour relecture humaine. Il ne décide pas si un changement est substantiel. Pour les systèmes qui continuent d’apprendre après leur mise sur le marché, les changements prédéterminés lors de l’évaluation initiale et documentés selon l’annexe IV, point 2 f), ne sont pas des modifications substantielles (article 43(4)).

Trois étapes de pipeline adaptées à ces obligations (notre proposition)

Le règlement ne nomme aucune étape de pipeline. Cette répartition place des contrôles rapides sur chaque pull request et l’analyse complète avant la publication.

Étape 1 : contrôles sur la pull request

Ils s’exécutent à chaque pull request et donnent un retour rapide aux développeurs.

  • Analyse du code: L’analyse statique à base de règles signale les composants d’IA et les schémas absents, par exemple des opérations d’IA sans journalisation. Elle ne détecte que les schémas standard des frameworks de ML.
  • Contrôle des documents: Des règles de politique vérifient que les documents exigés existent et contiennent les sections exigées. Elles vérifient que le contenu est présent, pas qu’il est exact ni bon.
  • Trace de la classe de risque: Vérifiez que la classification du risque du système est consignée et revue lorsque le code ou la finalité prévue changent. La classification elle-même est une décision humaine (article 6).

Étape 2 : merge gate

Un contrôle avant le merge, qui peut arrêter les changements non conformes.

  • Seuils de constats: Fixez des seuils pour les constats critiques et élevés. En mode bloquant, une analyse qui dépasse les seuils fait échouer le contrôle.
  • Constats sur les articles 5 et 14: Une analyse de code ne montre ni l’intention ni le contexte. Une personne examine chaque constat qui désigne une pratique interdite (article 5) ou l’absence de surveillance humaine (article 14).
  • Modifications de la documentation: Vérifiez que la documentation de l’annexe IV change dans la même pull request que le code qu’elle décrit.

Étape 3 : analyse avant publication

Une analyse complète de la version candidate.

  • Analyse complète: Une analyse complète du code et des documents. L’analyse des documents prend en charge huit langues : EN, DE, FR, IT, ES, NL, PL et PT.
  • Brouillon de dossier: Scanara rédige des brouillons de documents alignés sur les annexes IV et V à partir de vos données et de vos réponses d’évaluation. Le pré-remplissage est partiel ; vous rédigez et vérifiez le reste.
  • Instantané de preuves: Conservez le rapport d’analyse avec l’enregistrement de la version, pour pouvoir montrer ce qui a été vérifié et quand.

Comment fonctionne le merge gate GitHub de Scanara

Scanara reçoit les événements de pull request GitHub, analyse le changement et rend le résultat sous forme de check run GitHub. En mode rapport seul, un contrôle échoué est signalé comme neutre. En mode bloquant, le contrôle échoue.

Le merge gate ne fonctionne qu’avec GitHub. Les analyses planifiées ne sont pas encore disponibles ; les analyses s’exécutent à la demande et sur les pull requests.

Ce que les analyses vérifient et où elles s’arrêtent

La couverture est partielle. Dans l’instantané du 24 août 2026, 77 des 174 obligations cartographiées ont des règles de code, sur 43 articles, et 23 ont des règles de documents, sur 23 articles. La cartographie est antérieure aux modifications du règlement (UE) 2026/1744, par exemple les articles 4a, 60a et 75a à 75d. Les autres obligations exigent des évaluations et du travail humain.

Règles de code

  • Article 5 : pratiques interdites

    Les règles signalent des schémas de code qui peuvent indiquer une pratique interdite. Qu’une pratique soit interdite dépend de la finalité et du contexte, que le code ne montre pas.

  • Article 9 : gestion des risques

    Les règles signalent des points de décision d’IA sans code reconnaissable d’évaluation des risques ou de validation.

  • Article 10 : données et gouvernance des données

    Les règles signalent des pipelines d’entraînement sans contrôles reconnaissables de la qualité des données.

  • Article 12 : enregistrement

    Les règles signalent des opérations d’IA sans journalisation reconnaissable.

  • Article 14 : contrôle humain

    Les règles signalent des chemins de décision sans point d’intervention humaine reconnaissable, comme une neutralisation ou une procédure d’arrêt.

  • Article 15 : exactitude et robustesse

    Les règles signalent l’absence de validation du modèle et de métriques d’exactitude.

Règles de documents

  • Sections de la documentation technique (article 11)

    Les règles de Scanara définissent huit sections obligatoires de la documentation technique, fondées sur l’annexe IV, et vérifient qu’elles sont présentes. Elles vérifient que le contenu est présent, pas qu’il est bon.

  • Notice d’utilisation (article 13)

    Vérifie que la notice d’utilisation existe et contient les sections exigées.

  • Déclaration UE de conformité

    Vérifie que la déclaration contient les éléments énumérés à l’annexe V.

  • Huit langues

    L’analyse des documents prend en charge EN, DE, FR, IT, ES, NL, PL et PT.

Liste de contrôle de mise en œuvre

  • Ajoutez une analyse du code et des documents au workflow des pull requests.
  • Commencez en mode rapport seul et examinez les constats.
  • Fixez des seuils pour les constats critiques et élevés, puis passez en mode bloquant.
  • Exigez la relecture humaine de chaque constat qui touche l’article 5 ou l’article 14.
  • Conservez le rapport d’analyse avec chaque enregistrement de version.
  • Signalez pour relecture les changements du modèle, des données d’entraînement ou de la finalité prévue comme modifications substantielles possibles (article 43(4)).
  • Relancez l’analyse complète avant chaque version et mettez à jour la documentation de l’annexe IV.
  • Gardez la documentation technique dans le dépôt, à côté du code, et mettez-la à jour dans la même pull request.

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 : pistes d’audit, analyse à base de règles 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.