DevDay d’OpenAI : GPT-6.1 Sol, les agents Dots et un abonnement à 500 dollars au menu des annonces

GPT-6.1 Sol au DevDay : mesurer le gain avant de changer de modèle

Le DevDay d’OpenAI multiplie les annonces technologiques, mais une entreprise n’achète pas une conférence : elle paie des tâches accomplies. Pour savoir si GPT-6.1 Sol mérite une place dans une équipe, le bon réflexe consiste à partir de ses propres dossiers, pas d’un classement général.

Comparer GPT-6.1 Sol à Astra sur des tâches identiques

OpenAI place GPT-6.1 Sol entre GPT-6 Sol et GPT-6 Astra, avec une promesse simple : approcher les capacités du modèle le plus puissant pour une fraction de son prix. Sur le benchmark de développement logiciel DeepSWE v1.1 communiqué lors du DevDay, Sol atteint 75 % contre 74 % pour Astra. Les deux affichent 32 % sur le test de travail professionnel GDP.pdf.

Ces chiffres donnent une piste, pas un bon de commande. Une équipe qui maintient une boutique en ligne peut obtenir un excellent résultat sur une correction PHP et un résultat médiocre sur une migration de base de données. Le test utile ressemble donc à une semaine de travail ordinaire : dix tickets de code, dix analyses de documents et quelques demandes volontairement ambiguës.

Pour chaque tâche, il faut noter le résultat exploitable, le temps de reprise humaine et la dépense totale. Si un modèle coûte moins cher mais oblige un développeur à relire deux fois plus longtemps, l’économie de tokens s’évapore. Voilà une métrique solide, loin des captures d’écran où une démonstration réussit du premier coup.

Les limites annoncées méritent aussi leur place dans le protocole. Sur AutomationBench 1.0.6, Sol obtient 36 %, contre 41 % pour Astra et 40 % pour Claude Opus 5.5. En utilisation d’ordinateur, l’écart est plus serré : 71,5 % contre 73,5 % sur OSWorld 2.0. Pour des opérations qui traversent plusieurs logiciels, ces quelques points peuvent représenter davantage d’interventions humaines.

La recherche scientifique creuse l’écart : 57 % pour Sol et 68,1 % pour Astra sur Terminal-Bench Science 0.1. OpenAI indique également, sur un ensemble de questions difficiles, un taux d’erreur de 7,7 % pour Sol contre 3,9 % pour Astra. Selon le réglage de raisonnement et le test retenu, la différence de factualité varie ; il serait imprudent de transformer un seul chiffre en vérité universelle.

Calculer le prix d’une réponse plutôt que celui d’un million de tokens

La tarification API de Sol s’établit à 2 $ par million de tokens en entrée et 10 $ en sortie, contre 10 $ et 50 $ pour Astra. La lecture du cache revient à 0,10 $ par million, contre 1 $ pour Astra. Pour un service qui réutilise souvent les mêmes consignes, ce dernier poste peut peser lourd dans la facture.

Exemple fictif : une équipe prépare chaque jour cent fiches produit à partir de documents fournisseurs. Elle conserve ses règles éditoriales en cache, demande une proposition structurée, puis vérifie les caractéristiques techniques avant publication. Le modèle le moins cher devient intéressant si les fiches nécessitent peu de corrections ; il ne l’est plus si des caractéristiques inventées passent la relecture.

Claude Sonnet 5.5 affiche lui aussi 2 $ en entrée et 10 $ en sortie, tandis que le tarif annoncé pour la lecture de son cache est de 0,20 $. La comparaison des seuls prix reste trompeuse : OpenAI et Anthropic ne publient pas exactement les mêmes évaluations. Le vrai duel se joue sur un lot de tâches maison, avec le même barème de qualité pour chaque modèle.

Agents Dots : confier du travail continu sans céder les clés de l’entreprise

Les agents Dots changent la nature de la promesse d’OpenAI. Au lieu de répondre à une demande puis d’attendre la suivante, ces agents IA disposent d’un ordinateur dans le cloud et peuvent poursuivre des tâches dans la durée. Ils s’appuient sur GPT-6 Astra et sont conçus pour gagner en pertinence à mesure qu’ils interagissent avec leur utilisateur.

