Une procédure de panne applicative sert lorsque l’équipe ne dispose pas de toutes les personnes qui ont construit le système. Elle doit permettre d’identifier une interruption, de limiter les décisions improvisées et d’organiser une reprise contrôlée. Une suite de commandes sans contexte ne répond pas à ces besoins, même si elle a déjà fonctionné pour un développeur.
Imaginons une entreprise fictive dont le portail ne transmet plus les demandes au système de planification. Les clients continuent de soumettre des formulaires, mais le personnel ne reçoit pas les dossiers. La procédure doit traiter l’état des demandes et l’information aux équipes. Redémarrer un composant ne suffit pas à prouver que le travail manquant a été repris.
Définir un signal et un responsable
Décrivez les observations qui déclenchent la procédure : absence de confirmations, délai inhabituel ou différence entre deux vues métier. Distinguez les faits observés d’une hypothèse sur leur cause. Une personne peut voir que des dossiers ne progressent plus sans pouvoir conclure immédiatement que la base de données est responsable.
Indiquez qui prend la coordination et qui détient les droits techniques nécessaires. Prévoyez une solution de contact lorsque l’outil habituel est indisponible. Les responsabilités doivent correspondre à l’organisation actuelle. Une procédure qui dépend d’un ancien prestataire ou d’un compte inaccessible reste incomplète, même si son contenu technique paraît détaillé.
Encadrer les premières actions
Pour chaque action, précisez sa finalité, les conditions nécessaires et le résultat attendu. Indiquez les opérations qui exigent une validation particulière. Un redémarrage ou une reprise de file peut modifier des traitements en cours ; l’opérateur doit savoir ce qu’il préserve et ce qu’il risque de relancer.
Conservez les informations utiles avant de changer l’état du système, selon les règles de l’entreprise. Les journaux, identifiants de traitement et heures d’observation peuvent faciliter l’analyse. Évitez cependant de copier des données privées ou des secrets dans un canal général sous prétexte de documenter rapidement la panne.
Vérifier la reprise du service et du travail
Après une intervention, exécutez un parcours utilisateur représentatif. Soumettez une demande de test, contrôlez sa présence dans le système destinataire et observez la confirmation. Vérifiez séparément les demandes qui attendaient pendant l’interruption. Le retour d’une page d’accueil ne prouve pas que les dossiers accumulés ont été traités.
Définissez comment les différences seront rapprochées et qui peut les corriger. Une reprise automatique doit avoir un état observable et une condition d’arrêt. L’équipe métier doit pouvoir comprendre ce qui est terminé et ce qui nécessite encore une décision, sans interpréter des messages techniques dispersés.
Répéter puis maintenir la procédure
Organisez une répétition dans un environnement contrôlé avec des données adaptées. Faites suivre le document par une personne qui ne l’a pas rédigé. Notez les accès manquants et les étapes ambiguës, puis corrigez-les. Cette répétition doit rester distincte d’un test de reprise réel sur tous les composants de production.
Brainbaby Labs peut intégrer la préparation opérationnelle au périmètre d’un projet logiciel. Apportez un service essentiel, son responsable et un incident représentatif. La livraison peut alors inclure un scénario de reprise, les informations nécessaires à son suivi et une responsabilité de maintenance. Une procédure devient un outil de travail lorsqu’elle est comprise, vérifiée et tenue à jour par l’équipe concernée.