Mode dégradé d’un agent IA : continuer, arrêter et reprendre

Le mode dégradé d’un agent IA est la manière documentée de continuer une activité essentielle, de la ralentir proprement ou de l’arrêter lorsque le modèle, un outil, une donnée ou un fournisseur ne répond plus comme prévu. Ce n’est pas seulement un second modèle appelé en urgence. Un repli fiable indique ce qui reste autorisé, ce qui passe en file d’attente, ce qui revient à une personne et ce qui doit être bloqué tant que l’état n’est pas réconcilié.

Le bon plan commence par l’effet métier. Si l’agent prépare un brouillon, le mode dégradé peut accepter une production plus lente. S’il déclenche un paiement, modifie un dossier ou envoie un message, une incertitude doit souvent arrêter l’action plutôt que provoquer un basculement automatique vers un système moins connu.

Réponse en bref

Pour concevoir le mode dégradé d’un agent IA :

1. listez les effets métier que l’agent peut produire ;
2. cartographiez les dépendances nécessaires à chaque effet ;
3. définissez quatre niveaux de service, du nominal à l’arrêt protégé ;
4. choisissez un seuil de bascule mesurable pour chaque défaillance ;
5. prévoyez une alternative non IA ou manuelle quand elle est réellement soutenable ;
6. conservez les demandes en attente sans répéter les effets déjà produits ;
7. indiquez qui décide la bascule, qui opère et qui autorise la reprise ;
8. testez la procédure avec une panne simulée, sans toucher aux systèmes externes réels ;
9. réconciliez l’état avant de vider la file ;
10. revenez progressivement au nominal avec un débit limité et un critère d’arrêt.

La prochaine action utile est d’organiser un exercice de quarante-cinq minutes sur un seul workflow. Coupez une dépendance en environnement de test, appliquez la fiche de bascule, traitez trois opérations, puis vérifiez que la reprise ne crée ni perte ni double effet.

Le mode dégradé commence par une décision métier

Une architecture technique peut être disponible alors que le service rendu ne l’est plus. Le modèle répond, mais produit des sorties hors schéma. L’API métier accepte les requêtes, mais renvoie des données anciennes. Le moteur de recherche interne fonctionne, mais sans les documents mis à jour. La mesure utile n’est donc pas seulement « le serveur répond-il ? ».

Décrivez le service en une phrase observable :

Pour chaque demande admissible, le système prépare une proposition traçable en moins de dix minutes ; aucune action externe n’est exécutée sans validation.

Cette phrase révèle ce qui peut être dégradé. Le délai peut passer de dix minutes à quatre heures. La proposition peut être préparée manuellement. L’action externe, elle, reste interdite sans validation. La continuité ne signifie pas maintenir toutes les fonctions à tout prix.

L’ANSSI définit le plan de continuité d’activité comme un ensemble de procédures documentées permettant de poursuivre les opérations en mode dégradé après une perturbation. Le plan de reprise organise le retour vers le fonctionnement attendu. Pour un agent IA, ces deux temps doivent être séparés : continuer ou arrêter proprement d’abord, restaurer et réconcilier ensuite.

Cartographier les dépendances critiques

Un agent n’est pas un modèle isolé. Son résultat dépend d’une chaîne dont chaque composant peut tomber en panne ou rester disponible avec un comportement dégradé.

Inventoriez au minimum :

• le point d’entrée et l’authentification ;
• le modèle principal et ses limites ;
• les instructions et leur version ;
• les outils appelés ;
• les API et systèmes métier ;
• la base de connaissances et son index ;
• le stockage de l’état ;
• la file d’attente ;
• la validation humaine ;
• les journaux et alertes ;
• les services tiers de notification ;
• la procédure manuelle.

Pour chaque dépendance, posez quatre questions :

1. comment détecter une indisponibilité franche ?
2. comment détecter un résultat plausible mais incorrect ?
3. quel effet métier devient interdit si cette dépendance est douteuse ?
4. quelle preuve permettra d’autoriser la reprise ?