Le catalogue annoncé dépasse 4 000 connecteurs. C’est séduisant pour une équipe qui jongle entre CRM, messagerie, documents et outils de gestion. C’est également l’endroit où une démonstration brillante peut devenir un incident très banal : un mauvais droit d’accès, une donnée client copiée au mauvais endroit ou un message envoyé trop tôt.

Commencer par un agent Dots à faible risque

Un cas d’usage raisonnable pour une agence de communication à Bordeaux serait la veille commerciale. Un Dot pourrait relever les demandes reçues, rapprocher chaque prospect d’une offre existante et préparer un brouillon de réponse dans le CRM. La validation et l’envoi resteraient entre les mains d’une personne. Le gain attendu n’est pas « remplacer le commercial », mais réduire le temps perdu à recopier des informations.

Le déploiement peut suivre quatre étapes très concrètes :

• 🧭 Délimiter une mission : une source de données, un livrable précis et un responsable humain.
• 🔐 Limiter les permissions : lecture seule au départ, puis droits d’écriture sur un périmètre étroit.
• 🧪 Faire tourner un essai contrôlé : comparer les propositions de l’agent aux décisions prises par l’équipe.
• 📊 Mesurer les reprises : compter les erreurs, les demandes d’approbation et les minutes réellement économisées.

Pourquoi commencer petit alors que le produit promet des équipes entières d’agents ? Parce qu’un processus mal décrit ne devient pas meilleur quand on le réplique. Si la définition d’un prospect qualifié varie selon le commercial interrogé, l’agent apprendra surtout à reproduire cette confusion.

OpenAI prévoit l’accès aux Dots depuis ChatGPT sur ordinateur, mobile et web, ainsi que des échanges via Slack ou Teams. Le SMS est présenté comme une possibilité à venir. Ce choix d’interfaces compte : une équipe adopte plus facilement un outil qui intervient là où elle travaille déjà, sans imposer un nouveau tableau de bord à surveiller toutes les vingt minutes.

Faire des permissions un réglage métier, pas une formalité informatique

Sans configuration particulière, les Dots utilisent un système d’auto-évaluation des actions déjà associé à Codex. Selon le cas, une opération est autorisée, soumise à approbation ou bloquée. C’est un filet de sécurité utile, pas une raison d’ouvrir tout le CRM : l’approbation humaine reste nécessaire pour les paiements, les publications et les échanges sensibles avec des clients.

Les offres Pro et Business Premium donnent accès aux Dots ; une bêta concerne aussi les organisations Enterprise, Edu et Healthcare. Le premier agent est annoncé sans surcoût, avec des limites élargies temporairement pour certains travaux approfondis. Les tarifs futurs des agents supplémentaires et des réglages avancés doivent encore être précisés. Un responsable achats évitera donc de bâtir son budget annuel sur la gratuité du premier mois.

Pour les entreprises, les Specialist Dots disposent de leur propre identité et de leurs propres accès. Cette séparation facilite l’attribution des actions : un agent chargé du support ne devrait pas agir sous le compte personnel du directeur marketing. La valeur d’un agent permanent dépend autant de sa traçabilité que de son autonomie.

Avant de brancher vingt services, une question suffit à calmer l’enthousiasme : qui pourra expliquer, lundi matin, pourquoi l’agent a modifié une fiche client vendredi soir ? Si la réponse n’existe pas, le chantier prioritaire n’est pas l’automatisation. C’est la gouvernance du processus que l’on souhaite lui confier.

Abonnement à 500 dollars et mode ultrafast : calculer le coût de la vitesse

Le contraste a marqué cette édition du DevDay. Avant la série d’annonces, OpenAI a indiqué que le plan Pro à 200 $ offrirait deux fois moins d’usage, mesuré en équivalent de dépense API. Puis est arrivé Pro 500, un abonnement à 500 dollars par mois, avec les outils du plan Pro, des quotas au niveau maximal et l’accès au mode ultrafast.

