Après une mise à jour défectueuse, corriger aussi les conséquences pour les clients

Imaginons un logiciel de suivi des interventions qui permet aux gestionnaires de télécharger la liste des interventions terminées dans le mois. Ils ouvrent le fichier CSV dans Excel pour préparer leur rapport. Après une modification du code réalisée avec l’aide d’une IA, certaines interventions du dernier jour du mois ne figurent plus dans le fichier.

L’application reste accessible, le bouton fonctionne et le fichier s’ouvre. Pourtant, les rapports préparés à partir de ce fichier risquent d’être incomplets. Cet incident fictif montre pourquoi il faut corriger les fichiers et les rapports déjà utilisés, en plus de réparer le logiciel.

Décrire précisément l’erreur

Le premier signalement doit préciser le fichier en cause, la période demandée, l’entreprise cliente et la version du logiciel utilisée. Comparez les interventions attendues aux données téléchargées. Le problème peut venir du fichier, de l’affichage ou d’une différence entre les règles appliquées dans les deux cas.

Dans ce scénario, l’équipe reproduit une erreur dans le traitement des dates : la sélection des interventions s’arrête au début du dernier jour du mois, alors que le rapport doit couvrir la journée entière. Elle crée des interventions fictives de part et d’autre de cette limite pour vérifier la correction.

Un contrôle qui indique seulement que le site répond ne détecterait pas ce défaut. La surveillance doit aussi porter sur le résultat dont la gestionnaire a besoin : la liste complète des interventions admissibles.

Empêcher la création de nouveaux fichiers erronés

L’équipe doit savoir qui peut désactiver le téléchargement tout en maintenant les autres fonctionnalités. Elle suspend également les déploiements automatisés concernés pendant l’analyse de l’incident. Une personne coordonne la correction et décide comment informer les utilisateurs touchés.

L’IA peut aider à comparer les versions ou à préparer un test qui reproduit l’erreur. Elle conserve les droits d’accès convenus, et la correction qu’elle propose suit la procédure de vérification. L’urgence ne doit pas lui accorder automatiquement des droits supplémentaires.

Les recommandations de Google sur la gestion des incidents insistent sur des responsabilités claires, la coordination et la consignation des interventions. Une petite équipe peut appliquer ces principes en désignant la personne qui dirige la réparation, celle qui communique avec les utilisateurs et celle qui autorise la remise en service.

Retrouver les fichiers déjà utilisés

Après la correction, les nouveaux téléchargements peuvent être exacts alors que plusieurs utilisateurs conservent un fichier incomplet. L’équipe doit repérer les demandes concernées, préparer les fichiers corrigés et indiquer aux personnes autorisées quelle copie remplacer.

Elle doit aussi déterminer si ces fichiers ont servi à produire d’autres rapports. Remplacer le fichier téléchargé ne corrige pas automatiquement un tableau rempli à partir de celui-ci. Chaque action de suivi doit donc avoir un responsable, même une fois le logiciel rétabli.

Travail à effectuer	Résultat à vérifier
Réparer la fonctionnalité	Le fichier téléchargé contient toutes les interventions attendues
Repérer les utilisateurs touchés	Les demandes concernées sont retrouvées à partir des traces disponibles
Fournir les fichiers corrigés	Les personnes autorisées reçoivent le bon fichier et une explication
Corriger les conséquences	Une personne est responsable de chaque rapport ou action à reprendre
Autoriser les prochains déploiements	Un test reproduit le défaut et réussit sur la version corrigée

Ces travaux peuvent avancer en parallèle. Gardez la liste des actions inachevées au lieu de considérer l’incident comme résolu dès que le bouton fonctionne de nouveau.

Choisir une correction adaptée à la modification

Rétablir l’ancienne version du code peut résoudre certains incidents. Toutefois, si la mise à jour a aussi modifié les données enregistrées ou leur structure, l’ancien code risque de ne plus être compatible. L’équipe doit alors vérifier la procédure de rétablissement ou préparer une correction de la version actuelle.

Avant de répéter une opération dans un autre service, vérifiez si elle a déjà abouti. L’absence de réponse ne signifie pas que l’action n’a pas eu lieu. La reprise doit éviter les doublons et les envois répétés du même document.

Conservez les renseignements nécessaires au diagnostic : versions, filtres, heures et résultats des tests. Des données fictives permettent souvent de reproduire le défaut. L’analyse ne justifie pas de conserver indéfiniment les fichiers clients ou les secrets d’accès.

Vérifier le rétablissement avant de reprendre les déploiements automatisés

Ajoutez un test qui reproduit l’erreur de fin de mois. Vérifiez la version corrigée et déterminez ce qu’il faudra surveiller après la remise en service. Une disponibilité normale ou quelques téléchargements réussis ne prouvent pas que ce cas précis est maintenant traité correctement.

Les déploiements progressifs décrits par Google consistent à limiter d’abord l’utilisation d’une nouvelle version afin d’en observer le comportement. Cette approche n’aide que si les usages ou les vérifications couvrent le cas à surveiller. Les utilisateurs concernés restent exposés à la fonctionnalité; une diffusion limitée ne rend pas acceptable une divulgation non autorisée de données.

Décidez ensuite si les déploiements automatisés peuvent reprendre selon les mêmes règles ou si un examen supplémentaire est nécessaire. Cette décision peut être prise séparément de la remise en service. Le premier article explique comment ajuster l’autonomie de l’IA; le dernier tient compte du travail de rétablissement dans l’évaluation d’un essai.