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 — Management du développement responsable (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.

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, les A.x.1 — ici A.6.1.1 et A.6.2.1 — sont des énoncés d’objectif, pas des contrôles.

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 écrites, avec des critères d’acceptation (A.6.2.2) ? Avant de déployer : la vérification et la validation ont-elles eu lieu contre ces critères (A.6.2.4) ? En exploitation : la surveillance existe-t-elle, et déclenche-t-elle quelque chose (A.6.2.6) ?

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 — l’absence de l’activité correspondante.

Ce qu’elle ne peut pas écarter en revanche, c’est ce qui relève de l’exploitation : la spécification de ce qu’elle attend du système, la vérification avant mise en service, et la surveillance. Celles-là existent quel que soit l’auteur du modèle.

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 justification.

Une organisation peut donc rester certifiée en l’ayant écarté. Cela n’a aucune incidence sur ses obligations réglementaires de journalisation, qui existent indépendamment de la norme et ne sont pas couvertes par elle — 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.

Trois niveaux de mise en œuvre

Minimal crédible. Gestion de version du code et des modèles, chaque version étiquetée, une note de spécification par système, un test fonctionnel avant mise en service avec son résultat conservé, des journaux d’erreurs et d’usage. C’est le niveau de l’équipe qui travaille proprement, et il satisfait le domaine.

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 et ISO/IEC 5338 traitent du cycle de vie et peuvent servir de référence, mais elles ne sont pas exigées par ISO/IEC 42001.

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.