Écosystème d'agents – documentation

#Documentation utilisateur

L'écosystème d'agents aide à répondre à un appel à propositions (AAP) à partir d'une collection Zotero annotée. Il analyse les attendus de l'appel, extrait les concepts de la collection, mesure l'accord entre annotateurs, puis rédige une proposition d'article avec références, citations et mots-clés. Tout est archivé dans Omeka S.

flowchart LR
    subgraph Préparer["1. Préparer (Zotero)"]
        Z1[Collection de documents] --> Z2[Surlignages en couleur,<br/>notes, marqueurs]
    end
    subgraph Paramétrer["2. Paramétrer (interface)"]
        P1[Collection Zotero] --> P2[Lien ou fichier de l'appel]
        P2 --> P3[Plan de la proposition]
    end
    subgraph Lancer["3. Lancer"]
        L1[Enregistrer et lancer] --> L2[Suivre le journal]
    end
    subgraph Exploiter["4. Exploiter"]
        E1[AttenduAPP] --> E2[PropAPP]
        E2 --> E3[Relecture, rapport,<br/>graphe, kappa]
    end
    Préparer --> Paramétrer --> Lancer --> Exploiter

#1. Préparer le corpus dans Zotero

#La collection

Rassembler dans une collection Zotero les documents à mobiliser : articles, chapitres, pages web enregistrées, PDF, DOCX, ODT, EPUB, textes. Chaque notice Zotero fournit la référence bibliographique (BibTeX) de la proposition ; ses pièces jointes fournissent le texte analysé.

#Surligner avec une couleur qui indique votre positionnement

La couleur d'un surlignage indique votre position par rapport au passage. Elle oriente l'extraction des concepts et apparaît dans les citations de la proposition. La table par défaut reprend la palette de Zotero ; elle est modifiable dans Paramètres › Positionnement par couleur.

Couleur Positionnement Effet sur l'extraction
🟨 jaune Idée clé concepts centraux, reliés entre eux
🟩 vert Accord idées reprises : relations « soutient », « fonde », « prolonge »
🟥 rouge Désaccord thèses contestées : relations « s'oppose à », « critique »
🟦 bleu Définition concept défini et ses composantes
🟪 violet Méthode méthodes et protocoles
🟣 magenta Question ouverte questions à approfondir
🟧 orange Exemple exemples, cas, terrains
⬜ gris Contexte éléments secondaires

Les annotations faites dans le lecteur Zotero et celles déjà présentes dans un PDF sont toutes les deux prises en compte.

#Notes et marqueurs

#Coder les phrases pour l'accord inter-juges

Pour mesurer l'accord entre plusieurs annotateurs (juges), chaque juge ajoute comme marqueur le code de la grille d'annotation (grille_annotation.md) sur la phrase annotée :

Code Positionnement argumentatif
ACC-S, ACC-E, ACC-C Accord – assentiment, expansion, concession
DES-F, DES-A Désaccord – factuel/logique, absurde
NEU-S, NEU-R Neutralité – suspension, relativisation
RHET-H, RHET-E Rhétorique – ad hominem, épouvantail
DEP-S Dépassement – synthèse
AMB Ambigu

Les juges doivent travailler dans une bibliothèque de groupe Zotero : c'est ce qui permet de savoir qui a codé quoi. Les codes ne deviennent pas des concepts.

#2. Utiliser l'interface

L'interface s'ouvre sur http://127.0.0.1:7272. Elle comporte quatre onglets : Paramètres, Exécution, Résultats et Appels traités.

#Paramètres

Section Contenu
Connexions accès à Albert, Zotero et Omeka S (fichier .env). Les secrets ne sont jamais réaffichés : laisser le champ vide pour garder la valeur enregistrée. Le bouton Tester les connexions vérifie les trois services.
Données d'entrée collection Zotero (liste déroulante), lien vers l'appel, fichier de l'appel (si le site bloque le téléchargement), texte ou précisions sur l'appel
Proposition d'article plan en markdown, auteurs supplémentaires, nombre de mots-clés et de citations, style de citation
Modèles de langage modèles Albert (suggestions chargées depuis l'API)
Extraction sémantique taille des extraits de texte, lots de nettoyage
Zotero et marqueurs marqueurs automatiques, catégorie des concepts issus des marqueurs
Positionnement par couleur table couleur → positionnement → consigne pour le modèle
Accord inter-juges codes de la grille, similarité de phrase, kappa requis
Omeka S (avancé) vocabulaires, classes et propriétés utilisées

Enregistrer écrit les modifications dans .env et workflow.config.json ; Rétablir la configuration par défaut revient aux valeurs de config.ts.

#Le plan de la proposition

Le plan est un texte markdown : chaque titre devient une section de la proposition, les lignes Consigne : guident le rédacteur et ne figurent pas dans le texte final.

# Titre de la proposition
Consigne : titre court et explicite, en lien direct avec l'appel.

## Résumé
Consigne : 250 mots maximum ; problématique, démarche, apports attendus.

## Cadre théorique
Consigne : mobiliser les concepts du graphe et les références de la collection, avec citations.

#Quand le site de l'appel bloque le téléchargement

Certains sites (par exemple ceux protégés par Cloudflare) refusent les accès automatiques. Ouvrir la page dans le navigateur, l'enregistrer en PDF (Imprimer › Enregistrer au format PDF) ou en HTML, puis l'importer avec Fichier de l'appel. Le lien reste la source de l'appel dans Omeka S.

#Exécution

Enregistrer et lancer enregistre les paramètres et démarre le traitement. Le journal s'affiche en direct ; un traitement peut être arrêté. On peut fermer la page : le journal reprend à la réouverture.

stateDiagram-v2
    [*] --> Paramétré : Enregistrer
    Paramétré --> EnCours : Enregistrer et lancer
    EnCours --> Terminé : succès
    EnCours --> Échec : erreur d'une étape
    EnCours --> Arrêté : Arrêter
    Terminé --> EnCours : relancer
    Échec --> EnCours : corriger puis relancer
    Arrêté --> EnCours : relancer

Le traitement enchaîne les étapes suivantes (durée indicative : quelques minutes par document, selon la taille des textes) :

flowchart TD
    A[Appel à propositions<br/>→ AttenduAPP] --> C
    B[Documents Zotero<br/>texte, annotations, notes] --> C{ }
    C --> D[Graphe de concepts]
    C --> E[Accord inter-juges]
    D --> F[Export des concepts<br/>dans Omeka S]
    E --> F
    F --> G[Proposition d'article<br/>PropAPP]
    G --> H[Relecture épistémologique]
    H --> I[Rapport de traitement]

Un document dont l'extraction sémantique est déjà faite (date curation:access renseignée dans Omeka S) n'est pas retraité : ses concepts sont relus dans Omeka S. Relancer est donc rapide quand seuls quelques documents ont changé.

#Résultats

L'onglet Résultats affiche les documents produits : markdown mis en forme, tableaux CSV, graphe interactif.

Document Contenu Emplacement dans Omeka S
PropAPP proposition d'article : métadonnées (titre, auteurs, mots-clés), texte selon le plan, annexe des citations, références BibTeX item de l'appel
AttenduAPP analyse des attendus de l'appel : problématique, axes, contraintes formelles, critères, calendrier item de l'appel
Références BibTeX PropAPP.bib, notices de la collection item de l'appel
Relecture épistémologique critique de PropAPP au regard d'AttenduAPP item de configuration de l'exécution
Graphe de concepts visualisation interactive sigma.js (les données graphology JSON restent en local) item de configuration de l'exécution
Désaccords entre juges CSV des phrases codées, désaccords en tête item de configuration de l'exécution
Rapport de traitement étapes, documents traités, graphe, accord inter-juges, appel et proposition, tokens consommés, coût estimé (énergie, carbone, argent) item de configuration de l'exécution

#Le graphe de concepts

La taille d'un concept dépend de son nombre de relations, sa couleur de sa catégorie. Survoler un concept met en évidence ses voisins ; cliquer ouvre sa fiche (relations, documents sources, lien vers l'item Omeka S). La recherche, la légende (pour masquer une catégorie) et le zoom sont dans le panneau.

#Les auteurs de la proposition

Les annotateurs Zotero sont auteurs de la proposition (par nombre d'annotations décroissant), suivis des auteurs supplémentaires saisis dans les paramètres.

#Lire l'accord inter-juges

Kappa Interprétation (Landis et Koch)
≤ 0 aucun accord
0,01 – 0,20 léger
0,21 – 0,40 passable
0,41 – 0,60 modéré
0,61 – 0,80 substantiel : seuil de validation du corpus
> 0,80 presque parfait

Le kappa de Fleiss est calculé pour trois juges ou plus, et le kappa de Cohen s'y ajoute avec deux juges. Le rapport liste les codes les plus souvent confondus et un bilan rédigé par l'agent analyste ; le CSV détaille chaque phrase pour un recalibrage ciblé.

#La consommation de tokens

Le rapport de traitement indique le nombre de tokens consommés par les modèles : total, entrée, sortie (et raisonnement), détaillé par traitement (attendus de l'appel, extraction, nettoyage du graphe, rédaction, relecture, bilan kappa) et par modèle. Le total est aussi enregistré dans l'item de configuration de l'exécution (curation:data) et affiché dans l'onglet Appels traités.

#Le coût du traitement

Le rapport estime aussi le coût du traitement : énergie consommée (Wh), émissions de gaz à effet de serre (g CO₂e), coût de l'électricité et coût équivalent API (ce qu'aurait coûté le même volume de tokens aux tarifs du marché ; l'API Albert étant mise à disposition par l'État, ce n'est pas un montant facturé), détaillés par modèle, avec des ordres de grandeur (ampoule LED, recharge de smartphone).

Il s'agit d'une estimation, pas d'une mesure : l'énergie par token est déduite de la taille du modèle (paramètres actifs), du rendement des processeurs graphiques, de leur taux d'utilisation et du PUE du centre de données. Toutes ces hypothèses, l'intensité carbone de l'électricité et les tarifs de référence sont modifiables dans Paramètres › Coût du traitement et rappelées en bas de la section du rapport. La fabrication du matériel, le réseau et les postes de travail ne sont pas comptés.

L'estimation est aussi enregistrée dans l'item de configuration de l'exécution (curation:data) et affichée dans l'onglet Appels traités.

#Appels traités

L'onglet Appels traités liste les appels à propositions déjà analysés, avec l'historique de leurs exécutions (date, collection, statut, durée, tokens, coût estimé, titre de la proposition, lien vers la configuration dans Omeka S). Il réunit l'historique local (workflow.history.json) et les configurations enregistrées dans Omeka S : les exécutions faites depuis une autre machine ou avant une réinstallation y figurent aussi.

Pour chaque appel :

Seuls les documents nouveaux ou modifiés sont retraités : ceux dont l'extraction est déjà faite sont relus dans Omeka S. Un appel importé depuis un fichier local ne peut être rejoué que si le fichier est toujours présent dans aap/.

#3. exploZoteroAnno : animer une annotation collective

exploZoteroAnno est une seconde application, avec son propre serveur : http://127.0.0.1:7273 (lien dans l'en-tête de l'Atelier d'articles). Elle a ses propres connexions (onglet Grille, héritées de celles de l'Atelier sauf modification) et peut analyser pendant qu'un traitement de l'Atelier est en cours. Elle accompagne un groupe qui annote ensemble une collection Zotero : elle fixe une grille de couleurs commune, mesure la participation de chacun, analyse les convergences et divergences de lecture, et propose des thèmes pour une séance de discussion. Tout est enregistré dans Omeka S.

flowchart LR
    G[Définir la grille<br/>de couleurs] --> P[Partager le guide<br/>d'annotation]
    P --> A["Annotation collective<br/>dans Zotero (groupe)"]
    A --> R[Analyser]
    R --> V1[Participation]
    R --> V2[Collaborations]
    R --> V3[Thèmes de discussion]
    V3 --> S[Séance de discussion]
    S --> A

#Paramétrer la grille (onglet Grille)

Enregistrer et analyser lance le workflow ; il peut être relancé à tout moment pendant l'annotation : les nouvelles annotations de Zotero sont prises en compte.

#Visualiser la participation (onglet Participation)

#Analyser les collaborations (onglet Collaborations)

#Générer des thèmes de discussion (onglet Thèmes)

Un agent propose des thèmes pour une séance collective à partir des passages divergents et convergents, des commentaires, des notes et des marqueurs : pour chaque thème, une question ouverte, la raison du choix, les passages à relire (avec les personnes concernées) et une piste d'animation. Il veille à impliquer aussi les participants les moins actifs.

#Rapport et enregistrement (onglet Rapport)

Le rapport reprend participation, collaborations et thèmes, ainsi que les tokens consommés et le coût estimé. Chaque analyse crée dans Omeka S un item « Configuration explo-zotero-anno » (classe dcterms:MethodOfInstruction) avec la grille et les paramètres, son statut, sa consommation et, en médias : guide d'annotation, rapport, thèmes, réseau, données de participation et de collaborations. Les documents et annotations de la collection sont enregistrés comme dans l'Atelier d'articles (oa:Annotation avec auteur, couleur, date).

#4. Ce qui est enregistré dans Omeka S

flowchart TD
    COL[Collection Zotero<br/>bibo:Collection] --- CFG[Configuration d'exécution<br/>dcterms:MethodOfInstruction]
    AAP[Appel à propositions<br/>bibo:CallForPapers] -- dcterms:relation --> COL
    DOC[Document Zotero<br/>bibo:AcademicArticle, bibo:BookSection…] -- dcterms:isPartOf --> COL
    ANN[Annotation<br/>oa:Annotation] -- oa:hasTarget --> DOC
    DOC -- dcterms:subject --> CON[Concept<br/>skos:Concept]
    ANN -- curation:tag --> CON
    CON -- dcterms:relation --> CON
    AAP -. médias .-> M1[AttenduAPP, PropAPP, BibTeX]
    CFG -. médias .-> M2[relecture, graphe, rapport, CSV]

#5. Questions fréquentes

Puis-je modifier le plan de la proposition ? Oui, dans Paramètres › Proposition d'article › Plan de la proposition. Les titres et leur ordre sont respectés par le rédacteur.

Pourquoi un document n'est-il pas retraité ? Son extraction est déjà faite (curation:access). Pour la relancer, vider cette propriété sur l'item du document dans Omeka S.

Une nouvelle note Zotero est-elle prise en compte ? Oui : elle est ajoutée aux annotations du document dans Omeka S, et ses marqueurs deviennent des concepts, sans relancer l'extraction du document.

Le rédacteur peut-il inventer des références ? Il ne reçoit que les clés BibTeX de la collection et doit citer uniquement celles-ci (syntaxe Pandoc [@clé, p. 12]) ; la relecture épistémologique vérifie l'usage des références.