OpenAI a annoncé les dots le 30 septembre 2026, pendant le DevDay : des agents ChatGPT personnels "toujours actifs", tournant 24/7 sur leur propre machine cloud, propulsés par GPT-6 Astra. Démo fluide, pitch convaincant. Et une vraie question derrière pour qui a déjà monté une stack d'agents sur Claude : faut-il tout reprendre ? La réponse courte : non, mais il faut comprendre pourquoi avant de la donner. Cet article fait le tour factuel des deux offres et sort une décision par profil, en s'appuyant sur le guide Claude pour entrepreneurs francophones pour les notions produit déjà couvertes ailleurs.
Ce que sont les dots d'OpenAI (et ce qu'on sait vraiment)
Les dots sont des agents ChatGPT personnels "toujours actifs", annoncés par OpenAI le 30 septembre 2026 lors du DevDay. Chaque dot dispose de son propre ordinateur dans le cloud et travaille en autonomie sur les objectifs d'un utilisateur, 24 heures sur 24, sans que l'appareil de l'utilisateur ait besoin d'être allumé. Le modèle sous-jacent est GPT-6 Astra, le modèle haut de gamme d'OpenAI lancé début septembre 2026, classé "Critical" en cybersécurité par son propre Preparedness Framework.
Ce qui est confirmé par OpenAI : disponibilité pour les abonnés ChatGPT Pro et Business Premium, dans les marchés éligibles (périmètre géographique précis non communiqué, donc rien ne dit que la France est couverte dès le lancement). Plus de 4 000 applications connectables, dont Slack et Teams nommément citées. Un mode "lecture seule" empêche l'agent de contrôler le navigateur ou l'ordinateur quand l'utilisateur est absent.
Ce qui n'est pas confirmé : les 3 998 autres applications connectables, le prix spécifique de dots au-delà de l'inclusion dans Pro et Business Premium, les benchmarks chiffrés face à un équivalent Claude. OpenAI propose par ailleurs un siège Business Premium à 125 $/mois avec 5x la capacité d'usage, mais aucune source ne confirme explicitement que ce siège est un prérequis pour accéder à dots. Prudent de le mentionner comme contexte, pas comme fait.
Les cas d'usage qu'on imagine le plus naturellement pour ce type d'agent : veille concurrentielle qui tourne en continu, suivi d'inbox avec alertes, monitoring de prix ou de disponibilité. Rien de révolutionnaire sur le papier, mais empaqueté dans l'app ChatGPT, sans infra à monter. OpenAI n'a pas publié de liste exhaustive des cas d'usage pris en charge au lancement : à vérifier cas par cas à l'ouverture.
Ce que Claude permet déjà aujourd'hui côté agents permanents
Un "agent qui tourne tout le temps" côté Claude existe depuis longtemps, mais pas sous forme d'un bouton dans l'app. Il faut assembler trois briques : l'API Anthropic pour appeler le modèle, MCP pour connecter Claude à vos outils (CRM, Slack, bases de données, calendrier), et un orchestrateur de votre choix (cron sur un serveur, Agent SDK, Claude Managed Agents, n8n, ou un conteneur Docker sur un VPS).
Deux évolutions récentes rapprochent Claude du modèle "agent toujours actif". D'abord Claude Cowork, qui peut désormais travailler en arrière-plan dans le cloud même quand aucun appareil n'est allumé, avec notification quand une permission est requise. Ensuite Claude Managed Agents, l'offre d'agents gérés et hébergés par Anthropic via l'API, avec politique de permission `auto` depuis le 10 septembre 2026 : le serveur Anthropic évalue chaque appel d'outil et décide d'exécuter, refuser, ou mettre la session en pause.
Prenez un cas type. Agent de veille concurrentielle qui scrute cinq sites toutes les six heures et vous alerte sur Slack en cas de changement de prix. Sur dots : vous le décrivez à ChatGPT, l'agent se charge du reste. Sur Claude aujourd'hui : vous écrivez un script Python qui appelle l'API Anthropic avec des outils MCP (web fetch, Slack), vous le planifiez avec cron sur un VPS, vous gérez les logs et la reprise sur erreur. Même résultat, deux chemins totalement différents.
La vraie différence : agent intégré vs agent construit
C'est là que l'opposition prend du sens. Les dots sont un produit grand public et pro grand public : zéro config, l'agent vit dans l'app, OpenAI gère tout (le poste de travail cloud, l'exécution persistante, la sécurité, les intégrations). Claude via API, MCP et Agent SDK est une plateforme de construction : l'agent vit dans votre infra, lit vos données selon vos règles, utilise vos credentials sur vos systèmes.
Les conséquences concrètes se lisent sur quatre axes. Le contrôle des données : avec dots, l'agent tourne sur un poste de travail cloud OpenAI qui accède à vos outils via les connexions que vous autorisez ; avec Claude Managed Agents, pareil, mais vous pouvez aussi sortir de Managed et héberger l'orchestration chez vous via le self-hosted runner ou les inference hooks DLP. La portabilité : un dot est lié à ChatGPT, un workflow Claude écrit en Python avec appels API est portable (vous pouvez changer de modèle si la logique métier est bien isolée).
Le coût au volume : les dots sont inclus dans Pro et Business Premium sans tarif à l'usage communiqué pour l'instant, ce qui peut être très avantageux ou très désavantageux selon ce que couvre le forfait. Claude via API facture au token, vous savez exactement ce que coûte chaque exécution. La dépendance à un éditeur : un dot est une fonctionnalité ChatGPT, pas un format portable. Un agent Claude bien architecturé reste votre code.
Un dirigeant qui veut "un agent qui lit mes mails et m'alerte quand un client clé répond" n'a pas le même besoin qu'un dirigeant qui veut "un agent intégré au CRM maison qui qualifie les leads selon les règles de l'équipe commerciale et pousse les scores dans HubSpot". Les dots couvrent le premier cas sans effort. Pour le second, vous construisez, point.
Scénarios de décision : quand chaque option a du sens
Trois profils, trois décisions.
Solo ou petite équipe sans dev. Les dots quand ils sortiront feront le job pour l'écrasante majorité des usages personnels et pro-personnels : suivi d'inbox, veille, rappels, monitoring léger. Pas de serveur à louer, pas de code à maintenir, pas de MCP à configurer. Si votre stack actuelle, c'est ChatGPT Plus et quelques prompts, les dots sont la suite logique. Rester sur Claude dans ce cas, c'est se compliquer la vie pour un gain marginal.
PME avec un stack déjà sur Claude et des workflows métier. Vous avez des Projects, des agents Claude Code en production, des connecteurs MCP vers HubSpot ou Notion, des workflows qui portent de la logique spécifique à votre métier. Les dots n'apportent pas assez pour justifier la migration. Ils sont pensés pour des cas génériques dans l'app ChatGPT, pas pour reproduire une orchestration métier existante. Signal de décision : combien d'heures faudrait-il pour reconstruire sur dots ce que vous avez déjà qui tourne ? Si la réponse dépasse une semaine, rester sur Claude est le choix par défaut.
Équipe tech qui construit du produit. Claude via Agent SDK ou Managed Agents reste le choix par défaut pour la raison qui l'a toujours été : vous construisez une plateforme, pas un outil final. Les dots ne sont pas une plateforme de build. Vous ne pouvez pas livrer un dot à vos clients, vous ne pouvez pas inspecter ni versionner le prompt système d'un dot, vous ne pouvez pas garantir à votre client une rétention des données sur votre propre infra. Pour construire un agent qui est votre produit, Claude reste la bonne couche.
| profil | besoin principal | décision |
|---|---|---|
| solo sans dev | agents personnels prêts à l'emploi | tester dots dès ouverture |
| PME sur Claude | workflows métier déjà en production | rester sur Claude |
| équipe tech produit | agents qui sont le produit | Claude via Agent SDK |
Un dernier cas à ne pas oublier : l'équipe hybride qui veut les deux. Un dot pour la veille perso du dirigeant, Claude pour les workflows commerciaux. C'est parfaitement valable, et probablement ce qui se passera dans beaucoup d'entreprises à partir de 2027.
Ce qu'il faut faire maintenant si vous êtes déjà sur Claude
Ne réagissez pas à chaud. Une annonce DevDay n'est pas un plan de migration. Voici l'ordre dans lequel aborder la question sur les trois prochains mois.
Documentez vos agents Claude en place. Combien tournent, à quelle fréquence, pour quel résultat mesurable, à quel coût. Si vous ne pouvez pas répondre à ces quatre questions en cinq minutes, le problème n'est pas dots, c'est votre visibilité sur votre propre stack. Partez de là.
Isolez la logique métier du modèle. C'est le vrai sujet de portabilité. Si vos prompts, règles de décision et formats de sortie sont codés en dur dans des appels API Claude dispersés dans dix scripts, vous êtes bloqué sur Claude pour de mauvaises raisons. Si la logique métier vit dans des fichiers de configuration, des Agent Skills versionnées et des tests, vous pouvez changer de modèle en changeant un paramètre. La portabilité agent se joue dans l'architecture, pas dans le choix du LLM.
Testez les dots quand ils sortent sur un cas non critique. Un agent de veille, pas un agent qui touche à la facturation. Mesurez sur un critère précis : latence moyenne, qualité des alertes (taux de faux positifs), coût effectif pour 1000 exécutions comparables. Pas d'impression générale, des chiffres.
Évitez le piège inverse. Certains vont pousser à tout migrer sur dots parce que "c'est plus simple". Simple pour celui qui n'a rien construit. Pour vous qui avez une stack qui tourne, le coût de migration est réel : refaire les intégrations, retester, former l'équipe, accepter un lock-in nouveau. Si l'existant marche, le gain doit être massif pour justifier le changement, pas marginal.
Et si vous voulez structurer tout ça proprement, de l'audit de l'existant à l'architecture portable, c'est exactement le travail couvert dans Piloter vos agents autonomes : documenter, isoler, déployer sur votre serveur, superviser sans dépendre d'un seul éditeur. Les dots sortiront, d'autres suivront. Votre job de dirigeant n'est pas de courir après le dernier produit, c'est de garder la main sur ce qui fait tourner votre boîte.