quand le modèle se trompe et qu'un client en subit les conséquences

Une famille de cinq personnes atterrit à 23 h après neuf heures de vol. Leur chambre d'hôtel n'existe pas. Pas « pas encore prête » : disparue. L'établissement l'a vendue deux fois, et le modèle d'overbooking a décidé que leur réservation était celle à sacrifier. Aucun humain n'a pris cette décision en temps réel. Un algorithme l'a fait, quelques heures plus tôt, sur la base d'une prévision de no-show qui s'est révélée fausse.

Voilà à quoi ressemble le risque modèle dans le voyage et l'hôtellerie : pas un titre sur une IA devenue folle, mais une erreur de calcul discrète qui se transforme en client debout devant une réception à minuit, sans rien pour dormir.

Cette leçon retrace trois schémas de défaillance réels pour vous permettre de classer le risque IA par sévérité (quelle est la gravité du préjudice) et par blast radius (combien de réservations, de clients ou de lignes sont touchés d'un coup).

SchémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → 1 : le modèle d'overbooking qui compte mal les no-shows

Compagnies aériennes et hôtels pratiquent volontairement l'overbooking. C'est une pratique légitime, vieille de plusieurs décennies : un certain pourcentage de clients ne se présentera pas, donc vendre légèrement au-delà de la capacité maximise le revenu. Le calcul est un problème de prévision, et les modèles de prévision peuvent se tromper.

Comment ça casse : un modèle de prédiction de no-show est entraîné sur des schémas historiques (saison, jour de la semaine, canal de réservation, délai de réservation). Si le schéma change, par exemple un nouvel avis aux voyageurs qui modifie les comportements d'annulation, ou un groupe de clients corporate qui se comporte différemment des voyageurs loisir, le modèle continue de prévoir le monde d'hier. L'overbooking est calibré trop agressivement, et des clients payants, en droit d'être enregistrés, se voient refuser l'embarquement ou leur chambre.

Sévérité : moyenne à élevée. Le refus d'embarquement involontaire (être débarqué d'un vol pour lequel vous avez un billet valide) et les clients hôteliers « walkés » (relogés dans un autre établissement, souvent aux frais de l'hôtel) crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éent des dommages financiers et réputationnels réels. Le Department of Transportation américain (DOT) impose aux compagnies d'indemniser les passagers refusés involontairement, actuellement jusqu'à 4x le prix du billet avec un plafond fixé par la réglementation fédérale, en 2024 (source : transportation.gov). Dans l'UE, le règlement CE 261/2004 impose une indemnisation forfaitaire (jusqu'à 600 € par passager selon la distance du vol) en cas de refus d'embarquement.

Blast radius : un vol ou un établissement, mais répété chaque jour sur l'ensemble du réseau. Un modèle systématiquement mal calibré ne provoque pas une mauvaise nuit, il en provoque des centaines, silencieusement, jusqu'à ce que quelqu'un audite le schéma.

Le garde-fou : back-testez le modèle de no-show contre les résultats réalisés chaque semaine, pas chaque trimestre. Fixez un plafond dur de pourcentage d'overbooking que le modèle ne peut pas dépasser, quel que soit son score de confiance. Exigez une validation humaine lorsque le modèle recommande un overbooking au-delà d'un seuil (par exemple plus de 8 pour cent au-dessus de la capacité, à titre d'illustration, ce n'est pas une norme sectorielle universelle).

Schéma 2 : le chatbot qui invente des politiques de remboursement

Le chatbot d'Air Canada a indiqué à un client qu'il pouvait demander une réduction tarifaire pour deuil après son vol, en contradiction avec la politique réelle de la compagnie. Le client a porté plainte. En 2024, un tribunal canadien a jugé Air Canada responsable de la fausse déclaration de son chatbot (source : largement rapporté, notamment par CBC News). C'est désormais un cas d'école dans les formations à la gouvernance de l'IA.

Pourquoi cela arrive : les grands modèles de langage (LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →, systèmes d'IA entraînés à générer du texte proche de l'humain) produisent des réponses plausibles même lorsqu'ils n'ont pas la politique réelle dans leur contexte. On appelle cela l'hallucinationhallucinationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète → : le modèle produit un fait fabriqué, avec assurance. Un chatbot sans ancrage par retrieval (aller chercher le document de politique réel au moment de la réponse, plutôt que de s'appuyer sur la mémoire d'entraînement du modèle) est une machine à fabriquer déguisée en agent du service client.

Sévérité : faible par incident, mais juridiquement contraignante. Tribunaux et régulateurs ont signalé que les entreprises sont responsables de ce que disent leurs agents IA, exactement comme elles le sont de ce que dit un salarié. Les paroles du chatbot sont traitées comme celles de l'entreprise.

Blast radius : potentiellement énorme. Un template de prompt défectueux ou une base de connaissances obsolète peut générer la même mauvaise réponse à des milliers de clients simultanément, avant que quiconque s'en aperçoive.

Le garde-fou :

• Ancrez le chatbot dans une base de politiques vivante et versionnée (retrieval-augmented generationretrieval-augmented generationMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète →, RAG), pas dans l'entraînement général du modèle.
• Loguez chaque réponse adressée à un client pour audit.
• Ajoutez une barrière de confiance : si le modèle répond à une question de remboursement, d'indemnisation ou de sécurité, routez vers une revue humaine ou citez le document source mot pour mot au lieu de le paraphraser.
• Indiquez aux utilisateurs qu'ils parlent à une IA, exigence de l'EU AI Act pour de nombreux systèmes d'interaction client à partir des phases de déploiement de 2026 (source : EU AI Act).

Schéma 3 : le modèle d'optimisation d'itinéraires qui échoue pendant un ouragan

Croisiéristes, compagnies aériennes et prestataires logistiques utilisent des modèles d'optimisation d'itinéraires et de capacité pour repositionner des avions, réacheminer des itinéraires de croisière et rééquilibrer la demande hôtelière pendant les perturbations. Ces modèles sont entraînés majoritairement sur des conditions d'exploitation normales.

Comment ça casse : un ouragan, un nuage de cendres volcaniques ou une fermeture géopolitique d'espace aérien est un événement out-of-distribution, une situation sans équivalent dans les données d'entraînement. Un modèle optimisé pour une « perturbation typique » (une tempête qui retarde un hub pendant une journée) peut produire des recommandations dangereusement fausses lors d'un événement systémique (une tempête qui ferme trois hubs pendant une semaine), parce qu'il n'a jamais vu cette échelle de défaillances corrélées.

Sévérité : élevée. C'est le schéma avec le lien le plus direct à la sécurité physique des clients : passagers bloqués, équipages dépassant leurs limites de temps de service, navires de croisière réacheminés vers de plus mauvaises conditions météo parce que le modèle a sous-pondéré une tempête en intensification rapide.

Blast radius : à l'échelle du réseau et compressé dans le temps. Contrairement au cas du chatbot, il n'y a pas le temps de corriger discrètement. Les décisions doivent être prises en quelques heures.

Le garde-fou : maintenez un protocole de reprise manuelle armé par des experts des opérations, testé par des exercices sur table réguliers (simulations de crise), et pas seulement écrit dans un manuel. Exigez que le modèle produise un intervalle de confiance et signale quand les conditions réelles sortent de sa distribution d'entraînement. Le NIST AI Risk Management Framework (framework volontaire américain d'identification et d'atténuation des risques IA) recommande explicitement ce type de monitoring out-of-distribution.

Construire une grille simple sévérité × blast radius

Vous n'avez pas besoin d'un modèle complexe pour trier le risque IA. Une grille 2x2 suffit pour une présentation au conseil ou un audit interne :

Application :

• Mauvaise calibration de l'overbooking : sévérité moyenne, blast radius élevé (répétition quotidienne) → se situe entre le haut-droite et le bas-droite, surveiller de près avec des plafonds durs.
• Hallucination de chatbot : sévérité faible par occurrence, blast radius potentiellement élevé → seuils d'alerte plus ancrage obligatoire.
• Optimisation d'itinéraires pendant un ouragan : sévérité élevée, blast radius élevé → kill switch et reprise humaine, non négociables.

Un « kill switch » signifie ici une capacité opérationnelle à revenir instantanément à un routage manuel ou à une version stable antérieure du modèle, ce n'est pas une métaphore. Si votre équipe ne peut pas décrire comment elle désactiverait un modèle en quelques minutes, le garde-fou n'existe pas.

Les instances de gouvernance à connaître

• DOT (US Department of Transportation) : applique la protection des consommateurs du transport aérien, y compris l'indemnisation en cas de refus d'embarquement.
• EU AI Act : première réglementation complète sur l'IA, avec une entrée en application progressive de 2026 à 2027, qui classe les systèmes d'IA par niveau de risque ; les chatbots en contact client et les systèmes logistiques ayant un impact sur la sécurité sont soumis à des obligations de transparence et de documentation.
• NIST AI RMF : framework volontaire américain, largement adopté comme socle de gouvernance IA en entreprise, y compris hors des États-Unis.
• IATA (International Air Transport Association) : publie des guides opérationnels que les compagnies utilisent souvent comme référence pour valider les systèmes automatisés de réponse aux perturbations.

🎬 [VIDEO: "The Air Canada Chatbot Lawsuit Explained" - youtube.com - cherchez les analyses legal-tech récentes expliquant comment les tribunaux traitent les déclarations de chatbots IA comme des engagements contraignants pour l'entreprise]

Points clés

• Classez chaque système d'IA déployé par sévérité (préjudice financier / juridique / physique) et blast radius (combien de clients, de réservations ou de lignes il peut affecter avant qu'un humain s'en aperçoive).
• Les modèles d'overbooking échouent par dérive lente, pas par plantage spectaculaire. Back-testez chaque semaine et plafonnez l'overbooking indépendamment de la confiance du modèle.
• Les chatbots doivent être ancrés dans des documents de politique vivants (RAG), pas dans la mémoire d'entraînement. Les tribunaux traitent déjà les déclarations de chatbot comme des engagements de l'entreprise.
• Les modèles de perturbation systémique (ouragans, événements à l'échelle du réseau) exigent des protocoles de reprise manuelle testés, car les défaillances out-of-distribution surviennent précisément quand la sécurité des clients est en jeu.
• Appuyez-vous sur des ancrages réglementaires réels (DOT, EU AI Act, NIST AI RMF) pour construire votre gouvernance interne, pas sur un vocabulaire générique de « bonnes pratiques ».