Cycle de vie de l’IA : étapes, AI Act et preuves

Un système d’IA se gouverne de la première idée jusqu’à son retrait, pas seulement pendant qu’il tourne en production. L’AI Act parle peu de cycle de vie, mais il rattache presque chaque obligation des systèmes à haut risque à une étape : la destination au cadrage, les preuves de conformité avant la mise sur le marché, les journaux pendant l’exploitation, l’archivage après le retrait. Voici la gestion du cycle de vie de l’IA telle qu’une autorité la lira : étapes, obligations, jalons, changements et retrait.

L’essentiel

• La gestion du cycle de vie de l’IA est une discipline de gouvernance : elle décide qui fait avancer un système, sur quelles preuves, et ce qui est conservé.
• L’AI Act n’emploie le terme anglais « lifecycle » que 11 fois, mais presque toutes les obligations à haut risque se rattachent à une étape.
• Une modification substantielle relance l’évaluation de la conformité et peut faire d’un déployeur un fournisseur.
• Depuis l’omnibus de 2026, un changement important de conception fait entrer dans le champ les systèmes à haut risque déjà sur le marché.
• Le retrait reste l’étape oubliée du cycle de vie de l’IA, alors que le rappel, la base de données de l’UE et la conservation sur 10 ans s’y jouent.

Gestion du cycle de vie de l’IA : ce que le MLOps laisse de côté

Nous définissons la gestion du cycle de vie de l’IA comme le pilotage d’un système d’IA à travers toutes ses étapes : qui en répond, quelles décisions le font avancer, sur quelles preuves, comment un changement est traité, comment il sort du service. Les pages qui dominent les résultats de recherche racontent autre chose. IBM, AWS, le guide de la GSA américaine et une série d’éditeurs MLOps, CRM ou cybersécurité y décrivent un pipeline d’ingénierie : problème, données, entraînement, évaluation, déploiement, surveillance. L’aperçu IA de Google propose d’ailleurs de choisir entre outillage MLOps et gouvernance. C’est ce second versant qui manque.

Sur les dix pages lisibles les mieux classées, aucune ne cite ISO/IEC 42001, ISO/IEC 5338, ISO/IEC 22989 ou l’OCDE, aucune ne parle de signalement des incidents graves, une seule cite un article de l’AI Act, deux évoquent le retrait. Le MLOps automatise le pipeline, il ne décide pas : il sait redéployer un modèle, pas dire si ce redéploiement est une modification substantielle, qui l’a autorisé ni où se trouve la preuve.

Le règlement (UE) 2024/1689 confirme cette lecture. Selon notre décompte sur le texte publié au Journal officiel, le terme anglais « lifecycle » n’y figure que 11 fois : 7 dans les considérants, 4 dans le dispositif et les annexes (art. 9, § 2 ; art. 15, § 1 ; art. 40, § 2 ; annexe IV, point 6). L’article 9 fait du système de gestion des risques « un processus itératif continu qui est planifié et se déroule sur l’ensemble du cycle de vie d’un système d’IA à haut risque ». L’article 15 exige un fonctionnement constant « tout au long de leur cycle de vie ». L’annexe IV, point 6, veut la description des modifications pertinentes apportées par le fournisseur au fil de ce cycle ; l’article 12, paragraphe 1, des journaux sur toute la durée de vie du système ; l’article 72, paragraphe 2, une collecte de données sur toute leur durée de vie. Le mot est rare, l’obligation est partout (voir notre guide opérationnel du règlement IA de l’UE).

Les étapes du cycle de vie de l’IA : quatre modèles de référence comparés

Le tableau aligne quatre référentiels sur notre modèle de travail en huit étapes : ISO/IEC 22989, repris par le CEPD, le NIST AI RMF, les principes de l’OCDE et l’annexe A.6.2 d’ISO/IEC 42001.