Pour les professionnels, le sujet n’est pas de savoir si 500 $ « paraît cher ». Il faut déterminer combien coûte une tâche terminée, dans les limites réellement disponibles. Une équipe qui facture des audits techniques peut absorber cet abonnement si elle gagne plusieurs heures de production vérifiable. Un indépendant qui rédige quelques propositions commerciales par semaine risque surtout de payer pour une capacité inutilisée.

Réserver ultrafast aux tâches où chaque seconde compte

OpenAI annonce un facteur d’accélération pouvant atteindre huit, avec une vitesse proche de 300 tokens par seconde dans Codex. Côté API, l’option ultrafast multiplie les prix par six. Ces deux chiffres ne doivent pas être mis face à face comme si « huit fois plus rapide » garantissait « huit fois plus rentable ».

Une réponse affichée plus vite peut changer la donne dans un assistant utilisé en direct par un conseiller clientèle. Pendant un appel, quinze secondes de silence se ressentent. En revanche, pour analyser mille pages pendant la nuit, le gain de vitesse a peu de valeur si le rapport est attendu le lendemain matin. Le traitement standard peut alors suffire.

Une comparaison propre distingue trois durées : l’attente du modèle, le temps passé dans les outils externes et le temps de validation humaine. Si l’intelligence artificielle répond en deux secondes mais que le CRM met dix secondes à enregistrer une fiche, payer six fois plus cher le modèle ne résout presque rien. Le goulot d’étranglement se trouve ailleurs.

Voici un calcul simple, sur un scénario hypothétique. Une équipe traite 1 000 requêtes urgentes par mois. Si ultrafast économise vingt secondes sur chacune, le gain total représente environ cinq heures et demie. Il reste à comparer la valeur de ces heures au supplément facturé, puis à vérifier que l’accélération est bien perçue par l’utilisateur final. Une mesure en laboratoire ne remplace pas le chronomètre dans le produit.

Relire les quotas après la baisse du plan Pro

La réduction annoncée pour le plan à 200 $ complique les comparaisons historiques. Une entreprise qui consommait presque toute son allocation ne peut pas simplement reconduire son budget précédent. Elle doit relever ses usages par type de tâche, repérer les jours de pointe et calculer ce qui se passe lorsqu’un quota est atteint.

Le piège classique consiste à mélanger abonnement et API dans une même estimation. Un accès ChatGPT utilisé par un salarié, une application facturée au token et un service tiers consommant le quota d’un compte connecté ne produisent pas la même facture ni les mêmes contraintes. Un tableur avec quatre colonnes — outil, volume mensuel, limite et solution de repli — suffit souvent à faire apparaître les mauvaises surprises.

Pour une petite équipe SEO, le choix peut être très terre à terre : conserver le plan Pro pour la recherche et la relecture, utiliser l’API à prix standard pour les traitements en lot, puis réserver la priorité de vitesse à un outil client réellement interactif. Cette répartition est moins spectaculaire qu’un abonnement « maximal » pour tout le monde. Elle a le mérite de protéger la marge.

Il faut aussi tester les quotas dans une semaine chargée, pas pendant une démonstration tranquille. Une campagne qui démarre, plusieurs collaborateurs connectés et des révisions de dernière minute révèlent vite si la capacité promise couvre le travail réel. La bonne tarification est celle qui tient le mardi à 16 heures, quand tout le monde livre en même temps.

Decisions API, Codex et connecteurs : séparer les vrais nouveaux outils des mises à jour

Plus de vingt lancements lors d’un même DevDay, cela fait beaucoup de noms à ranger dans une feuille de route. La bonne méthode consiste à distinguer ce qui permet un nouvel usage de ce qui améliore un service déjà connu. Tout n’exige pas une migration ; tout ne mérite pas non plus d’être ignoré sous prétexte que l’annonce ressemble à un changement d’étiquette.

Utiliser Decisions API pour des choix bornés

La Decisions API répond à un besoin précis : choisir parmi des réponses définies à l’avance à partir d’un contexte textuel ou visuel. Propulsée par une version de GPT-6 Luna adaptée à cette tâche, elle est présentée en accès preview. Classification de contenus, orientation d’une demande et sélection de la prochaine action d’un agent figurent parmi les usages évoqués.

