Cycle de vie d'un système d'IA : ce qu'exige l'Annexe A.6

Pourquoi une approche par cycle de vie

Un système d'IA n'est pas un logiciel classique que l'on livre, puis que l'on oublie. Son comportement évolue avec les données qu'il reçoit, les contextes d'usage qui changent et les attentes réglementaires qui se durcissent. La norme ISO/IEC 42001 l'a compris : elle couvre l'ensemble du cycle de vie des systèmes d'IA, de la conception à la maintenance, en passant par le déploiement et la surveillance^[7].

Pour un éditeur ou fournisseur de solutions IA, cette exigence se traduit concrètement dans l'Annexe A.6, qui regroupe les contrôles relatifs au cycle de vie. L'enjeu n'est pas simplement de cocher des cases lors d'un audit. Il s'agit de démontrer que chaque phase, de l'idée initiale au retrait du système, fait l'objet de processus documentés, de responsabilités attribuées et de décisions traçables^[5].

L'ISO 42001 s'inscrit dans une logique de cycle PDCA (Plan-Do-Check-Act), héritée des normes de systèmes de management comme l'ISO 27001 ou l'ISO 9001^[5]. Mais elle y ajoute des dimensions propres à l'IA : explicabilité, biais, supervision humaine. C'est cette superposition qui rend l'Annexe A.6 à la fois familière aux professionnels de la qualité et nouvelle dans ses exigences.

Les phases couvertes par l'Annexe A.6

L'approche par cycle de vie que la norme impose ne se limite pas au développement technique. Elle englobe la totalité de l'existence opérationnelle d'un système d'IA. Selon les sources disponibles, on peut distinguer les phases suivantes, chacune assortie de contrôles spécifiques dans l'Annexe A.6^[1][7].

Chaque phase appelle des contrôles documentés et des responsabilités attribuées.

1Conception et cadrage

2Développement et validation

3Déploiement

4Surveillance et maintenance

5Mise hors service

Source : interprétation des contrôles A.6 à partir des descriptions de la norme^[1][7].

Un éditeur de solutions IA qui distribue un produit à plusieurs clients doit adapter cette grille à chaque déploiement. Le même modèle, installé dans un hôpital cantonal et dans une compagnie d'assurance, ne présente pas les mêmes risques ni les mêmes exigences de surveillance. Le SMIA doit refléter cette réalité.

Conception et évaluation initiale des risques

Le parcours commence par une définition claire du problème que le système d'IA est censé résoudre, assortie d'une évaluation des risques dès le départ^[1]. L'ISO 42001 demande de comprendre l'objectif prévu du système, les biais potentiels et les implications sur la confidentialité des données avant même la première ligne de code^[1].

Pour un éditeur, cette phase implique de documenter le périmètre fonctionnel du système, les populations concernées par ses décisions et les scénarios d'usage prévus. Si vous développez un outil de scoring pour des demandes de crédit, par exemple, vous devez identifier dès la conception les biais potentiels liés aux données d'entraînement, les groupes démographiques susceptibles d'être désavantagés et les garde-fous à intégrer.

L'évaluation des risques IA à ce stade n'est pas un exercice théorique. Elle conditionne les choix architecturaux, le budget de validation et les engagements contractuels que vous pourrez prendre envers vos clients. La norme attend que cette évaluation soit formalisée et conservée comme information documentée.

Développement et validation

Une fois le cadrage posé, la phase de développement doit intégrer les contrôles identifiés lors de la conception. La norme insiste sur une validation qui dépasse les tests logiciels traditionnels^[1]. Dans le domaine médical, par exemple, cela implique une validation clinique démontrant l'efficacité, la sécurité et l'équité à travers différents groupes démographiques^[1]. Le principe vaut pour tout domaine sensible.

Ce que cela signifie pour un éditeur : vos jeux de test doivent être représentatifs, documentés et versionnés. Si votre modèle de classification de documents a été entraîné sur des textes en français de France, sa performance sur des textes en français de Suisse romande (avec ses spécificités terminologiques, juridiques ou administratives) doit être vérifiée séparément.

La déclaration d'applicabilité (SoA) que vous préparerez pour votre SMIA devra indiquer quels contrôles de l'Annexe A.6 s'appliquent à la phase de développement et comment vous les avez traités. La préparation de la SoA est souvent le moment où les lacunes de documentation apparaissent.

Déploiement et surveillance continue

Le déploiement d'un système d'IA ne marque pas la fin du travail de l'éditeur. La norme souligne la nécessité d'une surveillance continue des performances, d'évaluations des vulnérabilités et de mises à jour régulières^[1]. L'ISO 42001 met l'accent sur la surveillance et l'évaluation continues après le déploiement, afin de garantir que le système fonctionne comme prévu dans des scénarios réels et s'adapte aux nouveaux schémas de données sans dérive^[1].

Pour un éditeur qui livre un produit SaaS, cette exigence se traduit par des tableaux de bord de performance accessibles au client, des alertes en cas de dégradation de la précision et des processus de remontée d'incidents documentés. La norme ne prescrit pas un outil particulier, mais elle exige que la surveillance soit systématique, pas occasionnelle.