Étape (notre modèle en 8 étapes)	ISO/IEC 22989 / CEPD	NIST AI RMF	OCDE	ISO/IEC 42001, annexe A.6.2
Cadrage et destination	Lancement et analyse	Plan and Design	Conception, données et modèles	Exigences et spécification (A.6.2.2)
Acquisition et préparation des données	Acquisition et préparation des données	Collect and Process Data	Conception, données et modèles	(contrôles des données en A.7)
Conception et développement	Développement	Build and Use Model	Conception, données et modèles	Documentation de conception et de développement (A.6.2.3)
Vérification et validation	Vérification et validation	Verify and Validate	Vérification et validation	Vérification et validation (A.6.2.4)
Déploiement	Déploiement	Deploy and Use	Déploiement	Déploiement (A.6.2.5)
Exploitation et surveillance	Exploitation et surveillance ; validation continue	Operate and Monitor	Exploitation et surveillance	Exploitation et surveillance (A.6.2.6) ; journaux d’événements (A.6.2.8)
Réévaluation et changement	Réévaluation	(TEVV tout au long du cycle)	(itératif, non séquentiel)	Documentation technique tenue à jour (A.6.2.7)
Retrait	Retrait	(pas d’étape distincte)	Décidé pendant l’exploitation et la surveillance	(aucun contrôle dédié)

ISO/IEC 5338:2023, publiée en décembre 2023 par le JTC 1/SC 42, transforme ces étapes en processus : elle s’appuie sur ISO/IEC/IEEE 15288 et 12207, y ajoute des processus propres à l’IA tirés d’ISO/IEC 22989 et d’ISO/IEC 23053, et vaut que vous développiez le système ou que vous l’achetiez. Le schéma du NIST AI 100-1 est lui-même adapté du cadre de classification de l’OCDE. Notre recommandation : pour piloter le cycle de vie de l’IA, choisissez un seul modèle de travail, reliez-y les autres par une table de correspondance, et n’en faites jamais tourner trois. Notre boîte à outils ISO 42001 pour l’AI Act fait le lien contrôle par contrôle.

Le cycle de vie de l’IA dans l’AI Act : les obligations étape par étape

Voici notre carte pour un système d’IA à haut risque : ce que le texte exige à chaque étape, où, et la preuve qu’une autorité de surveillance ou un organisme notifié demandera.

Étape	Ce que l’AI Act exige	Articles	Preuves à conserver
Cadrage et destination	Définir la destination, classer le système, ouvrir la gestion des risques	Art. 3, pt 12 ; art. 6 ; art. 9, § 1 et 2	Énoncé de la destination, note de classification, registre des risques
Acquisition et préparation des données	Gouvernance des données d’entraînement, de validation et de test	Art. 10 ; annexe IV, pt 2 d)	Fiches de données, provenance, examen des biais
Conception et développement	Documentation technique avant la mise sur le marché ; transparence et notice ; supervision humaine dès la conception ; exactitude, fiabilité, cybersécurité	Art. 11, 13, 14, 15 ; art. 17, § 1, b) et c)	Dossier annexe IV, notice d’utilisation, conception de la supervision
Vérification et validation	Essais selon des indicateurs définis avant la mise sur le marché ; évaluation de la conformité, déclaration, marquage CE	Art. 9, § 6 à 8 ; art. 17, § 1, d) ; art. 43, 47, 48	Rapports d’essais, dossier de conformité, déclaration UE de conformité
Déploiement	Enregistrement dans la base de données de l’UE avant la mise sur le marché (annexe III) ; obligations des déployeurs ; analyse d’impact sur les droits fondamentaux pour certains	Art. 49, 26, 27	Preuve d’enregistrement, liste de contrôle du déploiement, analyse d’impact si due
Exploitation et surveillance	Journaux sur toute la durée de vie ; surveillance après commercialisation ; surveillance et suspension par le déployeur ; incidents graves	Art. 12, 19 ; art. 26, § 5 et 6 ; art. 72, 73	Conservation des journaux, plan et rapports de surveillance, registre des incidents
Changement	Nouvelle évaluation en cas de modification substantielle, sauf changements prédéterminés décrits à l’annexe IV, pt 2 f) ; le déployeur qui modifie substantiellement devient fournisseur	Art. 3, pt 23 ; art. 43, § 4 ; art. 25, § 1 ; annexe IV, pt 6	Journal des changements avec décision de tri, documentation à jour
Retrait	Mesures correctives, retrait, désactivation ou rappel ; documentation conservée 10 ans ; statut mis à jour dans la base	Art. 20, 18 ; annexe VIII, section A, pt 7	Procès-verbal de mise hors service, calendrier de conservation, preuve de suppression

