United Airlines a discrètement mis à jour ses conditions générales pour y glisser une clause explicite : les agents IA n’ont pas le droit de réserver des billets à la place des voyageurs. Aucun communiqué de presse, aucune annonce officielle — juste une mise à jour que quelqu’un a repérée, postée sur Hacker News, et qui a généré 547 commentaires. Ce genre de réaction n’arrive pas par hasard.
Fin 2026, les agents IA autonomes ne sont plus de la science-fiction. Claude, GPT-4o, Gemini — avec les bons outils, ils peuvent ouvrir un navigateur, chercher des vols, comparer les prix et finaliser une réservation pendant que tu dors. La question n’est plus théorique.
Mais derrière cette clause se cache un vrai problème technique, pas juste une lubie juridique d’une grosse compagnie aérienne. Creusons.
TL;DR — United Airlines interdit les agents IA de réserver des vols à ta place, et la décision est compréhensible — mais techniquement inapplicable. Le vrai problème est l’absence totale de standard pour déléguer une autorisation à un agent IA. La clause dans les CGU est un pansement sur une plaie d’architecture.
Ce que fait concrètement un agent IA pour réserver un vol
Sous le capot, un agent qui réserve un billet utilise soit un navigateur headless (Playwright, Puppeteer), soit des function calls vers un MCP server qui expose des outils de voyage. L’instruction part de l’utilisateur — « réserve-moi un Paris–New York pour le 15 décembre, budget 800 € » —, l’agent décompose la tâche et exécute chaque étape : navigation, recherche, sélection, paiement. Propre sur le papier.
Le problème surgit à l’étape « paiement ». United — comme la quasi-totalité des compagnies aériennes — n’expose pas d’API publique avec des scopes granulaires. Pas de « autorise cet agent à dépenser jusqu’à X€ pour moi ». L’agent doit se connecter avec tes credentials, agir comme toi, et utiliser ta carte bancaire enregistrée — sans confirmation intermédiaire, sans aucune traçabilité de la délégation.
C’est exactement ce que les architectes de sécurité appellent un « confused deputy problem » : l’agent a les droits de l’humain, mais l’humain n’a pas nécessairement validé chaque action individuelle. Et quand quelque chose tourne mal — mauvaise date, mauvaise destination, annulation payante — personne n’est clairement responsable. Pas l’éditeur de l’IA, pas le voyageur, et certainement pas United.
Le vrai nœud : une chaîne d’autorisation cassée
Le framework conceptuel existe pourtant. OAuth représente le consentement délégué entre applications depuis quinze ans : quand une appli tierce accède à tes données Google, tu vois une popup qui liste exactement ce qu’elle peut faire. Tu consens explicitement. Un token signé prouve ce consentement. La chaîne est traçable, révocable, avec des scopes définis.
Rien de tel n’existe pour les agents IA agissant sur des plateformes tierces. Pas de scope « peut réserver un vol de moins de 800 € ». Pas de token qui expire après la transaction. Pas de validation humaine juste avant le paiement. L’agent a un accès total à ton compte — exactement le même qu’un attaquant qui aurait volé ta session. La différence légale entre les deux, du point de vue d’United, est mince.
Plusieurs initiatives tentent de combler ce vide : un draft « OAuth for Autonomous Agents » tourne à l’IETF, le W3C a des groupes de travail sur l’identité agentique, et MCP a posé des bases de délégation côté serveur. Mais rien n’est standardisé à ce jour. En attendant, les entreprises ont deux options : construire leurs propres solutions d’intégration, ou bloquer par défaut. United a choisi la deuxième.
DÉCOUVREZ NOS RÉALISATIONS
MyLaser (DT Systemes)
Site e-commerce avec configurateur de decoupe laser pour DT Systemes a Sainte-Luce-sur-Loire (44). Upload de fichiers .dxf et devis instantane.
Voir le projet →Techniquement, le ban est difficile à faire respecter
Distinguer un agent IA d’un humain dans un formulaire de réservation reste un problème partiellement non résolu. Les CAPTCHAs modernes analysent le comportement — mouvements de souris, timing des frappes, fingerprinting du navigateur —, mais les agents actuels les contournent de mieux en mieux, via simulation réaliste ou services tiers de résolution. L’User-Agent est falsifiable en deux lignes. Le trafic peut transiter par des IPs résidentielles. United ne peut pas détecter de manière fiable la présence d’un agent.
Ce que la clause construit, en revanche, c’est une base légale pour agir après coup : annuler une réservation suspecte, suspendre un compte, ou refuser un remboursement si un comportement automatisé est détecté rétrospectivement. C’est plus un outil de défense contractuelle qu’une barrière technique. Pragmatique — mais ça ne règle rien pour l’utilisateur qui veut déléguer sa recherche de vol de bonne foi.
Pour les équipes qui construisent des applications sur mesure intégrant des agents IA, c’est un signal concret : audite les CGU des plateformes tierces avant de déployer en production. Ce n’est pas glamour, mais c’est ce qui t’évite de livrer un outil que ton client ne pourra plus utiliser légalement au prochain renouvellement de contrat.
La distinction entre « l’agent a agi à ma place avec mon consentement » et « quelqu’un a usurpé mon compte » est quasi indiscernable pour une plateforme comme United. D’où la réaction de blocage par défaut plutôt que d’encadrement.
Ce que ça révèle sur la maturité réelle des agents IA
Le cas United illustre une tension structurelle : les agents IA autonomes se déploient plus vite que les standards qui devraient encadrer leurs interactions avec les systèmes existants. Les applications ont eu dix ans pour absorber OAuth et l’authentification déléguée. Les agents IA ont eu deux ans. L’écart se voit.
Le paradoxe, c’est que les compagnies aériennes auraient tout à gagner d’un écosystème d’agents bien cadré. Des agents qui monitorent les prix et rebookent automatiquement sur un vol moins cher. Des assistants qui gèrent les perturbations en temps réel. Tout ça est techniquement faisable — et les compagnies pourraient le proposer elles-mêmes via des APIs officielles avec des scopes granulaires. Ça demande de l’ingénierie, pas juste une clause dans des CGU.
Des acteurs plus agiles — OTAs, néo-compagnies, agrégateurs — pourraient se positionner comme « AI-native » et créer un avantage réel auprès des voyageurs d’affaires. Le secteur de l’e-commerce a vécu cette transition quand les marketplaces ont ouvert leurs APIs marchandes dans les années 2010 : les acteurs qui avaient investi tôt ont structuré le marché.
Le problème n’est pas que les agents IA réservent des vols. C’est qu’aucun standard ne prouve encore qu’ils en ont le droit.
Vers un standard d’autorisation pour les agents IA
La vraie solution, tout le monde dans la communauté IA le pressent, c’est un protocole d’authentification conçu spécifiquement pour les agents. OAuth était fait pour les applications. OIDC était fait pour les identités humaines. Il manque un équivalent pour représenter « l’agent X agit pour le compte de l’humain Y, avec les permissions Z, valables pour l’action T » — quelque chose de signé, de vérifiable, de révocable.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Des groupes de travail existent. Le Model Context Protocol pose des bases pour la délégation côté serveur. Des extensions OAuth pour agents autonomes circulent à l’IETF. Mais à ce stade, rien n’est finalisé ni adopté à grande échelle. Les développeurs qui déploient des agents en production naviguent dans un vide juridique et technique simultané — et les décisions comme celle d’United signalent que les grandes plateformes n’ont plus envie d’attendre.
Pour les développeurs, cela implique une discipline concrète : intégrer des mécanismes de confirmation humaine avant chaque action irréversible (« human-in-the-loop »), documenter explicitement les permissions utilisées, et mettre en place une traçabilité des actions de l’agent. Ce n’est pas un détail UX — c’est une nécessité légale, et les CGU d’United viennent de le rendre visible.
Mon avis : le ban d’United est une réaction compréhensible à un vide réel — et c’est précisément pour ça qu’il ne durera pas sous cette forme. Répondre à l’absence d’un standard d’autorisation agentique avec une clause CGU, c’est mettre un post-it sur un problème d’architecture. Ça fixe la douleur immédiate sans traiter la cause.
D’ici 2028, soit un standard émergera — et les grandes plateformes devront adapter leurs règles —, soit les acteurs qui auront construit leurs propres solutions d’intégration auront capté la part du marché des voyageurs qui automatisent leur quotidien. Dans les deux cas, la clause actuelle d’United sera dépassée.
La vraie question, si tu développes des outils qui s’appuient sur des plateformes tierces : sur quelles CGU repose ton architecture ? Et si elles changent demain matin, qu’est-ce qui s’effondre ? Ce n’est pas une réflexion réservée aux startups — c’est un point de fragilité que n’importe quelle équipe tech devrait auditer régulièrement.
