Assurance IA en production
Traiter changement, incident et reprise
Conserver la chronologie et les versions, contenir l’effet, qualifier les obligations puis démontrer que la reprise ne réintroduit pas le risque.
Continuité
Un changement et un incident partagent la même question de preuve
Dans les deux cas, il faut savoir quelle version était active, ce qui a varié, qui a été exposé, quelle action a été prise et sur quel test la suite a été autorisée. Le changement anticipe cette preuve ; l’incident la reconstruit sous contrainte de temps.
Changement
Qualifier l’effet avant d’autoriser la diffusion
Le dossier de changement décrit l’objet, la justification, les composants affectés, la population, les risques, les tests et le retour arrière. Une modification apparemment mineure peut changer la finalité, les interactions humaines, les journaux ou la dépendance à un tiers.
Détection
Ouvrir une chronologie unique dès le premier signal
La chronologie conserve l’heure, la source, la version, les personnes informées, les décisions et les actions. Elle distingue faits observés, hypothèses et informations encore manquantes. Les horloges et identifiants doivent permettre de rapprocher les composants distribués.
Préservation
Protéger les personnes sans effacer la cause
La contention peut imposer une suspension immédiate, mais les journaux, configurations, entrées et sorties utiles sont préservés conformément aux droits et durées applicables. Une correction qui modifie le système avant la conservation des faits peut rendre la cause impossible à établir.
Qualification
Séparer l’incident opérationnel de sa qualification réglementaire
L’équipe traite immédiatement le dommage et la continuité. En parallèle, les fonctions compétentes examinent si les critères d’un incident grave ou d’un autre régime de notification sont remplis, par quel acteur et dans quel délai. Une étiquette interne ne remplace pas cette qualification.
Correction
Relier la cause, l’action et le test de non-régression
La correction vise la cause démontrée ou contient explicitement l’incertitude. Le plan indique les versions affectées, les mesures immédiates, la correction durable, les tests, les contrôles compensatoires et le risque résiduel. Un ticket fermé sans résultat de test ne prouve pas la clôture.
Reprise
Faire de la reprise une nouvelle décision de production
La reprise exige un état connu, un protocole arrêté avant le test, une population représentative, des critères de réussite et un décideur habilité. Elle peut être progressive, segmentée ou assortie d’une surveillance renforcée. L’autorité accepte séparément les réserves restantes.
Conditions minimales de reprise
| Objet | Question | Preuve |
|---|---|---|
| Version | Que remet-on exactement en service ? | Manifeste et configuration rapprochés |
| Risque | La cause est-elle traitée ou contenue ? | Analyse, correction et contrôles compensatoires |
| Test | Le service et ses limites sont-ils vérifiés ? | Résultats, population et non-régression |
| Autorité | Qui accepte le risque résiduel ? | Décision datée et périmètre de reprise |
Version
- Question
- Que remet-on exactement en service ?
- Preuve
- Manifeste et configuration rapprochés
Risque
- Question
- La cause est-elle traitée ou contenue ?
- Preuve
- Analyse, correction et contrôles compensatoires
Test
- Question
- Le service et ses limites sont-ils vérifiés ?
- Preuve
- Résultats, population et non-régression
Autorité
- Question
- Qui accepte le risque résiduel ?
- Preuve
- Décision datée et périmètre de reprise
Clôture
Conserver un dossier qui permet de rejouer le raisonnement
Le dossier final contient la chronologie, les preuves préservées, la qualification, les notifications, l’analyse causale, les corrections, les résultats des tests et l’autorisation de reprise. Les enseignements modifient ensuite la référence, les seuils, les procédures ou l’architecture.
Sources et références
- AI Act — texte consolidé, articles 9, 26, 72 et 73 (nouvel onglet)
Gestion continue des risques, devoirs du déployeur, surveillance post-commercialisation et signalement des incidents graves.
- NIST AI 800-4 — Challenges to the Monitoring of Deployed AI Systems (nouvel onglet)
Catégories de surveillance et difficultés de mesure des systèmes d’IA dans leurs conditions réelles d’exploitation.
- NIST AI RMF 1.0 (nouvel onglet)
Gouverner, contextualiser, mesurer et gérer les risques d’un système d’IA.
- ANSSI — Sécurité d’un système d’IA générative (nouvel onglet)
Architecture, cycle de vie, dépendances, tests avant production et journalisation.
Questions fréquentes
Faut-il corriger avant de préserver les journaux ?
Il faut d’abord protéger les personnes et le service, tout en préservant les faits utiles. Une modification prématurée peut empêcher d’établir la cause.
Un incident interne est-il automatiquement un incident grave AI Act ?
Non. La qualification réglementaire dépend des critères du règlement, du rôle de l’entité, du système et des faits observés.
Qui autorise la reprise ?
L’autorité nommée avant l’incident, sur la base de la version, des résultats de test, des limites et du risque résiduel.
Incident et reprise
Pouvez-vous reconstituer la dernière décision de reprise ?
Présentez la chronologie et la version concernée. Nous vérifions si le dossier démontre réellement la maîtrise du retour en service.