Réponse.

Dans l'histoire du développement des systèmes informatiques distribués, les questions de gestion des erreurs et des scénarios de défaillance ont longtemps joué un rôle secondaire, cédant la place à la logique métier. Cependant, la croissance de l'échelle et la complexité de l'infrastructure ont montré au fil du temps que des scénarios de gestion des erreurs mal élaborés peuvent conduire à des pannes massives et à des pertes de données.

Le problème réside dans le fait que les systèmes complexes rencontrent de nombreux types de pannes : de l'indisponibilité de certains services à l'incohérence des données ou aux défaillances partielles des canaux de communication. Souvent, les clients considèrent uniquement les « défaillances » comme des pannes évidentes (par exemple, le serveur est indisponible), ignorant les chaînes d'erreurs interservices ou la dégradation de l'expérience utilisateur.

Une solution efficace repose sur une approche systémique :

Détection de tous les points de défaillance possibles.
Élaboration de scénarios exhaustifs de leur émergence en collaboration avec des architectes, des QA, des concepteurs et des ingénieurs d'exploitation.
Conformité du comportement du système avec l'entreprise (par exemple, peut-on retarder les commandes ou est-il nécessaire de mettre en cache les opérations).
Documentation précise de tous les types de messages d'erreur et des parcours de traitement.

Caractéristiques clés :

Gestion non seulement des échecs fatals, mais également des échecs légers/flottants (par exemple, une indisponibilité temporaire d'un service externe).
Inclusion de scénarios de dégradation de l'UI et de la fonctionnalité.
Distinction entre erreurs métier et défaillances techniques à toutes les étapes du traitement des exigences.

Questions pièges.

Quelle est la différence entre une exception au niveau de l'application et une exception au niveau de l'infrastructure ?

Très souvent, les candidats confondent les erreurs métier (par exemple, « utilisateur non trouvé ») avec des défaillances réelles (par exemple, « base de données indisponible »). L'application doit toujours faire une distinction claire entre les deux types d'exceptions et prévoir différentes stratégies de gestion (rollback, notifications, alerting).

Quels scénarios de défaillance doivent être modélisés pour une API interne, si elle n'est pas publique ?

Les scénarios de défaillance sont pertinents pour toutes les API : même si l'API est interne, des pannes peuvent toujours se produire (même à l'intérieur d'un même contour d'automatisation), et elles doivent être clairement modélisées pour fonctionner correctement avec des données inexactes/absentes.

Le système doit-il cacher toutes les erreurs à l'utilisateur pour maximiser l'UX ?

Non, la dissimulation absolue des erreurs conduit à une désinformation de l'utilisateur. Il est important de trouver un équilibre entre l'informativité (pour que l'utilisateur comprenne quoi faire ensuite) et la sécurité (sans révéler les détails de l'implémentation).

Erreurs typiques et anti-patterns

Gestion non formalisée des pannes (attrapages laissés « par défaut »).
Absence de scénarios de dégradation en cas de pannes partielles (dans le cas des microservices - un panier non fonctionnel bloque complètement le processus de commande).
Ignorer l'accumulation de pannes « silencieuses » (pas d'alerting/monitoring sur les situations exceptionnelles).

Exemple de la vie réelle

Cas négatif : Dans un grand projet e-commerce, un analyste système a laissé la gestion de toutes les erreurs réseau à l'architecture. Lors de mises à jour d'urgence et de la défaillance du service de messagerie, le système n'envoyait pas d'alertes concernant les commandes, et les utilisateurs ne comprenaient pas si leurs commandes avaient été créées.

Avantages :

Simplification de la description des exigences.

Inconvénients :

Perte de données (impossible de prouver la création d'une commande).
Les coûts de support ont augmenté après le lancement du produit.

Cas positif : L'analyste système, en collaboration avec l'architecte, a modélisé des scénarios distincts pour chaque service critique : l'indisponibilité de la file d'attente de courriers, les coupures de passerelles de paiement, la dégradation du service de recherche. Des messages conviviaux pour les clients ont été rédigés.