Qu'est-ce que la dégradation gracieuse lorsqu'une dépendance échoue ?

Question

Accepted Answer

**La dégradation gracieuse** signifie que lorsqu'une dépendance échoue, le système **maintient le flux principal en fonctionnement** en fournissant une expérience réduite ou partielle au lieu de retourner une erreur. L'objectif est d'**échouer doucement**, non pas échouer brutalement : une page dégradée vaut mieux qu'une 500.

## Techniques

- **Échouer doucement** — lorsqu'une dépendance est indisponible, servir des données **en cache, partielles, ou par défaut** plutôt que de retourner une erreur. Un résultat obsolète mais présent vaut généralement mieux que rien.
- **Désactiver via feature-flag les chemins non critiques** — désactiver les recommandations, l'analytique, ou les widgets élaborés afin qu'une défaillance là ne puisse pas casser la page principale.
- **Timeouts + fallbacks** — ne jamais attendre indéfiniment une dépendance lente ; interrompre et basculer vers une valeur ou un chemin de secours.
- **Isoler les défaillances (bulkheads)** — partitionner les ressources (thread pools, connection pools) par dépendance afin qu'un service défaillant ne puisse pas épuiser tout et traîner le reste vers le bas.
- **Protéger le flux principal** — identifier le chemin qui doit fonctionner (navigation, paiement) et s'assurer que les fonctionnalités non essentielles ne peuvent jamais le faire tomber.

## Exemple : le backend de recherche est indisponible

```text
BAD  (fail hard):
  search() → backend timeout → throw → user sees HTTP 500 (whole page dead)

GOOD (fail soft):
  result = search()
         catch timeout → return cached_results OR empty + notice
  page renders:
    [ "Showing recent results — live search is temporarily unavailable." ]
    + cached listings, working nav, working checkout
  → user keeps browsing; core flow intact
```

Au lieu d'une page morte, l'utilisateur obtient les résultats en cache et un petit avis, tandis que la navigation et le paiement continuent de fonctionner. La défaillance est confinée à une seule fonctionnalité.

## Pourquoi c'est important

Les dépendances *vont* échouer — APIs tierces, clusters de recherche, services de recommandation. Sans dégradation gracieuse, n'importe quelle défaillance s'en cascade dans une panne complète. Concevoir pour échouer doucement (données en cache/partielles/par défaut), désactiver les chemins non critiques via feature-flag, interrompre avec des fallbacks, et isoler les défaillances avec des bulkheads maintient le produit utilisable durant les défaillances partielles — c'est la différence entre un petit problème et un incident majeur.