Cette cartographie complète le contrat de fiabilité d’un agent IA. Les SLO aident à voir une dérive. Le mode dégradé indique quoi faire quand le seuil est franchi.

Définir quatre niveaux de service

Une décision binaire, tout fonctionne ou tout est coupé, convient rarement. Quatre niveaux rendent les comportements compréhensibles.

Niveau	Capacité conservée	Actions externes	Traitement des nouvelles demandes
N0 nominal	toutes les fonctions validées	selon le contrat normal	immédiat
N1 restreint	lecture, préparation ou outil limité	confirmation renforcée ou interdiction ciblée	immédiat avec avertissement
N2 manuel	formulaire, procédure humaine ou export minimal	par une personne autorisée seulement	file priorisée et débit réduit
N3 arrêt protégé	consultation de l’état et signalement	aucune	demandes refusées ou conservées sans exécution

Le niveau N1 peut désactiver un connecteur qui échoue tout en gardant la préparation d’un brouillon. Le niveau N2 peut produire une liste à traiter par une équipe. Le niveau N3 conserve les preuves et empêche toute nouvelle action jusqu’à clarification.

Évitez un vocabulaire rassurant mais imprécis comme « mode secours automatique ». Écrivez les fonctions réellement disponibles, les effets interdits et l’identité de la personne qui peut changer de niveau.

Construire la matrice dépendance, effet, bascule

La matrice relie un signal technique à une conséquence métier. Elle empêche de basculer tout le système pour un incident local ou, au contraire, de continuer une action dangereuse parce que le serveur renvoie encore un code 200.

Défaillance observée	Effet à protéger	Détection	Niveau cible	Condition de retour
modèle indisponible	produire une proposition	erreurs et délai sur une fenêtre définie	N2 manuel	test de santé et lot de cas réussis
sortie hors schéma	ne pas envoyer une action incomplète	validation locale	N1 ou N3 selon l’effet	série de sorties valides sur cas de contrôle
base documentaire trop ancienne	ne pas répondre avec une règle obsolète	version attendue absente	N1 lecture limitée	version réconciliée et test de récupération
API métier incertaine	éviter un double effet	délai après soumission, statut inconnu	N3 pour cette action	réconciliation avec le système cible
validation humaine indisponible	empêcher une action non approuvée	file sans validateur dans le délai	N1 préparation seule	validateur de remplacement autorisé
journalisation en panne	garder la traçabilité	absence d’accusé d’écriture	N3 pour effets sensibles	écriture et lecture de contrôle réussies

Le statut inconnu mérite une ligne propre. Une requête qui expire peut avoir été exécutée par le système cible. La relancer immédiatement transforme une panne de visibilité en double action. Le protocole d’idempotence protège la répétition, mais il ne dispense pas de réconcilier l’état réel.

Choisir la bonne stratégie de repli

Toutes les défaillances ne justifient pas le même mécanisme.

Réessayer avec délai

Le retry convient à un échec temporaire et réversible, lorsque la limite est bornée et que l’opération est protégée contre les doublons. Ajoutez un délai croissant, un nombre maximal et une destination finale. Réessayer sans budget masque une panne et surcharge la dépendance.

Mettre en file d’attente

La file conserve une demande admissible jusqu’au retour du service. Elle doit enregistrer l’identifiant métier, la version des données, le niveau d’autorité, la date limite et le statut de l’effet. Une file sans limite ni politique d’expiration déplace simplement la panne.

Utiliser une alternative non IA

Une règle déterministe, un formulaire ou un modèle de document peut préserver le service essentiel. Le NIST inclut explicitement les approches non IA parmi les alternatives à considérer. Cette solution est souvent plus sûre qu’un second modèle si le travail peut être simplifié.

Basculer vers un autre fournisseur ou modèle

