Oracle a annoncé Fusion Companion et Fusion Agentic Home le 26 octobre 2026, en décrivant une manière pour les employés d’énoncer un objectif métier et de laisser Fusion coordonner les transactions, les flux de travail, les approbations et les agents nécessaires pour l’exécuter. La conséquence en matière de gouvernance est que la sélection du flux de travail devient une partie de ce que les responsables des applications d’entreprise doivent évaluer, au même titre que les autorisations sur chaque action prise individuellement.
Oracle indique que ces capacités fonctionnent dans le cadre de contrôles d’entreprise déjà établis. L’annonce est une description fournie par l’éditeur, et non une preuve d’efficacité des contrôles testée de manière indépendante. Elle ne précise ni calendrier daté de disponibilité générale, ni tarification, ni éligibilité universelle des clients à Companion.
Ce qui change dans l’interaction
Selon l’annonce d’Oracle, Companion utilise le contexte métier, les données et les autorisations de l’utilisateur pour sélectionner et coordonner le travail. Des outils d’IA pris en charge, tels que ChatGPT, peuvent fournir un point d’entrée ; Agentic Home apporte une expérience Fusion native pour la délégation et le suivi d’avancement. Oracle décrit également une coordination avec d’autres systèmes d’entreprise ainsi qu’une escalade des décisions qui exigent un jugement humain.
La couverture distincte d’AgentsCalling met en avant les détails de déploiement encore non résolus et distingue Companion des agents spécialisés qui réalisent le travail. Elle n’a pas testé le produit de manière indépendante. Le fait de citer ChatGPT n’établit pas un accès pour tous les utilisateurs de ChatGPT ni ne prouve un protocole d’intégration particulier.
L’analyse de Maetra ci-dessous porte sur la manière dont un responsable applicatif pourrait évaluer cette conception allant de l’objectif au flux de travail. Il s’agit de tests d’acceptation proposés, et non de constats sur des déploiements Oracle.
Passez en revue le flux de travail sélectionné avant de mesurer la réussite
Une évaluation utile commence par un objectif métier défini de façon étroite et par un enregistrement du flux de travail que le système sélectionne. Le réviseur doit pouvoir voir quelles applications, quels agents et quelles transactions ont été impliqués, ainsi que les raisons de leur pertinence pour la demande. Une tâche terminée, à elle seule, apporte peu de preuves quant à l’éventuelle exécution d’une action inutile en cours de route.
Par exemple, imaginons qu’un employé de la chaîne logistique demande des options pour résoudre une commande en retard. Cette tâche hypothétique pourrait autoriser l’analyse et la préparation d’une recommandation, tout en réservant les changements de fournisseur à une décision distincte. L’évaluation doit vérifier que le flux de travail sélectionné respecte cette distinction. Elle doit aussi montrer comment le responsable peut découvrir qu’une nouvelle intégration a introduit une autre action possible.
Gardez le test centré sur le modèle d’autorité réel de l’organisation. Certaines actions autorisées peuvent s’exécuter automatiquement ; d’autres peuvent exiger une revue ou être interdites. Les références d’Oracle aux contrôles d’approbation ne doivent pas être interprétées comme la promesse que chaque étape reçoit une approbation humaine.
Vérifiez la transaction composée
Plusieurs étapes individuellement autorisées peuvent produire un résultat qui dépasse la demande initiale. Les responsables applicatifs doivent donc tester à la fois les autorisations des composants et l’effet métier final. Un flux de travail qui modifie un enregistrement, envoie un message et déclenche un processus en aval a besoin d’une explication claire de la manière dont ces étapes s’articulent.
Un dossier d’acceptation compact pourrait inclure :
| Test | Éléments de preuve à demander |
|---|---|
| Une demande avec deux flux de travail plausibles | Chemin sélectionné, contexte pertinent et actions résultantes |
| Une étape hors de l’autorité de l’employé | Refus ou escalade, sans effet non autorisé |
| Une autorisation retirée pendant une tâche longue | Comportement observé à la prochaine action ayant un effet |
| Une demande répétée après une interruption | Preuve des étapes déjà réalisées et traitement des doublons |
Il s’agit de questions d’acheteur. Elles n’impliquent pas qu’Oracle fournisse actuellement un champ de journal particulier, un comportement d’annulation donné ou un mécanisme précis de prévention des doublons. Demandez le comportement pris en charge, puis vérifiez-le dans la configuration que vous prévoyez de déployer.
Suivez l’autorité au-delà des frontières système
La coordination entre systèmes ajoute un autre point de revue. Lorsqu’un flux de travail sort de Fusion pour rejoindre une application ou un agent externe, identifiez l’identité agissante, l’autorité déléguée et les données envoyées au-delà de la frontière. Déterminez quel système détient l’enregistrement résultant et comment un opérateur enquête sur une défaillance partielle.
Commencez par un inventaire des capacités qui nomme les outils et les transactions mis à la disposition du flux de travail sélectionné. Reliez chaque effet significatif à la politique qui l’autorise et à la preuve conservée ensuite. Si le flux de travail peut choisir parmi plusieurs agents, vérifiez comment les changements apportés à cet ensemble sont revus. Une nouvelle voie vers le même objectif métier peut modifier le risque opérationnel, même lorsque les mots de l’utilisateur restent inchangés.
La décision de déploiement doit reposer sur des résultats observés à ces frontières et sur des réponses écrites aux questions de disponibilité. Une démonstration convaincante du chemin nominal est utile, mais elle ne peut pas établir ce qui se passe lorsqu’une autorisation change, lorsqu’une dépendance tombe en panne ou lorsqu’une demande est répétée.
L’annonce d’Oracle fait de ce sujet un problème d’évaluation actuel pour les équipes Fusion applicatives et de plateforme. Avant d’étendre le travail délégué, choisissez un objectif, cartographiez ses transactions possibles et testez les frontières d’autorité qui en résultent. La documentation de Maetra explique l’inventaire des capacités et les contrôles de politique qui peuvent aider à structurer cette revue. Elle n’établit pas une intégration Oracle et ne remplace pas les contrôles des applications qui exécutent le travail.