OpenAI transforme ChatGPT en plateforme d'automatisation d'équipe avec des agents de travail

OpenAI permet désormais aux équipes de créer des bots personnalisés capables de travailler de façon autonome

OpenAI a annoncé le déploiement d'agents "workspace" directement intégrés à ChatGPT, désormais accessibles aux abonnés des formules Business, Enterprise, Edu et Teachers. Ces agents, hébergés dans le cloud, sont conçus pour exécuter des tâches professionnelles de manière autonome : l'un peut par exemple surveiller le web à la recherche de retours sur un produit et envoyer un rapport automatisé sur Slack, tandis qu'un autre est capable de rédiger des e-mails de suivi commercial directement dans Gmail. OpenAI a présenté ces capacités dans un billet de blog accompagné de plusieurs cas d'usage concrets. Pour les entreprises abonnées, ce lancement représente un changement de paradigme : il ne s'agit plus seulement d'un assistant qui répond à des questions, mais d'un système capable d'agir dans leurs outils du quotidien sans intervention humaine constante. L'intégration native à des services comme Slack et Gmail abaisse significativement la barrière d'adoption pour des équipes non techniques, et positionne ChatGPT comme une plateforme d'automatisation opérationnelle à part entière. Cette annonce s'inscrit dans une course effrénée au développement d'agents IA autonomes. Le phénomène a été amplifié par la viralité d'OpenClaw, un agent IA se présentant comme "l'IA qui fait vraiment les choses", fondé par Peter Steinberger, qui a depuis rejoint OpenAI. La tendance reflète une conviction grandissante dans l'industrie : la prochaine vague de valeur de l'IA ne viendra pas des chatbots, mais des systèmes capables d'agir de façon autonome dans des environnements de travail réels.

Créez votre premier agent en quelques minutes : nouvelles fonctionnalités d'Amazon Bedrock AgentCore

Amazon a annoncé de nouvelles fonctionnalités pour Bedrock AgentCore, sa plateforme de développement d'agents IA, qui promettent de réduire drastiquement le temps nécessaire pour passer d'une idée à un agent fonctionnel. La pièce maîtresse de cette mise à jour est le "managed agent harness", une couche d'infrastructure gérée qui permet de déclarer et lancer un agent en trois appels d'API seulement, sans écrire de code d'orchestration. Le développeur n'a qu'à définir quel modèle utiliser, quels outils appeler et quelles instructions suivre : AgentCore assemble automatiquement le calcul, la mémoire, les identités et la sécurité. La plateforme est compatible avec les frameworks déjà en usage dans l'industrie : LangGraph, LlamaIndex, CrewAI et Strands Agents, le framework open source d'AWS qui propulse le harness. AgentCore gère également la persistance de l'état de session sur un système de fichiers durable, ce qui permet à un agent de suspendre une tâche en cours et de la reprendre exactement là où il s'était arrêté. Jusqu'ici, construire l'infrastructure sous-jacente d'un agent, compute, sandbox d'exécution de code, connexions sécurisées aux outils, stockage persistant, gestion des erreurs, représentait plusieurs jours de travail avant de pouvoir tester la moindre logique métier. Avec AgentCore, tester une variante d'agent, changer de modèle ou ajouter un outil devient une modification de configuration et non une réécriture de code. Rodrigo Moreira, VP Engineering chez VTEX, l'un des premiers utilisateurs, confirme que ce qui prenait auparavant des jours de mise en place peut désormais être validé en quelques minutes. Cette accélération du cycle de prototypage est particulièrement significative pour les équipes produit qui veulent itérer rapidement sur la logique agent sans s'embourber dans la plomberie backend. Les patterns "human-in-the-loop", souvent coûteux à implémenter, deviennent pratiques grâce à la persistance native de session, sans nécessiter de refonte architecturale ultérieure. La sortie de ces fonctionnalités s'inscrit dans une concurrence féroce entre les grands fournisseurs cloud pour capter les équipes qui industrialisent l'IA agentique. AWS fait le pari que les développeurs adoptent plus facilement un service géré s'il supprime la friction initiale tout en restant extensible : lorsque les besoins d'orchestration personnalisée ou de coordination multi-agents se précisent, il suffit de basculer d'une configuration déclarative vers du code, sur la même plateforme, avec la même pipeline de déploiement et le même isolement microVM. La prochaine étape annoncée, déployer et opérer les agents depuis le même terminal, vise à unifier le cycle complet de développement, de la première idée jusqu'à la production, dans un seul environnement sans rupture d'outil.

Equinox et JAX en pratique : modules natifs, transformations filtrées, couches à état et pipelines d'entraînement