Ce basculement n’est acceptable que si l’alternative a été évaluée sur les mêmes interfaces, permissions et cas critiques. Un modèle disponible mais incompatible avec le schéma, les outils ou la politique de données n’est pas un repli. Il crée une migration improvisée. Utilisez le protocole de changement de modèle sans régression avant de l’inscrire dans le plan.

Arrêter l’effet

L’arrêt est une stratégie valide. Si l’état de l’autorisation, du journal ou du système cible est inconnu, conserver la demande sans l’exécuter peut être le meilleur service possible. Le lecteur doit recevoir un message honnête et une prochaine étape, pas une fausse réussite.

Le contrat REPLI

La fiche REPLI tient sur une page et doit rester utilisable pendant l’incident.

R : Résultat minimum

Écrivez le service minimal à préserver et ce qui peut attendre. Exemple : recevoir les demandes et produire une liste priorisée, sans envoyer de réponse automatique.

E : Effets interdits

Listez les actions qui ne doivent jamais être exécutées en état dégradé : paiement, envoi externe, modification irréversible, suppression, publication ou décision concernant une personne, selon le cas.

P : Preuves de bascule

Définissez les signaux et leur fenêtre. Une seule erreur réseau ne suffit pas toujours. Une validation de schéma échouée sur une sortie destinée à déclencher un effet peut suffire immédiatement.

L : Limites du repli

Indiquez le volume maximal, le délai toléré, la durée pendant laquelle le mode peut rester actif et les données accessibles. Le manuel n’est pas une capacité infinie.

I : Identités responsables

Nommez le décideur de bascule, l’opérateur, le responsable métier, le validateur de reprise et le canal de communication. Les droits techniques doivent correspondre à ces rôles. La gestion d’identité et d’autorisation d’un agent reste active pendant la crise.

Conserver les opérations sans doubler les effets

Une file de continuité doit distinguer au moins sept états :

1. reçue ;
2. validée pour traitement ;
3. réservée ;
4. effet demandé ;
5. effet confirmé ;
6. état inconnu ;
7. réconciliée ou abandonnée.

Ne remettez pas automatiquement « état inconnu » dans la file normale. Une personne ou un processus déterministe doit interroger le système cible, retrouver l’identifiant externe ou contrôler le résultat métier. Seulement ensuite, l’opération peut être confirmée, annulée ou rejouée.

Le dossier minimal de chaque opération contient :

• un identifiant stable ;
• l’effet attendu ;
• la clé d’idempotence ;
• la version des données et des règles ;
• le dernier état connu ;
• les tentatives et leurs réponses ;
• l’identité ayant autorisé l’action ;
• la date limite métier ;
• la décision de reprise ;
• la preuve de réconciliation.

Cette structure rejoint la file d’erreurs d’un workflow IA, avec une différence : le mode dégradé couvre aussi les opérations nouvelles et la capacité minimale de l’organisation, pas seulement les échecs unitaires.

Préparer la reprise nominale

Le retour du fournisseur ou un test de santé vert ne suffit pas. Pendant la panne, les données, les instructions et le système métier ont pu évoluer. La reprise comporte cinq contrôles.

1. Vérifier la dépendance

Testez disponibilité, authentification, quotas, version et contrat de sortie. Utilisez un lot de cas représentatifs, pas seulement une requête « bonjour ».

2. Réconcilier l’état

Comparez la file locale, le journal de l’agent et l’état du système cible. Isolez chaque opération inconnue avant tout vidage de file.

3. Revalider les données

Une demande ancienne peut ne plus être pertinente. Vérifiez sa date limite, la version documentaire et l’autorisation encore valable.

4. Reprendre par canary

Traitez un petit lot, observez le résultat et augmentez progressivement le débit. Gardez un seuil de retour immédiat au niveau dégradé.

5. Fermer l’incident

