GPT‑5.6 et ChatGPT Work : du modèle au projet supervisé
OpenAI présente GPT‑5.6 comme une famille de modèles et ChatGPT Work comme un environnement capable de mobiliser ces capacités sur des fichiers, des applications et des livrables pendant plusieurs heures.
Le 9 juillet 2026, OpenAI a annoncé trois variantes principales : Sol, modèle phare ; Terra, pensé comme un équilibre entre capacité et coût ; et Luna, orienté efficacité. Une variante ultra vise les tâches les plus exigeantes. L’annonce attribue à cette famille des progrès en programmation, travail de connaissance, cybersécurité et sciences. Ces affirmations viennent d’OpenAI : elles décrivent la position du fournisseur et ses évaluations, pas une validation indépendante de tous les usages possibles.
La nouveauté la plus structurante tient à la parallélisation. OpenAI indique que le mode ultra peut coordonner plusieurs agents sur des axes distincts. Au lieu d’enchaîner recherche, analyse, production et contrôle dans une seule boucle, le système répartit ces branches puis réunit leurs résultats. Le modèle reste le moteur de raisonnement ; l’agent lui donne des outils, un contexte, une mission et des règles d’arrêt.
ChatGPT Work rend cette organisation visible dans un produit. OpenAI le décrit comme un agent capable d’avancer à travers des applications et des fichiers, de créer des feuilles de calcul, présentations, documents ou applications Web, et de travailler sur une durée longue. L’utilisateur peut suivre la progression, répondre à une question, changer la direction et approuver les actions importantes. L’autonomie annoncée n’efface donc pas la responsabilité humaine : elle déplace l’intervention vers le cadrage, les permissions, les points de décision et la validation finale.
AlphaEvolve : optimiser du code contre une mesure explicite
Disponible de manière générale sur Gemini Enterprise Agent Platform depuis le 9 juillet 2026, AlphaEvolve est présenté par Google Cloud comme un agent de découverte et d’optimisation de code fondé sur Gemini.
AlphaEvolve ne reçoit pas une demande vague du type « améliore ce système ». Le processus publié par Google Cloud comporte quatre étapes : définir un algorithme de départ et le problème ; mesurer les candidats avec une fonction de score ; optimiser en explorant des variantes ; puis appliquer le résultat à l’environnement de production. La fonction d’évaluation peut combiner exactitude, performance et contraintes opérationnelles. Elle transforme un objectif métier en critère testable.
Ce cadre permet à l’agent d’explorer davantage de solutions sans disposer du dernier mot. L’entreprise possède le problème, le code initial, les métriques et la décision de déploiement. Google Cloud cite des tests dans la logistique, les semi-conducteurs, la génomique, le calcul haute performance et les services financiers ; chaque résultat reste lié au protocole décrit.
Google rapporte par exemple que Coolblue a utilisé AlphaEvolve sur une prévision de demande à 28 jours. Après environ 200 itérations, l’entreprise indique une amélioration de plus de 5 % par réduction de la WMAPE par rapport à sa solution existante. Le score combinait le court terme, l’horizon complet et une pénalité en cas de sous-prévision. Ce n’est pas la preuve qu’un agent améliore automatiquement toute prévision : c’est l’illustration d’un agent efficace lorsque la qualité attendue est mesurable avant le lancement.
Pourquoi plusieurs agents plutôt qu’un seul
Une architecture multi-agents décompose un processus en responsabilités spécialisées, puis organise la circulation de données entre elles avec des sorties contrôlées.
Le 14 juillet 2026, AWS a détaillé un système construit par Thrad.ai avec Strands Agents et Amazon Bedrock AgentCore. Avant cette automatisation, l’équipe commerciale consacrait selon AWS entre 30 et 45 minutes à la recherche de chaque prospect dans six sources. Le système répartit désormais la découverte de tendances, l’enrichissement, l’analyse et la rédaction entre quatre agents. Deux collectent en parallèle, un troisième attribue un score, le dernier prépare un message conforme aux règles de marque.
La valeur ne vient pas seulement du nombre d’agents. Chacun possède une responsabilité, des outils et un contrat de sortie validé avec Pydantic. Une donnée au mauvais format est arrêtée avant l’étape suivante. Le score combine plusieurs critères pondérés, le profil client recherché et une décroissance temporelle. AWS précise aussi que les signaux sont triangulés avant de déclencher une analyse coûteuse.
AWS compare deux modes de coordination. Un graphe suit des transitions déterministes, faciles à auditer. Un essaim autorise des transferts plus dynamiques : un agent d’analyse peut redemander du contexte à un agent de recherche. Le choix ne devrait pas être idéologique. Pour une procédure réglementée, un graphe explicite peut être préférable. Pour une enquête incertaine, une coordination plus souple peut apporter de la profondeur, à condition de fixer des limites de tours, de coût et de permissions.
Nova Act : tester des parcours Web par la vision et l’action
Amazon Nova Act est un modèle multimodal capable d’observer des captures d’écran, d’identifier des éléments interactifs et d’agir dans un navigateur à partir du contexte visuel.
La proposition décrite par AWS le 14 juillet 2026 concerne le test d’expérience utilisateur, pas seulement la vérification fonctionnelle. Une automatisation classique dépend souvent de sélecteurs et de scripts écrits pour une interface précise. Nova Act traite l’écran comme une information visuelle : il examine la mise en page, repère des contrôles et choisit l’action suivante. AWS affirme que cette approche peut mieux tolérer certains changements d’interface et contenus dynamiques qui fragilisent des scripts rigides.
L’architecture publiée va au-delà d’un agent qui clique. Une première couche transforme la documentation en scénarios, une orchestration déclenche leur exécution, puis plusieurs navigateurs peuvent fonctionner en parallèle. Une couche d’analyse rapproche enfin journaux, captures et résultats. AWS recommande une approche hybride : générer une couverture de base, puis ajouter manuellement les cas critiques et limites.
Nova Act ne rend donc pas Selenium ou Playwright obsolètes. Les tests déterministes restent utiles pour des garanties reproductibles et des contrôles précis. Un agent visuel apporte une autre observation : que se passe-t-il lorsqu’un système tente d’atteindre un objectif comme un utilisateur, avec plusieurs chemins possibles ? La combinaison peut révéler des problèmes de compréhension ou de navigation que la seule réussite technique d’un scénario ne montre pas.
Les agents métier ont besoin de données traçables
Un agent ne peut agir de façon fiable sur un métier documentaire que si les pièces sont classées, découpées, extraites, évaluées et reliées à une trace vérifiable.
Le cas Built Technologies publié par AWS le 15 juillet 2026 illustre ce préalable dans le financement immobilier. Built gère des projets représentant, selon AWS, plus de 500 milliards de dollars. Les documents y sont nombreux, hétérogènes et déterminants pour les décisions. L’entreprise a construit sur Amazon Bedrock un moteur d’intelligence documentaire qui classe les fichiers, les sépare, extrait les informations, évalue leur qualité et applique un raisonnement adapté au métier.
AWS décrit ce moteur comme une base pour des produits agentiques, et non comme un simple formulaire de questions-réponses. La chaîne conserve les étapes et les résultats intermédiaires afin que les utilisateurs puissent comprendre l’origine d’une donnée. Des traitements qui prenaient des jours peuvent, d’après Built et AWS, être ramenés à quelques minutes sur des centaines de types de documents. Cette performance annoncée dépend néanmoins de la qualité des modèles, des schémas, des contrôles et des documents entrants.
Avant de confier un processus à un agent, l’entreprise doit savoir quelles sources font autorité, quelles informations doivent être citées et qui valide les exceptions. Sans provenance, une réponse peut être fluide mais impossible à défendre. Une chaîne traçable permet de comparer, corriger et auditer les décisions.
GPT‑Red : l’autonomie augmente aussi la surface d’attaque
GPT‑Red est un modèle interne de red teaming automatisé qu’OpenAI entraîne à rechercher des attaques contre ses propres systèmes afin d’améliorer la robustesse des modèles de production.
Un agent utile lit des pages, des fichiers, des e-mails et des sorties d’outils. Chacune de ces surfaces peut contenir une instruction cachée qui tente de détourner la mission. Le 15 juillet 2026, OpenAI a expliqué entraîner GPT‑Red par auto-jeu : le modèle attaquant est récompensé lorsqu’il provoque un échec valide, tandis que plusieurs modèles défenseurs apprennent à résister et à terminer la tâche initiale. OpenAI maintient GPT‑Red séparé des produits publics.
Dans une reproduction interne d’une arène d’injections indirectes, OpenAI rapporte une attaque réussie dans 84 % des scénarios pour GPT‑Red, contre 13 % pour les participants humains, en ciblant GPT‑5.1. L’entreprise affirme aussi que GPT‑5.6 Sol produit six fois moins d’échecs sur son benchmark direct le plus difficile que son meilleur modèle de production quatre mois auparavant. Ces chiffres mesurent des protocoles internes précis ; ils ne prouvent ni une sécurité universelle ni la disparition des injections de prompt.
Le cas d’un agent gérant un distributeur montre la matérialité du risque. OpenAI indique que GPT‑Red a préparé des attaques en simulation puis obtenu trois actions non autorisées contre le système de production, dont des modifications de prix et l’annulation d’une commande. Plus un agent dispose d’outils puissants, plus les permissions minimales, les confirmations, les environnements isolés, les journaux et les tests adversariaux deviennent indispensables.
Ce qu’une entreprise peut automatiser en 2026
Les cas officiels observés dessinent une grille pragmatique : automatiser les étapes répétables et mesurables, garder une validation humaine aux moments irréversibles ou difficiles à évaluer.
Les agents annoncés en juillet ne partagent pas un unique niveau d’autonomie. Certains préparent des livrables, d’autres explorent du code, testent une interface ou structurent des documents. Pour décider, il faut examiner la fréquence de la tâche, la disponibilité d’une mesure, la qualité des sources, le coût d’une erreur et la possibilité de revenir en arrière.
Recherche et production documentaire
Un agent peut rassembler des informations autorisées, produire une première synthèse, structurer une feuille de calcul ou préparer une présentation. La supervision doit vérifier les sources, les calculs, la confidentialité et la conformité du livrable avant diffusion.
Optimisation mesurable
Lorsque l’entreprise peut définir une fonction de score et un banc de test, un agent peut explorer des variantes d’algorithmes ou de paramètres. Le déploiement reste soumis à une revue, à des essais séparés et à un plan de retour arrière.
Tests de parcours et contrôle qualité
Des agents visuels peuvent exécuter de nombreux parcours, varier les instructions et signaler des frictions. Ils complètent les tests déterministes et l’observation humaine ; ils ne remplacent pas les critères d’acceptation ni les tests critiques reproductibles.
Traitement de documents métier
La classification, l’extraction et la comparaison peuvent être accélérées si chaque donnée reste liée à son origine. Les exceptions, montants sensibles, obligations légales et décisions finales doivent conserver une voie d’escalade humaine.
Coordination de spécialistes
Un système multi-agents devient pertinent lorsque plusieurs sources et outils imposent des expertises distinctes. Des contrats de sortie, des budgets, des limites de tours et une observabilité commune évitent que la coordination ne devienne opaque ou coûteuse.
Les limites à maîtriser avant la production
Un agent peut se tromper dans son raisonnement, mal utiliser un outil, suivre une instruction adverse, dépasser un budget ou produire un résultat impossible à justifier.
La première limite est l’évaluation. Une démonstration réussie ne garantit pas un taux d’erreur acceptable en situation réelle. Il faut des scénarios représentatifs, des exceptions, une mesure et un suivi des régressions. Les chiffres des fournisseurs restent attachés à leurs environnements et ne remplacent pas un test local.
La deuxième limite est organisationnelle. Un agent traverse des services, des documents et des permissions appartenant à plusieurs équipes. Les responsables doivent définir ce qu’il peut lire, écrire, envoyer ou supprimer et les seuils imposant une confirmation. Une journalisation et une personne responsable comptent davantage qu’une promesse générale d’autonomie.
La troisième limite est économique. Plusieurs agents peuvent réduire le temps humain tout en augmentant le nombre d’appels, la latence et la supervision. Pour un processus stable, une règle ou un script reste souvent plus rapide, moins cher et plus fiable. L’agent est utile lorsque l’incertitude exige une interprétation ; l’automatisation déterministe lorsque le chemin est connu.
Questions fréquentes
Un modèle transforme des entrées en sorties. Un agent ajoute un objectif, des outils, une mémoire et une boucle d’action. Il est dit autonome lorsqu’il peut choisir certaines étapes selon ce qu’il observe, toujours dans un périmètre de permissions et de règles défini.
Plusieurs agents sont utiles quand le processus exige des sources, outils ou critères réellement distincts. Chaque spécialiste peut avoir un contrat de sortie contrôlé, puis transmettre son résultat à une étape d’analyse ou de production.
Google Cloud décrit une étape d’application après définition, mesure et optimisation. En pratique, l’entreprise reste responsable du banc de test, des métriques, de la revue et de la décision de déploiement.
Non. Nova Act apporte une navigation fondée sur la vision et l’action, utile pour varier des parcours. Les outils déterministes restent importants pour les contrôles reproductibles et les garanties fonctionnelles précises.
Aucun des documents officiels étudiés ne permet de conclure à une sécurité absolue. GPT‑Red illustre au contraire la nécessité de tests adversariaux, de permissions minimales, de validations et de protections en couches.
Par une tâche fréquente, documentée, mesurable et réversible : recherche assistée, préparation d’un livrable, classification ou test exploratoire. Les actions sensibles doivent rester soumises à une validation explicite.
Conclusion
Les annonces de juillet 2026 ne montrent pas des agents capables de gérer seuls une entreprise. Elles montrent quelque chose de plus utile : des systèmes qui avancent sur un projet long, explorent des variantes mesurées, coordonnent des spécialistes, utilisent une interface et structurent des données métier. Leur valeur apparaît lorsque l’objectif, les outils, la mesure et la validation sont conçus ensemble.
L’entreprise qui veut passer en production doit donc résister à deux raccourcis. Le premier consiste à appeler « agent » toute automatisation. Le second consiste à confondre autonomie et absence de contrôle. Les cas d’OpenAI, Google Cloud et AWS convergent sur un principe : plus le système peut agir, plus son périmètre, ses traces, ses évaluations et ses points d’approbation doivent être explicites.
