Q01Les agents vont-ils déplacer des tickets Jira tout seuls ?
Non, pas par défaut. Chaque écriture vers Jira, Linear, ClickUp, Monday ou Notion tourne derrière un gate HITL. L'équipe d'agents IA prépare le ticket, le changement de status ou le commentaire et le PM approuve avant que ça n'atterrisse. Tu peux lever le gate par template une fois que le pipeline gagne la confiance.
Q02Les agents peuvent-ils raisonner sur nos données de projet ?
Trois voies. Le Static context attache la charte, la DoD et le RACI à des personas spécifiques à chaque run. L'outil rag_retrieve permet à ProjectScoper et DeliveryLead de tirer depuis les PRD précédents, les retros et les risk logs à la demande. La mémoire cross-run reporte le risk register de la semaine dernière dans la revue de cette semaine pour que les owners de mitigation ne se réinitialisent pas.
Q03Ça remplace Asana, Monday, Linear ou ClickUp ?
Non, ça se branche à côté. Melaya est la couche de planification, de scoring et de synthèse. Ton équipe garde Jira, Linear, ClickUp, Monday ou Asana comme système d'enregistrement. Le gate HITL passe les updates approuvés à l'outil que tu paies déjà pour que le workflow engineering ne change pas.
Q04Comment éviter que les updates de status sonnent IA ?
Les brouillons citent le ticket exact, la PR, la note de retro ou le graphe de vélocité qu'ils ont lus. Les reps peuvent exiger une citation sur chaque claim comme pré-check HITL, et le StakeholderManager réutilise les tournures de tes cinq derniers updates approuvés chargés dans le knowledge store.
Q05Sur quels modèles peut-on faire tourner l'équipe d'agents IA ?
N'importe lesquels. Claude sur PMOSynth là où la qualité de raisonnement justifie le coût, GPT sur les personas de rédaction, un Ollama local sur RiskRegister quand les données ne peuvent pas sortir de ton réseau. Chaque agent choisit son propre modèle et provider.
Q06À quelle vitesse une équipe delivery peut-elle lancer son premier pipeline ?
Avec Jira ou Linear connecté, le pipeline de status hebdomadaire est un canvas à 4 nœuds : tirer les tickets, scorer les risques, rédiger l'update, approuver. La plupart des équipes le déploient dans une session de travail et ont la première note de status revue dans la boîte du sponsor le jour même.
Q07Comment ça gère l'audit et la gouvernance ?
Chaque run logge chaque étape, chaque appel d'outil, chaque invocation de modèle et chaque décision d'approbation. Replay n'importe quel run à tout moment. Les programmes régulés utilisent le journal d'audit comme preuve pour les steering committees et les auditeurs externes.
Q08Peut-on restreindre quelles personas peuvent écrire dans quel système ?
Oui. L'accès aux outils est par agent. ScrumMaster peut lire chaque backlog mais n'écrire que dans un seul projet Jira. PMOSynth peut lire le risk register mais ne poster que sur un canal de board privé. Les outils scopés sont le défaut, l'accès large est en opt-in.
Q09Pourquoi utiliser Melaya plutôt que n8n ou Zapier pour l'automatisation de la gestion de projet ?
Utilise Melaya quand le travail nécessite de la planification, pas juste des triggers. n8n, Zapier et Make exécutent des étapes trigger-action prédéfinies et sont plus forts en connecteurs pour les automatisations linéaires simples. Une mise à jour steerco n'est pas linéaire : le Delivery Lead de Melaya évalue chaque milestone via RAG, PMO Synthesis rédige la vue de santé prête pour le board, et chaque écriture Jira dans le bundle project_mgmt marque une pause pour approbation humaine.
Q10Peut-on réutiliser un même crew de delivery pour chaque programme du PMO ?
Oui. Sauvegarde n'importe quelle run réussie comme template réutilisable et pointe le même crew Project et Program sur le prochain programme. Le bundle knowledge reconstruit le store par workflow à partir des charters, PRDs et des steerco decks précédents de ce programme, donc le Project Scoper et Risk Register travaillent sur un contexte frais pendant que le canvas, les allowlists d'outils et les gates d'approbation restent identiques.
Q11Comment suit-on ce que coûte la production d'un rapport de statut ou d'une mise à jour du registre des risques ?
Melaya rapporte le coût par résultat accepté, pas les dépenses brutes en tokens. Les traces de run complètes montrent chaque étape que le crew a prise, avec des motifs d'échec typés quand une run ne passe pas la barre. Le routage de modèles par étape parmi 23 fournisseurs te permet de mettre un modèle peu coûteux sur la synthèse Jira et un plus puissant sur la recommandation go ou no-go de PMO Synthesis.
Q12Les emails sponsors et les données de capacité peuvent-ils rester dans notre propre réseau ?
Oui. Melaya tourne dans le cloud ou sur ton runner local, et les étapes sensibles peuvent rester sur le runner. Le bundle email lit les fils sponsors et fournisseurs là-bas, le bundle calendar lit les calendriers des squads pour la vraie capacité, et les écritures en staging comme gmail_send et gcal_create_event attendent encore derrière des gates HITL (validation humaine) avant que quoi que ce soit ne parte.
Q13Comment le crew maintient-il le registre des risques à jour entre les revues mensuelles ?
Le persona Risk Register recalcule la probabilité et l'impact chaque semaine, assigne des responsables et des mitigations, et escalade tout risque scoré au-dessus de 15 directement au sponsor. Le bundle messaging poste ensuite le digest risques du lundi sur ton canal de delivery, soumis à une gate HITL (validation humaine) et logué dans le même audit trail que les écritures Jira, donc une dépendance tier-1 qui glisse remonte dans le digest hebdomadaire, pas à la prochaine revue mensuelle.