Incident IA : concevoir la reprise avant la panne

# Incident IA : concevoir la reprise avant la panne

Un statut vert ne remet pas votre workflow en marche.

Lorsqu'un service IA intervient dans un processus métier, l'incident ne se limite pas à une page indisponible. Une erreur peut se produire pendant l'accès, pendant l'appel au modèle, dans une dépendance du workflow ou au moment où une équipe doit reprendre la main. Préparer la reprise consiste à reconnaître ces couches avant qu'elles ne se mélangent sous pression.

La page de statut d'un fournisseur a signalé trois incidents résolus le 24 août, dont des erreurs de requêtes modèles et des erreurs d'accès. Cette chronologie ne mesure pas l'impact complet sur chaque organisation. Elle rappelle une règle utile : une même interruption apparente peut demander des réponses différentes.

Cartographier les dépendances avant l'incident

Commencez par dessiner le trajet réel d'une demande. Qui lance l'action ? Quelle identité est utilisée ? Quelle donnée part vers le service ? Quel système reçoit la réponse ? Quelle personne décide si le résultat peut poursuivre le processus ?

Ce trajet permet de distinguer les dépendances qui restent souvent invisibles : authentification, réseau, quota, modèle, connecteur, file d'attente, stockage temporaire ou validation humaine. L'objectif n'est pas de prévoir chaque panne. Il est de savoir où regarder lorsque le flux ne se comporte plus comme prévu.

Distinguer accès, modèle et orchestration

Une erreur d'accès indique que l'utilisateur, le compte, la clé ou le chemin d'authentification ne permet plus de poursuivre. Une erreur liée au modèle concerne l'appel ou la réponse du service. Une erreur d'orchestration intervient lorsque les systèmes autour du modèle ne transmettent plus, ne déclenchent plus ou ne traitent plus la réponse attendue.

Ces catégories peuvent produire un écran similaire pour l'utilisateur. Elles ne demandent pas la même reprise. Relancer automatiquement une tâche peut être inutile si l'identité est bloquée. Modifier une configuration locale peut être hors sujet si l'incident se situe en amont.

Avant le lancement, notez pour chaque couche le signal disponible, la personne qui vérifie et l'action qui peut être tentée sans créer un second problème.

Journaliser sans exposer les données

Une reprise dépend d'une trace. Cette trace doit aider à comprendre ce qui s'est passé sans transformer les journaux en copie incontrôlée de données sensibles.

Conservez les éléments nécessaires à la lecture du flux : heure, identifiant de tâche, couche concernée, état de la tentative, décision prise et destination de la reprise. Évitez d'enregistrer par défaut un contenu qui n'est pas nécessaire au diagnostic.

La journalisation utile ne promet pas d'expliquer chaque incident. Elle permet de savoir ce qui a été reçu, ce qui a échoué, ce qui a été suspendu et ce qui doit être rejoué avec prudence.

Prévoir un mode dégradé

Un mode dégradé n'est pas une version secrète du service. C'est une réponse explicite lorsque la dépendance n'est pas disponible. Selon le processus, cela peut signifier mettre une demande en attente, orienter l'équipe vers une vérification humaine, préparer une réponse différée ou empêcher une action sensible de partir.

La bonne question est : que doit-il se passer si la réponse IA n'arrive pas ou ne peut pas être utilisée ? La réponse doit être compréhensible par la personne qui travaille au moment de l'incident, pas seulement par celle qui a conçu le workflow.

Les actions sensibles restent soumises à validation humaine. Un mode dégradé prépare cette validation au lieu de la demander dans l'urgence.

Tester le retour à la normale

La reprise ne se termine pas lorsque le fournisseur indique que l'incident est résolu. Vérifiez ce qui arrive aux demandes restées en attente, aux tâches interrompues et aux décisions qui ont été prises en mode dégradé.

Définissez les conditions de reprise : qui autorise le redémarrage, quelles demandes peuvent être rejouées, quelles traces doivent être vérifiées et quel signal déclenche l'arrêt du rattrapage. Sans cette étape, un retour à la normale peut créer des doublons, des oublis ou des actions contradictoires.

Ce qu'une page de statut ne prouve pas

Une page de statut peut indiquer qu'un incident a été résolu. Elle ne décrit pas nécessairement le périmètre de votre workflow, les données en attente, les décisions internes ni l'état de vos dépendances périphériques.

Elle ne remplace donc pas votre cartographie, votre journalisation ou votre procédure de reprise. Elle constitue un signal externe parmi d'autres, à lire avec les observations de votre propre processus.

À retenir

Préparez cinq éléments avant l'incident : la carte des dépendances, la distinction entre accès, modèle et orchestration, une trace exploitable, un mode dégradé et une règle de retour à la normale.

Aucun workflow ne devient invulnérable grâce à cette préparation. Il devient plus lisible lorsque l'incident survient.

Pour cadrer les contrôles, les exceptions et les reprises d'un workflow, découvrez le service d'automatisation.