UFO³ : orchestrer des agents Windows, Linux et Android avec un DAG de tâches

Deux produits dans un même dépôt, et un choix à faire avant l'installation

Le dépôt microsoft/UFO ne contient pas un outil mais deux niveaux d'usage que le README présente côte à côte. UFO² est décrit comme un Desktop AgentOS pour Windows : un agent unique, une boucle ReAct séquentielle, une intégration profonde avec le système d'exploitation et un mélange d'actions GUI et d'appels API. Galaxy, la partie UFO³, ajoute une couche d'orchestration multi-appareils au-dessus de ces agents. Le tableau comparatif du README donne la distinction la plus utile : côté UFO² le modèle de tâche est une boucle séquentielle, côté Galaxy c'est un graphe orienté acyclique de TaskStars avec dépendances et exécution parallèle. La cible n'est donc pas la même. Une personne qui veut automatiser le lancement d'une application Windows et remplir un formulaire n'a aucune raison de déployer Galaxy. Une personne qui doit faire dialoguer un poste Windows, une machine Linux et un téléphone Android autour d'une même requête a besoin de la couche supérieure, parce que UFO² seul ne fait pas de collaboration inter-appareils. Le README indique explicitement que cette collaboration croisée est absente de UFO² et qu'elle constitue la fonction centrale de Galaxy. Le public visé est donc double : développeur seul sur un poste Windows d'un côté, équipe d'automatisation avec parc hétérogène de l'autre. Le dépôt est publié sous licence MIT, la branche par défaut est main, et les versions récentes listées vont de 3.0.6 à 3.0.8 entre juin et août 2026.

La Constellation : comment une requête devient un graphe exécutable

Le mécanisme central de Galaxy tient en un mot employé par le README : Constellation. Une demande formulée en langage naturel est décomposée en un DAG structuré, dont les nœuds sont appelés TaskStars et dont les arêtes expriment des dépendances. Cette décomposition est dite déclarative, ce qui signifie que le graphe est produit avant l'exécution, puis soumis à un ordonnancement automatique. Le second principe de conception va plus loin : le graphe est vivant. Le README parle d'évolution continue pilotée par les résultats, avec des réécritures contrôlées et des ajustements dynamiques pendant l'exécution. Concrètement, si une TaskStar échoue ou renvoie un résultat inattendu, le graphe peut être modifié à chaud plutôt que de faire échouer toute la requête. C'est la différence de fond avec la boucle ReAct de UFO², où chaque étape suit la précédente de manière linéaire. L'exécution est décrite comme asynchrone et parallèle, avec une correspondance entre appareils fondée sur les capacités déclarées. Les rôles sont nommés : le ConstellationAgent s'occupe de la planification et de l'évolution du graphe, le TaskOrchestrator coordonne l'exécution. La communication passe par un protocole maison, l'Agent Interaction Protocol, présenté comme une couche de coordination sécurisée reposant sur WebSocket, avec tolérance aux pannes et reconnexion automatique. Le README mentionne aussi des verrous de sécurité et une correction formellement vérifiée, sans donner de détail sur la méthode de vérification employée.

Ce que la documentation ne tranche pas

Trois zones restent floues à la lecture du README. D'abord la vérification formelle annoncée au point 3 des principes de conception : aucune référence d'outil, aucun modèle, aucune propriété n'est citée. Une affirmation de correction formelle sans artefact vérifiable n'a pas de valeur pratique pour un évaluateur. Ensuite le protocole AIP. Il est décrit comme sécurisé et tolérant aux pannes, mais le README ne précise ni le mécanisme d'authentification, ni le format des messages, ni la politique de reconnexion. Pour un système qui traverse des machines, c'est l'information la plus importante à obtenir avant tout déploiement. Enfin la liste des plateformes prises en charge : Windows, Linux, Android sont nommés, avec la mention « more coming ». Aucun état d'avancement par plateforme n'est fourni. Un agent Android peut exister en tant que modèle de développement sans être au même niveau de maturité que l'agent Windows, hérité de UFO². Le README signale par ailleurs que Galaxy est en développement actif, alors que UFO² est étiqueté LTS. Cette asymétrie est un signal de stabilité, pas un défaut caché, mais elle doit entrer dans la décision.

Mise en route : ce que le dépôt donne réellement

Le README ne contient pas de bloc d'installation complet pour Galaxy. Il renvoie vers deux ressources distinctes : le fichier galaxy/README.md dans le dépôt et une page de démarrage rapide sur la documentation en ligne, à l'adresse microsoft.github.io/UFO/getting_started/quick_start_galaxy/. Pour UFO², le pointeur est ufo/README.md. La documentation complète est hébergée sur microsoft.github.io/UFO/. Les prérequis de langage sont visibles dans les badges du README : Python 3.10 ou 3.11. Aucune commande pip, aucun nom de paquet, aucune clé de configuration n'apparaît dans le texte fourni. C'est une limite réelle du matériau : je ne peux pas indiquer ici la commande d'installation ni le fichier de configuration à éditer, parce qu'ils ne figurent pas dans le README. La seule chose vérifiable est la structure du dépôt, avec un répertoire galaxy/ et un répertoire ufo/, chacun avec son propre README. Le chemin de migration conseillé par le README pour les utilisateurs existants de UFO² est de continuer à l'utiliser tel quel, puis de l'adopter progressivement comme agent Windows à l'intérieur de Galaxy. Cette progressivité est le point le plus concret du document.

