Aller au contenu principal

Cas d'usage

La surface de Copera est volontairement générique — boards pour les données structurées, docs pour la prose, drive pour les fichiers, channels pour la messagerie. Le skill CLI enseigne à un agent les commandes ; ce qu'il en fait vous appartient. Cette page rassemble les motifs que nous voyons le plus souvent. Aucun n'est une fonctionnalité intégrée — chacun est un workflow que vous décrivez à l'agent, et (pour les récurrents) capturez comme skill de workflow afin que toute session future l'exécute à l'identique.


Boards : suivez le travail là où vit déjà votre équipe

Trier les tâches entrantes

Vous déposez un lien Sentry, un e-mail client, ou un collage depuis Slack. L'agent le classe comme une ligne dans votre board de suivi avec une sévérité inférée, le statut à Triage, et (pour haute sévérité) une notification postée dans votre channel d'alertes.

Ce que fait l'agent

  • Lit le schéma de votre table de suivi une fois (en cache).
  • Mappe votre saisie en texte libre → les bonnes valeurs de colonnes.
  • Crée la ligne et (conditionnellement) poste une notification.

Construisez cela avec un skill de workflow comme triage-bug ou triage-task. L'interview de l'agent capture quel board + table vous utilisez, quelles options de sévérité existent, et le channel de notification de votre équipe.

Pipeline d'ingénierie commerciale

Un board avec une ligne par demande technique entrante : quel client, quelle zone produit, ce qui bloque le deal, qui possède la réponse. L'agent classe les nouvelles demandes au fur et à mesure que vous les décrivez, met à jour la propriété/le statut au fil de l'eau, et fait remonter les lignes stagnantes dans votre revue hebdomadaire.

Ce que fait l'agent

  • Nouvelle demande → rows create avec la colonne LINK client résolue (recherche la ligne client par nom).
  • Changement de statut → rows update pour la colonne concernée.
  • Revue hebdomadaire → rows list filtré sur les lignes stagnantes, résumé dans un post de channel ou un doc généré.

Astuce : capturez cela comme deux skills de workflow distincts (sales-eng-intake et sales-eng-review) pour que le résumé hebdomadaire récurrent n'entraîne pas le surcoût de schéma de l'intake.

Onboarding client

Lorsqu'un deal se conclut, l'agent crée la ligne CRM du client, lie les contacts, génère un doc de kickoff depuis un modèle, le place sous le bon parent, et poste un message « kickoff scheduled » dans votre channel customer-success.

Ce que fait l'agent

  • rows create dans le CRM avec des colonnes LINK vers les lignes de contacts.
  • docs create sous le doc parent d'onboarding client, contenu depuis un modèle.
  • channels message send avec l'URL du doc.

Reporting de statut

Fin de semaine : l'agent interroge les lignes de votre tracker d'ingénierie mises à jour cette semaine, regroupe par propriétaire ou par statut, et poste un digest dans le channel de l'équipe. Ou génère un doc qui vit sous /Engineering/Weekly/.

Ce que fait l'agent

  • rows list (paginé si besoin).
  • Regroupe + résume en texte clair.
  • channels message send ou docs create.

Docs : Copera comme base de connaissances de votre agent

Copera Docs est un arbre markdown à l'échelle du workspace. Cela en fait un choix naturel pour les agents IA — une prose durable, consultable, versionnée que tout agent peut lire pour le contexte.

Lire pour le contexte (récupération de connaissances)

Vous demandez : « Quelle est notre politique sur la suppression des données clients ? » L'agent recherche dans l'arbre des docs, lit le(s) doc(s) correspondant(s), et répond à partir de la prose — en citant l'URL du doc pour que vous puissiez vérifier.

Ce que fait l'agent

  • docs search "customer data deletion" → trouve les docs correspondants.
  • docs content <doc-id> pour le meilleur résultat (en cache) → lit le markdown.
  • Répond à partir du doc, en citant la source.

Pourquoi cela fonctionne : le cache des docs signifie que les questions de suivi sur le même sujet ne re-téléchargent pas. Et comme la prose est la vôtre, l'agent arrête de deviner à partir des données d'entraînement.

Résumés de réunions hebdomadaires

Vous conservez les notes de réunion sous /Engineering/Meetings/ (ou ailleurs). L'agent lit les docs de réunion de la semaine dernière, extrait les décisions et actions, et poste le résumé comme un nouveau doc sous /Engineering/Weekly-Summaries/ avec des liens vers les réunions sources.

