AI Boardroom — tutoriel complet

Objectif

À l'issue de ce tutoriel, vous aurez importé le bundle Scrydon Pack AI Boardroom dans votre tenant, créé une nouvelle instance pour la réunion de conseil fictive Helios Renewables AG Q1 2026, téléversé un dossier de conseil réaliste de huit documents, regardé six agents IA spécialisés produire un briefing exécutif consolidé, enregistré la réunion, et fait passer le procès-verbal généré par IA par le cycle de révision et d'approbation.

Marc, notre secrétaire de société fictif, guide ce parcours sur un tenant vierge. Tous les noms d'entités, administrateurs, chiffres et résolutions présents dans les documents de démonstration sont fictifs.

Prérequis

Vous disposez d'un déploiement Scrydon avec les surfaces agentic, ontology et analytics activées. Vous êtes connecté en tant qu'administrateur de workspace. Définissez les variables d'environnement suivantes dans votre shell pour l'étape d'importation :

export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"               # visible dans /settings/organization
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"  # ou collez depuis le navigateur

Étape 1 — Télécharger le bundle de pack

Le pack est un flux gzip compact (≈ 4 Kio) contenant pack.json, un ontology/manifest.json (les trois types d'objets et deux types de liens décrits ci-dessous), et process-flow/manifest.json. Aucun code exécutable.

Télécharger ai-boardroom-4.2.0.scrydon-pack.tar.gz

Ou depuis un terminal :

mkdir -p ai-boardroom-tutorial && cd ai-boardroom-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/ai-boardroom-4.2.0.scrydon-pack.tar.gz

Étape 2 — Inspecter le pack (optionnel mais recommandé)

Exécutez l'inspecteur SDK pour confirmer que l'archive est valide par rapport au schéma de runtime avant de la téléverser. L'inspecteur lit l'archive en mode streaming, applique les mêmes limites de sécurité que l'endpoint d'importation (10 Mo compressé, 20 Mo décompressé, 400 fichiers, pas de liens symboliques, pas de traversée de chemin), et exécute le contrôle de cycle de DAG de tâches sur le sous-répertoire process-flow/.

bunx @scrydon/sdk-authoring pack inspect ai-boardroom-4.2.0.scrydon-pack.tar.gz

Sortie attendue (abrégée) :

Pack:
  Package:  ai-boardroom@4.2.0
  Contents: ontology@1.0.0, process-flow@1.0.0
  Install order: ontology → process-flow
  ontology: ai-boardroom@1.0.0
  process-flow: ai-boardroom (3 stages)

Le sous-répertoire ontology déclare trois types d'objets (BoardMeeting, BoardDocument, ActionItem) et deux types de liens (DocumentDistributedAt, ActionItemFromMeeting). Les blocs ontologyContract des tâches et actions du sous-répertoire process-flow y font référence par slug. Lorsque vous téléversez le pack, l'importateur installe d'abord l'ontologie, interroge la branche fraîchement installée du tenant pour les ID de classe résolus, puis relie les slugs à ces ID avant de persister le flux — le tout dans une seule transaction DB.

Étape 3 — Téléverser le pack

Envoyez l'archive en POST à l'endpoint d'importation de pack de votre organisation. La réponse inclut l'ID de modèle attribué et le slug que vous utiliserez à l'étape 4.

curl -X POST "$SCRYDON_URL/api/packs/import?organizationId=$ORG_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@ai-boardroom-4.2.0.scrydon-pack.tar.gz"

Réponse 200 attendue :

{
  "packageId": "ai-boardroom",
  "version": "4.2.0",
  "bundleHash": "sha256:...",
  "ontology": {
    "branchId": "br_01HF...",
    "alreadyInstalled": false,
    "slugs": {
      "objectTypes": {
        "BoardMeeting": "ot_01HF...",
        "BoardDocument": "ot_01HF...",
        "ActionItem": "ot_01HF..."
      },
      "linkTypes": {
        "DocumentDistributedAt": "lt_01HF...",
        "ActionItemFromMeeting": "lt_01HF..."
      }
    }
  },
  "processTemplate": {
    "processTemplateId": "pt_01HF..."
  }
}

Si vous obtenez un 413, l'archive dépasse la limite de 10 Mo compressé. Le bundle livré fait ≈ 4 Kio, donc un 413 signifie que le fichier a été modifié — re-téléchargez-le.

Si vous obtenez un 409 system_template_conflict, le slug ai-boardroom est déjà détenu par le modèle système auto-installé. Créez un fork avec un slug personnalisé (voir la section « Personnaliser le bundle ») — ou utilisez directement le modèle système sans rien téléverser.

Étape 4 — Créer une nouvelle instance de réunion

Ouvrez votre déploiement Scrydon à $SCRYDON_URL/process-flows. La carte AI Boardroom (Helios Renewables Q1) doit apparaître sous le tag Governance. Cliquez sur Nouvelle instance depuis le modèle et donnez un nom à l'instance, par exemple Helios Q1 2026 Board Meeting.

L'instance s'ouvre sur la vue kanban par défaut (définie par defaultView dans le modèle). Vous devriez voir trois colonnes de stages :

• Preparation (14 tâches)
• Meeting (4 tâches)
• Post-processing (7 tâches)

La première tâche — Créer l'ordre du jour de la réunion — est débloquée et assignée à la persona executive. Toutes les autres tâches sont conditionnées par dependsOnTaskSlugs et apparaissent verrouillées.

Chaque tâche qui touche un document du dossier de conseil porte désormais un ontologyContract qui référence les ID de classe du tenant issus de l'étape 3 — ainsi, lorsque vous interrogerez plus tard « quelles tâches de flux de processus opèrent sur des instances BoardDocument ? », le graphe d'ontologie fournira une réponse typée.

Étape 5 — Définir l'ordre du jour

Ouvrez Créer l'ordre du jour de la réunion et utilisez l'ordre du jour de démonstration comme source de vérité.

Télécharger 01-agenda.md — ordre du jour fictif du conseil Q1 du 18 mars 2026 avec dix points, trois résolutions et une date limite de lecture préalable.

Collez l'ordre du jour dans l'éditeur de document de la tâche (l'action document), confirmez la date de réunion et la liste des participants, puis marquez la tâche comme terminée. Le runtime matérialise une instance d'objet BoardMeeting liée à cette tâche (le ontologyContract.writes de l'action déclarait objectType: "BoardMeeting"). Cela débloque la tâche suivante dans le DAG : Téléverser les documents du conseil.

Étape 6 — Téléverser le dossier du conseil

Ouvrez Téléverser les documents du conseil (assignée à la persona secretary). La tâche contient une seule action file_upload qui accepte le dossier du conseil de la réunion. Chaque fichier téléversé produit une instance d'objet BoardDocument liée à la réunion via le type de lien DocumentDistributedAt.

Téléchargez les huit documents réalistes du conseil Helios Renewables ci-dessous et déposez-les dans la zone de téléversement. Ils sont intentionnellement cross-référencés — les financiers référencent le dossier du CFO, le plan stratégique référence la proposition d'acquisition, le registre des risques référence la situation de la chaîne d'approvisionnement — afin que les agents IA disposent d'un contexte cohérent pour raisonner.

Pour récupérer les huit fichiers en une seule commande :

mkdir -p helios-q1-2026 && cd helios-q1-2026
for f in 01-agenda 02-ceo-letter 03-cfo-q1-financials 04-strategic-plan-update \
         05-acquisition-proposal 06-risk-register-update \
         07-compliance-audit-report 08-resolution-pack; do
  curl -O https://docs.scrydon.com/static/ai-boardroom/$f.md
done

Déposez les huit fichiers dans la zone de téléversement, marquez la tâche comme terminée, et le pipeline IA démarre.

Étape 7 — Observer le pipeline IA

Six tâches du stage Preparation s'exécutent désormais automatiquement (elles ont executionMode: "automatic" et un workflow @system/agent-*). Vous les verrez passer de gris → bleu → vert dans la vue kanban au fur et à mesure de leur achèvement. L'ordre est gouverné par le DAG :

Upload documents
    └── AI : Classifier les documents
            └── AI : Générer la pré-lecture SMART
                    └── (Executive) Réviser et modifier la pré-lecture
                            ├── AI : Analyste financier          ┐
                            ├── AI : Conseiller juridique        │
                            ├── AI : Évaluateur des risques      │ (six agents
                            ├── AI : Conseiller stratégique      │  s'exécutent en parallèle
                            ├── AI : Responsable de la conformité│  une fois la pré-lecture
                            └── AI : Analyste opérationnel       ┘  approuvée)
                                    └── (Executive) Réviser les analyses des agents
                                            └── AI : Résumé consolidé
                                                    └── (Secretary) Finaliser la préparation

Une fois que les six agents ont terminé et que l'executive marque Réviser les analyses des agents comme fait, l'agent Résumé consolidé produit un briefing exécutif unique qui nomme les trois résolutions, résume le consensus des analystes, et liste les points sur lesquels deux agents ou plus étaient en désaccord (dans ce dossier, les agents financier et stratégique sont en désaccord sur la question de bifurquer le pivot vs les décisions M&A — cela est signalé pour discussion au conseil).

Étape 8 — Finaliser la préparation

La tâche Finaliser la préparation est une action manuelle checklist assignée au secrétaire. C'est la porte entre le stage Preparation et le stage Meeting. La checklist par défaut vous demande de confirmer : (1) tous les documents téléversés, (2) pré-lecture approuvée, (3) analyses révisées, (4) résumé consolidé distribué aux membres du conseil, (5) participants et quorum confirmés.

Marquez la checklist comme terminée. L'instance passe automatiquement au stage Meeting.

Étape 9 — Enregistrer la réunion

Le stage Meeting s'ouvre avec Enregistrer la réunion — une action voice_trigger limitée au chemin board-meeting. En production, vous ouvririez l'application d'enregistrement de réunion, captureriez l'audio en direct et le soumettriez. Pour le tutoriel, vous pouvez utiliser la transcription d'exemple fournie.

Télécharger une transcription de réunion d'exemple (réunion fictive de 90 minutes où le conseil approuve les trois résolutions ; le vote Solarcraft passe à 6–0 avec l'administrateur Almeida récusé).

Téléversez la transcription (.txt ou .vtt accepté), marquez la tâche comme terminée, et les deux agents parallèles s'activent : AI : Analyser la transcription et AI : Générer des alertes de conformité.

L'agent d'alertes de conformité inspecte la transcription pour :

• Les conflits d'intérêts (l'administrateur Almeida se récuse-t-il effectivement au procès-verbal ? — oui, dans la transcription d'exemple)
• Le quorum au moment de chaque vote (Oui — 7 sur 8 présents, ≥ 5 requis)
• La gestion du vote nominatif pour la résolution R-2026-Q1-03 (Oui — le président appelle chaque administrateur par son nom)
• Les transactions avec des parties liées non divulguées (Aucune détectée)
• Les préoccupations relatives aux obligations fiduciaires (Aucune détectée)

Révisez les alertes dans Réviser les alertes de conformité. Confirmez chacune (la transcription d'exemple produit trois alertes vertes et zéro rouge) ; le stage progresse.

Étape 10 — Post-traitement

Trois agents s'exécutent maintenant en parallèle :

• AI : Générer le procès-verbal — produit un procès-verbal formel couvrant les présences, les points de l'ordre du jour, les principaux arguments, les résultats des votes et les résolutions adoptées.
• AI : Extraire les décisions — extrait chaque décision formelle en lignes structurées : texte de la décision, répartition des votes, opinions dissidentes, conditions attachées. Pour Helios Q1, vous verrez les trois résolutions plus l'approbation de la réallocation des dépenses d'investissement.
• AI : Extraire les points d'action — responsables, délais, dépendances. Six points d'action sont extraits de la transcription d'exemple, dont « CFO + CEO : signer le SPA Solarcraft au plus tard le 5 mai 2026 dans la fourchette EV de 175–195 M€ » avec responsable, délai et lien vers la résolution R-2026-Q1-03. Chaque point d'action extrait se matérialise en instance d'objet ActionItem liée à BoardMeeting via le type de lien ActionItemFromMeeting.

Ouvrez Réviser le procès-verbal et modifiez tout champ souhaité ; le document est ensuite Approuvé par l'executive (l'action approval), et Finaliser le post-traitement archive l'instance.

Étape 11 — Suivi deux semaines plus tard

Le modèle est livré avec une tâche à déverrouillage différé : Révision des points d'action post-réunion (2 semaines). Cette tâche utilise unlockAfterTaskSlug: "finalize-post-processing" avec unlockDelay: { value: 2, unit: "weeks" }. Elle apparaît dans la file du secrétaire exactement deux semaines après la clôture de l'instance, vous invitant à réévaluer la progression des points d'action et à escalader les éléments bloqués.

Pour le tutoriel, vous pouvez accélérer le minuteur dans les outils de développement : ouvrez l'instance, exécutez

curl -X POST "$SCRYDON_URL/api/process-instances/$INSTANCE_ID/dev/fast-forward" \
  -H "Cookie: $SESSION_COOKIE" \
  -d '{"by": "P14D"}'

et la tâche de suivi se déverrouille immédiatement.

Trois variantes d'erreur à observer

Personnaliser le bundle

La plupart des équipes souhaitent ajuster les personas, remplacer les ID de workflow pour les six agents spécialisés, ajouter une étape de post-traitement de pack de conformité personnalisée, ou étendre l'ontologie avec leurs propres types d'objets (par ex. ShareholderResolution, RegulatoryFiling). Trois options, par ordre croissant de permanence :

1. Forker le manifeste en TypeScript. Copiez packages/sdk-authoring/src/process-flows/templates/ai-boardroom/index.ts dans votre propre projet SDK, changez package.id et template.slug en valeurs personnalisées, incrémentez package.version, et exécutez bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. Re-téléversez via le même endpoint d'importation. Pour étendre l'ontologie, reproduisez la structure sous packages/sdk-authoring/src/packs/examples/ai-boardroom/ontology/ et enregistrez votre propre sous-répertoire d'ontologie.
2. Modifier process-flow/manifest.json ou ontology/manifest.json dans l'archive. Extraire → modifier → repackager avec tar -czf. Pratique pour les modifications ponctuelles (par ex. renommer la persona du secrétaire en « greffier ») ; non recommandé pour la maintenance continue.
3. Utiliser directement le modèle système. Si vous n'avez pas besoin d'un slug personnalisé ou de types d'ontologie supplémentaires, abandonnez le pack et utilisez le modèle système ai-boardroom auto-installé — aucun téléversement requis.

Si vous forkez, changez toujours le slug et package.id depuis ai-boardroom afin que votre modèle personnalisé n'entre pas en conflit avec le modèle système auto-installé ou les futures mises à jour du tutoriel.

Pour aller plus loin