Les logiciels métier deviennent directement pilotables par les coding agents

Illustration éditoriale — Les logiciels métier deviennent directement pilotables par les coding agents

Dans le moteur de jeu, le saut est concret : le plugin officiel de Unity pour Claude Code installe 29 skills, la Unity CLI et le serveur MCP de l’éditeur. L’agent peut inspecter la hiérarchie, modifier scènes et assets, exécuter du C# et utiliser les workflows documentés par l’équipe Unity.

Sanity applique le même principe au contenu. Son serveur MCP hébergé expose directement les requêtes GROQ, les releases et les mises à jour de documents avec connaissance du schéma. Un même coding agent peut ainsi passer du code au contenu structuré sans recopier manuellement le contexte ni réimplémenter les règles du produit.

Alteryx pousse ce mouvement vers les données d’entreprise en exposant workflows, datasets et logique métier gouvernée à des agents externes. Pour les développeurs, l’intégration change de niveau : au lieu d’enseigner chaque application par prompt, l’agent reçoit des opérations supportées, un contexte natif et des garde-fous maintenus par l’éditeur.

Les plateformes séparent le runtime d’agent, ses capacités installables et ses politiques

Illustration éditoriale — Les plateformes séparent le runtime d’agent, ses capacités installables et ses politiques

Le harness de Codex devient un service avec Agents API. Le développeur décrit tâche, modèle, tools et environnement, tandis qu’OpenAI gère sessions longues, compaction du contexte, recherche de tools et subagents. Le runtime peut toutefois rester dans un sandbox OpenAI, chez un partenaire ou dans l’infrastructure de l’équipe.

Google traite l’autre moitié du problème avec son Developer Plugin. Un bundle portable réunit skills, documentation et configuration MCP sous un manifeste commun, puis s’installe dans Antigravity, Claude Code ou Codex. L’objectif est de déplacer les capacités métier hors du prompt et d’éviter une configuration différente pour chaque coding agent.

Salesforce généralise ce pattern à l’entreprise avec son Enterprise AI Harness : contexte, actions, gouvernance, sécurité et routage de modèles sont réunis derrière un AI Control Plane. Pour les développeurs, l’agent devient donc une composition de runtime, capacités installables et politiques partagées, plutôt qu’un assemblage ad hoc reconstruit pour chaque interface.

Les agents longue durée quittent le chat pour des tâches persistantes qui reviennent au bon moment

Illustration éditoriale — Les agents longue durée quittent le chat pour des tâches persistantes qui reviennent au bon moment

Le chat synchrone devient un mauvais cadre pour les tâches qui durent. AWS publie Pizza Bot, où un agent travaille en arrière-plan puis dépose son retour dans `Unread` ou `Action` ; le thread conserve état, checkpoints et demandes d’approbation même si l’utilisateur change de client ou revient plus tard.

Meta applique le même rythme à Muse : le travail continue après fermeture de l’app et revient quand une décision humaine est requise avant un e-mail ou un achat. Paperclip pousse cette reprise dans le runtime : une approbation stockée réveille la tâche d’origine après redémarrage sans rejouer automatiquement une action distante incertaine.

Pour les développeurs, l’unité de conception n’est donc plus la session de chat mais une tâche durable. L’agent harness doit persister contexte et effets de bord, distinguer résultat, attente et autorisation, puis reprendre exactement au bon point. Notifications et écrans d’approbation deviennent des vues d’un état serveur, pas des ornements d’interface.

Sources