Incident IA : fermer le périmètre touché avant de préparer le retour

Les réponses du support sont plus fluides depuis une nouvelle configuration, mais une exception de procédure disparaît dans certains dossiers. Le service reste disponible et renvoie des réponses sans erreur HTTP. Des traitements engagés avant le retrait continuent aussi à préparer leur sortie. Le risque est de confondre disponibilité technique et qualité métier, puis de remettre une ancienne version sans savoir quels états elle va retrouver.

En pratique, l’incident doit posséder un chemin de fermeture du périmètre touché, distinct du diagnostic complet de sa cause. Le retour réexamine versions, sources, droits et effets déjà engagés. L’industrialisation et la gouvernance d’une IA doivent préparer cette frontière avant exploitation : un rollback de configuration ne remet pas le métier ni les données à zéro.

Huit états fictifs servent à identifier les travaux touchés par une même version de politique, puis vingt contrôles locaux examinent leur retour. Une ligne d’effet passé reste conservée dans SQLite ; aucun modèle, déploiement ou retour de version réel n’est lancé. Les admissions ne produisent aucun nouvel effet ni réponse publiée. L’expertise IA sur mesure de Dawap peut relier cette matrice aux procédures d’incident et qualifier les conditions de reprise de la famille affectée.

Pour qui l’incident doit avoir un chemin de retrait

Reconnaître une dégradation qui peut exister sans panne de fournisseur

Un assistant documentaire peut perdre une condition, un agent peut choisir une mauvaise capacité ou une extraction peut changer le sens d’un champ. L’API répond et les temps restent normaux, mais le travail produit ne correspond plus au contrat métier. Le runbook doit nommer ces familles avec les signaux et conséquences qui justifient une fermeture, sans attendre que le monitoring technique détecte une indisponibilité.

Le périmètre dépend de la capacité ouverte : consultation, proposition soumise à revue ou écriture. La perte d’une citation peut fermer une famille documentaire ; une action mal rattachée peut demander de suspendre les transmissions et de rapprocher les opérations engagées. Une mesure globale d’erreurs ne suffit pas à choisir ce geste. Le responsable doit retrouver ce que les utilisateurs et les outils peuvent encore produire.

Organiser la décision et le travail restant pendant la fermeture

Le chapitre Incident Response de Google SRE distingue mitigation, résolution et coordination. Ses principes incluent rôles explicites et registre de travail. Pour un service IA, la personne qui choisit le périmètre fermé doit pouvoir coordonner métier, application et propriétaire de source, tandis que les traitements concernés gardent un état compréhensible.

La passation précise quelles demandes passent en consultation limitée ou en traitement manuel, et qui suit les résultats encore inconnus. Fermer une capacité ne signifie pas abandonner les dossiers à une file invisible. Le coût de l’incident inclut cette reprise, le diagnostic et les corrections métier ; le seul coût des tokens ne décrit pas le travail nécessaire pour retrouver un service utilisable.

Diagnostiquer le changement sans attendre une certitude totale

Conserver la combinaison réellement utilisée pour la réponse ou l’action

Le diagnostic retrouve prompt, modèle, corpus, configuration d’outil et version applicative pertinents. Un alias courant peut ne pas suffire à expliquer un résultat ancien. Les références disponibles doivent décrire la combinaison observée, avec les passages et paramètres utiles. Une évolution simultanée de plusieurs composants ne permet pas de désigner la cause sur la seule proximité avec l’heure de déploiement.

Une comparaison avec une version antérieure aide à formuler une hypothèse, mais sa portée dépend du contexte. Le document peut avoir changé, une permission peut être retirée ou la question peut appartenir à une autre famille. Conservez l’attente métier et les cas dégradés avant de refaire la recette. Le diagnostic doit pouvoir expliquer quelle différence a été isolée et quelles autres restent possibles.

Réduire l’impact sans transformer la première hypothèse en vérité

Le banc déclare des incidents sur P2, M2 ou C2, selon le scénario. Ces repères sont fictifs ; aucun prompt, modèle ou corpus n’a été mesuré comme défectueux. Le programme reçoit la décision de retrait et vérifie ses conséquences sur les états. Il ne détecte pas automatiquement la cause d’un incident et ne certifie pas que P1, M1 ou C1 donnent de meilleures réponses.

Le registre d’incident distingue signal, hypothèse, mitigation appliquée et observation qui permet de la confirmer. Une fermeture peut être décidée à titre conservatoire selon les conséquences métier, avec une recette de diagnostic encore ouverte. La réouverture possède son propre accord ; elle ne découle pas simplement de l’absence de nouvelles alertes lorsque le trafic a été suspendu.