Equinox s'impose discrètement comme l'une des bibliothèques de deep learning les plus élégantes construites sur JAX, l'environnement de calcul numérique de Google. Développée comme une surcouche légère, elle repose sur un principe central : chaque modèle est un eqx.Module, traité nativement comme un PyTree, la structure d'arbre que JAX utilise pour manipuler ses tenseurs. Concrètement, cela signifie qu'une couche Linear, un bloc convolutif Conv1dBlock ou un réseau MLP se décomposent automatiquement en feuilles (les poids, les biais) et en métadonnées structurelles, sans couche d'abstraction cachée. Le tutoriel publié cette semaine détaille l'ensemble du workflow : initialisation des modules, champs statiques via eqx.field(static=True), transformations filtrées comme filterjit et filtergrad, couches avec état comme BatchNorm, et entraînement complet sur un problème de régression synthétique, le tout combiné avec Optax pour l'optimisation et Jaxtyping pour les annotations de forme. L'intérêt pratique d'Equinox réside dans la façon dont il résout une friction fondamentale de JAX : comment gérer des paramètres entraînables et des métadonnées non-différentiables dans le même objet. Avec les transformations filtrées, il devient possible d'appliquer jit ou grad uniquement sur les feuilles numériques du modèle, en excluant automatiquement les chaînes de caractères, entiers ou booléens qui définissent l'architecture. Cette distinction évite les erreurs de traçage silencieuses qui affectent les approches naïves. Pour les chercheurs qui travaillent sur des architectures expérimentales, où l'on mélange souvent des hyperparamètres fixes et des poids appris, c'est un gain de fiabilité et de lisibilité significatif. Les couches comme BatchNorm, qui maintiennent un état interne (moyenne courante, variance), sont également prises en charge de manière explicite, sans recourir à des contournements complexes. Equinox s'inscrit dans un mouvement plus large qui voit JAX gagner du terrain dans la recherche en apprentissage automatique, notamment face à PyTorch. Google DeepMind, qui l'utilise intensivement, ainsi que de nombreux laboratoires académiques ont adopté cet écosystème pour sa capacité à composer des transformations fonctionnelles (différentiation, vectorisation, parallélisme) de façon modulaire. Equinox se positionne comme une alternative à Flax ou Haiku, les deux bibliothèques historiques de l'écosystème JAX, en privilegiant une syntaxe plus proche de PyTorch tout en restant purement fonctionnelle. Avec l'essor des modèles de grande taille et les besoins croissants en parallélisme matériel, des outils qui séparent clairement la structure du modèle de son état numérique devraient continuer à gagner en adoption dans les mois à venir.

OpenAI lance Privacy Filter, un modèle open source de suppression des données personnelles dans les jeux de données d'entreprise

OpenAI a publié Privacy Filter, un modèle open source spécialisé dans la détection et la suppression des informations personnelles identifiables (PII) avant qu'elles n'atteignent un serveur distant. Disponible sur Hugging Face sous licence Apache 2.0, cet outil repose sur 1,5 milliard de paramètres mais n'en active que 50 millions à chaque traitement, grâce à une architecture Sparse Mixture-of-Experts qui réduit considérablement la charge de calcul. Contrairement aux grands modèles de langage classiques qui lisent un texte de gauche à droite, Privacy Filter est un classificateur bidirectionnel de tokens : il analyse chaque phrase dans les deux sens simultanément, ce qui lui permet de mieux distinguer, par exemple, si le prénom "Alice" désigne une personne privée ou un personnage littéraire public. Le modèle gère une fenêtre de contexte de 128 000 tokens, suffisante pour traiter un document juridique entier en une seule passe, et s'appuie sur un décodeur de Viterbi contraint avec un schéma de balisage BIOES pour garantir la cohérence des entités redactées. Il détecte huit catégories de données sensibles : noms de personnes, coordonnées, identifiants numériques, URLs, numéros de compte, dates et identifiants secrets comme les clés API. L'enjeu concret est considérable pour les entreprises soumises au RGPD ou à la réglementation HIPAA dans le secteur de la santé. En déployant Privacy Filter directement sur leurs serveurs internes ou dans leur cloud privé, elles peuvent anonymiser les données localement avant de les envoyer vers un modèle plus puissant comme GPT-5 ou gpt-oss-120b, sans jamais exposer d'informations sensibles à l'extérieur. Ce modèle résout un problème structurel de l'adoption de l'IA en entreprise : le risque que des données confidentielles, médicales ou financières se retrouvent intégrées dans des pipelines d'inférence ou de fine-tuning hébergés dans le cloud. La possibilité de faire tourner le modèle sur un laptop standard ou directement dans un navigateur web abaisse encore davantage la barrière d'entrée. Cette publication s'inscrit dans un retour marqué d'OpenAI vers l'open source, après des années centrées sur des modèles propriétaires accessibles uniquement via ChatGPT et l'API. Début 2025, l'entreprise avait déjà lancé la famille gpt-oss, des modèles à poids ouverts orientés raisonnement, puis ouvert plusieurs outils d'orchestration agentique. Privacy Filter est un dérivé direct de cette famille gpt-oss, réentraîné pour la classification plutôt que la génération. Ce virage stratégique suggère qu'OpenAI cherche à consolider sa position dans l'écosystème développeur face à la concurrence de Meta (LLaMA), Mistral et Google, en proposant des briques d'infrastructure que les entreprises peuvent intégrer sans dépendance à ses services payants. La prochaine étape logique serait l'extension des catégories PII supportées et l'intégration native dans les frameworks agentiques déjà publiés.

💬 C'est exactement le verrou qui bloquait l'adoption en entreprise depuis deux ans. Un modèle léger, déployable en local, qui filtre les données personnelles avant d'envoyer vers le cloud : sur le papier, c'est le genre de brique qu'on attendait. Et distribuer ça sous Apache 2.0, c'est malin : si ton pipeline s'appuie sur leurs outils gratuits, tu vas finir par appeler leurs modèles payants derrière.