Et si une brique devient indisponible ?

La concentration change la configuration du risque

La Bank of England souligne que la dépendance à un petit nombre de fournisseurs d'IA peut affecter les services financiers en cas de défaillance de ceux-ci, surtout si la migration vers des alternatives est difficile. L'analyse porte sur le système financier ; elle ne démontre pas que toute dépendance partagée produira une défaillance systémique.

Pour l'équipe produit, la question peut être très concrète : quels parcours dépendent de cette consultation, de ce fournisseur ou de ce modèle ? Un inventaire des fournisseurs ne suffit pas s'il ne révèle pas les services qui cessent de fonctionner lorsqu'une pièce s'arrête.

Référence : Bank of England · IA et stabilité financière ↗

Une défaillance n’a pas toujours la même conséquence

Une recherche d'information peut être reportée. Une opération de paiement peut être en attente de confirmation et ne doit pas être relancée sans vérifier son état. Un échec de signature peut empêcher la finalisation de la formalisation, même si d'autres parties du dossier restent disponibles.

Ces situations appellent des réponses différentes. Le contrat doit rendre visible s'il y a eu refus, indisponibilité, expiration ou résultat inconnu. L'interface suit cette distinction afin que l'utilisateur ne soit pas incité à répéter une action qui a peut-être déjà eu lieu.

Alternative ne veut pas dire équivalence

Un adaptateur peut regrouper les particularités d'un fournisseur, mais ne garantit pas un remplacement immédiat. Une alternative doit fournir les champs nécessaires, en préserver la signification et répondre aux exigences opérationnelles. L'authentification, les limites, les délais et les effets peuvent aussi changer.

Tester une alternative signifie vérifier le parcours complet. Une réponse techniquement valide peut avoir une sémantique différente. Le choix d’un fournisseur doit tenir compte de ce coût de changement et des conditions réelles d’activation d’une voie secondaire.

Mesurez la récupération comme un travail produit

Un exercice utile consiste à choisir une dépendance et à observer comment le parcours se comporte sans elle. Qui est prévenu ? Le dossier peut-il attendre ? Quelle action est bloquée ? Comment le travail revient-il dans le flux une fois le service rétabli ?

Cet échange rapproche architecture, exploitation et service client. L'objectif n'est pas de promettre l'absence de défaillances, mais d'éviter les états ambigus et la reprise improvisée. La continuité doit avoir des responsables et des critères de retour, tout comme une fonctionnalité a des critères d'acceptation.