Prenons une boîte de réception commerciale. Une entreprise reçoit des demandes de devis, des questions de facturation et des messages sans rapport avec son activité. Plutôt que de demander à un modèle de rédiger librement une décision, elle définit trois destinations possibles et mesure combien de messages sont dirigés au bon endroit. Un quatrième état, « vérification humaine », évite de forcer les cas ambigus dans une mauvaise catégorie.

Le test doit inclure des exemples désagréables : message ironique, pièce jointe illisible, client qui mélange réclamation et nouveau projet. Une précision moyenne flatteuse ne compense pas un mauvais aiguillage des demandes importantes. Pour cet usage, le taux de faux routages coûteux et le volume de vérifications humaines valent mieux qu’un score unique présenté sans contexte.

L’Agents API prend désormais en charge l’utilisation native d’un ordinateur. Cette capacité élargit les scénarios, notamment quand un outil métier ne propose pas d’interface de programmation exploitable. Elle ajoute aussi une dépendance aux interfaces graphiques : un bouton déplacé ou une fenêtre inattendue peut casser un parcours. Avant de confier une tâche critique à cet accès, mieux vaut vérifier si une API classique ou une intégration directe existe.

Brancher les outils existants sans perdre la maîtrise des usages

OpenAI annonce également la possibilité d’utiliser un abonnement ChatGPT avec seize services tiers, dont Notion, Vercel et Devin. Les quotas sont alors prélevés sur le plan OpenAI connecté. L’avantage est clair pour l’utilisateur : moins de comptes à alimenter séparément. Pour l’administrateur, la question devient plus fine : quel service consomme quoi, et avec quelles données ?

Une équipe de développement peut, par exemple, apprécier de retrouver son accès au modèle dans un outil de déploiement et un assistant de code. Elle doit malgré tout documenter les droits accordés à chaque service et vérifier l’effet d’un pic de consommation sur le reste du travail. La commodité d’une facture regroupée ne dispense pas d’un suivi par usage.

Le partenariat annoncé autour de Bedrock Managed Agents vise, lui, les organisations déjà installées chez AWS. Déployer des agents managés depuis leur environnement habituel peut réduire les frictions d’adoption, à condition de vérifier les règles de sécurité, les coûts et les responsabilités entre fournisseurs. Une architecture familière ne rend pas automatiquement un projet simple.

D’autres nouveautés relèvent davantage de l’évolution continue : Codex Security Cloud prolonge un travail déjà présenté en version de recherche, tandis que Sites gagne la possibilité d’héberger des plugins après son lancement précédent. La question à poser à chaque fois reste la même : « Quel blocage concret cette mise à jour retire-t-elle ? » Si personne ne peut citer un blocage, le chantier peut attendre.

Un responsable digital peut trier ces annonces en trois piles : expérimenter maintenant, surveiller la disponibilité, ou ne rien changer. Ce tri évite le syndrome du tableau blanc rempli de logos et vide de résultats. Une nouveauté vaut du temps d’équipe lorsqu’elle raccourcit un processus mesurable, pas lorsqu’elle allonge une liste d’outils.

OpenAI face à Anthropic : organiser un test terrain après le DevDay

Avec GPT-6.1 Sol, les Dots et de nouveaux accès pour les développeurs, OpenAI cherche clairement à renforcer sa place dans l’intelligence artificielle professionnelle. La concurrence avec Anthropic ne se résume pourtant pas à désigner un vainqueur sur scène. Pour une entreprise, la question utile est plus sobre : quels modèles de langage produisent le meilleur résultat, sur ses données, au coût qu’elle peut supporter ?

Sol rapproche certaines performances d’Astra d’un niveau de prix bien inférieur. Cela ne signifie pas qu’il dépasse Claude Opus 5.5 partout, ni qu’Astra constitue automatiquement le meilleur choix pour chaque dossier. Les évaluations publiées ne couvrent pas toujours les mêmes tâches, avec les mêmes méthodes. Les placer dans un graphique unique sans précaution donnerait une impression de précision trompeuse.

Construire un banc d’essai avec des dossiers représentatifs

