🚀 Régulation IA : la FTC exige des preuves (2026)
FTC 2026 : l’enquête sur OpenAI/Anthropic, la régulation de l’IA et la sécurité des systèmes. Découvrez les coûts, modèles open source et actions.
IA : les régulateurs demandent des comptes, les entreprises font leurs calculs
L'intelligence artificielle passe une étape. Moins de grandes annonces, plus de sujets concrets : comment on gère les incidents de sécurité, qui paie vraiment la facture, et qui porte la responsabilité quand quelque chose tourne mal. Dans le même temps, les modèles capables de détecter des failles apportent aussi une nouvelle couche de travail : corriger, tester, remettre en conformité. Et avec l'arrivée de modèles ouverts assez puissants pour tourner sur une machine locale, revient forcément la même question, très terre-à -terre : le coût total... et la maîtrise des données.
Cette semaine, plusieurs signaux vont dans le même sens. La Federal Trade Commission (FTC) a demandé à OpenAI et Anthropic des documents sur leurs incidents, leurs protections, leur communication commerciale et leurs politiques de confidentialité. Meta modifie les conditions de certains comptes professionnels. Accenture plafonne la contribution qu'elle accorde à ses salariés pour Claude. Bank of America renforce ses équipes de remédiation après la découverte de vulnérabilités par des modèles d'IA.
Pris séparément, tout cela pourrait sembler dispersé. Ensemble, c'est plus révélateur : l'IA n'est plus seulement jugée sur ses performances. Elle doit aussi être gouvernée, sécurisée, financée et intégrée dans des opérations qui fonctionnent au quotidien. Pour les entreprises européennes, la vraie question n'est pas « faut-il être prudents ? », mais « comment éviter à la fois le déni et la paralysie ».
Pourquoi la FTC demande des documents aux laboratoires d'IA
La FTC a adressé à OpenAI et Anthropic des demandes d'enquête civile d'environ 50 pages chacune. D'après les informations rapportées par Axios, les documents demandés portent notamment sur les incidents de sécurité, les garde-fous, les communications marketing et les politiques de confidentialité. Une telle demande peut agir comme une assignation à produire des pièces. Elle ouvre une enquête, sans pour autant signifier que l'entreprise a enfreint la loi.
Cette nuance compte. Une enquête n'est ni une condamnation ni la preuve d'un manquement. En revanche, elle signale que les autorités veulent regarder les pratiques internes, pas seulement ce que les utilisateurs voient. Les déclarations publiques sur la sûreté, les procédures réellement appliquées et les incidents enregistrés peuvent être mis sur la même table.
La traçabilité devient un réflexe opérationnel
Pour une entreprise qui déploie de l'IA, l'objectif n'est pas d'imiter la bureaucratie d'un gros laboratoire. C'est de pouvoir répondre, simplement et vite, à des questions qui finissent toujours par arriver : quel système a été utilisé, sur quelles données, pour quelle décision, avec quel niveau de contrôle humain, et quels incidents ont déjà été observés.
Dans la vraie vie, ces informations sont souvent dispersées entre plusieurs équipes : produit, sécurité, juridique, métiers. Tant que « ça marche », ça tient. Le problème, c'est quand un incident touche des données personnelles, quand un modèle produit une réponse dangereuse, ou quand un client conteste une décision automatisée. Sans journal de suivi, on perd du temps, on brouille les responsabilités, et on perd de la confiance.
Un registre bien tenu peut consigner :
- le fournisseur, la version du modèle et la date de mise en service ;
- les usages autorisés et ceux qui sont interdits ;
- les catégories de données utilisées et les règles de conservation ;
- les évaluations de sécurité et les contrôles humains prévus ;
- les incidents, leurs conséquences, les mesures prises et leur clôture ;
- les changements importants apportés au système ou à son périmètre.
Ce n'est pas « faire de la paperasse ». Le registre sert à reconstruire ce qui a été décidé et à corriger ce qui doit l'être. Et surtout, il aide à distinguer un incident isolé d'un problème qui revient - ce qui est très difficile à établir à partir de discussions, sans structure, et de tickets incomplets.
Le contexte européen impose sa propre discipline
En Europe, la préparation doit tenir compte du RGPD, des règles sectorielles et des obligations liées aux systèmes concernés, y compris celles prévues par le règlement européen sur l'intelligence artificielle. Le niveau de contrôle dépend de l'usage : un assistant interne qui reformule des documents n'a pas le même profil de risque qu'un système qui contribue à des décisions sur le recrutement, le crédit ou l'accès à un service essentiel.
Erreur fréquente : traiter la conformité comme un dossier à part du produit. Si les équipes ne savent pas quelles données peuvent être envoyées à un fournisseur, ou comment désactiver une fonction, la « politique écrite » ne protège pas grand-chose. La gouvernance doit se traduire dans les outils, les droits d'accès, les contrats et les procédures de réponse aux incidents.
Autre point à garder en tête : distinguer ce que les entreprises affirment de ce qui peut être vérifié. Les laboratoires publient des évaluations et des engagements, mais la demande de la FTC rappelle que le discours ne remplace pas les éléments concrets. Pour un acheteur, la question utile n'est donc pas « le fournisseur dit-il être responsable ? », mais « peut-il expliquer ses contrôles, ses limites et sa gestion des incidents ? ».
Les nouveaux coûts et risques de l'IA en entreprise
Les annonces d'Accenture et de Bank of America montrent une même réalité : l'IA peut apporter de la valeur, mais le coût « réel » dépasse souvent ce qu'on voit sur une facture d'abonnement.
D'après un document interne rapporté par 404 Media, Accenture finance jusqu'à 29 dollars par mois et par salarié pour l'usage de Claude. Certains salariés auraient auparavant dépensé jusqu'à 1 000 dollars mensuels. Au-delà du plafond, le coût doit être rattaché à un budget de projet. Ce choix ne dit pas forcément que l'outil est mauvais : il traduit surtout un passage. On quitte une expérimentation trop libre pour entrer dans une dépense qui doit être justifiée.
Un abonnement ne résume pas le coût d'usage
Pour piloter une dépense d'IA, le coût par compte est trop grossier. Ce qu'il faut regarder, c'est le coût par tâche réellement terminée : essais infructueux, appels répétés, validation humaine, traitement des données, et éventuellement les outils complémentaires.
Une équipe peut consommer beaucoup de crédits parce qu'elle a trouvé un usage à forte valeur. Elle peut aussi en consommer beaucoup parce que les consignes sont floues, que les réponses doivent être reprises, ou que chacun teste l'outil sans objectif précis. Un plafond général peut réduire la facture, mais il peut aussi pénaliser les usages les plus rentables.
Une approche plus fiable consiste Ă :
- définir quelques usages mesurables, au lieu de financer l'accès « sans cadre » ;
- suivre la dépense par équipe et par type de tâche ;
- mesurer le temps réellement économisé après vérification des résultats ;
- fixer un seuil d'alerte et une procédure de financement pour les dépassements ;
- ajuster modèles et paramètres quand la qualité ou le coût change.
En clair : le budget doit suivre la valeur produite. Un usage qui coûte 100 euros mais évite plusieurs heures de travail fiable peut être intéressant. Un usage à 20 euros qui crée une heure de vérification en plus ne l'est pas, même si l'abonnement paraît léger.
Quand une faille apparaît, la correction a son propre coût
Bank of America, elle, a recruté 1 000 contractuels supplémentaires pour corriger des failles mises en évidence par des modèles, selon son dirigeant Brian Moynihan, cité par CNBC. Cette équipe s'ajoutait à environ 3 000 personnes déjà affectées à ce domaine. Les coûts de remédiation logicielle et de conformité liés à la lutte contre le blanchiment auraient atteint plusieurs centaines de millions de dollars au troisième trimestre, avec l'idée qu'ils diminuent une fois les corrections réalisées.
Le point important est simple : trouver une vulnérabilité, c'est le début. Il faut confirmer le problème, mesurer l'exposition, prioriser les systèmes, développer un correctif, le tester, puis le déployer sans interrompre les services. Et si le parc logiciel n'est pas bien inventorié ou si les équipes de développement sont déjà saturées, les découvertes s'accumulent plus vite que les corrections.
Toute organisation qui utilise l'IA pour analyser du code ou accélérer des tests devrait donc prévoir une capacité de remédiation. Concrètement : inventaire exploitable, responsables identifiés, critères de priorité basés sur le risque. Sans ça, l'outil produit des listes de défauts plus vite que l'entreprise ne peut les traiter.
Modèles ouverts : reprendre la main, avec des compromis
Les modèles ouverts évoqués cette semaine pointent une autre tendance : certaines entreprises peuvent choisir d'exécuter des modèles localement sur leur matériel, au lieu de passer par une API facturée à l'usage.
Meta a présenté Muse Spark Open, un modèle annoncé à 816 milliards de paramètres, avec une fenêtre de contexte d'un million de jetons. Il est conçu pour fonctionner localement sur des ordinateurs Apple, mais la configuration mentionnée exige au moins un téraoctet de mémoire et sera plus à l'aise sur une station Mac Studio équipée d'une puce M5 Ultra. Autrement dit : ce n'est pas un modèle à installer sur un ordinateur portable standard.
Nvidia a aussi annoncé Nemotron 3.5 Super VL, un modèle ouvert de 120 milliards de paramètres orienté vers le traitement de documents, graphiques, tableaux, images et pages web, ainsi que Bolt (24 Go) destiné au codage et à la recherche en local. Nvidia indique que les entreprises peuvent adapter Super VL à leurs propres documents et politiques, et l'exécuter là où leurs règles de données l'imposent.
Le calcul économique dépend du volume et de la confidentialité
Sortir du modèle « API » ne fait pas disparaître les coûts. Une partie passe juste de coûts variables vers des coûts fixes : matériel, énergie, maintenance, mises à jour, exploitation, et surtout compétences techniques. Cette option devient intéressante quand les volumes sont prévisibles, que les données sont sensibles, ou que des contraintes de résidence des données pèsent vraiment.
À l'inverse, une API est souvent plus simple à lancer, plus facile à faire évoluer et plus rentable pour une équipe qui utilise le modèle de façon sporadique. Mettre en local demande une supervision, une organisation, et un plan de continuité. Et si le modèle n'est pas assez bon sur des tâches métier réelles, le coût du matériel ne compense pas le temps perdu à corriger ses sorties.
Les annonces de performance doivent aussi être lues avec prudence. Les évaluations publiées par les fabricants aident à repérer des capacités, mais elles ne remplacent pas un test sur vos documents, vos langues et vos processus. Et sur ces versions récentes, les évaluations indépendantes restent encore limitées.
Tester avant de migrer
Une comparaison sérieuse commence par un jeu de tâches représentatif, pas par une démo « qui marche bien ». Il faut inclure les requêtes fréquentes, les cas difficiles, les documents longs, les erreurs qu'on peut tolérer, et les situations où le modèle doit reconnaître qu'il ne sait pas.
Pour chaque option, mesurez au minimum :
- le taux de réponses jugées acceptables après contrôle humain ;
- le temps total pour obtenir un résultat exploitable ;
- le coût par tâche (infrastructure + exploitation) ;
- les risques liés aux données et aux accès ;
- le comportement en cas d'erreur ou de demande ambiguë.
Une entreprise peut très bien conclure qu'un modèle local convient à la recherche dans des documents internes, tandis qu'une API reste plus efficace pour certains travaux complexes. Il n'y a pas besoin de choisir « un seul modèle pour tout le monde ». La voie la plus pragmatique combine plusieurs options, avec des règles explicites sur les données et les usages autorisés.
Une méthode pratique pour décider
Ces sujets ne concernent pas que les grands laboratoires. Les conditions de Meta, la hausse des attaques, les budgets d'outils et les modèles locaux touchent aussi les PME et les éditeurs européens. L'idée n'est ni de tout interdire, ni de généraliser les usages sans contrôle : il faut rendre les choix visibles et réversibles.
1. Cartographier les usages réels
Commencez par observer ce qui existe déjà : assistants publics, extensions de navigateur, outils de programmation, fonctions d'IA intégrées aux logiciels métier. Les usages non recensés sont souvent ceux qui posent le plus de problèmes. Pour chaque outil, identifiez le responsable interne, les données concernées et le but concret.
2. Lire les conditions d'utilisation des services existants
L'exemple de Meta sert de rappel. D'après trois spécialistes du droit cités par Nieman Lab, des conditions applicables à partir du 30 octobre permettent à Meta d'explorer les sites associés à certains comptes professionnels Facebook, Instagram et WhatsApp, et d'utiliser leur contenu pour entraîner ses produits. La portée exacte dépend des conditions et du compte concerné : ce n'est pas une « règle générale » si on ne vérifie pas le texte qui s'applique.
Dans la pratique, le risque pour un média ou une entreprise, c'est de voir un compte professionnel comme un simple canal de publication. Or les outils associés peuvent créer des engagements supplémentaires. D'où l'intérêt d'une revue menée par les équipes juridiques et techniques, puis d'une décision : est-ce compatible avec la politique de confidentialité et de propriété intellectuelle, ou faut-il ajuster ?
3. Préparer une réponse aux incidents
Un incident lié à l'IA peut prendre plusieurs formes : fuite de données, accès non autorisé, réponse qui cause un préjudice, ou usage détourné d'un outil. Les consignes doivent préciser qui peut suspendre le service, qui conserve ce qui doit être conservé, qui évalue l'impact, et qui communique avec les clients ou les autorités.
Les travaux de Citizen Lab cités par WIRED élargissent la focale sur l'écosystème numérique : 45 appareils appartenant à des personnes travaillant pour Al Jazeera auraient été ciblés en 2024 et 2025 par des attaques sans clic via des publicités en ligne. Les chercheurs relient ces campagnes à l'entreprise de marketing Discover-Tech et à un logiciel espion attribué à Candiru. Google a depuis bloqué Discover-Tech de ses plateformes publicitaires. Selon les chercheurs, le blocage des publicités constitue une défense importante pour les individus.
Le point n'est pas de dire que chaque campagne publicitaire est aussi dangereuse. Le cas sert surtout à rappeler qu'un canal banal peut être utilisé pour distribuer une attaque ciblée. Les organisations doivent penser au-delà du « modèle » : appareils, comptes, fournisseurs, publicité, logiciels tiers, accès internes... tout ça forme une chaîne.
4. Lier chaque investissement à une décision mesurable
Avant d'acheter des licences supplémentaires, d'installer un modèle local ou de déployer un outil d'analyse de code, posez la question : quel travail va être amélioré ? quel risque va être réduit ? quel indicateur montrera que le changement fonctionne ? et qui prendra en charge les erreurs quand elles arriveront ?
Cette discipline évite deux erreurs inverses : financer une expérimentation sans critères de sortie, ou couper un outil utile parce que son coût paraît élevé sans mesurer la valeur produite. Le bon pilotage relie dépenses, qualité, sécurité et capacité à corriger quand ça dérape.
Le reste de l'actualité montre aussi que le marché n'est pas stabilisé. Les investisseurs présents lors d'une journée d'Anthropic auraient discuté d'une valorisation d'environ 1 500 milliards de dollars pour une vente d'actions envisagée en novembre, contre près de 2 000 milliards auparavant. Ce chiffre n'est pas une valorisation officielle annoncée par Anthropic. Le ralentissement de la croissance trimestrielle évoqué dans le même reportage rappelle que les attentes financières peuvent changer vite. De son côté, Character.ai a déposé une demande de protection au titre du chapitre 11 aux États-Unis, en invoquant les coûts de développement et de croissance, ainsi que les frais juridiques et réglementaires. Disney s'est proposé comme acquéreur initial de certains droits de propriété intellectuelle pour 20 millions de dollars.
Ces exemples ne suffisent pas à conclure sur la viabilité de toutes les entreprises d'IA. Ils disent surtout ceci : une croissance visible ne suffit pas. La structure des coûts, les obligations juridiques et la capacité à générer des revenus durables comptent autant.