Dégradation contrôlée des applications : que maintenir lorsqu’une dépendance tombe en panne

Lorsqu’une application dépend de services internes ou externes, la panne de l’un d’eux ne devrait pas nécessairement entraîner l’arrêt de tout le système. Cependant, maintenir toutes les fonctions comme si de rien n’était peut aussi provoquer des données incohérentes, des opérations en double ou des décisions fondées sur des informations obsolètes. Concevoir une dégradation contrôlée consiste à décider à l’avance quelles capacités restent disponibles, lesquelles sont limitées et lesquelles doivent être bloquées tant qu’une dépendance ne répond pas.

Cette décision doit protéger le processus métier, et pas seulement la disponibilité technique. Pour chaque fonction, il convient d’examiner le service dont elle dépend, les conséquences de son indisponibilité, la durée d’interruption tolérable et la manière de rétablir la cohérence par la suite. L’équipe peut ainsi proposer une solution de remplacement utile sans dissimuler le problème ni prendre de risques inutiles.

Ce que signifie une dégradation contrôlée

Une application fonctionne en dégradation contrôlée lorsque, face à une panne ou à une réponse insuffisante d’une dépendance, elle conserve un ensemble délibéré de fonctions assorties de limites explicites. Il ne s’agit ni d’une copie complète du service ni d’une promesse que tout continuera de fonctionner. C’est une politique qui définit le comportement de l’application en cas de défaillance partielle.

Cette approche se distingue d’autres mécanismes connexes :

• Mode hors ligne : il permet d’utiliser certaines fonctions sans connexion et, dans certains cas, de synchroniser les modifications plus tard. La dégradation contrôlée peut aussi s’appliquer lorsque le réseau fonctionne, mais qu’un service précis est en panne.
• Nouvelles tentatives : elles relancent une requête qui a échoué, généralement avec des limites et des délais. À elles seules, elles ne déterminent pas ce que la personne doit voir ou faire pendant que la dépendance reste indisponible.
• Dégradation contrôlée : elle définit l’expérience et les règles métier applicables pendant la panne, notamment les opérations autorisées, les données utilisables et les restrictions à respecter.

Par exemple, si un service de recommandations tombe en panne, l’application peut afficher une sélection générique tout en maintenant la recherche. En revanche, si la validation nécessaire à la confirmation d’un paiement est indisponible, autoriser le paiement malgré tout peut présenter un risque supérieur à la suspension temporaire de cette action.

Relier chaque fonction à ses dépendances et à son impact

Commencez par cartographier les capacités du produit, plutôt que par dresser un inventaire isolé des services. Pour chaque fonction visible, indiquez les dépendances nécessaires et le résultat produit. Une fiche utile précise l’opération, le service requis, les données lues ou écrites, l’effet pour l’utilisateur et les conséquences d’un résultat incorrect.

Évaluez ensuite deux dimensions : l’impact de l’impossibilité d’achever la fonction et le préjudice possible si elle est exécutée avec des informations incomplètes ou incorrectes. Ces deux situations ne sont pas équivalentes. Un retard dans le chargement de contenu peut être gênant, tandis qu’accepter une transaction sans vérifier son état peut entraîner des pertes ou des problèmes de rapprochement.

Répartissez d’abord les fonctions en trois groupes :

• À maintenir : les capacités indépendantes de la dépendance en panne, comme la consultation de contenus déjà disponibles localement.
• À limiter : les actions qui restent utiles si leur portée est restreinte, par exemple afficher des données stockées en indiquant leur date de mise à jour ou permettre l’enregistrement d’un brouillon sans l’envoyer.
• À suspendre : les opérations dont la fiabilité dépend d’une vérification impossible à effectuer, comme confirmer une action irréversible sans en valider les conditions.

Cette classification doit tenir compte des solutions de remplacement et des conséquences pour les équipes concernées. Le produit peut définir quelle expérience reste utile ; les équipes techniques et opérationnelles doivent confirmer quelles pannes elles savent détecter et quelles garanties les systèmes offrent. Examinez aussi les dépendances indirectes : une fonction peut sembler autonome tout en nécessitant une validation ultérieure pour achever le processus.

Choisir entre capacité limitée, cache et procédure manuelle

Le choix dépend de l’ancienneté acceptable des données, du fait que l’opération modifie ou non l’état du système et de la possibilité de rapprocher les modifications ultérieurement. Un cache n’est pas adapté à tous les usages : une donnée utile pour orienter une consultation peut être inappropriée pour autoriser une opération.

