Préparer la panne d’une automatisation
Une démonstration réussie ne suffit pas pour un usage quotidien. Prévois informations manquantes, connexion interrompue et travail partiellement accompli pendant que le flux reste facile à modifier.
Alerter la bonne personne
Nomme responsable et remplaçant. Distingue urgence et traitement différé. Une alerte identifie le travail concerné et la prochaine action sûre sans mot de passe ni données clients inutiles.
Microsoft décrit parcours d’erreur, notifications et règles de nouvelle tentative. La question métier vient d’abord : que doit comprendre le destinataire avant de décider ?
Distinguer arrêt et exécution partielle
Un flux fictif crée une tâche puis actualise une fiche. Si la seconde étape échoue, la tâche peut déjà exister. Tout relancer peut la dupliquer. Conserve assez d’informations pour connaître les effets, pas seulement l’échec global.
Interroge la personne chargée de l’implémentation sur entrées répétées et résultats incertains. Un délai dépassé ne signifie pas toujours que le destinataire n’a rien fait. Paiements, messages et publication nécessitent des contrôles adaptés.
Convenir des arrêts
Définis quand interrompre les tentatives automatiques : données invalides ou échec répété à examiner, par exemple. Une connexion temporairement indisponible diffère d’une instruction toujours incorrecte.
Prévois une désactivation autorisée et le traitement des éléments en attente. Organise le travail manuel urgent sans répétition ultérieure au redémarrage. Consigne son achèvement au même endroit que la reprise.
Répéter la récupération
Teste une panne sûre avec des données contrôlées. La personne désignée suit les instructions, vérifie l’état et décide de reprendre. Si elle dépend de connaissances non écrites du créateur, améliore la transmission.
Après un incident réel, examine cause et effets. Un plan utile reste court sous pression et évite qu’une tâche interrompue devienne plusieurs actions involontaires.
Sources: Microsoft Learn: Employ robust error handling.