Lire un incident comme une chaîne de responsabilité
Cas documentés et scénarios pédagogiques
Un cas ne sert pas seulement à désigner un coupable. Il sert à voir les acteurs, la séquence, l’impact et la preuve disponible.
Sources et contexte de lecture
Sources primaires ou références publiées indiquées dans chaque cas · interprétations TENIR explicitement séparées des faits
Rendu public simplifié, lecture du 19 octobre 2026. KB3 : ligne de rendu doctrinale instituée et active. Elle rend le sens ; elle n’est pas le code, ni une constitution. KB2 : ligne antérieure. Ce site ne certifie aucune implémentation. Lire le statut détaillé →
Sur cette page
Comment lire un cas
Chaque fiche suit la même séquence :
Promesse du marché
↓
Achat ou intégration
↓
Délégation
↓
Décision ou action
↓
Incident
↓
Recherche du responsable
↓
Preuve disponible ou absenteLes faits publiés, les interprétations possibles et les questions ouvertes ne sont jamais confondus.
Cas 1 — Quand une réponse devient une promesse
Secteur : transport aérien · relation client
Un assistant conversationnel a fourni à un client une information erronée concernant une possibilité de remboursement. Le client a tenté de s’appuyer sur cette information dans sa relation avec la compagnie.
La question n’est pas seulement de savoir si la réponse était fausse. Il faut aussi demander : l’organisation pouvait-elle établir quelles règles, données ou limites avaient encadré cette réponse ? Le client pouvait-il raisonnablement la recevoir comme une information officielle ?
À retenir : une réponse automatisée peut être reçue comme un engagement de l’entreprise, même lorsqu’elle n’a pas été rédigée ou validée par une personne.
Trois questions :
- Les réponses qui annoncent un droit, un prix ou un remboursement sont-elles reliées à une source officielle ?
- Qui peut corriger une réponse fausse et dans quel délai ?
- L’organisation peut-elle retrouver la version de la règle et de l’assistant qui ont produit la réponse ?
Statut : cas documenté — chatbot fournissant une information erronée, et non agent autonome exécutant une transaction.
Source : Civil Resolution Tribunal, Moffatt v. Air Canada, 2024 BCCRT 149. Cette décision ne permet pas, à elle seule, de conclure quelle technologie exacte se trouvait derrière l’assistant.
Cas 2 — Quand personne ne sait si l’opération est partie
Statut : scénario pédagogique — aucun règlement bancaire réel démontré.
Secteur : banque · assurance · paiement
Une intention est formulée. Une commande est envoyée. La réponse du fournisseur disparaît. L’organisation doit décider quoi faire alors qu’elle ne sait pas si l’effet externe a eu lieu.
Le réflexe le plus dangereux consiste à transformer le silence en échec, puis à répéter l’opération. Une autorisation prouve qu’une action pouvait être demandée. Elle ne prouve pas que l’effet externe a eu lieu — ni qu’il n’a pas eu lieu.
Les joueurs : système d’orchestration, propriétaire du compte, moteur de politique, fournisseur de règlement, équipe opérationnelle, responsable du risque, auditeur et bénéficiaire.
À examiner : l’identité unique de l’opération, l’état réel auprès du fournisseur, la trace de la première tentative et l’autorité qui décide de reprendre, suspendre ou réconcilier.
Limite : ce scénario ne certifie aucun règlement bancaire réel et ne remplace pas un test autorisé chez un fournisseur.
Cas 3 — Le marché se renvoie la chaîne
Statut : matrice d’analyse — à compléter par des sources avant toute présentation comme cas réel.
Secteur : intégration IA · gouvernance fournisseur
Le fournisseur indique que le client reste responsable de l’usage. L’intégrateur indique qu’il a suivi les spécifications. L’équipe métier indique qu’elle s’est appuyée sur la solution. La personne affectée reçoit pourtant une conséquence unique.
Question centrale : qui possède la chaîne de preuve reliant la promesse commerciale, le mandat, la configuration, l’action, l’effet et la réparation ?
Ce cas doit être complété par des sources et exemples vérifiables avant toute publication comme « cas réel ». En attendant, il sert de matrice d’analyse et non d’allégation factuelle.
Une règle de lecture
Ce qu’un cas permet d’affirmer doit rester plus étroit que ce que le marché permet d’imaginer.
Voir les acteurs qui composent chaque chaîne →
Démonstration · 1 min 15
Quand l’agent ne sait plus si le paiement est parti.
Un seul scénario pour comprendre la frontière : l’action est préparée, la réponse disparaît, puis le système doit choisir entre répéter, suspendre ou réconcilier.
Démonstration pédagogique · aucun paiement réel · données fictives.
Replay d’un cas
La responsabilité se perd dans la séquence.
Le marché vend une capacité. L’incident révèle la chaîne qu’il fallait posséder.
Carte sectorielle maître
Banque & assurance
Un virement peut être autorisé sans que son effet externe soit confirmé. C’est dans cet intervalle que la responsabilité doit tenir.
Séquence des événements
Cadrage
Périmètre, sources et propriétaires métier / technique.
Une question trop large produit une preuve inutilisable.Intention
L’agent prépare ou propose le virement.
Intention légitime ≠ autorisation de toute méthode.Admission
Le moteur de contrôle applique les règles d’admission.
Autorisation ≠ sûreté ni effet externe.Commande
La demande est envoyée au système de règlement.
La frontière entre décision et effet est franchie.Réponse perdue
Le fournisseur peut avoir reçu la demande ; le canal de retour est interrompu.
Le résultat devient UNKNOWN.HOLD
La réémission automatique est bloquée.
Un timeout ne doit jamais autoriser une reprise par défaut.Réconciliation
L’état externe est recherché avant toute suite.
Sans preuve suffisante, l’effet reste non démontré.Joueurs et preuves
Agent IA+
Rôle : Prépare ou propose la trajectoire.
Preuve attendue : Intention, version, contexte et outils sollicités.
Moteur de contrôle+
Rôle : Applique les règles d’admission.
Preuve attendue : Politique active, autorité, epoch et décision.
Système de règlement+
Rôle : Représente le fournisseur externe.
Preuve attendue : Réception, état de l’opération et identifiant externe.
Opérateur+
Rôle : Intervient quand l’état reste ambigu.
Preuve attendue : Responsable, échéance, décision et motif d’escalade.
Banque / fintech+
Rôle : Porte le cadre organisationnel et la réponse au client.
Preuve attendue : Mandat, procédures, réconciliation et réparation.
Personne impactée+
Rôle : Subit, conteste ou attend l’effet.
Preuve attendue : Information compréhensible, voie de recours et réponse traçable.
Couche expertInvariants, défense et verdicts+
Invariants et règles critiques
Reprise sous incertitude
Aucune nouvelle tentative susceptible de reproduire l’effet sans preuve de non-exécution ou idempotence qualifiée.
Échec évité : Double règlement pour une seule intention.Traçabilité du HOLD
Conserver opération, tentative, cause, responsable, échéance et transitions.
Échec évité : Une suspension sans propriétaire devient une dette invisible.Autorité d’exécution
L’effet doit être lié à une autorité active, son epoch et ses conditions de consommation.
Échec évité : Un reçu de décision est pris pour une preuve d’effet externe.Défense en profondeur
- 1 · LégitimitéCadre, mandat, règles métier et périmètre réglementaire.
- 2 · GouvernanceRôles, permissions, propriétaires et politique d’escalade.
- 3 · Protection runtimeInterception, idempotence, séparation et statut HOLD.
- 4 · RéconciliationVérification factuelle auprès du système tiers.
- 5 · Preuve & réparationDossier, recours, responsabilité et correction de l’effet.
Verdict de restitution
Fonctionnement démontré dans le périmètre de test défini.
Ambiguïté d’état : arrêt et réconciliation obligatoires.
La preuve disponible ne permet pas de conclure sur la non-répétition ou l’effet externe.
Modèle pédagogique TENIR Labs · DORA / EU AI Act à qualifier selon le périmètre · aucun règlement bancaire réel démontré.
Carte sectorielle maître
Transport & mobilité critique
Dans un système de transport critique, une réponse absente ne constitue jamais une preuve d’absence d’effet.
Séquence des événements
Intention
L’agent identifie une perturbation et propose une modification.
Une intention naturelle n’est pas encore un ordre physique.Admission
Autorité active, règles d’exploitation et marges de sécurité.
Une action utile peut dépasser les habilitations ou les séparations minimales.Commande
API de régulation ou ordre de modification avec clé unique.
Une clé absente ouvre la voie aux ordres contradictoires.Système critique
ATC, signalisation, gestionnaire de flotte ou infrastructure.
L’effet modifie l’ordonnancement physique réel.Réponse ambiguë
ACK perdu via ACARS, GSM-R, 5G-V2X ou réseau sol.
Le rejeu aveugle peut créer un conflit de trajectoire.HOLD
Gel de la décision sous statut UNKNOWN STATE.
Le timeout ne peut pas être interprété comme un échec.Réconciliation
Capteurs, radar, télémétrie ou registre d’infrastructure.
Sans attestation de l’état réel, la reprise reste interdite.Sortie
ACCEPT, RETRY contrôlé, déviation ou arrêt.
L’ambiguïté persistante impose l’escalade humaine.Joueurs et preuves
Agent IA+
Rôle : Détecte une perturbation et propose une trajectoire.
Preuve attendue : Contexte, intention, modèle, outils et clé d’exécution.
Porte G-03+
Rôle : Vérifie l’autorité et les contraintes de sécurité.
Preuve attendue : Habilitation, zone, marges de séparation et politique active.
Porte G-06 ONCE+
Rôle : Associe la commande à une exécution unique.
Preuve attendue : Identifiant immuable et contrat d’idempotence.
Système critique+
Rôle : Reçoit ou applique l’ordre sur l’infrastructure.
Preuve attendue : Accusé de réception, état inscrit et journal système.
Opérateur humain+
Rôle : Décide en procédure dégradée si l’état reste ambigu.
Preuve attendue : Escalade, décision, heure, motif et sortie de HOLD.
Usager impacté+
Rôle : Subit le retard, la déviation ou la décision de sécurité.
Preuve attendue : Information, continuité de service et voie de recours.
Couche expertInvariants, défense et verdicts+
Invariants et règles critiques
Reprise sous incertitude
Aucune nouvelle commande sans attestation de l’état réel de l’infrastructure.
Échec évité : Deux ordres contradictoires ou une trajectoire incohérente.Traçabilité du HOLD
L’agent ne peut pas déduire l’échec ni réémettre aveuglément une commande ambiguë.
Échec évité : Le système repart sans savoir ce qui s’est produit.Escalade de sûreté
Une ambiguïté persistante déclenche une procédure dégradée et un opérateur habilité.
Échec évité : La décision critique reste dans une boucle autonome sans sortie sûre.Défense en profondeur
- 1 · SûretéContraintes d’exploitation, séparation et habilitations.
- 2 · AdmissionAutorité active, zone, fenêtre et politique de décision.
- 3 · Exécution uniqueClé immuable, idempotence et contrôle runtime.
- 4 · État réelRadar, capteur, télémétrie ou registre d’infrastructure.
- 5 · DégradéDéviation, arrêt, contrôleur humain et réparation.
Verdict de restitution
L’ordre est confirmé comme appliqué et l’état local est mis à jour.
La non-réception est démontrée et la même clé d’exécution protège la reprise.
L’ambiguïté persiste : procédure dégradée et escalade immédiate.
Matrice pédagogique TENIR Labs · domaines aérien, ferroviaire et flotte autonome à qualifier selon le système concerné · ne constitue pas une certification de sûreté.