United bloque les agents IA non autorisés. Ce n’est pas “juste l’aérien”.
Tu bosses sur des agents IA entreprise qui doivent réserver, modifier, annuler, payer, créer des comptes, déposer des demandes dans un SaaS, bref agir dans des systèmes tiers. Et là, United Airlines envoie un message très clair : l’agent “perso” non autorisé, qui se connecte et fait des actions à ta place, n’est plus le bienvenu.
Le 11 novembre 2026, United a annoncé qu’elle allait restreindre l’accès à ses plateformes numériques (site et app), y compris indirectement via les agences de voyages et agrégateurs, pour interdire l’usage d’agents IA personnels tiers non autorisés pour chercher, réserver ou gérer des voyages. Source : communiqué United (united.mediaroom.com).
Ce qui est intéressant pour Lyon et la région, c’est que ce “blocage” ressemble à ce que tu vas rencontrer partout dès que ton agent devient LLM transactionnel : il ne conseille plus, il exécute. Et quand il exécute dans un SI qui n’est pas le tien, la réaction naturelle, c’est la fermeture ou l’encadrement strict.
Le fait déclencheur : ce que United dit, précisément
Le communiqué United met noir sur blanc trois motifs, qui sont une grille de lecture parfaite pour tes propres projets :
- Protection des données et des comptes : United pointe le risque lié au partage d’identifiants avec des assistants personnels tiers. Source : United (united.mediaroom.com).
- Risque d’actions non voulues : achats, modifications de compte, utilisation de miles. Source : United (united.mediaroom.com).
- Risque de non-conformité réglementaire : exemple cité, le check-in qui requiert une attestation humaine liée aux bagages et matières dangereuses. Source : United (united.mediaroom.com).
Et un détail change tout : United ne dit pas “interdiction des agents IA”. United vise les agents non autorisés. Donc on va vers un monde “autorisé vs non autorisé”. Pas un monde “agents partout en freestyle”.
Pourquoi c’est un signal fort pour tes agents IA entreprise à Lyon
À Lyon, tu as beaucoup d’entreprises qui veulent “agentifier” des workflows : achats, déplacement, notes de frais, support, RH, commerce, IT. Le scénario typique ressemble à ça :
- un agent lit un email,
- ouvre un portail tiers,
- se connecte (souvent avec des identifiants humains stockés quelque part),
- fait une transaction,
- et te confirme “c’est bon”.
Le problème : ce scénario marche en démo, puis explose dès que tu touches à la vraie vie : MFA, responsabilités, litiges, conformité, anti-bot, conditions d’utilisation, sécurité. United ne fait qu’officialiser une tendance : les SI transactionnels tracent une frontière entre “recherche/conseil” et “action dans un compte”.
United le dit aussi : d’autres secteurs (banque, retail) ont déjà mis en place des mesures similaires, et elle encourage l’adoption de garde-fous. Source : United (united.mediaroom.com).
La vraie raison derrière les blocages : la frontière “conseil” vs “action”
Un agent IA qui “cherche le meilleur vol” pose surtout des questions de qualité et d’hallucinations. Un agent IA qui “réserve et paye” pose des questions de dommages. Et ça change la posture du fournisseur tiers.
1) Sécurité des comptes : le partage d’identifiants est mort
United cite explicitement le partage d’identifiants avec un assistant tiers. C’est un anti-pattern classique en entreprise aussi : tu mets un login dans un coffre, l’agent le récupère, et tu appelles ça “automatisation”.
Vu du SI tiers, c’est une catastrophe :
- tu perds l’assurance que la personne authentifiée est bien celle qui agit,
- tu encourages le contournement de MFA,
- tu ouvres la porte au vol de session, au “session hijacking”, à l’exfiltration de PII.
Et en cas d’incident, tout le monde se renvoie la balle : “ce n’est pas moi, c’est l’agent”. Exactement ce que le fournisseur veut éviter.
2) Fraude et abus : un LLM transactionnel amplifie les attaques
Les risques agents LLM ne sont pas théoriques. Automatiser la recherche et la réservation, c’est multiplier la vitesse et le volume :
- tests de cartes et tentatives de paiement,
- abus de coupons,
- annulations en boucle,
- réservations spéculatives qui bloquent l’inventaire,
- scraping agressif qui coûte cher.
Le voyage est un secteur historiquement bombardé par les bots. Donc quand tu ajoutes “agent IA” par-dessus, beaucoup d’acteurs vont réagir par défaut avec un mode “anti-bot renforcé”.
3) Règles métier et conformité : certaines étapes exigent un humain
Le point le plus sous-estimé : la conformité n’est pas juste “RGPD”. United parle d’une attestation humaine au check-in liée aux matières dangereuses. Source : United (united.mediaroom.com).
Et ce n’est pas inventé. Côté réglementation US, il existe bien des obligations d’information passager via un “passenger notification system”, notamment au moment du check-in et du boarding pass. Source : 49 CFR 175.25 (faraim.org).
Traduction entreprise : dès que ton flux inclut un acknowledgement à valeur réglementaire ou contractuelle, le SI tiers va vouloir :
- prouver qu’un humain a vu, compris, accepté,
- lier cette preuve à une identité, un timestamp, un contexte,
- refuser la délégation totale à une IA non encadrée.
4) Protection des données et de la valeur : anti-extraction, anti-scraping
Au-delà de la sécurité, il y a une logique économique : empêcher l’extraction de données à grande échelle (comparaison de prix, inventaire, conditions) qui alimente d’autres services et peut servir à entraîner ou évaluer des modèles.
Dans le cas United, cette dimension est largement commentée dans des analyses externes, et s’inscrit dans une tendance “anti-extraction”. Exemple de décryptage : (fourweekmba.com).
5) Coûts opérationnels : l’agent qui spamme, c’est toi qui payes
Chaque requête coûte : infra, anti-bot, support, gestion des litiges. Le fait qu’United mentionne aussi des restrictions “via agences et agrégateurs” suggère que le sujet n’est pas seulement l’interface web, mais toute la chaîne de distribution et ses coûts. Source : United (united.mediaroom.com).
Comment concevoir un agent compatible avec des SI tiers (sans se faire bloquer)
Tu ne contrôles pas les règles du SI tiers. Donc tu dois concevoir ton agent pour être acceptable : identité claire, consentement, limites, preuves, anti-abus. Voilà une approche pragmatique.
1) Arrête de “piloter un navigateur” par défaut
Le combo headless browser + clics + scraping, c’est le costume officiel du bot non autorisé. Même si ton intention est “légitime” (réserver pour un salarié), techniquement tu ressembles à une attaque.
À privilégier :
- API officielles quand elles existent,
- ou intégrations partenaires contractuelles,
- ou connecteurs SaaS documentés (avec quotas, scopes, logs).
Le RPA web reste utile, mais en dernier recours, sur des périmètres fermés, avec un plan B quand ça casse (et ça casse souvent).
2) Authentification et délégation propres : tokens, scopes, step-up
Si ton agent doit agir dans un compte tiers, le modèle sain, c’est la délégation, pas l’usurpation.
- OAuth et consentement utilisateur, quand dispo.
- Tokens à portée limitée (scopes), pas un accès total au compte.
- Rotation et durée de vie courte des tokens.
- MFA step-up pour les actions sensibles (paiement, annulation, changement d’email, ajout de bénéficiaire).
Le but : que le SI tiers puisse dire “je sais qui autorise quoi, et pour combien de temps”. Et que toi, côté entreprise, tu puisses prouver le consentement.
3) Traçabilité : si tu ne peux pas auditer, tu ne peux pas automatiser
United met le sujet “actions non voulues” sur la table. La seule réponse sérieuse, c’est la traçabilité de bout en bout. Tu veux pouvoir reconstituer l’histoire en 2 minutes quand ça part en incident.
À journaliser, systématiquement :
- l’utilisateur demandeur (identité interne),
- l’intention (ce que l’agent pense faire),
- les données d’entrée (sources, extraits),
- les actions proposées vs les actions exécutées,
- l’identifiant des outils appelés (API, endpoints, scopes),
- horodatage, résultat, erreurs, retries.
Si tu veux creuser le sujet “preuves” côté entreprise, tu as un point d’appui ici : https://lyon-ia.com/blog/tracabilite-decisions-ia.
4) Garde-fous transactionnels : sépare le LLM et l’exécution
Le LLM est bon pour raisonner et rédiger. Il est mauvais pour exécuter sans filet. Le modèle robuste :
- LLM : propose un plan, extrait les champs, explique.
- Orchestrateur déterministe : valide, applique des règles, exécute.
Concrètement, pour un LLM transactionnel :
- allowlist d’actions autorisées (créer une réservation, oui, supprimer un profil, non),
- plafonds (montant max, nombre d’actions par jour, fenêtre horaire),
- interdiction des actions irréversibles sans validation humaine,
- mode “draft” par défaut, exécution après confirmation.
Pour une base de garde-fous, tu peux t’appuyer sur : https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.
5) Anti-abus : rate limiting, détection d’anomalies, sandbox
Si le SI tiers te perçoit comme un bot abusif, tu seras bloqué. Même si tout est “légal”. Donc tu dois te comporter comme un bon citoyen technique :
- rate limiting strict,
- gestion des retries (pas de boucles infinies),
- détection d’anomalies (pics d’appels, comportements répétitifs),
- environnements de test (sandbox) quand disponibles,
- coupe-circuit : arrêt automatique si suspicion de dérive.
6) Résistance aux attaques spécifiques agents : prompt injection et exfiltration via outils
Quand tu branches un agent à des outils, tu ajoutes une surface d’attaque. Le classique : un email ou une page web injecte des consignes qui font exfiltrer des données ou déclencher une action.
À minima :
- filtrer et classifier les entrées non fiables,
- isoler les permissions (principe du moindre privilège),
- valider les champs transactionnels côté orchestrateur,
- tester en “red team” (scénarios d’attaque).
Point de départ utile : https://lyon-ia.com/blog/injection-de-prompt-securite et https://lyon-ia.com/blog/securiser-un-agent-ia.
Conformité agents IA : ce que tu dois prévoir avant d’appeler un SI tiers
Quand ton agent touche à des données perso (voyages, identité, moyens de paiement, préférences), tu es dans un terrain conformité direct. Pour la France, ça veut dire RGPD, et de plus en plus AI Act selon les cas d’usage.
Sans rentrer dans le juridique pour juristes, retiens une règle opérationnelle : si ton agent agit, tu dois pouvoir prouver qui a autorisé, quoi, quand, et avec quelles limites. C’est exactement ce que United met en avant quand elle parle d’actions non voulues et d’attestation humaine.
Pour un cadrage orienté RGPD sur l’agentique, tu peux t’appuyer sur : https://lyon-ia.com/blog/ia-agentique-et-rgpd-ce-que-la-note-cnil-change-pour-vos-agents-check-list-a-lyon.
Clauses à vérifier avec tes fournisseurs SaaS (et avec les SI tiers visés)
Le sujet United te rappelle une réalité simple : tu peux avoir un agent techniquement brillant et contractuellement illégal. Donc tu dois lire les règles d’accès, et pas après le blocage.
1) Le droit d’usage “automated access / bots / agents”
Question bête, mais centrale : le contrat et les CGU autorisent-ils l’accès automatisé ? Beaucoup l’interdisent par défaut, ou l’autorisent uniquement via API.
2) Canaux autorisés : site/app vs API vs partenaires
United mentionne explicitement la restriction sur site/app et indirectement via agences/agrégateurs. Donc toi aussi, tu dois clarifier :
- quel canal est autorisé,
- quels endpoints,
- quels quotas,
- quel mécanisme d’auth,
- et ce qui est considéré comme contournement (RPA web, scraping, etc.).
3) Responsabilité et litiges : qui paie quand l’agent se trompe ?
Ton agent fait une réservation non voulue ou une action irréversible. Qui est responsable ? Toi ? Ton éditeur d’agent ? Le SaaS ?
Tu veux des clauses sur :
- traçabilité et audit,
- mécanismes de contestation,
- annulation et réversibilité,
- support en cas d’incident.
4) Données : rétention, usage pour entraînement, sous-traitants
Si ton agent envoie des données à un modèle ou à une plateforme, tu dois verrouiller :
- durée de conservation,
- usage ou non pour entraînement,
- localisation et sous-traitants,
- capacité à purger.
Tu as un guide concret sur la rétention ici : https://lyon-ia.com/blog/politique-conservation-donnees-ia. Et pour les clauses fournisseurs, ici : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses.
5) Sécurité : logs, détection d’abus, notification d’incident
Si le SI tiers te demande “prouve-moi que ce n’est pas un bot malveillant”, tu dois pouvoir répondre. Donc exige :
- des logs exploitables,
- des alertes,
- un mécanisme de suspension,
- des engagements de notification en cas d’incident.
Checklist : “agent IA prêt pour un SI tiers”
Tu veux brancher un agent sur une plateforme externe (voyage, banque, retail, RH, ITSM, CRM). Utilise cette checklist avant de coder plus loin. Si tu coches la moitié seulement, prépare-toi à être bloqué.
- API d’abord : l’agent passe par une API officielle ou un canal contractuel, pas par scraping web.
- Auth propre : OAuth ou délégation formelle, pas de partage d’identifiants humains.
- Scopes : permissions minimales, séparées par type d’action.
- Step-up : MFA ou validation humaine obligatoire pour paiement, annulation, changement de profil, opérations irréversibles.
- Consentement : preuve stockée de l’accord utilisateur (quoi, quand, pour quelle durée, sur quel périmètre).
- Traçabilité complète : intention, inputs, actions proposées, actions exécutées, résultats, horodatage, identités.
- Logs exploitables : centralisés, immuables autant que possible, avec une politique de rétention claire.
- Garde-fous transactionnels : allowlist d’actions, plafonds, limites de fréquence, validations humaines.
- Orchestrateur déterministe : le LLM ne déclenche pas directement une transaction sans couche de règles.
- Anti-abus : rate limiting, détection d’anomalies, coupe-circuit, gestion saine des retries.
- Tests d’attaque : prompt injection, exfiltration via outils, usurpation d’identité, scénarios de fraude.
- Plan de repli : si le SI tiers bloque, tu as un mode manuel, un parcours alternatif, ou un fallback support.
- Contrats relus : clauses “automated access”, canaux autorisés, responsabilité, incident, réversibilité, données.
Ce que ça change, concrètement, pour tes projets à Lyon
Le signal United te pousse à arrêter de penser “agent = automatisation universelle”. Dans les faits, tu auras deux catégories :
- Agents de recommandation : ils cherchent, comparent, préparent, rédigent. Acceptés presque partout.
- Agents d’action : ils se connectent, modifient, payent, engagent la responsabilité. Acceptés uniquement si tu joues avec les règles : API, autorisation, preuves, limites.
Si tu construis des agents IA entreprise pour des équipes lyonnaises (DSI, achats, travel, finance), le bon move est simple : design “conformité et sécurité” dès le départ, pas en rustine après le premier blocage. C’est exactement ce que l’aérien vient de rendre visible, de façon brutale, mais prévisible.
Laisser un commentaire