Zoho fait évoluer Catalyst 3.0 vers un environnement où les agents de programmation peuvent agir directement sur l'infrastructure cloud, et pas seulement produire du code. La version ajoute un serveur MCP actif, des compétences dédiées aux agents, une interface en ligne de commande non interactive et des intégrations avec Claude, Cursor, Codex et Gemini. Le changement important tient surtout au passage entre assistance au développement et exécution réelle sur la plateforme.
Dès qu'un agent peut créer une table, configurer l'authentification ou déployer une application, la question du contrôle devient aussi importante que celle de la qualité du code. Il faut savoir sous quelle identité il agit, quels droits lui sont accordés, quels outils il appelle et comment revenir sur une modification problématique. Catalyst 3.0 rapproche ces mécanismes de contrôle du chemin d'exécution de l'agent.
L'agent intervient désormais sur les ressources cloud
Selon Zoho, le serveur MCP de Catalyst permet aux agents compatibles de communiquer directement avec l'infrastructure et d'effectuer des opérations de déploiement ou de configuration. Le dépôt officiel de l'extension Cursor confirme cette approche : il fournit des compétences propres aux différents services, le contexte du projet et l'accès à des opérations sur les données, le cache et le stockage.
Cette architecture va plus loin que le schéma classique dans lequel l'agent modifie un dépôt tandis qu'une chaîne CI/CD distincte garde la main sur la production. Ici, l'interface destinée à l'agent atteint les ressources de la plateforme. Le gain potentiel est une chaîne de livraison plus courte, mais l'erreur d'un agent peut également avoir des conséquences plus larges.
Identité et droits deviennent des composants d'architecture
Zoho décrit un modèle dans lequel l'agent s'authentifie avec son propre ensemble d'autorisations configurables. Les commandes destructrices sont par ailleurs désactivées en mode non interactif. C'est un point essentiel pour les exécutions sans supervision : un agent ne devrait pas hériter automatiquement des privilèges du développeur qui l'a lancé.
En pratique, l'identité d'un agent doit être gérée comme celle d'un compte de service. Les équipes ont intérêt à appliquer le moindre privilège, à séparer les droits entre développement et production, et à conserver une validation humaine ou automatisée renforcée pour les changements sensibles. MCP n'est donc pas seulement une couche d'interopérabilité ; il participe à la frontière d'autorisation.
La traçabilité devient une exigence de livraison
Catalyst 3.0 regroupe les journaux applicatifs, les journaux de plateforme et les appels d'outils MCP. Zoho indique également que les modifications sont versionnées, attribuables et réversibles. En cas d'incident, cette combinaison doit permettre de reconstituer quel agent a appelé quel outil et quelle modification en a résulté.
Cela ne démontre pas que toutes les actions sont sûres. En revanche, cette traçabilité est une condition nécessaire pour le diagnostic, la gouvernance et la réponse aux incidents. Pour comparer des plateformes adaptées aux agents, le nombre de modèles pris en charge devient moins décisif que la qualité des contrôles d'identité, d'autorisation, de journalisation et de retour arrière.
Les chiffres de performance restent des affirmations du fournisseur
Zoho publie ses propres essais montrant des taux d'achèvement de tâches de l'ordre de 90 à 95 % lorsque les compétences d'agent et le contexte MCP sont activés. Ces résultats n'ont pas été établis par une évaluation indépendante et doivent donc rester présentés comme des chiffres du fournisseur.
Les éléments livrés sont plus faciles à vérifier : la page produit documente le serveur MCP, les autorisations limitées, la journalisation des appels d'outils et le versionnage, tandis que le dépôt officiel expose l'intégration Cursor et les compétences spécifiques aux services Catalyst. Les équipes peuvent donc évaluer le modèle d'exécution sans reprendre les performances annoncées.
Le choix porte aussi sur l'endroit où réside l'autorité de l'agent
Catalyst 3.0 illustre une évolution plus large de l'ingénierie agentique : les fournisseurs d'infrastructure ouvrent des opérations de production aux agents tout en intégrant les garde-fous destinés à limiter leur pouvoir.
Deux approches se dessinent. L'autorité peut rester dans un environnement d'orchestration externe, relié au cloud par les mécanismes d'automatisation habituels, ou être confiée à une interface native de la plateforme, où permissions et traces d'exécution sont directement liées à l'infrastructure. Cette seconde voie peut simplifier l'exécution, mais accroît aussi la dépendance envers le modèle de contrôle du fournisseur. La portabilité du processus agentique doit donc être évaluée séparément de celle de l'application.