Les agents IA pilotent votre pipeline photo

Le 3 septembre 2026, OpenAI a lancé GPT-6 Astra, un modèle conçu pour piloter un logiciel par lui-même : remplir des formulaires, naviguer sur des pages web, mener des tâches en plusieurs étapes sur un ordinateur, pas seulement répondre à des questions à leur sujet. Le co-fondateur d'OpenAI lui-même y a vu un pas vers l'AGI. Que cette étiquette soit méritée ou non, la direction est claire.

Ce n'est pas l'histoire d'une seule entreprise. Claude d'Anthropic sait piloter un ordinateur depuis 2024. Operator d'OpenAI a fait de même à partir de 2025. Le mode agent de ChatGPT a fusionné les deux idées en un seul produit plus tard la même année. Astra est l'entrée la plus récente et la plus capable d'un schéma désormais profond de plusieurs lancements : des systèmes IA qui ne se contentent plus de dire quoi faire, ils le font eux-mêmes.

Ce basculement change ce que "conçu pour l'IA" doit signifier pour tout logiciel qu'un agent pourrait toucher. Une interface de chat convient à une personne. Un agent a besoin d'autre chose : un point d'accès qu'il peut appeler, un job qu'il peut démarrer et vérifier, un résultat qu'il peut récupérer une fois le travail terminé. Un logiciel qui n'expose qu'un champ de prompt et un bouton de téléchargement est une impasse pour un agent, quelle que soit la qualité du modèle derrière.

Ce qu'On-Model avait déjà bien fait

Nous avons abordé cette idée côté acheteur dans L'infrastructure IA pour l'imagerie mode : On-Model a été conçu comme une infrastructure qu'un distributeur intègre à son pipeline, pas comme un outil créatif qu'une personne ouvre pour créer une image. Cette distinction se révèle importante aujourd'hui, pour une raison totalement différente. Une infrastructure, par définition, est conçue pour être appelée par autre chose qu'une personne qui clique dans une interface. On-Model dispose d'une API REST, d'ID de jobs asynchrones, de webhooks et de traitement par lots depuis bien avant que "IA agentique" ne devienne un terme courant. Nous n'avons pas construit cela pour des agents. Nous l'avons construit parce qu'un pipeline de production doit tourner sans supervision, et il se trouve que c'est exactement la forme d'interface dont un agent a également besoin.

Que l'appelant soit une personne dans l'application, un script dans une tâche cron nocturne, ou désormais un agent autonome agissant sur un objectif exprimé en langage naturel, l'interaction sous-jacente est identique :

L'agent reçoit un objectif
        │
S'authentifier (jeton Bearer)
        │
Créer ou réutiliser un projet
        │
Téléverser chaque image produit  →  reçoit un file_id
        │
Démarrer un job — model swap / flat-to-model / packshot / garment recolor
        │
Suivre la progression (flux d'événements ou webhook)  →  status: completed
        │
Récupérer les résultats  →  URLs des images finales
        │
Transmettre au PIM / DAM / site marchand

Rien ne change dans l'API pour qu'un agent puisse la piloter. C'est tout l'intérêt.

Ce qu'un agent appelle concrètement

Un framework d'agent ne lit pas notre documentation, il lit une définition d'outil. Voici à peu près la forme que vous enregistreriez pour le point d'accès model-swap, construite directement à partir des champs de requête réels :

{
"name": "start_model_swap_job",
"description": "Swap an approved brand identity onto one or more uploaded product images and start an async job.",
"parameters": {
  "type": "object",
  "properties": {
    "identity_code": {
      "type": "string",
      "description": "The approved model identity to apply"
    },
    "project_id": { "type": "string" },
    "images": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Uploaded file_id values"
    },
    "swap_options": {
      "type": "object",
      "properties": {
        "model": { "type": "string", "enum": ["auto", "onda", "nano_banana_2"] },
        "num_variations": { "type": "integer", "minimum": 1, "maximum": 4 },
        "use_anchor": { "type": "boolean" }
      }
    }
  },
  "required": ["identity_code", "project_id", "images"]
}
}

Appelez-le, récupérez un job_id, puis interrogez-le régulièrement ou laissez un webhook vous prévenir quand c'est terminé. Tout le reste — flat-to-model, create-packshot, garment recolor — suit le même schéma : demander un job, le laisser tourner, récupérer les résultats. C'est documenté de la même façon, que le lecteur soit un développeur ou que ce qui génère la requête soit un modèle de langage.

Une tâche de lundi matin

Imaginez qu'une responsable des opérations dise à son agent : "La collection de sweats d'automne vient d'arriver. Applique notre identité Priya et prépare les tailles Zalando et Shopify avant le point d'équipe." Un agent compétent n'a pas besoin d'une personne pour traduire cela en clics. Il peut :

1. Vérifier le flux PIM pour les nouvelles références et récupérer les images flat-lay.
2. Téléverser chacune et collecter les valeurs file_id.
3. Démarrer un job model-swap avec identity_code réglé sur l'identité de marque approuvée, use_anchor activé pour que le mannequin ait l'air de la même personne sur tout le lot.
4. Suivre le flux d'événements du job jusqu'à ce que chaque image indique completed.
5. Récupérer les résultats, puis soit redimensionner selon les spécifications marketplace dans le même appel, soit démarrer un job de suivi avec la bonne width/height pour chaque plateforme.
6. Renvoyer les fichiers finaux dans le DAM et répondre "terminé" avec un lien.

C'est exactement le même déroulé qu'une coordinatrice de production suit aujourd'hui à la main, simplement exécuté par quelque chose qui ne dort pas entre les étapes 2 et 5. Rien dans cette séquence n'est spéculatif. Ce sont six appels à une API qui existe déjà.

Pourquoi toute la catégorie va dans cette direction

Les agents computer-use vont continuer à s'améliorer précisément sur le type de travail fastidieux, en plusieurs étapes et structuré dont un pipeline de contenu est fait : vérifier le flux, traiter le lot, router la sortie, confirmer l'arrivée. Cela favorise les logiciels conçus dès le départ comme une infrastructure plutôt que ceux qui n'ont jamais attendu qu'une personne à l'autre bout de la requête. Un outil à champ de prompt n'offre rien à quoi un agent peut s'accrocher. Un système construit autour de jobs, d'ID et de vérifications de statut est exactement la surface qu'un agent est conçu pour piloter.

On-Model n'a pas eu à devenir compatible avec les agents. Il l'était déjà, parce que nous l'avons construit comme une infrastructure dès le départ, pas comme un outil créatif. GPT-6 Astra ne crée pas ce fait, il le rend simplement pertinent d'une nouvelle façon. À mesure que les agents prennent en charge une part croissante du travail opérationnel que les équipes mode font aujourd'hui à la main, les plateformes qui parlent déjà API, pas seulement chat, sont celles qu'un agent peut réellement prendre en main.

• Intégration API — points d'accès, démarrage rapide et exemples de code pour intégrer On-Model à un pipeline
• Documentation API — authentification, forme complète des requêtes/réponses pour chaque type de job
• L'infrastructure IA pour l'imagerie mode — pourquoi nous avons construit On-Model comme un pipeline, pas un champ de prompt
• Cinq types d'entrée, une seule plateforme — les types de job qu'un agent (ou une personne) peut démarrer
• Essayer On-Model gratuitement — obtenez un jeton API et lancez votre premier job en quelques minutes