La question de la fiabilité du système d'IA se pose ici avec acuité. Un modèle de recommandation qui fonctionnait correctement en 2024 peut dériver si les comportements des utilisateurs changent ou si la distribution des données d'entrée évolue. L'éditeur doit définir des seuils de performance en dessous desquels un recalibrage est déclenché.

Maintenance et recalibrage

Les systèmes d'IA ne sont pas des outils que l'on paramètre une fois pour toutes^[1]. L'Annexe A.6 attend de l'organisation qu'elle prévoie des processus de maintenance proactive. Cela inclut le suivi de la dérive du modèle, la vérification de la qualité des données et la détection de biais émergents^[1].

Le recalibrage d'un modèle n'est pas anodin. Il peut modifier les résultats pour des catégories entières d'utilisateurs. L'éditeur doit donc documenter chaque recalibrage, les raisons qui l'ont motivé, les données utilisées et les tests de régression effectués. Cette traçabilité est ce que l'auditeur vérifiera lors de l'audit de certification.

La gouvernance des données selon l'Annexe A.7 est étroitement liée à cette phase. Un recalibrage avec des données de mauvaise qualité ou biaisées aggrave le problème au lieu de le résoudre. L'Annexe A.6 et l'Annexe A.7 fonctionnent en tandem sur ce point.

Mise hors service responsable

C'est la phase que les éditeurs oublient le plus souvent. Pourtant, la norme couvre le cycle de vie jusqu'à la retraite du système^[1]. Un système d'IA qui cesse d'être maintenu ne disparaît pas : ses données d'entraînement existent encore, ses décisions passées ont eu des conséquences, et ses utilisateurs doivent être informés et accompagnés vers une alternative.

Pour un éditeur, la mise hors service implique plusieurs obligations : notifier les clients dans un délai raisonnable, garantir la portabilité ou la suppression des données conformément aux engagements contractuels, et documenter les raisons du retrait. Si votre produit est utilisé dans un contexte réglementé (santé, finance), des obligations de conservation des logs de décision peuvent s'appliquer bien après l'arrêt du système.

L'observation générale montre que les démarches de certification achoppent rarement sur la conception ou le développement, où les équipes techniques sont à l'aise. C'est sur la mise hors service et la maintenance à long terme que les lacunes documentaires sont les plus fréquentes.

Piège fréquent pour les éditeurs

Le piège le plus courant pour un éditeur de solutions IA consiste à traiter le cycle de vie comme un processus purement technique, confié à l'équipe de développement. Or, la norme ISO 42001 structure un système de management, pas un processus d'ingénierie. Les rôles et responsabilités doivent être définis au niveau de la direction, pas seulement dans l'équipe produit^[4][5].

Concrètement, si seul votre CTO sait quand un modèle doit être recalibré et selon quels critères, vous avez un problème de gouvernance, pas un problème technique. La norme attend une politique IA définie par la direction, une identification des rôles et responsabilités, et une cartographie des systèmes IA^[5].

Un autre piège : considérer que le cycle de vie s'arrête à la livraison chez le client. Si vous fournissez un modèle pré-entraîné que le client affine avec ses propres données, la responsabilité du cycle de vie est partagée. La norme insiste sur la maîtrise des risques dans la chaîne de sous-traitance IA^[5]. Votre contrat doit préciser qui surveille quoi, qui déclenche un recalibrage et qui décide de la mise hors service. Les contrôles relatifs aux tiers (Annexe A.10) complètent ici l'Annexe A.6.

Exemple pratique en contexte romand

Prenons le cas fictif d'un éditeur genevois qui développe un outil de tri automatique des demandes d'aide sociale pour des communes vaudoises. Le système classe les dossiers entrants par degré d'urgence, en s'appuyant sur des données textuelles et des métadonnées administratives.

En phase de conception (A.6), l'éditeur documente l'objectif du système, identifie le risque de biais lié à la langue (certains requérants s'expriment dans un français non standard) et prévoit un mécanisme de supervision humaine pour les cas classés « non urgents ». L'analyse d'impact est réalisée avant le développement, conformément aux attentes de la norme.

En phase de développement, l'éditeur constitue un jeu de test incluant des dossiers rédigés dans différents registres de langue. La validation ne se limite pas à la précision globale : elle mesure la performance par sous-groupe linguistique. Les résultats sont versionnés et conservés.

Après déploiement dans trois communes pilotes, l'éditeur installe un tableau de bord de surveillance. Chaque mois, un rapport automatisé compare les taux de classification par catégorie d'urgence. Au bout de six mois, une dérive est détectée : le modèle sous-estime l'urgence des dossiers contenant certaines formulations administratives introduites par un nouveau formulaire cantonal. Un recalibrage est déclenché, documenté et testé avant redéploiement.

Deux ans plus tard, le canton décide de changer de système. L'éditeur active son processus de mise hors service : notification aux communes, extraction des données pour archivage légal, suppression des données personnelles des serveurs de production, et rapport final de clôture. Chaque étape est tracée dans le SMIA.

Cet exemple illustre que le cycle de vie n'est pas un concept abstrait. C'est une séquence de décisions documentées, chacune rattachée à un contrôle de l'Annexe A.6, et vérifiable par un auditeur. La structure clause par clause de la norme permet de relier chaque décision au bon contrôle.

Questions fréquentes

À lire ensuite