Retrouver versions, sociétés et états concernés

Construire une matrice de portée avant de réinitialiser les traitements

Cas concret : l’incident fictif concerne prompt P2 dans la société A. L’inventaire contient huit états construits à la main. Quatre portent cette combinaison, dont deux traitements en attente, une action inconnue et un travail terminé. La société B conserve P2 dans une autre portée de politique. La matrice distingue appartenance au périmètre touché et travail de résolution de chaque état.

Fermer les états dont la version ne peut pas être identifiée

La sélection locale compare société, composant et version déclarés. Elle ne découvre pas les workers, caches ou requêtes d’une production. A42-08 retire le repère de prompt et reçoit inventory_incomplete avant toute admission. Une inconnue d’inventaire ne doit pas rejoindre par défaut la population supposée saine. Le service doit retrouver la dépendance ou conserver le dossier dans un état fermé explicite.

La portée peut devoir s’élargir lorsqu’un composant est partagé ou qu’un alias commun a changé. Elle doit être revue avec les traces et la topologie disponibles. Les huit lignes ne prouvent pas une couverture exhaustive de la plateforme. Elles montrent pourquoi un même retrait demande des gestes différents pour un traitement en file, un effet ambigu et un résultat déjà appliqué.

Fermer la capacité et les réponses encore en cours

Donner un effet opérationnel au retrait décidé

Une version retirée ne doit plus ouvrir la capacité concernée. Le mode de repli peut garder une consultation autorisée ou une proposition manuelle, selon la règle choisie. Les nouvelles demandes, reprises et chemins issus du cache doivent retrouver la décision courante. Un retrait annoncé uniquement dans un document d’exploitation ne ferme pas les branches qui peuvent encore servir une ancienne sortie.

La fonction Manage 2.4 du NIST AI RMF prévoit des mécanismes et responsabilités pour remplacer, désengager ou désactiver un système dont les résultats s’écartent de l’usage prévu. Ce cadre aide à préparer la gouvernance du retrait ; il ne constitue pas une certification du laboratoire. La fermeture doit rejoindre des capacités et des responsabilités concrètes dans votre application.

Réexaminer une réponse préparée avant la décision de fermeture

Exemple concret : A42-20 conserve une réponse manuscrite prête à sortir sous P2, puis présente la politique d’incident sur P2. Held_impacted ferme son admission. Le banc ne lance pas une génération puis une interruption ; il construit l’ancien résultat et applique la garde courante. La recette réelle doit éprouver cette fenêtre entre préparation, contrôle et présentation au lecteur.

Une publication qui utilise un état de politique ancien peut laisser sortir le résultat après la fermeture. Les reprises, notifications et lectures de cache doivent donc être identifiées. Le contrat précise où la garde est évaluée et quel résultat doit être retiré, différé ou recontrôlé. Une fin de génération ne prouve pas que la sortie reste admissible dans le périmètre désormais ouvert.

Préserver les effets connus et les opérations inconnues

Conserver les faits que le changement de version ne peut pas annuler

Le laboratoire garde une ligne d’effet passé OP42, reçu CN42, statut applied, dans chaque base SQLite. La lecture avant et après contrôle retrouve exactement les mêmes valeurs. Aucun contrôle ne supprime cette ligne ni n’en ajoute une autre. Il s’agit d’un registre fictif, pas d’un avoir ERP. La conservation montre la séparation locale entre décision de retour et fait déjà enregistré.

A42-11 conserve une mission completed sous P2 et reçoit completed_preserved, même en mode sûr. La clôture n’est pas réouverte parce que la version a été retirée. Une correction métier éventuelle doit être une opération distincte avec sa propre décision. Restaurer un prompt, un modèle ou un service ne supprime pas automatiquement les objets que ses outils ont déjà créés.

Laisser le rapprochement ouvert lorsque l’action reste inconnue

A42-10 porte action_unknown et l’opération OP42-PENDING, distincte de l’effet historique OP42. Le verdict reconciliation_required précède une nouvelle admission, y compris avec incident et mode sûr. Le service doit fermer les prochains gestes tout en conservant le travail de résolution du résultat. Le banc n’effectue aucun lookup de cette opération pendante ni tentative de compensation.

Le rapprochement possède ses accès et son contrat d’outil. La demande de retrait n’efface pas l’effet possible d’un appel engagé, ni la réserve associée à sa dépense. Les équipes doivent retrouver les opérations ouvertes et leur propriétaire. La mitigation peut empêcher un nouvel envoi pendant que la preuve du premier geste est encore recherchée, sans considérer la fermeture comme une annulation confirmée.

