OpenAI ne vient pas de sortir un chatbot un peu plus malin. Avec Dots, l’entreprise vous propose de confier une mission persistante à un agent qui continue d’avancer depuis son propre ordinateur cloud.
Le problème, c’est que la plupart des gens vont lui demander de « les aider à être plus productifs ». Et ils vont recevoir, très vite, une version automatisée de leur désorganisation.
A retenir
OpenAI Dots désigne des agents IA persistants capables de travailler entre deux conversations, avec leurs propres environnement et navigateur cloud. Vous leur fixez un objectif, connectez les applications nécessaires, puis définissez les actions qu’ils peuvent préparer, exécuter ou soumettre à validation. Les Dots sont propulsés par GPT-6 Astra et leur déploiement démarre progressivement pour certains abonnés Pro et Business Premium majeurs, selon les marchés éligibles.
L’intérêt ne consiste pas à « avoir un assistant ». Cette expression ne veut rien dire. L’intérêt consiste à déléguer une boucle de travail identifiable : surveiller des sources, produire un point d’avancement, repérer les contradictions dans un brief, préparer une synthèse de réunion ou auditer régulièrement une page.
GPT-6.1 Sol complète ce système pour les usages professionnels et techniques. OpenAI le présente comme un modèle proche de GPT-6 Astra sur le code agentique, l’usage d’ordinateur et les workflows complexes, avec un coût standard par token cinq fois inférieur à celui d’Astra. Mais Sol n’est pas la vedette de cette histoire : c’est le moteur rationnel qui évite de mobiliser un modèle premium pour chaque tâche répétitive.
La règle qui protège tout le reste est simple : l’agent peut analyser, rechercher et préparer. Il ne doit pas envoyer, publier, modifier ou acheter sans une permission explicite. L’autonomie sans trace de contrôle est moins une innovation qu’un futur incident à documenter.
Un Dot n’est pas un chatbot pressé
Le premier réflexe sera mauvais.
Vous ouvrirez ChatGPT, découvrirez Dots et écrirez quelque chose comme : « Aide-moi à mieux gérer mon travail. » Puis vous serez déçu par le résultat. C’est presque garanti.
Un Dot n’est pas une personne qui comprend spontanément votre hiérarchie de priorités, votre jargon interne et les non-dits de votre équipe. C’est un agent capable d’agir sur la durée, de mobiliser des outils et de conserver un fil de travail. Ce n’est pas du tout la même chose.
OpenAI décrit Dots comme des agents « always-on », capables de poursuivre des tâches entre plusieurs échanges. Chaque Dot possède un ordinateur cloud et peut se connecter aux applications que vous lui autorisez. C’est précisément ce qui les rend intéressants. C’est aussi ce qui les rend plus risqués qu’un simple chat.
Car un chatbot qui se trompe vous fait perdre une minute.
Un agent qui travaille dans vos sources pendant que vous dormez peut produire une erreur très propre, très documentée, très convaincante, et la reproduire chaque jour à 9 heures.
J’ai fait l’erreur dans un workflow de veille éditoriale. L’objectif semblait limpide : surveiller les annonces photo et proposer des angles d’articles. En réalité, le périmètre était catastrophique. Aucun référentiel de sources, aucune règle sur les rumeurs, aucune distinction entre une fiche produit, un dépôt FCC, un communiqué et un test terrain.
Le résultat ? Une avalanche de sujets fondés sur les mêmes annonces recyclées, des fuites de fiabilité douteuse et des pseudo-nouveautés déjà démenties. L’automatisation n’était pas défaillante. Elle avait appliqué exactement ma consigne, qui était absurde.
La leçon a été assez humiliante : une IA ne corrige pas un processus flou. Elle l’accélère.
Votre premier objectif n’est donc pas de créer un assistant intelligent. C’est de lui confier une responsabilité bornée, mesurable et vérifiable.
OpenAI Dots : créez un rôle, pas un personnage
Au lancement, les Dots sont accessibles depuis l’application desktop de ChatGPT ou le web sur ordinateur. OpenAI précise que le déploiement se fait progressivement pour les utilisateurs majeurs éligibles, et que l’accès Pro ne couvre pas l’Espace économique européen, la Suisse et le Royaume-Uni à son lancement. Les conditions peuvent évoluer rapidement : vérifiez toujours l’éligibilité de votre compte avant de changer d’abonnement uniquement pour cette fonction.
Cette précision importe particulièrement si vous travaillez depuis la France. Ne transformez pas une promesse produit américaine en achat impulsif.
Quand l’accès est disponible, créez votre Dot depuis ChatGPT sur desktop. Ne lui donnez pas un nom amusant avant de lui donner un métier. Le nom est décoratif. La responsabilité, elle, structure tout.
Pour un lancement produit ou éditorial, commencez plutôt ainsi :
Coordonne le lancement de [nom du projet] prévu le [date]. Utilise uniquement le brief, la checklist et les conversations que je partage explicitement. Identifie les changements confirmés, les blocages, les informations manquantes, les responsables non attribués et les décisions qui nécessitent mon arbitrage.
Pour ta première tâche, prépare un rapport de statut avec un lien source pour chaque affirmation. Distingue les décisions validées, les suggestions et les points incertains. Demande les accès manquants. Prépare les messages, mais ne les envoie jamais sans mon approbation.
Ce prompt n’a rien de poétique. Tant mieux.
Il force l’agent à respecter quatre réalités que les équipes oublient constamment : une source n’est pas une interprétation, une suggestion n’est pas une décision, un nom cité dans une conversation n’est pas forcément un responsable et une action proposée n’est pas une action acceptée.
Ensuite, lisez le premier rapport comme si un stagiaire très compétent vous l’avait remis. Vérifiez la date de lancement. Ouvrez les sources. Cherchez les conclusions qui ont été déduites au lieu d’être prouvées. Contrôlez les personnes auxquelles un rôle a été attribué.
S’il a confondu une hypothèse avec une décision, ce n’est pas le moment de créer une automatisation. C’est le moment de corriger votre cadre.
Un agent ne gagne pas votre confiance parce qu’il a produit un texte impeccable. Il la gagne lorsqu’il reconnaît ce qu’il ne peut pas établir.
Connecter Slack ne suffit à rien
C’est l’un des malentendus les plus coûteux autour des agents IA.
Vous connectez Slack, Google Drive, Microsoft Teams, votre calendrier ou un dépôt de code. Puis vous supposez que l’agent sait ce qu’il doit surveiller, ce qui compte, qui doit être alerté et où se trouve la version à jour. Non. Vous venez simplement de lui donner des accès.
C’est comme donner les clés d’un immeuble à quelqu’un sans lui dire quel appartement visiter.
Les Dots disposent de leur propre ordinateur cloud et de leurs propres sessions. Votre connexion personnelle ouverte dans Chrome sur votre ordinateur ne les authentifie pas automatiquement. Il faut donc traiter les accès comme une étape à part entière : autoriser le service, vous connecter dans l’environnement du Dot lorsque c’est nécessaire, puis vérifier exactement les données qu’il peut lire.
Commencez par une demande froide, presque administrative :
Retrouve le brief de lancement, la checklist opérationnelle et les dernières décisions partagées. Donne-moi les liens directs vers ces sources. Liste les changements récents et précise quels documents, dossiers ou canaux tu ne peux pas consulter.
Cette étape semble triviale. Elle ne l’est pas.
Un client m’a un jour demandé de diagnostiquer un système qui envoyait des alertes de retard sur une campagne e-commerce. Le système avait bien accès aux fichiers. Il avait simplement choisi une ancienne version de planning dans un dossier partagé. Il en a déduit que la campagne prenait trois semaines de retard. L’équipe a réuni sept personnes pour un problème qui n’existait pas.
La machine n’avait pas halluciné. Elle avait trouvé une mauvaise vérité dans un mauvais dossier.
C’est pourquoi il faut choisir un document maître. Pas « le dernier fichier ». Pas « ce qui circule dans le canal ». Un emplacement précis, avec un propriétaire identifié et une règle claire : toute décision confirmée est inscrite ici.
Si votre équipe ne sait pas où se trouve la vérité opérationnelle, ne demandez pas à un agent de l’inventer.
Le rapport qui remplace les faux points d’équipe
La plupart des entreprises ne manquent pas de réunions. Elles manquent de preuves à l’intérieur de leurs réunions.
Un Dot bien configuré ne doit pas vous livrer une « synthèse ». Ce mot est devenu un cache-misère. Une synthèse peut être élégante, longue, nuancée, et absolument inutile au moment de décider.
Demandez plutôt un livrable qui réduit l’incertitude.
Compare le brief actuel, la checklist de lancement et les échanges sélectionnés. Produis une mise à jour en quatre blocs : les changements confirmés, les blocages, la personne responsable de la prochaine action et les décisions qui attendent mon arbitrage.
Relie chaque fait à sa source. Si deux sources se contredisent, affiche le conflit au lieu de choisir arbitrairement. Si un responsable n’a pas explicitement accepté sa mission, présente-le comme une suggestion, jamais comme une attribution confirmée.
La dernière phrase est probablement la plus importante de tout l’article.
Les agents aiment rendre un tableau complet. Vous aussi, d’ailleurs. Le problème est que les trous remplis par une IA sont souvent des hypothèses déguisées en organisation. « Paul a commenté le ticket, donc Paul est propriétaire. » « Le lancement était prévu mardi, donc la date est encore mardi. » « Le manager a écrit “on pourrait”, donc la décision est prise. »
Vous voyez le danger.
Le rapport utile ne transforme pas les silences en certitudes. Il les fait remonter là où un humain doit trancher.
Vous pouvez inspecter l’activité du Dot, ses tâches déléguées et les résultats qu’il a produits. Faites-le vraiment. L’interface n’est pas une décoration destinée à rassurer les responsables innovation. Elle est l’endroit où vous voyez si l’agent a travaillé sur les bonnes sources ou s’il a empilé des déductions sur un fichier incomplet.
Votre objectif ne doit pas être de recevoir plus de documents.
Votre objectif doit être d’obtenir moins de surprises.
L’autonomie est une permission, jamais un cadeau
À partir du moment où votre premier rapport est propre, vous pouvez programmer une routine.
Chaque matin ouvré, par exemple, votre Dot peut analyser les sources validées, signaler les changements depuis la veille, isoler les décisions en attente et préparer les relances nécessaires. Il peut travailler pendant que votre ordinateur personnel est fermé, puisque le travail s’exécute depuis son environnement cloud.
Mais attention : une tâche planifiée qui produit un brouillon n’est pas la même chose qu’une tâche planifiée qui agit.
Ne cédez pas immédiatement au fantasme de l’agent qui répond sur Slack, réattribue des tickets, met à jour le CRM, publie une page et « nettoie » les fichiers. C’est précisément à cet instant que vous transformez un outil de productivité en source de dégâts récurrents.
Voici la règle que je mettrais par défaut dans les instructions personnalisées :
Recherche, compare, analyse et prépare des brouillons dans les limites des accès accordés. Demande systématiquement une approbation explicite avant d’envoyer un message, modifier un fichier partagé, créer ou supprimer un élément, publier un contenu, engager une dépense ou effectuer une action irréversible.
Ce choix est volontairement conservateur. Il est meilleur que la norme du marché.
Les démonstrations d’agents les plus impressionnantes montrent toujours une IA qui clique vite. Elles montrent beaucoup moins souvent ce qui se passe quand elle clique au mauvais endroit avec la même assurance.
OpenAI indique que les Dots permettent de définir ce qu’un agent peut faire seul, avec des contrôles et des permissions configurables. Cela ne dispense pas d’une politique interne claire. Une permission accordée est une possibilité. Ce n’est pas une décision raisonnable. OpenAI
Posez-vous la question avant chaque automatisation : si cette action était mal interprétée, qui serait obligé de s’expliquer à un client, un collègue ou un prestataire ?
Si la réponse est « moi », gardez une validation humaine.
GPT-6.1 Sol : ne payez pas Astra pour trier des post-its
L’erreur classique, maintenant, sera de sélectionner systématiquement le modèle le plus puissant pour chaque tâche.
C’est une manière élégante de faire exploser une facture.
GPT-6.1 Sol se place justement dans cet espace. OpenAI le décrit comme un modèle amélioré pour le code agentique, l’utilisation d’ordinateur et les workflows professionnels complexes, avec des performances proches de GPT-6 Astra sur ces usages pour un tarif standard d’entrée et de sortie cinq fois inférieur. En API, OpenAI affiche 2 dollars par million de tokens en entrée, 0,10 dollar par million de tokens mis en cache et 10 dollars par million de tokens en sortie.
Le contexte cache est particulièrement intéressant pour les équipes qui réutilisent souvent la même base documentaire, les mêmes conventions de code, le même cahier des charges ou les mêmes règles métier. Ce n’est pas sexy. C’est exactement pour cela que c’est rentable.
Mais Sol n’est pas « Astra moins cher ». C’est une erreur de positionnement.
Utilisez Astra lorsque le coût d’une mauvaise décision est élevé, que la tâche exige le meilleur niveau de raisonnement disponible ou que l’agent doit naviguer dans une situation très ambiguë. Utilisez Sol quand vous avez besoin d’un bon niveau d’exécution à grande échelle : audit de pages, analyse de briefs, revue de cohérence documentaire, correction de code, préparation de rapports et traitement de flux répétitifs.
Pour tester Sol proprement, ne lui demandez pas un poème ou une idée de post LinkedIn. Donnez-lui un travail que vous savez juger :
Analyse ce brief et cette page de destination. Identifie les affirmations non sourcées, les promesses ambiguës, les contradictions internes et les formulations qui peuvent nuire à la confiance. Propose des corrections précises. Pour chaque correction, indique l’élément de preuve nécessaire avant publication.
Ensuite, comparez le résultat à votre méthode habituelle. Pas seulement sur la qualité d’écriture. Comparez le taux d’erreur, la pertinence des alertes, le temps gagné et le nombre de corrections humaines restantes.
Voilà une évaluation sérieuse.
OpenAI indique que GPT-6.1 Sol est disponible dans ChatGPT Work et Codex pour les abonnés Plus, Pro, Business, Enterprise et Edu, ainsi que via l’API avec l’identifiant gpt-6.1-sol. Il n’est pas encore proposé dans l’interface de chat classique au moment de son lancement.
Space n’est pas un Drive avec un nouveau nom
Vous pouvez avoir les meilleurs modèles, les meilleurs agents et les meilleures intégrations. Si personne ne sait quelle décision est à jour, vous aurez seulement automatisé la confusion.
C’est ici que ChatGPT Space devient pertinent.
OpenAI présente Space comme un espace de travail collaboratif dans lequel les équipes, ChatGPT, Codex et les Dots peuvent travailler autour de fichiers, documents et outils partagés. Pages sert de format de document collaboratif pour écrire, créer, modifier, visualiser des données ou préparer des contenus avec l’aide d’agents.
Sur le papier, cela ressemble à une nouvelle version de l’espace de travail collaboratif que tout le monde possède déjà. En pratique, tout dépend de la discipline que vous y imposez.
Ne créez pas un Space pour y déposer des documents comme on vide ses poches sur une table.
Créez une page de référence qui fixe l’état actuel du projet : le périmètre validé, les sources faisant autorité, les faits approuvés, les décisions ouvertes, les responsables confirmés, les échéances et un journal de modification daté. C’est cette page que le Dot doit relire. C’est cette page que l’équipe doit consulter avant de prétendre que « personne n’avait été informé ».
Pour une rédaction ou un site de niche, cette page peut regrouper l’angle retenu, les sources primaires, les visuels à obtenir, les informations techniques à vérifier, la version définitive du titre, les éléments juridiques sensibles et les liens internes à intégrer.
Vous ne cherchez pas à centraliser tout le travail.
Vous cherchez à rendre visible ce qui compte encore.
L’idée paraît presque archaïque. Un document maître, vraiment ? Oui. Parce que la technologie avance vite, mais les équipes continuent de perdre des heures sur la même question : « Quelle est la dernière version ? »
Codex ne doit jamais vous demander de croire sur parole
Le même raisonnement s’applique au développement.
Les nouveautés présentées autour de Codex incluent des environnements réutilisables, une interface de revue de code, une CLI enrichie et des capacités de sécurité. L’objectif est clair : faire travailler les agents de code dans des environnements mieux définis, avec davantage de contrôle sur les changements et leurs preuves.
Très bien. Mais un agent de code qui « a corrigé le bug » sans démonstration n’a rien corrigé. Il vous a remis une hypothèse sous forme de commit.
Ne dites jamais : « Corrige le formulaire mobile. »
Dites ceci :
Reproduis l’erreur du formulaire d’inscription décrite dans [lien du ticket]. Identifie la cause racine. Applique la correction la plus petite compatible avec l’architecture existante. Lance les vérifications pertinentes. Retourne le diff, les tests exécutés, leurs résultats et les incertitudes restantes.
Cette formulation change tout.
Elle oblige l’agent à commencer par le symptôme, non par son intuition. Elle limite les réécritures inutiles. Elle vous donne un diff à relire et vous force à regarder les tests, au lieu de vous contenter d’un message rassurant.
J’ai vu un correctif automatisé réduire une exception JavaScript visible, passer le linting, puis empêcher silencieusement l’envoi d’un formulaire dans un cas de validation précis. Tout semblait parfait dans la pull request. Le bug d’origine avait disparu. Un autre venait de prendre sa place.
La leçon est simple : une correction n’existe pas parce qu’un agent l’affirme. Elle existe lorsque le défaut est reproduit, que le changement est lisible et que la vérification prouve que le comportement attendu est revenu.
Le reste, c’est du théâtre technologique.
OpenAI Dots : commencez avec une seule boucle utile
Vous n’avez pas besoin de déployer Dots, Sol, Space, Codex, plugins et API en même temps.
En réalité, ne le faites pas.
Les entreprises les plus enthousiastes vont bâtir cette semaine des systèmes complexes, connectés à tout, capables de produire une quantité impressionnante de travail intermédiaire. Dans un mois, elles passeront leurs réunions à comprendre pourquoi personne ne fait confiance aux résultats.
Choisissez une seule boucle de travail. Une boucle qui vous coûte réellement du temps et dont le résultat peut être jugé.
Pour un éditeur, je choisirais la veille éditoriale vérifiée. Le Dot consulte une liste fermée de sources officielles, de fabricants, de dépôts de brevets, de pages de support et de médias fiables. Il remonte uniquement les changements datés. Sol transforme ces notes en propositions d’angles. Vous vérifiez les sources, vous tranchez l’angle et le Space conserve la décision éditoriale.
La consigne pourrait être la suivante :
Chaque jour ouvré à 8 h 30, examine uniquement les sources approuvées pour repérer les annonces, mises à jour, retraits de produits ou changements de prix survenus depuis le dernier rapport. Sépare les informations publiées, les préannonces et les rumeurs. Cite chaque source. Propose trois angles éditoriaux sans rédiger l’article complet. Ne publie, n’envoie et ne modifie rien sans validation.
Pour une équipe produit, commencez plutôt par le rapport de lancement. Pour un développeur, par le passage contrôlé d’un ticket reproductible à une proposition de correctif. Pour une équipe commerciale, par une préparation de compte rendue vérifiable avant toute relance.
Le bon agent n’est pas celui qui a accès à tout.
C’est celui qui accomplit une responsabilité claire avec assez de contexte pour être utile, assez de limites pour ne pas devenir dangereux et assez de preuves pour que vous puissiez dire oui sans avoir à tout refaire derrière lui.
OpenAI pousse désormais l’IA hors de la zone du chat ponctuel : Dots pour la continuité, Sol pour l’efficience, Space pour la mémoire collective, Codex pour l’exécution technique. La question n’est plus seulement : « Qu’est-ce que l’IA peut produire ? »
La bonne question est beaucoup plus difficile.
Quelle part de votre travail mérite vraiment d’avancer sans vous, et laquelle doit toujours revenir entre vos mains avant de devenir réelle ?
