Missions Milian : l'automatisation par l'IA pilotée par les événements avec des garde-fous clairs

Famulor a enrichi les Missions Milian avec Mission Studio. Depuis la mise à jour du 30 août 2026, les Missions peuvent être exécutées non seulement manuellement ou selon un calendrier, mais aussi en réponse à des événements de l'espace de travail. Un appel terminé, un nouveau message, une réservation, un prospect, un webhook ou tout événement provenant d'un système connecté peut désormais servir de point de départ à un travail en arrière-plan. Ce nouveau déclencheur n'est qu'une partie de la nouveauté : l'objectif, le contexte, les connexions, les actions autorisées et les limites d'exécution sont désormais regroupés dans une version publiée.

Points clés

• Mission Studio centralise les déclencheurs, les accès, les exécutions et les versions dans un espace de travail unique.
• Les Missions pilotées par les événements réagissent aux activités de l'espace de travail ; les Missions manuelles et planifiées existantes restent inchangées.
• Chaque version publiée fixe le déclencheur, les filtres, les ressources, les connexions aux applications, les groupes d'actions et les limites d'exécution.
• Les exécutions sont visibles, traitées dans l'ordre et traçables via le statut, la consommation de crédits et les transcriptions.
• Les Missions événementielles sont actuellement une fonctionnalité en version bêta de l'espace de travail.

Quoi de neuf dans Mission Studio ?

Selon la documentation des Missions Milian de Famulor, une Mission est une tâche versionnée pour Milian, le copilote de l'espace de travail. Elle s'exécute en arrière-plan sans nécessiter d'onglet de navigateur ouvert, que ce soit à la demande, selon un calendrier ou désormais après un événement. Mission Studio organise la configuration en Vue d'ensemble, Déclencheur, Accès, Exécutions et Versions. Les Missions existantes basées uniquement sur un calendrier ne sont pas migrées automatiquement ; leur première modification dans Studio crée un nouveau brouillon.

Une Mission publiée possède exactement un déclencheur. En plus des lancements manuels et planifiés, Studio prend en charge les événements issus d'appels, de conversations, de messages, d'e-mails, de réservations, de prospects, de webhooks entrants, de systèmes CRM et d'applications connectées. Des filtres ET/OU permettent d'affiner le déclencheur en utilisant les champs d'événement éligibles. Le modèle opérationnel passe donc d'une logique de « vérification chaque matin » à une logique de « réponse immédiate dès qu'un événement pertinent survient ».

Ceci diffère des actions en cours d'appel lors d'une conversation en direct. Les actions en cours d'appel effectuent un travail pendant qu'un assistant parle avec un client. Les Missions, quant à elles, gèrent un travail de fond indépendant, initié manuellement, selon un calendrier ou par un événement de l'espace de travail.

Des calendriers aux événements : pourquoi est-ce important ?

Les calendriers restent utiles pour les rapports quotidiens et les revues hebdomadaires. Cependant, pour les événements opérationnels, ils introduisent soit un temps d'attente, soit un sondage inutile. Un déclencheur événementiel lance une Mission au plus proche du moment ayant généré le travail. Parallèlement, la version publiée empêche toute modification fortuite de modifier instantanément la logique active.

L'écosystème plus large des agents débat des mêmes problèmes opérationnels. Un fil de discussion très suivi sur Hacker News concernant les flux de travail durables se concentre sur la reprise, les tentatives, la surcharge liée au versionnage, l'observabilité et le coût réel des opérations. Il s'agit d'un signal de la communauté, et non d'une preuve d'efficacité. L'étude SKILL.nb souligne également le versionnage, les portes d'exécution et les preuves auditables comme mécanismes de fiabilité pour les flux de travail réutilisables des agents. Mission Studio applique cette logique opérationnelle aux tâches réelles de l'espace de travail.

Trois modèles pratiques pour les Missions pilotées par les événements

1. Suivi après un appel

Un appel terminé peut lancer une Mission qui évalue le contexte disponible et, dans la limite de ses actions autorisées, prépare un brouillon de suivi, une tâche ou un résumé interne. Les filtres doivent restreindre le déclencheur aux cas nécessitant réellement un suivi. Cela évite les vérifications par lots trop larges et maintient le flux de travail proche de l'interaction client.

2. Enrichir les nouveaux prospects dans des limites définies

Un nouveau prospect peut déclencher une Mission utilisant des ressources approuvées de l'espace de travail et des connexions aux applications enregistrées. Un objectif utile est délibérément restreint : rassembler les informations pertinentes, structurer l'enregistrement et préparer l'étape suivante. Les équipes ayant besoin d'informations web à jour peuvent combiner le flux de travail avec des recherches appropriées ou des outils d'agent, mais uniquement lorsque ces outils sont explicitement inclus dans les accès de la Mission.

3. Transformer les réservations et les messages en travail de suivi

Une réservation, un e-mail entrant ou un message peut lancer un travail de fond tel que la préparation d'une liste de contrôle interne, la notification de l'équipe responsable ou la production d'un compte-rendu concis. Ce modèle complète la planification automatisée sur plusieurs canaux sans encombrer la conversation client avec une logique de processus supplémentaire.

Des limites claires plutôt qu'un accès illimité pour l'agent

