B Bastien Gauthier
CV
Étude de cas · Résilience produit · SQLI (régie)

Mode dégradé : continuité de service

Pilotage d'un mode dégradé pour permettre au e-commerce de continuer à vendre malgré l'indisponibilité du SI aéroportuaire ou du système de tarification parking.

Retour aux projets
Résilience Continuité de service Adobe Commerce Temporisation Reprise SI aéroportuaire

Le défi

Permettre au e-commerce de continuer à vendre même quand le SI de l'aéroport ou le système de tarification parking devient indisponible pendant plusieurs heures.

Le sujet n'était pas simplement d'afficher un message d'erreur plus propre. Il fallait maintenir la prise de commande avec des restrictions, temporiser l'envoi des réservations, gérer leur reprise une fois les services rétablis, bloquer certaines actions comme la modification ou l'annulation, et garder un cadre suffisamment sûr pour que la réservation reste réellement exploitable à l'arrivée du client.

La tension à arbitrer Comment rendre le e-commerce aussi autonome que possible quand le SI tombe, sans prendre de réservation ingérable, sans perdre inutilement du chiffre d'affaires, et sans transformer chaque incident en crise manuelle ?

Mon approche

J'ai piloté ce sujet comme un vrai chantier produit de résilience, avec une logique très opérationnelle : quoi activer, dans quel cas, avec quelles restrictions, et comment reprendre proprement après incident. Concrètement :

  • Découpage par blocs indépendants : séparation du mode dégradé en petits modules activables ou non selon la nature exacte du problème côté SI.
  • Temporisation et reprise : cadrage de la prise de commande, du stockage temporaire, puis du réenvoi des réservations une fois le service de nouveau disponible.
  • Règles métier spécifiques : disponibilité restreinte en mode dégradé pour laisser le temps au SI de reprendre avant le début réel de la réservation.
  • Gestion client et support : messages explicites, blocage des modifications et annulations, et récupération des emails des clients à recontacter dans un groupe éphémère compatible RGPD.
  • Orchestration de flux : choix du flux API à utiliser selon les indisponibilités rencontrées, sans basculer pour autant sur le service final en direct.

Décisions produit clés

Trois arbitrages structurants qui ont rendu le mode dégradé exploitable, activable plus finement et réellement utile pendant un incident long.

Continuer à vendre, mais avec un périmètre contrôlé

Décidé

Maintenir la prise de commande même en cas d'indisponibilité SI, mais avec des restrictions claires sur les disponibilités et sur certaines actions client.

Pourquoi

Le but n'était pas de tout laisser passer coûte que coûte, mais de préserver la vente sans créer derrière des réservations intenables ou des promesses impossibles à tenir.

Découper le mode dégradé en blocs activables indépendamment

Décidé

Construire le dispositif en petits blocs indépendants pour pouvoir activer seulement ce qui est nécessaire selon le type de difficulté rencontrée côté SI.

Pourquoi

Un incident SI n'a pas toujours le même impact. Ce découpage rendait le système plus agile et évitait d'activer un mode trop large quand seule une partie du problème devait être traitée.

Prévoir la reprise dès le départ, pas après la panne

Décidé

Définir dès le cadrage comment les commandes et réservations seraient reprises et transmises une fois les services de nouveau disponibles.

Pourquoi

Sans logique de reprise, un mode dégradé ne fait que déplacer le problème. La valeur venait justement de la capacité à absorber l'incident puis à revenir proprement dans le flux nominal.

Indicateurs d'impact

Vente maintenue Prise de commande conservée malgré l'indisponibilité de services critiques
CA protégé Perte de chiffre d'affaires limitée en cas de panne ou d'attaque SI
Confiance renforcée Un e-commerce plus résilient, plus autonome et plus fiable en situation dégradée
Schéma du mode dégradé e-commerce avec prise de commande maintenue, temporisation et reprise après rétablissement du service
Vue d'ensemble du mode dégradé, entre continuité de vente, restrictions temporaires, reprise et communication client.

Ce que ce projet prouve

  • Ce projet montre que je sais traiter la résilience comme un sujet produit complet, pas seulement comme un incident technique à contourner.
  • Il reflète aussi ma capacité à cadrer un système qui reste utile même quand le SI principal ne l'est plus, avec des restrictions compréhensibles et une logique de reprise pensée à l'avance.
  • Enfin, il illustre une manière de travailler très orientée run : protéger le chiffre d'affaires, limiter l'impact client et rendre l'outil plus fiable quand les systèmes autour deviennent instables.
Prochaine étape

Discutons de votre projet

Retour aux projets Me contacter