Imaginons un éditeur de sites qui gère un catalogue de 5 000 pages. Son équipe veut accélérer trois activités : corriger des problèmes de code, classer des opportunités éditoriales et préparer des mises à jour de contenus. Un test sérieux prélève des cas faciles, des cas pénibles et quelques pièges déjà rencontrés en production. Les données sensibles sont retirées ou protégées avant l’envoi aux services évalués.

Chaque modèle reçoit la même consigne et les mêmes informations. Deux personnes évaluent ensuite les résultats sans voir quel outil les a produits. Pour le code, elles vérifient les tests et le temps de correction ; pour l’éditorial, les affirmations factuelles et la qualité des sources ; pour le classement, les erreurs qui feraient perdre une vraie opportunité. Cette méthode prend un peu de temps, mais elle empêche l’effet « la première réponse avait l’air brillante ».

Le coût doit inclure les entrées, les sorties, le cache éventuel et les appels supplémentaires nécessaires pour corriger une réponse. Il faut aussi relever la latence, sans lui donner plus d’importance qu’elle n’en a pour un traitement différé. Sur les tâches où l’automatisation agit dans des logiciels, les validations humaines et les opérations ratées deviennent des lignes du calcul, pas des notes de bas de page.

Une grille simple attribue une note à la qualité, au temps de reprise et au prix par dossier terminé. Les coefficients dépendent du risque : pour une publication financière, l’exactitude domine ; pour un brouillon interne, le temps gagné peut compter davantage. Le gagnant peut alors varier selon l’usage. C’est normal, et souvent plus rentable qu’une politique imposant un modèle unique à toute l’entreprise.

Passer de l’essai à la production sans mauvaise surprise

Le lancement progressif constitue la suite logique. On peut d’abord soumettre des demandes réelles aux nouveaux outils sans utiliser leurs réponses, puis comparer celles-ci au traitement habituel. Vient ensuite un périmètre restreint, avec approbation humaine et possibilité de revenir immédiatement à l’ancien fonctionnement.

Les agents autonomes exigent une vigilance supplémentaire. Il faut conserver des traces d’action exploitables, fixer des limites de dépenses, prévoir la révocation des accès et identifier une personne responsable du processus. Ces garde-fous ne ralentissent pas un bon déploiement : ils évitent qu’une petite erreur répétée vingt-quatre heures sur vingt-quatre ne devienne un gros problème.

Enfin, les annonces d’OpenAI restent à lire avec leur niveau de disponibilité réel : produit accessible, bêta limitée, preview ou fonction promise pour plus tard. La même discipline s’applique aux prix, susceptibles de peser différemment selon les volumes et les options. Un plan d’action fondé sur une fonctionnalité encore indisponible n’est pas un plan ; c’est une attente mise en calendrier.

Pour une équipe qui veut agir dès maintenant, le premier mouvement est modeste : choisir vingt tâches réelles, relever leur coût actuel, puis comparer les solutions disponibles sur des critères écrits à l’avance. Le DevDay fournit des candidats. Le terrain, lui, décide lesquels méritent de rester.

Quel est le prix API annoncé pour GPT-6.1 Sol ?

OpenAI annonce 2 dollars par million de tokens en entrée, 10 dollars en sortie et 0,10 dollar pour la lecture d’un million de tokens en cache. Le coût réel dépend du volume et des réponses à reprendre.

Les agents Dots peuvent-ils travailler sans surveillance ?

Ils sont conçus pour effectuer des tâches en continu, mais leurs accès et leurs autorisations doivent être encadrés. Les actions sensibles gagnent à rester soumises à une approbation humaine.

À qui peut servir l’abonnement Pro 500 ?

Il s’adresse surtout aux professionnels capables d’utiliser régulièrement ses quotas élevés et le mode ultrafast. Il faut comparer le prix mensuel au nombre de tâches terminées et au temps réellement gagné.

Comment choisir entre GPT-6.1 Sol, Astra et un modèle concurrent ?

Constituez un lot de tâches représentatives, évaluez les résultats à l’aveugle et mesurez la qualité, les corrections humaines, la latence et le coût complet par tâche. Les benchmarks publiés servent de point de départ, pas de verdict.