Documentez l’heure, l’impact, les opérations concernées, les corrections, les décisions et le propriétaire des actions restantes. Une panne sans retour d’expérience se reproduit avec la même procédure fragile.

L’exercice de panne en quarante-cinq minutes

Le profil NIST pour l’IA générative recommande de définir les responsabilités, de tester les technologies de repli, d’envisager le traitement manuel et de répéter les plans d’incident. L’ANSSI recommande également de s’entraîner afin de pratiquer et d’améliorer les plans de continuité et de reprise.

Un exercice court peut suivre ce déroulé :

Temps	Injection	Action attendue
0 à 5 min	le modèle dépasse le délai sur trois demandes	confirmer le signal, nommer le décideur
5 à 12 min	une demande a peut-être déclenché un effet	isoler l’état inconnu, ne pas rejouer
12 à 20 min	la file atteint son seuil d’alerte	prioriser, informer, appliquer la capacité manuelle
20 à 30 min	le fournisseur revient	exécuter les tests de santé et de compatibilité
30 à 38 min	une donnée a changé pendant l’arrêt	expirer ou revalider les demandes anciennes
38 à 45 min	reprise limitée	traiter le canary, mesurer, décider de poursuivre

L’exercice reste local ou utilise un environnement de test. Il ne doit pas envoyer de message, débiter un compte, modifier un dossier réel ou toucher une production non prévue.

Mesurer le plan plutôt que sa documentation

Un document complet n’est pas une preuve de fonctionnement. Mesurez :

• le temps entre le premier signal et la décision de bascule ;
• le temps nécessaire pour informer les utilisateurs ;
• le nombre d’effets interdits effectivement bloqués ;
• les demandes perdues, doublées ou restées inconnues ;
• la capacité manuelle soutenable par heure ;
• le temps de réconciliation ;
• le nombre de demandes expirées avant reprise ;
• le taux de réussite du canary ;
• les écarts entre la fiche et les actions réelles.

Reliez chaque métrique à une décision. Si la file dépasse la capacité de traitement manuel en trente minutes, il faut réduire les entrées ou modifier le résultat minimum. Si la réconciliation est impossible, la priorité devient l’identifiant métier et l’observabilité, pas un second fournisseur.

Ce qu’un consultant ou une équipe doit livrer

Un plan de continuité d’agent IA utile comprend au moins :

• la carte des effets et dépendances ;
• les quatre niveaux de service ;
• la matrice dépendance-effet-bascule ;
• le contrat REPLI ;
• les messages destinés aux utilisateurs ;
• la structure de file et les états ;
• la procédure de réconciliation ;
• le jeu de tests de reprise ;
• le scénario d’exercice ;
• le journal de décisions et d’améliorations.

Ces livrables permettent de comparer une architecture ou une mission sans confondre disponibilité technique et continuité métier. Pour cadrer un besoin plus large, le cahier des charges d’une mission de consultant IA aide à définir périmètre, données, tests, exploitation et sortie.

Limites

Ce guide adapte des principes généraux de continuité, de reprise et de gestion des risques à un agent IA. Il ne remplace pas un PCA ou un PRA d’entreprise, une analyse de risques sectorielle, les obligations de notification d’incident ni les procédures de cybersécurité existantes. Un système critique exige une qualification adaptée à son contexte et des exercices plus complets.

Les seuils, délais et niveaux proposés sont des structures à remplir, pas des valeurs universelles. Un repli manuel peut lui-même être indisponible, dangereux ou trop lent. Un second modèle peut partager le même fournisseur, la même région, le même stockage ou la même erreur de conception. La diversité affichée n’est donc pas une indépendance prouvée.

Commencez par un workflow borné et une panne simulée. Si l’activité ne sait pas fonctionner quarante-cinq minutes sans l’agent, le problème de continuité est déjà visible. La page automatisation IA et Python présente l’approche de mission pour cartographier, prototyper et tester un workflow sans déléguer automatiquement la décision.