Ce que fait l'agent

  • docs tree --parent <meetings-folder> → liste les docs de réunion récents.
  • docs content <doc-id> pour chacun (lectures concurrentes s'il y en a beaucoup).
  • Synthétise le résumé + les actions.
  • docs create --title "Week of …" sous le dossier des résumés.
  • Optionnellement channels message send avec l'URL du résumé.

Créer et partager de nouveaux docs depuis une conversation

En plein appel, vous dites à l'agent : « Documente cet incident — ce qu'on a rencontré, le contournement, le propriétaire. » L'agent rédige le markdown à partir de votre conversation, crée le doc sous /Engineering/Incidents/, poste le lien dans votre channel d'incidents, et (si vous l'avez configuré) ajoute une ligne à votre board de suivi d'incidents.

Ce que fait l'agent

  • docs create --title "Incident: …" --content "<markdown>" sous le dossier des incidents.
  • channels message send avec le lien.
  • (Optionnel) rows create dans le board des incidents avec l'URL du doc comme colonne.

Revue de doc et suggestions d'édition

Vous pointez l'agent vers un brouillon de doc. Il lit le contenu, suggère des éditions en ligne (dans votre conversation), et sur votre approbation les applique avec docs update.

Ce que fait l'agent

  • docs content <doc-id> pour lire.
  • Propose des changements dans la conversation.
  • Sur approbation, docs update <doc-id> --content "<edited markdown>" (replace), ou docs update <doc-id> --operation append pour ajouter à la fin.
astuce

Docs comme contexte d'agent : si un skill de workflow a besoin de contexte de fond (la terminologie de votre équipe, votre guide de style, vos conventions de runbook), référencez les IDs de docs pertinents dans la prose du skill et demandez à l'agent de les lire au début de la procédure. Le cache des docs rend cela peu coûteux sur les exécutions suivantes.


Drive : workflows de fichiers

Organiser les envois par convention

Vous déposez des fichiers dans une conversation. L'agent les envoie vers le drive sous une structure de dossiers correspondant à la convention de votre équipe (p. ex. /<year>/<quarter>/<customer>/), en créant les dossiers au besoin.

Ce que fait l'agent

  • drive tree --parent <root> pour trouver la structure existante.
  • drive mkdir pour tout dossier manquant.
  • drive upload <file> --parent <resolved-folderId>.

Distribuer des rapports

L'agent génère un rapport (markdown ou sortie rendue), l'envoie vers un dossier drive partagé, et poste le lien vers le(s) channel(s) concerné(s) — en remplaçant la boucle typique « capture d'écran du dashboard, coller dans Slack ».

Ce que fait l'agent

  • Génère le rapport en local (ou comme doc + export).
  • drive upload report.pdf --parent <reports-folderId>.
  • channels message send avec l'URL du fichier depuis la réponse d'upload.

Workflows multi-surfaces

Les skills de workflow les plus utiles couvrent plusieurs surfaces Copera.

Digest de standup quotidien

L'agent interroge : lignes du board de sprint mises à jour depuis hier, activité récente des docs dans le dossier docs de l'équipe, envois drive dans les assets partagés. Synthétise en un résumé d'un message posté dans le channel de standup avant la réunion.

Résumé de point de contact client

Pour un client donné (résolu vers sa ligne CRM + lignes liées) : récupérer tous ses tickets ouverts, notes de réunion récentes, et tout asset drive qui leur est attaché. Générer un brief markdown d'une page que l'agent peut partager avant un appel client.

Rétrospective d'incident

Lorsque vous clôturez un incident : l'agent lit la ligne de l'incident dans le board des incidents, le doc d'incident, et toute ligne liée depuis le doc. Génère un doc de rétrospective sous /Engineering/Retros/ et le relie à la description de la ligne d'incident.


Ce qui va dans un skill de workflow vs ad hoc

Tous les cas d'usage n'ont pas besoin de devenir un skill de workflow. Règle empirique :

  • Ad hoc — découverte ponctuelle, lectures occasionnelles, exploration d'un board inconnu. Parlez simplement à l'agent ; le skill CLI s'en charge.
  • Skill de workflow — tout ce que vous faites plus de deux fois avec la même forme. Construisez-le une fois, exécutez-le à l'identique à chaque fois, partagez-le avec votre équipe. Voir Skills de workflow.