Le règlement (UE) 2026/1744, l’omnibus numérique sur l’IA en vigueur depuis le 27 juillet 2026, reporte au 2 décembre 2027 les obligations de l’annexe III et au 2 août 2028 celles de l’annexe I (produits). Il intègre le plan de surveillance après commercialisation à la documentation de l’annexe IV, attend de la Commission des lignes directrices avec un modèle d’ici le 2 septembre 2027 (nouvel article 72, paragraphe 3) et proportionne le système de gestion de la qualité à la taille des PME et des petites entreprises à moyenne capitalisation (article 17, paragraphe 2). Le report ne change pas l’ordre des étapes du cycle de vie de l’IA. À lire aussi : évaluation de la conformité, documentation des systèmes d’IA, model card et gestion des risques IA.

Jalons du cycle de vie de l’IA : qui décide, sur quelles preuves

Gouverner le cycle de vie de l’IA, c’est tenir six portes. Chacune a un décideur nommé, des preuves attendues et trois issues : on passe, on revient en arrière ou on arrête.

1. <b>Entrée.</b> Le système entre dans l’inventaire des systèmes d’IA avec un responsable nommé et une destination écrite. Sans ces deux éléments, il n’existe pas pour la gouvernance, même s’il tourne déjà.
2. <b>Validation de la conception.</b> Classification, analyse d’impact et registre des risques sont sur la table ; le comité de gouvernance de l’IA dit oui ou non. Là se fixe le niveau de preuve que le projet portera.
3. <b>Mise en production.</b> La validation est réussie au regard d’indicateurs fixés à l’avance, la documentation est complète, la supervision humaine est confiée à des personnes désignées. Pour un système à haut risque, évaluation de la conformité et enregistrement sont faits avant ce jalon, jamais après.
4. <b>Tri des changements.</b> Tout changement de modèle, de données ou de destination est consigné, puis classé : courant, prédéterminé ou substantiel. Le tri est une décision tracée, avec un nom et une date.
5. <b>Réévaluation périodique.</b> Au moins une fois par an, et après tout incident, on confronte les résultats réels aux risques identifiés. Un écart ouvre une action corrective.
6. <b>Retrait.</b> Décision, notification, archivage, suppression. Le jalon se referme quand l’inventaire et la base de données de l’UE disent la même chose que le terrain.

Les rôles suivent : le responsable métier porte la destination et la décision d’usage ; le comité de gouvernance tranche aux jalons 2, 3 et 6 ; le juridique et le DPO vérifient la classification, la base légale et les durées de conservation ; la validation des modèles, en deuxième ligne, conteste les métriques comme en gestion du risque modèle ; la sécurité contrôle les accès, les journaux et la mise hors service. Dans AI Sigil, les processus sont modélisés en étapes, chacune avec ses formulaires et ses approbations, et le registre des systèmes d’IA garde la trace de qui a validé quoi.

Contrôle des changements : quand une mise à jour devient une modification substantielle