La courbe d'apprentissage annoncée par le projet lui-même

Le tableau comparatif du README évalue la complexité de UFO² comme allant de simple à modérée, et celle de Galaxy de simple à très complexe. La courbe d'apprentissage est notée faible pour l'un, modérée pour l'autre. L'installation est marquée comme facile pour UFO² et modérée pour Galaxy. Ces notations viennent du projet, pas d'un test indépendant, et il faut les lire comme une auto-évaluation. Elles restent cohérentes avec l'architecture : un DAG avec réécriture à chaud, un protocole de communication inter-machines et une correspondance par capacités demandent plus de configuration qu'un agent unique. Le point de friction probable n'est pas l'écriture du graphe mais l'enrôlement des appareils : chaque machine doit exposer ses capacités et rejoindre la couche AIP. Sur un parc de trois machines, cela reste gérable. Sur un parc de trente, la question de l'inventaire des capacités et de la cohérence des versions d'agents devient un sujet d'exploitation à part entière. Le README ne traite pas ce cas.

Quand UFO³ est le mauvais outil

Si votre besoin tient sur une seule machine Windows, Galaxy ajoute une couche de coordination dont vous ne tirerez rien. Vous payez la complexité du DAG, du protocole AIP et de l'orchestrateur pour un graphe qui n'aura jamais plus d'une branche utile. UFO² fait le travail avec une boucle séquentielle et une installation décrite comme facile. Le README recommande lui-même ce chemin aux débutants et aux workflows simples. Autre cas défavorable : un environnement où toutes les cibles ne sont pas Windows. Le README nomme Linux et Android, mais sans indiquer de niveau de maturité par plateforme, et la mention « more coming » suggère que la couverture s'étend. Bâtir une chaîne de production sur un agent Android dont l'état n'est pas documenté revient à prendre un risque non mesuré. Troisième cas : une équipe qui a besoin d'un engagement de support. UFO² est étiqueté LTS, Galaxy non. Si votre contrainte est la stabilité sur plusieurs années, l'étiquette compte plus que la liste de fonctionnalités.

Face à un cadre d'orchestration générique

La comparaison pertinente n'est pas avec un autre agent de bureau, mais avec un orchestrateur de workflows généraliste du type de ceux qui exécutent des tâches conteneurisées ou des appels d'API selon un graphe déclaratif. La différence d'approche est nette. Un orchestrateur classique suppose que chaque étape est un programme déterministe avec une entrée et une sortie typées. UFO³ suppose l'inverse : les étapes sont des agents qui pilotent une interface graphique, donc des étapes non déterministes dont le résultat peut varier d'une exécution à l'autre. C'est précisément ce qui justifie la réécriture dynamique du graphe décrite dans le README : un ordonnanceur classique n'a pas besoin de modifier son graphe en cours de route, parce que ses nœuds ne se trompent pas de la même façon. En contrepartie, UFO³ hérite de l'instabilité de ses nœuds. Un graphe qui se réécrit à chaud est plus difficile à reproduire qu'un graphe figé, et le débogage d'une exécution passée suppose de conserver la trace des réécritures. Le README ne décrit pas d'outil de rejeu. C'est un manque pour un usage en production, où l'on veut comprendre pourquoi une exécution d'hier a pris un chemin différent.

Maintenance, versions et licence

Le rythme de publication est documenté : v3.0.6 le 6 juin 2026, 3.0.7 le 12 juin 2026, v3.0.8 le 10 août 2026, avec un dernier push sur main au 9 septembre 2026. Trois versions en trois mois indiquent un projet en mouvement, ce qui est cohérent avec l'étiquette de développement actif de Galaxy. Pour une équipe, cela implique de suivre les versions de près, surtout si le format du graphe ou le protocole AIP évoluent entre deux publications. Le README ne fournit pas de politique de compatibilité entre versions mineures, ni de guide de migration entre 3.0.6 et 3.0.8. La licence est MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Le README ne mentionne aucune clause additionnelle, aucun fichier de brevet, aucune restriction de champ d'usage. Cela ne constitue pas un avis juridique : si le projet est intégré dans un produit distribué, faites relire le fichier LICENSE et les mentions de copyright par votre service juridique. Deux articles arXiv sont cités dans les badges, 2511.11332 et 2504.14603. Ils décrivent probablement l'architecture, mais je ne les ai pas lus et je ne peux pas dire ce qu'ils contiennent.

Conclusion éditoriale

UFO² convient aux équipes qui automatisent un poste Windows unique et veulent un chemin d'installation court. Galaxy s'adresse à celles qui doivent coordonner plusieurs machines hétérogènes et accepter un statut de développement actif, sans engagement LTS. Avant d'adopter Galaxy, vérifiez trois points dans la documentation en ligne : la disponibilité réelle d'un agent pour vos cibles Linux ou Android, le schéma de configuration du ConstellationAgent et la façon dont les verrous de sécurité sont posés entre appareils. Si l'un de ces trois points reste flou après lecture, restez sur UFO², qui est documenté comme supporté à long terme et peut servir plus tard d'agent Windows dans Galaxy.

Sources officielles

1. License: MIT
2. microsoft/UFO on GitHub
3. Project website
4. README
5. Releases