1. Ce n’est pas Doc. C’est Dot. Et cela ressemble davantage à un responsable qu’à une fenêtre de chat
Le nom prête facilement à confusion. Ce n’est pas Doc, mais Dot.
Une conversation classique avec ChatGPT suit souvent ce cycle : vous demandez, le modèle réfléchit, répond, puis le tour se termine. Un Dot est conçu autrement. OpenAI décrit les Dots comme des agents toujours actifs, alimentés par GPT-6 Astra, disposant de leur propre ordinateur dans le cloud et de leur propre navigateur, capables d’utiliser des applications connectées et de poursuivre des objectifs dans la durée.
Il ressemble donc moins à « l’IA qui répond aux questions » qu’à « la personne responsable de ce dossier ».
L’IA vient de quitter la boîte de chat pour rejoindre le tableau des responsabilités.
2. « 24 h/24 » ne signifie pas une boucle infinie ; cela signifie que la responsabilité survit à la conversation
Cette nuance est essentielle. Un agent toujours actif n’est pas un VPS gratuit qui brûle du CPU chaque seconde pour toujours.
La vraie valeur est la continuité. Un Dot peut conserver une responsabilité après la fin de la conversation, effectuer des recherches en arrière-plan, lancer des contrôles récurrents, consulter des sources connectées et poursuivre des tâches planifiées sans attendre un nouveau message. OpenAI appelle proactive research cette recherche d’informations utiles en arrière-plan.
Avant, l’humain devait se souvenir du travail, rouvrir l’IA, reconstruire le contexte et redonner les instructions. Avec un Dot, le responsable conserve le dossier.
Cela semble subtil jusqu’à ce qu’on mesure le temps perdu à demander : « On en était où déjà ? ».
3. La configuration commence sur ordinateur ; ensuite le Dot peut vous suivre sur mobile
Le premier Dot se crée dans l’application de bureau ChatGPT ou sur le web depuis un ordinateur. Vous lui donnez un nom, un objectif, connectez les applications nécessaires et définissez ce qu’il peut faire de façon autonome.
Après la configuration, vous pouvez lui parler depuis l’application mobile. Autrement dit : l’acte de naissance se fait sur ordinateur, puis l’agent tient dans votre poche.
Son profil permet de voir les travaux en cours, planifiés et terminés. Vous pouvez également gérer la fréquence des tâches récurrentes et leurs notifications. L’accès à votre propre ordinateur est facultatif ; par défaut, le Dot dispose déjà d’un ordinateur distinct dans le cloud.
Il n’est donc pas nécessaire de laisser votre PC domestique allumé toute la nuit.
4. Le modèle d’usage est généreux, mais OpenAI ne promet pas « illimité pour toujours »
Au lancement, le premier Dot est inclus sans coût supplémentaire pour les utilisateurs éligibles Pro et Business Premium. Pour la famille Enterprise, l’accès commence sous forme de bêta activée par l’administrateur.
OpenAI indique que les conversations avec un Dot ne comptent pas dans les limites normales de ChatGPT. Le plan comprend aussi une allocation pour les travaux plus approfondis, avec des limites étendues pendant le premier mois. Les notes de version précisent également que, durant ce premier mois, l’utilisation de Dots par les utilisateurs éligibles n’est pas déduite de l’allocation normale de leur plan.
Des utilisateurs précoces ont raconté avoir laissé tourner des travaux créatifs lourds toute une nuit sans voir leur compteur habituel beaucoup diminuer. C’est cohérent avec les conditions de lancement, mais cela ne prouve pas l’existence d’une ferme de calcul gratuite, infinie et permanente.
Et si le Dot crée ou gère une tâche Codex ou ChatGPT Work, cette tâche consomme normalement l’usage correspondant de Codex ou Work.
Ce n’est pas un buffet infini. Mais l’entrée est étonnamment copieuse.
5. Le meilleur cas d’usage est peut-être « l’assistant des automatisations récurrentes »
Scheduled Tasks est excellent pour démarrer le travail à la bonne heure. Dans l’automatisation réelle, toutefois, la difficulté principale est souvent de terminer.
Une API vacille. Une permission manque. Une étape expire. Une seule sous-tâche échoue. Le log est écrit. Le blocage est classé. La prochaine action est enregistrée.
Et personne n’exécute cette prochaine action.
Grand classique de l’automatisation.
C’est exactement là qu’un Dot devient intéressant.
Scheduled Task démarre le service. Dot reste responsable du résultat.
Si une exécution se termine en PARTIAL, BLOCKED, HOLD ou FAILED, Dot relit l’état actuel, reprend depuis le dernier checkpoint confirmé, poursuit les travaux indépendants et sûrs, répare la cause et suit le processus jusqu’à la véritable condition de fin.
On passe de « prévenez-moi si ça casse » à « quelqu’un reste responsable après la casse ».
6. Dot, Scheduled Task et Codex se comprennent bien comme chef d’atelier, horloge et équipe de réparation
Un modèle à trois couches est facile à raisonner.
Scheduled Task est l’horloge : il démarre le travail au bon moment ou sous la bonne condition.
Dot est le chef d’atelier : il conserve l’état entre plusieurs exécutions, repère le travail inachevé, décide de la prochaine étape, évite les retries aveugles et pousse le processus jusqu’à un résultat terminal.
Codex est l’équipe de réparation : on l’appelle lorsqu’il faut modifier réellement du code, tester, refactoriser ou réaliser une implémentation complexe.
La règle cruciale est que « j’ai créé une tâche Codex » ne veut pas dire « c’est terminé ».
Codex démarre → produit une correction → le diff est examiné → les tests tournent → la modification est appliquée → le pipeline redémarre → le résultat réel est vérifié.
C’est seulement là que la boucle est fermée.
Le chef d’atelier ne peut pas rentrer chez lui simplement parce qu’il a appelé le mécanicien.
7. La gestion des échecs doit être une boucle fermée, pas un générateur de rapports
La partie la plus importante des instructions d’un Dot est la condition d’arrêt.
Une instruction faible dit : « Préviens-moi si quelque chose échoue. » On obtient une caméra de surveillance coûteuse.
Une instruction forte dit : « En cas d’échec, relis l’état actuel, identifie la cause, applique la plus petite correction sûre, vérifie à nouveau et continue tant qu’il reste du travail exécutable. Si une modification de code est nécessaire, délègue à l’agent de programmation, récupère le résultat puis revalide. Si l’exécution ne peut pas finir maintenant, sauvegarde le checkpoint exact et la prochaine action pour reprendre à cet endroit. »
Si le même problème revient, il faut également revoir la tâche récurrente elle-même : son prompt, ses conditions d’arrêt, ses références, ses hypothèses et sa définition du terminé.
« Cause racine classée » revient à dire sur le terrain : « Nous savons maintenant quel type d’incendie c’est. »
Parfait. Maintenant éteignez-le.
8. Il n’est pas nécessaire de donner les clés de tout le royaume au Dot
Dots prend en charge les permissions et les Custom Rules. Vous pouvez décider quelles actions sont autonomes, lesquelles nécessitent une approbation préalable, lesquelles doivent être confirmées à chaque fois et lesquelles doivent être rendues à un humain.
proactive research est également limité volontairement. Il peut lire des sources connectées autorisées et conserver des notes privées, mais ses outils de recherche ne peuvent pas envoyer directement de messages, modifier du contenu via des plugins, ni contrôler un navigateur ou un ordinateur. Les actions ultérieures repassent par les permissions, approbations et contrôles de sécurité habituels.
Ce n’est pas seulement une limitation. Un opérateur 24 h/24 n’a pas besoin d’un permis 24 h/24 pour détruire la production.
Une bonne règle est : observation large, autorité étroite pour les changements importants.
9. À l’usage, « avoir de l’initiative » signifie que la réponse est déjà là avant même la question
Quand on commence réellement à utiliser un Dot, un autre rôle devient évident au-delà de la supervision des Scheduled Tasks : prendre en charge les vérifications récurrentes qu’un humain devait auparavant penser à demander.
Par exemple, le Dot peut suivre le trafic, tracer la progression des articles qui commencent à monter, puis aller plus loin : ne pas seulement demander « quels articles progressent ? », mais « qu’ont en commun les articles qui progressent ? ». Sujet, point d’entrée, langue, évolution après publication et navigation interne peuvent devenir une analyse continue plutôt qu’une question ponctuelle.
Même logique pour l’exploitation. Si quelque chose se bloque dans Cloudflare ou GitHub, le Dot peut examiner l’état, réduire le champ des causes, effectuer une réparation sûre lorsqu’il en a l’autorisation, puis suivre le travail jusqu’à son terme. Au lieu de redemander chaque fois « où est-ce bloqué ? », « comment évolue le trafic ? » ou « quels articles montent ? », on peut ouvrir le Dot et constater que l’enquête, le graphique ou la réparation ont déjà avancé.
C’est peut-être la forme d’intelligence la plus utile.
Et, en pratique, le Dot ne s’est pas limité à surveiller des métriques. Il peut aussi faire avancer des builds Cloudflare, observer l’état de GitHub et effectuer des corrections lorsque c’est nécessaire. Ce n’est donc pas seulement une couche de surveillance qui détecte puis rapporte : lorsqu’il en a l’autorisation, il peut descendre sur le terrain et agir.
À ce stade, « avoir de l’initiative » n’est plus une formule sympathique mais une réalité opérationnelle : observer, réparer, vérifier puis continuer sans demander une nouvelle micro-instruction à chaque étape. On passe progressivement de « bon outil » à « opérateur réellement chargé du travail ».
On ne va plus chercher une réponse auprès de l’IA à chaque fois. On regarde le bureau d’un responsable et le graphique, le diagnostic et le résultat de la réparation sont peut-être déjà prêts.
« Une IA qui a de l’initiative » semble abstrait, mais en pratique c’est très concret : elle récupère à l’avance les questions que vous deviez autrefois penser à poser encore et encore.
Le véritable gain de productivité vient peut-être moins de réponses plus rapides que de la disparition de l’obligation humaine de se souvenir en permanence de ce qu’il faut encore vérifier.
Et dans la pratique, le Dot peut aller au-delà de l’observation. Il peut suivre l’état des builds Cloudflare, examiner ce qui se passe dans GitHub et avancer sur de vraies corrections lorsque les permissions et les règles de sécurité l’autorisent. Le comportement commence à passer de « j’ai trouvé le problème » à « je l’ai trouvé et je m’en suis occupé ».
À ce stade, on ne se dit plus « cela pourrait être prévenant », mais « c’est réellement prévenant ». L’humain n’a plus besoin de refaire à chaque fois le tour des dashboards, dépôts, statuts de build et tâches bloquées.
La relation ressemble moins à « donner du travail à une IA » qu’à consulter les résultats d’un opérateur qui surveillait déjà le système.
10. Conclusion : la magie n’est pas « toujours allumé », mais « toujours responsable »
Le changement important n’est pas l’apparition d’une nouvelle fenêtre de chat intelligente.
C’est le fait qu’une IA puisse conserver la responsabilité quand vous partez, travailler à travers des tâches planifiées et des applications connectées, puis reprendre au point de l’échec précédent au lieu de vous obliger à raconter toute l’histoire à nouveau.
Dots devient donc particulièrement intéressant comme superviseur de workflows récurrents instables : surveiller, récupérer l’inachevé, appeler un spécialiste seulement quand c’est nécessaire et poursuivre jusqu’à la vraie condition de fin.
C’est la version IA des lutins du cordonnier.
Mais le matin, ne vérifiez pas seulement que les chaussures existent. Vérifiez aussi qu’elles sont à la bonne taille.
Achever, pas seulement rapporter.