C’est au moment du changement que le cycle de vie de l’IA devient du droit. L’article 3, point 23, définit la modification substantielle : un changement apporté après la mise sur le marché ou la mise en service, ni prévu ni planifié dans l’évaluation initiale de la conformité, qui affecte la conformité aux exigences du chapitre III, section 2, ou modifie la destination évaluée. L’article 43, paragraphe 4 impose alors une nouvelle évaluation, même si le système modifié reste utilisé par le déployeur actuel. Exception pour les systèmes qui continuent d’apprendre : les changements prédéterminés lors de l’évaluation initiale et décrits à l’annexe IV, point 2 f), ne sont pas substantiels. Et selon l’article 25, paragraphe 1, points b) et c), celui qui modifie substantiellement le système, ou en change la destination au point de le rendre à haut risque, devient le fournisseur.

Depuis l’omnibus, le changement est aussi la porte d’entrée des systèmes existants. L’article 111, paragraphe 2, modifié par le règlement (UE) 2026/1744, ne vise un système à haut risque mis sur le marché avant la date d’application du chapitre III que s’il subit, à compter de cette date, des changements importants de conception ; les systèmes des autorités publiques ont jusqu’au 2 août 2030. Un considérant précise que cette notion équivaut en substance à la modification substantielle. Votre contrôle des changements devient le déclencheur qui fait entrer le stock existant dans le champ.

La doctrine reste à écrire. La Commission a publié le 19 mai 2026 un projet de lignes directrices sur la classification à haut risque, en consultation jusqu’au 23 juillet 2026 après prolongation, pour une version finale d’ici fin 2026 ; les lignes directrices sur la modification substantielle figurent encore parmi les textes que le Bureau de l’IA prépare. En juin 2026, un document de réflexion du CERRE a soutenu que les changements courants du cycle de vie devraient en règle générale rester hors de ce régime, dans la logique de l’article 43, paragraphe 4. Son exemple : un éditeur qui remplace le modèle d’IA à usage général sous-jacent par une version plus récente. Hors de l’Union, les lignes directrices définitives de la FDA du 4 décembre 2024 sur les plans de contrôle des changements prédéterminés des logiciels de dispositifs médicaux intégrant de l’IA structurent le plan en trois parties : description des modifications, protocole de modification, évaluation d’impact. Un gabarit tout trouvé pour l’annexe IV, point 2 f).

Questions de tri

• La modification change-t-elle la destination du système ?
• Touche-t-elle une exigence du chapitre III : exactitude, fiabilité, supervision humaine, données ?
• Était-elle prédéterminée et décrite dans la documentation technique ?
• Qui l’a faite : le fournisseur, le déployeur ou l’éditeur d’un composant ?
• Concerne-t-elle un système existant, après la date d’application ?

Exploitation et surveillance : journaux, dérive et incidents

L’exploitation est l’étape la plus longue du cycle de vie de l’IA, et souvent la moins documentée. Côté fournisseur, l’article 72 impose un système de surveillance après commercialisation qui collecte, documente et analyse activement les données de performance sur toute la durée de vie du système. Côté déployeur, l’article 26, paragraphe 5, oblige à surveiller le fonctionnement sur la base de la notice d’utilisation, à informer le fournisseur et à suspendre l’utilisation dès qu’un risque apparaît. Les journaux prévus à l’article 12 se conservent au moins six mois, chez le fournisseur (article 19, paragraphe 1) comme chez le déployeur (article 26, paragraphe 6), sauf disposition contraire du droit de l’Union ou du droit national.

Les incidents graves obéissent à l’article 73 : signalement immédiat et au plus tard 15 jours après la prise de connaissance, 2 jours en cas d’infraction de grande ampleur ou d’incident grave touchant une infrastructure critique au sens de l’article 3, point 49 b), 10 jours en cas de décès. Un premier rapport incomplet est admis, à compléter ensuite (article 73, paragraphe 5), et la Commission a publié un modèle de rapport. Notre page sur le signalement des incidents d’IA détaille le circuit.

La dérive du modèle est le risque silencieux de cette étape : les données de production s’éloignent de celles de l’entraînement et la performance s’érode sans alerte. Le CEPD fait d’ailleurs de la validation continue une phase à part entière pour les systèmes qui continuent d’apprendre. Dans la gestion du cycle de vie de l’IA, la surveillance ne sert que si elle est reliée au jalon 5 : un seuil franchi doit ouvrir une réévaluation, pas un ticket orphelin.

