Calliops
Méthode · sept étapes, une porte

Comment les réunions d'une équipe deviennent un savoir client commun

Une exigence client est dite une fois, à une personne, dans une réunion. La suivante l'entend trois semaines plus tard sans savoir que c'est la même. Calliops part de l'enregistrement, en extrait ce qui a été demandé, décidé ou risqué, et range les quatre versions de la même chose sur une seule ligne — qui garde les quatre citations et le compte dont vient chacune.

Qu'est-ce qu'un besoin ?

Un besoin est une demande, telle qu'un ou plusieurs clients l'ont exprimée, avec toutes les phrases qui la prouvent. Il porte un titre, une description de ce qui est demandé, les comptes qui le portent et chaque citation avec sa réunion, sa date, son locuteur et son horodatage.

Un besoin ne dit jamais ce qu'il faut construire. C'est la contrainte centrale du système et elle est structurelle, pas éditoriale : le passage qui crée les besoins n'a aucun champ où écrire une solution, et la consigne lui interdit d'en proposer une. Il trie, et il s'arrête.

BES-042 · 4 citations · 3 comptes · thème « Sécurité et accès »

Quelles sont les sept étapes ?

Le pipeline compte sept étapes, du calendrier à la spécification. Chaque flèche entre deux étapes est une transformation réelle : aucune étape ne recopie la précédente.

ÉtapeCe qui entreCe qui sort
01CalendrierUn évènement, un lien MeetUne réunion et son transcript
02EnrichissementLe transcript et ses participantsRéunion datée, rattachée à un compte et à un projet
03ExtractionRéunion enrichieDécisions, risques, demandes, actions, idées — chacune citée
04DéduplicationÉléments extraitsUn enregistrement par chose dite
05RevueÉléments dédupliquésÉléments validés, corrigés ou écartés
06RegistreÉléments validésBesoins enrichis, rattachés à un thème
07Génération de specUn besoin validéUser stories, contraintes UX, scope technique, definition of done

Comment quatre réunions deviennent-elles une seule ligne ?

À l'étape 06, chaque élément validé est confronté aux besoins qui existent déjà dans l'espace, et la consigne est de préférer ce qui existe plutôt que de créer. Une demande déjà enregistrée reçoit une citation de plus ; elle ne produit pas un second enregistrement.

C'est ce qui distingue un registre d'un compte rendu. Un compte rendu par réunion produit quatre documents que personne ne rapproche. Le registre produit une ligne dont la quatrième citation vient d'une personne qui n'a jamais parlé aux trois autres.

La déduplication de l'étape 04 fait le même travail à l'intérieur d'une réunion : une chose répétée sept fois en quarante-huit minutes est un enregistrement, pas sept.

Où une personne doit-elle intervenir ?

À une seule étape, la cinquième. Rien de ce qui a été extrait n'entre au registre sans qu'une personne l'ait validé, corrigé ou écarté — et rien de ce qui a été écarté ne revient.

La génération de spécification, à l'étape 07, ne rouvre pas de porte : elle ne lit que des besoins validés, et ce qu'elle écrit reste une proposition tant qu'une personne ne l'a pas relue. Le passage de « ce que le client demande » à « ce qu'il faut donc faire » n'est jamais fait sans qu'un humain ait d'abord dit oui au besoin.

Que se passe-t-il si personne ne relit ?

Rien n'entre au registre. Les éléments extraits restent en brouillon dans la file de revue, marqués en pointillé, et continuent d'être dédupliqués contre les réunions suivantes. La file ne se périme pas.

La première validation, même une semaine plus tard, fait descendre au registre tout ce qui a été validé, pas seulement l'élément qu'on vient de cocher.

Quels sont les états d'un élément et d'un besoin ?

Cinq états, nommés par ce que la personne contrôle plutôt que par ce que le système fait.

ÉtatCe que ça veut dire
Brouillon IAExtrait, pas encore lu par une personne. En pointillé partout.
En revueDans la file, en attente de validation.
ValidéUne personne a dit oui. Entre au registre et devient citable.
ClosLe sujet est réglé. Reste lisible, ne remonte plus comme ouvert.
ÉcartéUne personne a dit non. N'entre pas au registre, ne revient pas.

Que peut-on tirer du registre ?

Quatre choses, et elles lisent toutes la même matière validée. Le brief avant réunion, qui dit ce que chaque participant a déjà dit et ce qui reste ouvert. Le registre lui-même, une ligne par demande. La carte des thèmes, qui montre de quoi un compte parle réellement sur six mois. Et la question posée en langage courant, à une réunion, à un compte ou au registre entier.

Aucune de ces quatre lectures ne touche aux brouillons. Une carte des thèmes dessinée à partir de ce qui n'a pas été relu serait une carte de ce que le modèle a cru entendre.

Les agents accèdent aux mêmes lectures par MCP, avec le même périmètre.

Et la spécification ?

C'est l'étape 07, à partir du forfait Organisation. Un besoin validé devient une spécification : des user stories, les contraintes UX, le scope technique et la definition of done. Chaque bloc porte les mêmes citations que le besoin dont il vient.

Le registre reste utile à une équipe qui ne livre aucun logiciel ; la spécification est ce qu'une équipe qui en livre en tire ensuite, sans rien ressaisir.

Où sont écrits les besoins validés ?

Dans Calliops, et dans votre Notion si vous le branchez. Rien n'est écrit dans Notion avant validation, et tout est exportable en Markdown, citations et validations comprises.

Et si une synchronisation échoue ?

L'écran le dit avec l'heure et propose de reprendre. L'élément bloqué est marqué en tampon encre, pas en rouge : il n'est pas perdu, il attend.

Sync Notion interrompue à 09:41. Reprendre.

Pour aller plus loin

Nous ouvrons par vagues, un espace produit à la fois, pour tenir la qualité de l'extraction.

Rejoindre la bêtaBêta fermée · palier Organisation offert