Atlassian Rovo : automatiser la planification et la livraison de projets avec l'IA (guide ops)

1. Ce que Rovo peut (et ne peut pas) faire pour vos projets

Rovo propose trois fonctionnalités pour aider à transformer vos données en actions :

• Recherche unifiée : interrogez simultanément Jira, Confluence et des apps tierces (Google Drive, Slack) en respectant les permissions utilisateur (F1). Exemple : Rovo peut rechercher les documents Confluence et messages Slack liés à un bug via Rovo Search ou un agent configuré.
• Agents spécialisés : des IA préconfigurées pour des tâches spécifiques, comme *Ops Expert* (surveillance des incidents JSM) ou *Jira Delivery Agent* (détection des risques de livraison) (F2). Ces agents peuvent être appelés via `/Rovo` dans Jira/Confluence ou intégrés dans des règles d'automatisation.
• Connecteurs tiers : synchronisez les données de Google Drive, GitHub ou SharePoint, avec un index mis à jour en cas de suppression (sauf pour GitHub, qui nécessite de désinstaller l'app *GitHub for Jira*) (F4).

Limites techniques à connaître

• Pas de planification automatique des sprints : Rovo ne crée pas de sprints ou de jalons sans validation humaine. Il peut identifier des risques de livraison (ex : retards sur des dépendances), mais l'action finale (ajustement des priorités) reste manuelle (F2).
• Dépendance aux permissions : si un utilisateur n'a pas accès à un document Google Drive, Rovo ne le lui affichera pas — même si l'agent est configuré pour le rechercher (F4). Vérifiez les permissions avant de connecter une app tierce.
• Périmètre des connecteurs : par défaut, Rovo indexe l'intégralité de l'espace de travail d'une app tierce (ex : tout votre Google Drive). Utilisez une blocklist pour exclure des dossiers sensibles (F6).
• Rétention des données : les inputs/outputs de Rovo Chat et des agents sont conservés 30 jours pour des raisons de sécurité. Les données tierces supprimées mettent jusqu'à 30 jours à disparaître de l'index (sauf GitHub) (F5).

2. 5 cas d'usage prioritaires pour ops/dev (avec exemples de templates)

Note : Ces workflows sont des exemples génériques inspirés de la documentation Atlassian. Testez-les avec vos données avant déploiement.

Voici des scénarios concrets pour automatiser des tâches répétitives, avec des templates Make.com ou n8n. Chaque template inclut :

• Un déclencheur (ex : création d'un ticket Jira) ;
• Une action Rovo (ex : appel d'un agent via API) ;
• Une action de suivi (ex : mise à jour du ticket).

2.1. Tri automatique des demandes Jira Service Management (JSM)

Problème : Les équipes support passent un temps significatif à trier manuellement les demandes.

Solution : Utilisez l'agent *Service Request Helper* pour classer les tickets par priorité et les router vers la bonne équipe. L'agent peut extraire des mots-clés des descriptions (ex : « facture », « accès VPN ») et proposer des labels automatiquement.

1. Déclencheur : Nouveau ticket créé dans JSM (webhook).
2. Action : Appel à l'agent *Service Request Helper* via l'API Rovo (endpoint : https://api.atlassian.com/rovo/agent/{agentId}/execute).
3. Action : Mise à jour du ticket avec les labels et la priorité suggérés.

Voir un exemple similaire en Python pour gérer les erreurs (ex : agent indisponible).

2.2. Surveillance des risques de livraison dans Jira

Problème : Les retards sur les dépendances (ex : une API externe non livrée) sont détectés trop tard, souvent lors des réunions de suivi.

Solution : L'agent *Jira Delivery Agent* analyse les tickets et identifie les risques (ex : tickets bloqués, dépendances non résolues). Il peut envoyer des alertes Slack ou mettre à jour un tableau de bord Confluence.

1. Déclencheur : Ticket Jira mis à jour (webhook).
2. Action : Appel à l'agent *Jira Delivery Agent* pour analyser les dépendances.
3. Condition : Si risque détecté → création d'une tâche dans le backlog de l'équipe concernée.

Documentation officielle pour configurer l'agent.

2.3. Nettoyage automatique du backlog Jira

Problème : Les backlogs Jira contiennent souvent des tickets obsolètes (ex : fonctionnalités abandonnées), ce qui complique la priorisation.

Solution : Créez un agent personnalisé dans Rovo Studio pour identifier les tickets inactifs depuis plus de 90 jours et suggérer leur archivage. L'agent peut utiliser l'outil MCP listJiraIssues pour récupérer les tickets et appliquer des filtres.

1. Déclencheur : Tous les lundis à 9h (planification).
2. Action : Appel à l'agent personnalisé via API Rovo.
3. Action : Envoi d'un rapport Slack avec les tickets à archiver.

Exemple de requête MCP pour lister les tickets inactifs :

{
  "tool": "listJiraIssues",
  "parameters": {
    "jql": "updated < -90d AND status != Done",
    "fields": ["key", "summary", "updated"]
  }
}

2.4. Synchronisation Slack ↔ Jira Service Management

Problème : Les demandes créées dans Slack sont souvent perdues ou dupliquées dans JSM.

Solution : Utilisez un agent Rovo pour synchroniser les conversations Slack avec les tickets JSM. L'agent peut créer un ticket JSM à partir d'un message Slack et mettre à jour le fil de discussion avec le statut du ticket.

1. Déclencheur : Nouveau message dans un canal Slack dédié (ex : #support).
2. Action : Appel à l'agent Rovo pour créer un ticket JSM (outil MCP createJiraIssue).
3. Action : Mise à jour du fil Slack avec le lien vers le ticket JSM.

Guide officiel pour configurer la synchronisation.

2.5. Résumé automatique des commentaires Jira

Note : Ce template utilise l'API OpenAI, dont l'usage peut engendrer des coûts selon votre abonnement.

Problème : Les tickets Jira avec des dizaines de commentaires deviennent illisibles, ce qui ralentit la prise de décision.

Solution : Créez une app Forge (comme dans ce tutoriel) pour résumer les commentaires d'un ticket en utilisant l'API OpenAI. L'app peut être déclenchée manuellement via un bouton dans le panneau Jira.

1. Déclencheur : Bouton « Résumer les commentaires » dans le panneau Jira.
2. Action : Récupération des commentaires via .requestJira().
3. Action : Appel à l'API OpenAI pour générer un résumé.
4. Action : Ajout du résumé comme commentaire dans le ticket.

Exemple de code pour appeler OpenAI :

const response = await fetch('https://api.openai.com/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${openAIKey}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    model: 'gpt-4',
    messages: [{ role: 'user', content: `Résume ces commentaires : ${comments}` }]
  })
});

3. Gouvernance et sécurité : les garde-fous à mettre en place

Rovo offre des garanties de conformité (SOC2, ISO 27001, HIPAA), mais son déploiement nécessite des précautions pour éviter les risques de *shadow AI* ou de fuite de données.

3.1. Permissions et périmètre des connecteurs

• Vérifiez les permissions avant de connecter une app tierce : Rovo synchronise les permissions existantes, mais ne les corrige pas. Par exemple, si un utilisateur a accès à un dossier Google Drive sensible, Rovo le lui affichera (F4). Utilisez des blocklists pour exclure des contenus spécifiques (ex : dossiers RH).
• Limitez le périmètre des connecteurs : par défaut, Rovo indexe l'intégralité de l'espace de travail d'une app tierce (ex : tout votre Google Drive). Pour Google Drive et SharePoint, configurez une blocklist pour exclure les dossiers sensibles (F6).
• Gérez les suppressions de données : les données supprimées dans une app tierce mettent jusqu'à 30 jours à disparaître de l'index Rovo (sauf GitHub, qui nécessite de désinstaller l'app *GitHub for Jira*) (F5). Pour les données critiques, désactivez le connecteur et attendez la suppression.

3.2. LLMs tiers : risques et bonnes pratiques

• Pas de rétention des données par les fournisseurs : Selon Atlassian, les fournisseurs de LLMs tiers (OpenAI, Anthropic, Google) ne stockent pas les inputs/outputs de Rovo, mais Atlassian les conserve 30 jours pour des raisons de sécurité (F8).
• Variabilité des réponses : Comme tout modèle probabiliste, les réponses des LLMs tiers peuvent varier. Testez vos agents avec des jeux de données réels avant déploiement. Pour les cas critiques, privilégiez les modèles auto-hébergés (Llama, Mixtral) (F8).
• Coûts des outils MCP : Les outils MCP (ex : createJiraIssue) peuvent être facturés selon votre abonnement Atlassian. Vérifiez votre consommation via le tableau de bord admin.

3.3. Conformité et résidence des données

• Résidence des données : Rovo prend en charge la résidence des données pour les clients Atlassian Cloud Premium/Enterprise. Vérifiez que votre région est couverte ici.
• HIPAA : Rovo peut être utilisé de manière conforme à HIPAA. Consultez le guide officiel pour les exigences spécifiques.
• Audit des agents : les agents Rovo peuvent être partagés entre équipes. Limitez l'accès aux agents sensibles via des agents vérifiés.

4. Comment étendre Rovo avec des outils techniques

Rovo expose des APIs et des outils pour interagir avec Jira et Confluence, mais leur utilisation nécessite des compétences techniques.

4.1. Les outils MCP : une API pour automatiser Jira/Confluence

Le serveur MCP d'Atlassian (intégré à Rovo) expose des outils pour interagir avec Jira et Confluence, organisés en groupes de permissions (read, write, delete). Voici les outils les plus utiles pour l'automatisation :

• getJiraIssue : Récupère un ticket Jira par ID ou clé.
• createJiraIssue : Crée un ticket Jira (nécessite le groupe executeWrite).
• transitionJiraIssue : Change le statut d'un ticket (nécessite executeWrite).
• getConfluenceContent : Récupère une page Confluence par ID.
• discover : Découvre dynamiquement des outils via une description en langage naturel et exécutés avec confirmation selon leur niveau de risque (executeRead, executeWrite, executeDestructive) (F11).

Exemple d'appel à l'outil createJiraIssue :

POST https://mcp.atlassian.com/v2/mcp/executeWrite
Headers:
  Authorization: Bearer {access_token}
  Content-Type: application/json
Body:
{
  "tool": "createJiraIssue",
  "parameters": {
    "projectKey": "PROJ",
    "issueType": "Task",
    "summary": "Corriger le bug #123",
    "description": "Le bug #123 bloque la livraison du sprint 5."
  }
}

4.2. Forge : étendre Rovo avec des apps personnalisées

Forge est le framework d'Atlassian pour créer des apps personnalisées. Vous pouvez l'utiliser pour :

• Créer des agents Rovo avec des outils spécifiques (ex : intégration avec une API interne) ;
• Automatiser des workflows complexes (ex : résumé de commentaires Jira avec OpenAI) (F12).

Exemple de manifeste Forge pour une app de résumé de commentaires :

modules:
  jira:issuePanel:
    - key: comment-summarizer
      function: main
      title: Résumer les commentaires
      icon: https://example.com/icon.png
  function:
    - key: main
      handler: index.run
permissions:
  scopes:
    - read:jira-work
    - write:jira-work
  external:
    fetch:
      backend:
        - api.openai.com

Voir le tutoriel complet pour implémenter cette app.

5. Pièges courants et comment les éviter

6. Prochaines étapes : par où commencer ?

Pour exploiter Rovo sans risque, suivez cette feuille de route :

1. Priorisez un cas d'usage simple : commencez par un workflow à faible risque, comme le tri automatique des demandes JSM (scénario 2.1) ou la synchronisation Slack/JSM (scénario 2.4).
2. Configurez les permissions et les connecteurs : vérifiez les permissions des apps tierces et configurez une blocklist pour exclure les données sensibles.
3. Testez les agents avec des données réelles : utilisez des jeux de données représentatifs pour valider la cohérence des réponses.
4. Déployez progressivement : commencez par une équipe pilote et étendez le déploiement après validation.
5. Surveillez les coûts et les performances : utilisez le tableau de bord admin pour suivre la consommation des outils MCP et les temps de réponse des agents.

Pour aller plus loin :

• Consultez notre guide sur les agents IA pour comprendre leur fonctionnement et leurs limites.
• Découvrez comment implémenter l'IA en entreprise sans perdre le contrôle sur les données.
• Explorez des exemples concrets d'automatisation en Python pour des cas similaires.