• Données en cache : utilisez-les lorsque la lecture reste utile même si les données ne sont pas entièrement à jour. Indiquez leur ancienneté et ne les présentez pas comme une confirmation actuelle. Définissez le seuil au-delà duquel elles ne sont plus acceptables ; si vous ne pouvez pas fixer cette limite selon des critères métier, ne les utilisez pas pour des décisions sensibles.
• Capacité réduite : proposez une partie de la fonction, par exemple consulter des informations sans pouvoir les modifier, ou préparer une demande sans l’envoyer. Expliquez quelle étape reste en attente et ce qui sera nécessaire pour la mener à bien.
• Procédure manuelle : elle peut convenir si une procédure claire existe, si des responsables sont désignés et si un enregistrement est effectué ensuite. Sans ces contrôles, le travail manuel risque de créer des doublons et de devenir une source de données parallèle.
• Blocage temporaire : il est préférable lorsque l’opération ne peut être exécutée en toute sécurité ou vérifiée ultérieurement. Limitez l’action concernée, pas nécessairement toute l’application.

Avant d’autoriser les écritures différées, précisez comment les opérations sont identifiées, stockées et relancées, quelle réponse est présentée à la personne et comment les conflits sont résolus. En l’absence de règle sûre, conserver l’intention sous forme de brouillon est généralement moins risqué que d’affirmer que l’action a été effectuée.

Bloquer les opérations susceptibles de rendre les données incohérentes

La question essentielle est de savoir si le système peut distinguer une requête qui n’a pas été reçue, une requête traitée dont la réponse a été perdue et une requête toujours en attente. Si ce n’est pas possible, répéter une opération sensible sans contrôle peut l’exécuter plusieurs fois. Les nouvelles tentatives doivent être limitées et adaptées au type de requête. Pour les actions qui ont des effets, il faut concevoir des mécanismes permettant de détecter les doublons et de consulter le résultat avant de recommencer.

Suspendez ou limitez une opération lorsqu’elle :

• nécessite une validation indisponible et qu’aucune règle de remplacement approuvée n’existe ;
• peut produire un effet irréversible ou difficile à compenser ;
• ne permet pas de savoir si une demande précédente a été menée à bien ;
• repose sur une donnée stockée qui a dépassé le seuil de fraîcheur acceptable pour cette décision.

Si une procédure de compensation existe, indiquez qui peut la lancer et comment elle est consignée. Ne partez pas du principe qu’une action compensatoire annule l’effet initial : elle peut nécessiter l’intervention des équipes opérationnelles, un examen ou une communication à la personne concernée. La politique doit tenir compte de ces limites.

Expliquer les limites et rétablir le service de manière contrôlée

Le message doit préciser quelle fonction est limitée, ce que la personne peut faire immédiatement et si elle devra répéter une étape. Évitez d’affirmer « l’opération est terminée » lorsqu’une demande a seulement été enregistrée en attente. Ne promettez pas non plus un délai de rétablissement que l’équipe ne peut garantir. Un état clairement expliqué limite les nouvelles tentatives impulsives et les demandes évitables adressées au support.

Lorsque la dépendance est rétablie, ne relancez pas aveuglément tout ce qui était en attente. Vérifiez l’état réel, traitez les opérations selon un ordre défini, détectez les doublons et consignez les résultats. En cas de conflit entre des modifications, appliquez une règle convenue — par exemple, effectuer une vérification avant tout remplacement — et conservez suffisamment de traces pour examiner les écarts.

Le rétablissement doit reposer sur des conditions observables. Vérifiez que la dépendance répond de manière stable, que ses résultats sont valides et que l’application peut mener le parcours normal à son terme. Retirez ensuite les restrictions progressivement et de façon contrôlée. Si les symptômes réapparaissent, le système doit pouvoir limiter de nouveau la fonction au lieu d’alterner sans cesse entre disponibilité et panne.

Tester les décisions et mesurer les résultats

Une politique de dégradation qui n’existe que dans un document ne prouve pas que l’application l’applique correctement. Simulez la panne, une latence élevée, des erreurs partielles et des réponses tardives pour chaque dépendance importante. Vérifiez l’écran, mais aussi les journaux, les opérations en attente et le comportement face aux doublons. Incluez des tests de rétablissement et de rapprochement, et pas seulement des tests d’activation du mode limité.

Examinez conjointement les indicateurs techniques et métier. Parmi les indicateurs techniques figurent les erreurs et les temps de réponse de la dépendance, le volume de nouvelles tentatives et la durée de la dégradation. Les indicateurs métier comprennent les opérations bloquées, les demandes en attente, les conflits détectés et les cas nécessitant une intervention manuelle. Une meilleure disponibilité ne suffit pas si elle augmente les transactions incohérentes ou la charge du support.

Pour chaque fonction, répondez et validez ces quatre questions : que maintient-on, que limite-t-on, que bloque-t-on et comment confirme-t-on le rétablissement ? Si l’équipe ne peut pas y répondre, sa stratégie n’est pas encore complète. La dégradation contrôlée transforme une panne inévitable en une décision explicite : préserver la valeur qui reste sûre et reporter ce qui dépend d’une garantie temporairement indisponible.