Retrait : l’étape que personne ne planifie

Le retrait est le parent pauvre de tous les référentiels du cycle de vie de l’IA. Dans les lignes directrices du CEPD sur la gestion des risques des systèmes d’IA du 11 novembre 2025, la liste de contrôle des risques par phase (annexe 3) n’associe aucun risque au déploiement et aucun au retrait, phase dont elle dit seulement que le système doit être mis hors service de manière responsable et efficace. Le cycle de vie de l’OCDE ne prévoit pas de phase de retrait distincte : la décision peut intervenir pendant l’exploitation et la surveillance. Dans notre revue, deux des dix pages les mieux classées seulement en parlent.

Plusieurs obligations atterrissent pourtant là. L’article 20 impose au fournisseur qui constate une non-conformité de mettre le système en conformité, de le retirer, de le désactiver ou de le rappeler, et d’en informer distributeurs et déployeurs. L’article 18 fait conserver la documentation technique, celle du système de gestion de la qualité et la déclaration UE de conformité pendant 10 ans après la mise sur le marché. L’annexe VIII, section A, point 7, prévoit le statut du système dans la base de données de l’UE : plus mis sur le marché ou en service, rappelé. S’y ajoutent la conservation des journaux et, pour les données d’entraînement et d’inférence, la limitation de la conservation et l’effacement prévus par le RGPD (voir IA et RGPD). Un retrait propre se prépare donc dès le cadrage.

Liste de contrôle du retrait :

• Décision et motif consignés, avec le nom du décideur.
• Déployeurs, utilisateurs et, le cas échéant, distributeurs informés.
• Accès révoqués ; artefacts du modèle archivés ou supprimés.
• Données personnelles supprimées ou anonymisées selon le calendrier de conservation.
• Documentation archivée pour toute la durée de conservation.
• Inventaire et statut dans la base de données de l’UE mis à jour ; le système de remplacement repasse par le jalon d’entrée.

Acheté, pas développé : le cycle de vie côté déployeur

La plupart des organisations achètent leur IA plus qu’elles ne la construisent. Les lignes directrices du CEPD décrivent d’ailleurs un cycle de vie d’achat, conçu pour les institutions de l’Union soumises au règlement (UE) 2024/2509 : publication et transparence, appel d’offres, sélection et attribution, puis exécution. L’exécution rejoue la vérification et la validation, le déploiement, l’exploitation et la surveillance, la validation continue, la réévaluation et le retrait. Pour un acheteur, la gestion du cycle de vie de l’IA passe donc par le contrat. Cinq clauses la rendent gouvernable : notification préalable des changements de modèle ou de version, accès aux journaux, coopération en cas d’incident, documentation et notice d’utilisation, fin de vie avec restitution ou suppression des données. La due diligence fournisseurs doit les vérifier avant la signature, pas au premier incident. Reste le risque de l’article 25 : apposer votre nom ou votre marque sur un système à haut risque, ou le modifier substantiellement, fait de vous le fournisseur.

En France, les recommandations de la CNIL sur le développement des systèmes d’IA, publiées sous forme de fiches pratiques en 2024 et 2025, couvrent les phases de conception et de données : c’est la référence à produire dès que des données personnelles sont en jeu. Le dispositif de surveillance du marché au titre de l’AI Act, articulé autour de la DGCCRF et de la CNIL, est annoncé mais pas encore formalisé par la loi. Pour les acheteurs publics, ces clauses s’inscrivent dans le Code de la commande publique, dès le cahier des charges. Ailleurs, l’Allemagne a désigné la Bundesnetzagentur comme autorité de surveillance du marché par le KI-MIG, en vigueur depuis le 29 juillet 2026, et l’Espagne s’appuie sur l’AESIA.

Questions fréquentes

<b>Qu’est-ce que la gestion du cycle de vie de l’IA ?</b>