Vérifier ce que l’ancienne version peut reprendre

Retrouver une combinaison de composants et de formats compatible

Le repère de retour décrit prompt, modèle et corpus, mais aussi les contrats de checkpoint et d’outil nécessaires. A42-12 présente un schéma 2 à un runtime fictif qui ne supporte que 1 et reçoit checkpoint_incompatible. Un changement de version peut avoir produit des états que le service antérieur ne sait pas interpréter. Leur migration ou leur revue doit être décidée avant de rouvrir la progression.

A42-19 présente P1/M1/C1 alors que la politique active de A demande encore P2/M1/C1 et reçoit version_review. Préparer un ancien état ne change pas la politique d’admission. Le retour doit identifier la combinaison effectivement activée, puis vérifier les missions qu’elle peut reprendre. Une suite de versions nominales ne prouve pas leur compatibilité ni l’équivalence de leurs réponses.

Comprendre la portée du retour d’infrastructure

La documentation Kubernetes des Deployments relie leurs révisions au template de Pod. Pour un système IA, il faut donc inventorier aussi les configurations et données qui peuvent évoluer à l’extérieur de ce template. Le retour d’un déploiement ne constitue pas une preuve de retour du corpus, des permissions ou des objets métier déjà appliqués.

Le banc ne déploie pas Kubernetes et n’exécute aucun rollback. La recette d’infrastructure doit vérifier images, configuration, migrations et dépendances de la version ciblée. Celle du métier conserve les effets connus et les sources encore autorisées. Un corpus ancien peut contenir un document retiré ; une image antérieure peut ignorer un nouveau champ de contrôle. Ces compatibilités exigent une décision explicite.

Réexaminer sources, droits et accords avant réouverture

Ne pas restaurer une autorisation ou une source devenue inadmissible

A42-13 ferme une source déclarée retirée ; A42-14 garde une capacité désactivée ; A42-15 retire le droit de lecture. Le retour reste refusé dans les trois cas, même sous la combinaison courante. Ces champs sont des valeurs injectées, sans moteur de permissions ou index réel. La production doit retrouver l’autorité courante plutôt que considérer l’ancien snapshot comme un droit permanent d’usage.

A42-16 conserve un accord lié à P2/M1/C1 tandis que la reprise présente P1/M1/C1. Approval_version_review demande une revue de cette filiation. Le laboratoire adopte cette politique stricte pour ses repères fictifs ; il ne décide pas que tout changement de prompt exige toujours une nouvelle signature utilisateur. Le contrat réel définit les changements de proposition, de portée ou d’effet qui invalident l’accord.

Faire de la recette et de l’accord de retour deux conditions séparées

A42-17 porte recipePassed faux et reçoit recipe_pending ; A42-18 porte humanReturnAuthorized faux et reçoit reopening_not_authorized. Le programme ne réalise pas les évaluations représentées par ces booléens. Il vérifie qu’elles ne sont pas oubliées dans la garde. La recette réelle doit établir quels écarts sont corrigés, quelles limites restent ouvertes et qui décide l’exploitation de la famille concernée.

Le retour peut commencer en consultation, avec revue humaine ou sur un périmètre réduit, selon le processus. Une admission locale n’autorise pas toutes les écritures d’un catalogue d’agents. Les capacités doivent rejoindre leur propre contrat, leur idempotence et leurs préconditions. Le mode retenu rend le travail utile possible tout en conservant les restrictions et les seuils de fermeture définis pour le pilote.

Vingt contrôles et trois admissions locales au retour

Observer les gardes sans leur attribuer une mesure de qualité IA

Les snapshots et politiques sont enregistrés puis relus dans vingt bases SQLite 3.53.1. Le contrôleur examine inventaire, état, portée, version, schéma, source, capacité, droits, accord et préconditions de retour. Les jeux sont manuscrits ; les variantes isolent une frontière. Le tableau rend le verdict calculé, sans nouvelle publication, effet externe ou déploiement.

Conserver les compteurs et les limites de la recette

Les seules admissions sont A42-01, A42-03 et A42-04. L’effet historique reste présent dans chaque base et tous les contrôles publient zéro réponse. Le bilan exact ci-dessous conserve la matrice d’impact et ces sorties. Il ne calcule ni disponibilité, délai de reprise, diminution d’erreur ni réussite d’un modèle : les composants et leurs résultats sont des repères fictifs.

{"cases":20,"impacted":["J1","J5","J7","J8"],"admitted":["A42-01","A42-03","A42-04"],"pastEffectCount":1,"newEffects":0,"publishedOutputs":0,"sqliteVersion":"3.53.1"}

