A.6 — Cycle de vie du système d'IA

Le domaine A.6 est le seul à se subdiviser, et c’est ce qui explique les erreurs de numérotation qu’on lit partout. Il compte neuf contrôles répartis en deux objectifs :

A.6.1 — Orientations de management pour le développement des systèmes d’IA (deux contrôles) : A.6.1.2 les objectifs de développement responsable, A.6.1.3 les processus de conception et de développement responsables.

A.6.2 — Cycle de vie du système (sept contrôles) : A.6.2.2 exigences et spécification, A.6.2.3 documentation de la conception et du développement, A.6.2.4 vérification et validation, A.6.2.5 déploiement, A.6.2.6 exploitation et surveillance, A.6.2.7 documentation technique, A.6.2.8 enregistrement des journaux d’événements.

Il n’existe ni A.6.3, ni A.6.4 : ces numéros circulent, ils sont faux. Et comme partout dans l’Annexe A, aucun contrôle ne porte un numéro en .1 : le Tableau A.1 énonce l’objectif sans numéro, en tête de A.6.1 comme de A.6.2, et c’est l’Annexe B qui lui donne ce rang (B.6.1.1, B.6.2.1). Le premier contrôle de chaque groupe porte donc .2.

Ce que l’auditeur regarde

Il ne juge pas votre méthode de développement : la norme n’en impose aucune. Il vérifie que des jalons de gouvernance existent aux bons endroits, et qu’ils ont produit quelque chose.

Trois jalons portent l’essentiel. Avant de construire : les exigences du système sont-elles spécifiées et documentées (A.6.2.2) ? Avant de déployer : les mesures de vérification et de validation sont-elles définies par écrit, avec les critères qui diront si le résultat est acceptable, et le plan de déploiement pose-t-il ce qui doit être satisfait avant la mise en service (A.6.2.4, A.6.2.5) ? En exploitation : ce qu’exige la conduite du système est-il défini et écrit — correctifs, mises à jour, assistance, suivi du fonctionnement et des performances (A.6.2.6) ? C’est aussi de ce côté que la norme aborde le dysfonctionnement : les lignes directrices de l’Annexe B (B.6.2.6) évoquent la correction des erreurs, l’assistance et la remontée d’un incident par le support. Aucune des clauses 4 à 10 n’y est consacrée, et la clause 10.2 n’entre en jeu que si l’incident révèle une exigence non satisfaite.

Le rôle change tout dans ce domaine

C’est le domaine où votre position dans la chaîne de valeur produit le plus d’écart.

Une organisation qui développe ses modèles est concernée par les neuf contrôles. Une organisation qui utilise un service tiers n’a pas de cycle de développement à maîtriser : elle peut écarter une partie de ces contrôles, avec une justification qui tient — son appréciation des risques ne les rend pas nécessaires, et aucune exigence externe applicable ne les impose (6.1.3 f). L’absence de l’activité correspondante en est l’illustration la plus simple, pas le motif à elle seule.

Ce qui touche à l’usage se prête mal à l’exclusion, en revanche : dire ce qu’elle attend du système, le vérifier avant de l’ouvrir à ses utilisateurs, en surveiller le fonctionnement. Ces activités existent quel que soit l’auteur du modèle, et l’argument de l’activité absente ne vaut donc pas pour elles. La norme ne les rend pas obligatoires pour autant : comme tout contrôle de l’Annexe A, elles s’écartent dans la déclaration d’applicabilité, si la justification tient. Une organisation utilisatrice aura rarement de quoi la soutenir — et la clause 8.1 lui impose de toute façon de maîtriser ce qu’elle se procure à l’extérieur.

A.6.2.8 — Un point que beaucoup rapportent de travers

Le contrôle relatif à l’enregistrement des journaux d’événements est régulièrement présenté comme obligatoire. Il ne l’est pas plus qu’un autre contrôle de l’Annexe A : c’est la déclaration d’applicabilité qui décide, avec une justification — et la norme compte les exigences externes applicables parmi ce qui peut fonder cette justification, ou la priver d’appui (6.1.3 f).

Une organisation peut donc rester certifiée en l’ayant écarté. Ses obligations réglementaires de journalisation, elles, demeurent : la norme ne les reprend pas à son compte, et si la clause 4.1 fait déterminer les enjeux externes pertinents, c’est une note, donc à titre indicatif, qui range parmi eux les exigences légales applicables. C’est un exemple précis de ce que la certification ne prouve pas.

En pratique, l’écarter est rarement une bonne idée : sans journal, aucune dérive ne s’établit après coup et aucune décision ne se reconstitue. Ce que doit contenir un journal utile, combien de temps le garder et ce que l’AI Act impose en plus sont détaillés dans la fiche du contrôle A.6.2.8.

Trois niveaux de mise en œuvre

Minimal crédible. Pour chaque système : quelques lignes sur les objectifs de développement responsable et sur la façon de concevoir et de développer (A.6.1.2, A.6.1.3), une note de spécification (A.6.2.2), les choix de conception consignés (A.6.2.3), les vérifications prévues avant la mise en service, et les critères qui disent si le résultat est acceptable (A.6.2.4), dont le résultat gagne à être conservé même si le contrôle ne l’exige pas, un plan de déploiement même court (A.6.2.5), ce qu’il faut pour exploiter le système — correctifs, assistance, évolutions, et le suivi du fonctionnement comme des performances (A.6.2.6) —, la documentation technique utile à chaque public (A.6.2.7), et la décision des étapes du cycle de vie où les journaux sont activés, avec la période d’utilisation pour plancher (A.6.2.8). La gestion de version du code et des modèles, chaque version étiquetée, aide à tenir cet ensemble sans le remplacer. C’est ce niveau qui couvre le domaine, pour les contrôles que retient votre déclaration d’applicabilité.

Mature. Une chaîne d’intégration qui exécute les contrôles avant déploiement — performance, robustesse, écarts entre groupes —, une revue de conception associant la gouvernance, un environnement de production surveillé en continu avec des seuils qui alertent, des notes de version, et une procédure de retour arrière éprouvée.

À éviter. Exiger un avis externe à chaque déploiement, ou l’accord écrit de plusieurs directions pour modifier un paramètre. Des revues mensuelles imposées à des projets mineurs produisent le même effet que partout ailleurs : le contournement.

Ce que le domaine ne demande pas

Aucun modèle de cycle de vie, aucune méthode de développement, aucun jeu de tests, aucun seuil de performance. ISO/IEC 22989 propose un modèle générique d’étapes et ISO/IEC 5338 décrit les processus du cycle de vie : la norme s’y réfère sans imposer ni l’un ni l’autre, et chaque organisation reste libre de définir ses propres étapes. ISO/IEC 22989 est bien une référence normative d’ISO/IEC 42001, mais pour le vocabulaire, pas pour son modèle de cycle de vie.

Il n’exige pas non plus une chaîne d’intégration automatisée : un contrôle manuel dont le résultat est conservé satisfait la même exigence.