Mission Studio rend le périmètre opérationnel autorisé visible avant la publication. La version active inclut le déclencheur, les filtres, les ressources référencées, les connexions aux applications enregistrées, les groupes d'actions autorisés et les plafonds de crédits, d'appels d'outils et de durée d'exécution. Milian ne reçoit que ce périmètre publié lors d'une exécution.

Les connexions sont vérifiées à nouveau immédiatement avant chaque exécution. Une Mission refuse de s'exécuter si une connexion accordée est manquante, expirée, désactivée ou rompue. Pour les webhooks entrants, un propriétaire ou un administrateur de l'espace de travail peut générer un secret qui n'est affiché qu'une seule fois et envoyé dans l'en-tête X-Automation-Secret. La rotation du secret invalide immédiatement la valeur précédente.

Ces contrôles s'alignent sur l'approche du guide de gouvernance de l'IA vocale de Famulor : définir d'abord l'objectif et les autorisations, exécuter l'agent ensuite, et examiner les exécutions et les transcriptions après coup.

Versionnage et exécutions : ce qui reste traçable

La publication crée une version immuable. Les modifications ultérieures restent dans un brouillon tandis que la version active continue de s'exécuter. La restauration d'une ancienne version crée également un nouveau brouillon au lieu de réécrire l'historique. Les membres peuvent enregistrer des brouillons ; les propriétaires et administrateurs de l'espace de travail peuvent publier ou mettre en pause. Les rôles de lecteur et de facturation restent en lecture seule.

Chaque déclencheur crée une exécution en arrière-plan visible. Les exécutions événementielles sont dédoublonnées et traitées une par une par Mission ; les événements supplémentaires attendent dans l'ordre FIFO au lieu d'être ignorés silencieusement. Le tableau de bord affiche la version active, la dernière et la prochaine exécution, le statut, la consommation de crédits et l'état d'attention. Selon la documentation, les transcriptions des exécutions sont conservées pendant dix jours.

Les échecs restent visibles. Une mutation externe potentiellement terminée n'est pas relancée automatiquement. Après examen de la transcription, une exécution terminée peut être relancée manuellement ; cela crée une exécution marquée séparément et liée à l'exécution source. Ce comportement aide à réduire le risque de duplication des actions externes.

Comment démarrer avec une Mission bien définie

1. Définissez un objectif précis : décrivez un résultat vérifiable plutôt qu'une mission ouverte.
2. Choisissez un déclencheur : utilisez un événement lorsqu'une réponse immédiate crée de la valeur ; un calendrier est souvent plus clair pour les rapports périodiques.
3. Ajoutez des filtres : limitez le déclencheur aux cas pertinents et testez les champs sélectionnés avec des exemples réalistes.
4. Restreignez le contexte et les actions : utilisez @ pour ne joindre que les ressources, connexions et outils nécessaires de l'espace de travail.
5. Définissez des limites d'exécution : choisissez les crédits maximum, les appels d'outils et la durée d'exécution correspondant à la tâche.
6. Examinez et publiez : inspectez l'objectif, le déclencheur, les filtres, les accès et les limites en tant que version immuable unique.
7. Observez les exécutions : examinez le statut, les transcriptions et l'état d'attention avant d'élargir le périmètre.

API REST et MCP pour les équipes techniques

Les Missions ne se limitent pas à la gestion par tableau de bord. L'API REST publique couvre la création, la lecture, la mise à jour, la suppression et l'exécution des Missions, ainsi que le listage et la relance des exécutions. Les mêmes capacités sont disponibles en tant qu'outils MCP avec des portées routines:read et routines:write distinctes. Les équipes exploitant des agents depuis des interfaces externes peuvent utiliser l'architecture décrite dans Famulor MCP avec ChatGPT et Claude comme contexte supplémentaire.

Questions fréquentes

Les Missions pilotées par les événements remplacent-elles les calendriers ?

Non. Les calendriers manuels, horaires, quotidiens, hebdomadaires et personnalisés restent disponibles. Les Missions planifiées existantes continuent de s'exécuter sans changement.

Que se passe-t-il lorsque les fonctionnalités en version bêta de l'espace de travail sont désactivées ?

Les Missions événementielles sont mises en pause et marquées comme nécessitant une attention. Les Missions manuelles et planifiées classiques restent actives.

Une Mission en cours peut-elle perdre des événements entrants ?

Selon la documentation de Famulor, les événements supplémentaires attendent dans l'ordre d'arrivée lorsqu'une Mission est déjà en cours d'exécution. Les exécutions événementielles sont également dédoublonnées.

Les versions précédentes sont-elles toujours traçables ?

Oui. Les versions publiées sont immuables. Les modifications et restaurations créent de nouveaux brouillons plutôt que de réécrire l'historique.

Conclusion : le travail piloté par les événements nécessite un cadre opérationnel

Mission Studio transforme les Missions Milian en bien plus que de simples tâches récurrentes. Les événements peuvent lancer le travail immédiatement, tandis que les versions publiées, les accès restreints, les limites d'exécution et les transcriptions assurent la traçabilité des opérations. Une bonne première implémentation consiste en un processus étroit et à faible risque avec une vérification de succès explicite. Activez les fonctionnalités en version bêta de l'espace de travail, ouvrez Missions Milian, et ne publiez qu'après avoir examiné conjointement le déclencheur, les filtres, les accès et les limites.