La conservation vérifie les valeurs lues dans la table d’effet, pas l’effacement physique ou la sûreté d’un ERP. Les contrôles utilisent un ensemble réduit de champs connus, sans validateur exhaustif de types. Aucune file de travail, propagation distribuée ou génération concurrente n’est lancée. La recette réelle doit éprouver contrôle courant, messages tardifs et compatibilité dans son infrastructure, puis mesurer le résultat métier après retour.

Suivre la mitigation, la file ouverte et la qualité

Mesurer ce qui est fermé et ce qui reste à résoudre

Le suivi distingue familles suspendues, demandes reprises manuellement, opérations inconnues et résultats à corriger. Une baisse des erreurs après fermeture peut simplement venir du trafic retiré. La file restante doit être visible avec son propriétaire et sa prochaine vérification. Les états completed restent dans l’analyse d’impact lorsqu’un résultat passé peut devoir être examiné, sans être rejoués automatiquement.

La journalisation relie incident, versions, décisions et opérations ouvertes. Elle conserve les pièces utiles dans leur périmètre d’accès, avec des métadonnées de diagnostic adaptées à l’exploitation. Le dossier peut permettre de retrouver un résultat sans exposer toutes les conversations. La responsabilité de revue et le délai d’escalade sont définis par le processus, pas par une alerte moyenne de consommation.

Reprendre une mesure métier lorsque la capacité est réouverte

La recette de retour rejoue cas dégradés, questions voisines, sources retirées et changements de droits. Une version qui évite l’erreur en refusant davantage peut augmenter la charge de support. Le bilan doit donc conserver couverture, abstentions utiles, temps de vérification et effets du processus. Une réponse fluide ou un HTTP 200 ne remplace pas ce suivi du travail réellement terminé.

Le seuil d’exploitation est décidé selon la famille, les erreurs graves et le repli disponible. Le coût complet inclut révisions documentaires, revue et dossiers repris pendant l’incident. Aucun ROI ne peut être déduit de trois admissions sur vingt situations construites. La comparaison terrain exige périodes, périmètres et volumes connus, avec une lecture séparée des demandes qui n’ont pas été ouvertes à l’IA.

Erreurs fréquentes dans le retour d’un système IA

Restaurer le composant visible et oublier les dépendances

Le prompt peut revenir à P1 tandis que corpus, cache, outil ou format d’état restent ceux de la nouvelle version. Cette combinaison n’a peut-être jamais été évaluée. Le signal faible est une réouverture annoncée comme ancienne version, suivie de refus de lecture ou de réponses qui conservent la règle retirée. L’inventaire doit décrire la combinaison et les dépendances réellement actives.

Une autre erreur consiste à vider les missions pour contourner les états difficiles. Les effets possibles et les réserves ne disparaissent pas avec l’historique affiché. Le retrait doit garder ces liens pour les équipes de résolution. Une migration peut convertir un checkpoint selon un contrat explicite ; elle ne peut pas transformer une opération inconnue en absence d’effet simplement pour rendre le redémarrage plus rapide.

Rouvrir sur une impression de calme plutôt que sur une recette

Paradoxalement, le silence du monitoring peut être le résultat d’une capacité fermée. Il ne prouve pas que la cause est corrigée. Le retour possède une décision et une recette distinctes de la mitigation. Les comportements qui avaient provoqué l’incident restent des cas de régression, avec leurs sources et restrictions, même lorsque le fournisseur ou l’infrastructure sont redevenus disponibles.

Un troisième signal apparaît lorsque le travail manuel accumulé est oublié dans le bilan de reprise. La capacité est techniquement ouverte, mais les dossiers restent incomplets ou les équipes relancent les mêmes opérations. Le runbook doit suivre cette file et les preuves d’effet. La clôture d’incident distingue service restauré, données examinées et actions de correction encore attribuées.

Plan d’action pour retrait, rapprochement et recette

L’implémentation relie les signaux d’entrée à une décision de portée et à des états de sortie. La responsabilité de fermeture appartient au service ; les propriétaires de source et d’outil résolvent les pièces métier. L’instrumentation suit l’inventaire, les opérations ouvertes et les gardes de retour. Le repli conserve une voie de travail explicite pendant que la capacité concernée reste fermée.