C’est la discipline qui gouverne un système d’IA de la première idée à son retrait. Elle nomme un responsable à chaque étape, fixe les décisions qui font avancer le système, définit les preuves qu’elles exigent, encadre les changements et organise la mise hors service. Elle s’appuie sur des outils d’ingénierie sans s’y réduire : son objet est la décision et la trace. Pour un système à haut risque, c’est aussi ce qui produit à temps les preuves attendues.

<b>Quelles sont les étapes du cycle de vie de l’IA ?</b>

Notre modèle de travail compte huit étapes : cadrage et destination, acquisition et préparation des données, conception et développement, vérification et validation, déploiement, exploitation et surveillance, réévaluation et changement, retrait. ISO/IEC 22989 et le CEPD en décrivent neuf, le NIST AI RMF six, l’OCDE quatre phases souvent itératives. L’essentiel est de choisir un seul modèle pour le cycle de vie de l’IA et d’y relier les autres.

<b>L’AI Act impose-t-il une gestion du cycle de vie de l’IA ?</b>

Pas sous ce nom. Le texte rattache ses obligations à des étapes précises : gestion des risques continue (article 9), gouvernance des données (article 10), documentation technique (article 11), journaux (articles 12 et 19), évaluation de la conformité (article 43), surveillance après commercialisation (article 72), signalement des incidents graves (article 73), conservation de la documentation pendant 10 ans (article 18). Pour un système à haut risque, ne pas gérer le cycle de vie revient à ne pas pouvoir prouver la conformité.

<b>Quelle différence entre la gestion du cycle de vie de l’IA et le MLOps ?</b>

Le MLOps automatise le pipeline technique : préparation des données, entraînement, tests, déploiement, suivi des métriques. La gestion du cycle de vie décide qui peut faire passer un système à l’étape suivante, sur quelles preuves, et ce qui doit être conservé. Le MLOps fournit des traces utiles, mais il ne dit pas si un réentraînement constitue une modification substantielle, ni qui l’a autorisé. Cette qualification relève du comité de gouvernance et du juridique.

<b>Quand un changement devient-il une modification substantielle ?</b>

Selon l’article 3, point 23, de l’AI Act, lorsqu’il intervient après la mise sur le marché ou en service, sans avoir été prévu dans l’évaluation initiale de la conformité, et qu’il affecte la conformité aux exigences du chapitre III, section 2, ou modifie la destination. Il déclenche alors une nouvelle évaluation (article 43, paragraphe 4), sauf s’il était prédéterminé et décrit à l’annexe IV, point 2 f). Celui qui opère la modification devient fournisseur (article 25). Les lignes directrices de la Commission sur ce point restent en préparation.

<b>Que se passe-t-il quand un système d’IA est retiré ?</b>

Le fournisseur qui constate une non-conformité doit mettre le système en conformité, le retirer, le désactiver ou le rappeler, et en informer distributeurs et déployeurs (article 20). La documentation et la déclaration UE de conformité restent conservées 10 ans (article 18). Le statut est mis à jour dans la base de données de l’UE, et le RGPD impose la limitation de la conservation et l’effacement des données personnelles. Un retrait se termine par une trace, pas par un simple arrêt des serveurs.

Conclusion

Le MLOps a résolu une partie du problème : faire tourner des modèles de façon fiable. Il n’a pas résolu l’autre : dire qui décide, sur quelles preuves, et ce que l’on garde. C’est cela, la gestion du cycle de vie de l’IA, et c’est sur ce terrain que l’AI Act sera appliqué. Chaque étape porte ses obligations, le changement fait basculer des systèmes existants dans le champ depuis l’omnibus, et le retrait engage dix ans de conservation. Commencez petit : un inventaire à jour, un modèle de travail unique, six jalons avec un décideur nommé, une procédure de tri des changements, une liste de contrôle du retrait. Pour outiller le cycle de vie de l’IA avec des formulaires et des approbations par étape, le registre des systèmes d’IA d’AI Sigil est conçu pour cela.