1. Préparer les versions et les autorités. Identifiez combinaison de prompt, modèle, corpus, configuration, outils et formats persistés. Conservez les repères utiles avec chaque traitement. Définissez les responsables qui peuvent fermer une famille et revoir l’hypothèse, avec une procédure pour les états dont une version ou une source ne peut pas être retrouvée.
2. Définir la fermeture et ses chemins. Qualifiez nouvelles demandes, tâches engagées, caches et réponses prêtes. Le retrait doit être observable à la frontière qui autorise la suite ou la présentation. Préparez consultation limitée ou traitement manuel, puis testez une ancienne sortie préparée avant la décision sans la laisser contourner la politique courante.
3. Conserver les effets et la file de rapprochement. Séparez travail en attente, mission terminée et action inconnue. Retrouvez les identités d’opération et les reçus disponibles. La fermeture n’autorise ni réémission ni compensation ; chaque geste de résolution garde son contrat et son accord. Attribuez les inconnus et les réserves aux personnes habilitées.
4. Vérifier le candidat de retour. Contrôlez combinaison activée, checkpoints, dépendances, sources courantes, droits et accords encore admissibles. Éprouvez l’infrastructure et le résultat du modèle dans la recette réelle. Un ancien composant ne suffit pas à restaurer un service si ses données ou ses formats ne peuvent plus être interprétés selon le contrat retenu.
5. Décider et mesurer la réouverture. Conservez attentes, cas régressifs, limites et mode de retour. Le responsable arbitre la capacité et les seuils de retrait, avec revue humaine quand elle reste nécessaire. Après ouverture, mesurez travail utile et file manuelle, puis suivez les corrections de données et les actions qui restent ouvertes au-delà du retour technique.

Le contrat de rollback précise ce qu’il reconfigure et ce qu’il conserve. La traçabilité relie la décision au candidat et à la recette, tandis que les dépendances encore incompatibles gardent un motif de revue. Le responsable peut alors expliquer pourquoi une famille revient en consultation, reste fermée ou nécessite une migration avant d’être de nouveau proposée aux utilisateurs.

Relier gouvernance, évaluations et preuves d’action

Préparer les conditions de retrait avant le lancement

Le dossier de lancement d’une IA en production fixe capacités, recette et responsabilités. Le contrôle des régressions entre versions IA conserve les attentes qui doivent rejoindre le retour après incident. Les écarts graves restent visibles même lorsqu’une moyenne de qualité augmente.

Le contrôle des instructions reçues dans les données complète le retrait lorsqu’un contenu influence une capacité. Le retrait d’une source RAG et de ses copies vérifie les chemins qui peuvent encore transmettre une règle fermée. Le retour d’une version technique ne doit pas rétablir automatiquement cette source.

Garder l’opération et la mission explicables pendant la reprise

La reprise d’une mission d’agent depuis son checkpoint conserve faits acquis et gestes pendants avant un prochain plan. Le dossier de preuve d’une action IA rapproche proposition, autorisation et reçu. Ces deux contrats permettent d’organiser une résolution sans remettre à zéro les effets que le service doit encore expliquer.

La recette d’incident relie donc version de service, autorité de source et identité d’action. Changer un composant peut modifier la progression admissible tout en laissant une opération passée rattachée. Les équipes doivent retrouver ces relations et les décisions encore nécessaires, avec une voie de revue qui garde les droits et les limites du processus.

Conclusion : conserver les faits pendant le changement de version

Le retrait d’un système IA ferme un périmètre et organise le travail qui reste ouvert. Le diagnostic retrouve versions et dépendances ; le rapprochement conserve les effets et les opérations inconnues. Un candidat de retour doit pouvoir interpréter les états, utiliser les sources encore admissibles et retrouver les conditions qui autorisent sa progression. La restauration d’un composant ne remplace pas ces décisions.

Les huit états et vingt contrôles locaux rendent trois admissions de recette, sans publier une réponse ou envoyer un effet. La ligne d’opération passée reste conservée dans chaque base SQLite. Aucun modèle, déploiement ou rollback réel n’est éprouvé ; les booléens de recette et d’accord sont des préconditions fictives. Leur valeur doit être établie dans la chaîne réelle avant de rouvrir le service.

L’industrialisation et la gouvernance d’une IA relient cette discipline aux rôles, interfaces et évaluations. Les utilisateurs disposent d’un chemin de travail pendant la fermeture, tandis que les équipes gardent les opérations à résoudre. La réouverture reste une capacité décidée sur un périmètre et une recette, avec des limites qui peuvent de nouveau être appliquées.

Pour retirer une version à l’origine d’un incident, notre expertise IA sur mesure peut identifier les missions touchées, fermer leurs prochaines admissions et préparer une recette de retour. Les actions au résultat inconnu gardent leur responsable de résolution ; les effets établis restent dans le dossier. L’ouverture exige ensuite des droits et sources courants, une compatibilité vérifiée et une décision de retour explicite, au lieu de réactiver indistinctement les anciens travaux.