Partie 3 · Projets, temps et connaissances
Fédération
Relier votre Symbifox à celui d'un partenaire pour que tâches, livrables, ordres du jour et cartographies traversent, et que ce qui bouge chez lui revienne chez vous.
L'application Fédération relie deux instances Symbifox qui se font confiance. Un objet partagé d'un côté apparaît chez l'autre, et ce qui bouge revient : l'état d'une tâche, l'accusé de réception d'un livrable, un sujet proposé à un ordre du jour. Elle s'adresse aux organisations qui travaillent avec un partenaire, un sous-traitant, un donneur d'ouvrage ou un client qui a lui aussi son Symbifox. Personne n'a de compte à ouvrir chez l'autre, et aucun mot de passe ne change de mains.
Vue d'ensemble#
Un pair est l'autre instance. Vous en avez autant que de partenaires reliés. Chaque pair porte son adresse, l'état du lien, la personne à qui les objets reçus seront assignés, et le plafond de taille des pièces jointes que vous acceptez.
Le lien naît d'un jumelage : une instance émet un code à usage unique, l'autre l'accepte. Un secret partagé naît des deux moitiés, aucune des deux instances ne le choisit seule, et il signe ensuite chaque message.
Un lien fédéré relie un objet de chez vous à son miroir chez le pair. L'objet d'origine reste le vôtre; le miroir est une copie vivante, qui se met à jour et qui peut répondre. Rien ne se supprime jamais : retirer un partage archive le miroir.
Cinq sortes d'objets traversent, chacune apportée par son module :
- les tâches, avec leur état, leur jour d'échéance, leurs messages et leurs pièces jointes;
- les livrables remis, avec leur titre, leur version, leur date et leurs fichiers;
- les ordres du jour de rencontre, en lecture, avec la possibilité d'y proposer un sujet;
- les cartographies de processus, avec leur tracé complet et leurs versions successives;
- la conversation, sous forme d'un canal de discussion par objet partagé.
Ce qui ne traverse jamais, quoi qu'il arrive : vos notes internes, vos heures et feuilles de temps, le verbatim d'une rencontre, vos identifiants, et tout message dont le texte commence par un cadenas.
La liste des liens rassemble tout ce qui a un jumeau chez un partenaire, quel que soit le genre de l'objet.
Configuration#
Le jumelage est réservé aux administrateurs. Depuis Fédération > Pairs, créez la fiche du partenaire, puis Générer une invitation. Le pair a besoin de deux choses : l'adresse de votre instance et le code, valable quarante-huit heures et utilisable une seule fois. Vous les transmettez comme vous voulez, ou vous renseignez une adresse de courriel et laissez la fiche les envoyer, auquel cas elle garde la trace du destinataire.
Chez le partenaire, Fédération > Accepter une invitation demande votre adresse, le code, et à qui assigner les objets reçus. Les deux instances sont alors actives, et Tester la connexion le vérifie.
Trois réglages méritent une décision, sur la fiche du pair :
- À qui assigner les objets reçus. Les miroirs arrivent dans un projet fermé, visible de ses seuls abonnés, et portent le nom de cette personne.
- Ce que ce pair peut vous envoyer. Par défaut, tout ce que votre instance sait recevoir. Vous pouvez à la place cocher une liste précise : un partenaire à qui vous ne voulez que des tâches n'aura pas le droit de vous déposer des livrables. Le refus se produit avant que votre instance ne cherche l'objet visé, donc il ne révèle rien de ce qui existe chez vous.
- Le plafond des pièces jointes. Au-delà, un fichier reste chez l'émetteur, et le miroir le dit plutôt que de faire semblant.
Premiers pas#
Partagez une première tâche. Sur le projet, nommez le pair dans Pairs de fédération : sans cela, aucune tâche du projet ne propose la fédération, et le champ n'apparaît même pas. Ouvrez ensuite une tâche et renseignez Fédéré avec. Une note au fil de discussion récapitule ce qui part et ce qui reste.
Le miroir apparaît chez le partenaire à la passe suivante de la boîte de sortie, au plus deux minutes. Il le voit dans un projet nommé d'après vous, avec trois colonnes : à faire, en attente de vous, terminé.
Quand il déplace sa tâche dans Terminé, elle vous revient En cours plutôt que de se fermer : sa part est finie, la balle est dans votre camp. C'est le retournement d'état, et c'est ce qui fait qu'une tâche fédérée ne se perd pas.
Tâches courantes#
Remettre un livrable. Depuis Fédération > Livrables, créez la remise : un titre, une version, une date, un résumé en texte et les fichiers. Renseignez le destinataire, qui est le contact à qui la remise est adressée : c'est lui qui détermine quels pairs peuvent la recevoir, et sans destinataire aucun pair n'est proposé. L'accusé de réception revient avec le nom de qui a lu et la date.
Publier une nouvelle version. Changez la version et remplacez les fichiers. Chez le partenaire, la nouvelle remplace l'ancienne, fichiers compris, et l'accusé de la version précédente tombe des deux côtés : un accusé porte sur un contenu, pas sur un titre.
Partager un ordre du jour. Sur un ordre du jour dont le projet nomme un pair, renseignez Fédéré avec. Le partenaire le lit chez lui : titre, date, lieu, durée, objectifs, contexte et sujets publiés. Il ne peut pas le réécrire, et un bandeau le lui dit. Ce qu'il peut faire, c'est Proposer un sujet : le sujet arrive chez vous en « Proposé par un destinataire », à examiner, et il n'entre ni dans le document imprimé ni dans le courriel tant que vous ne l'avez pas accepté.
Partager une cartographie. Renseignez Fédéré avec sur la carte. Le partenaire reçoit une vraie cartographie, avec ses niveaux, ses couloirs, ses nœuds et ses flux : il peut la tracer en PDF et ouvrir ses pages d'étape. Elle porte votre nom entre parenthèses, pour la distinguer des siennes. Après avoir retouché le tracé, employez Renvoyer le tracé au pair : les niveaux ne font pas partie des champs surveillés, parce qu'une carte se retouche par ses nœuds bien plus souvent que par son titre.
Ouvrir un canal de discussion. Depuis Fédération > Liens, le bouton Ouvrir le canal crée un canal pour cet objet. Ce qui s'y écrit est posté au fil de discussion de l'objet, d'où il part chez le partenaire; ce qui arrive de lui y reparaît. Le canal est la fenêtre, le fil de discussion reste le registre. Comptez deux à quatre minutes par aller-retour : ce n'est pas du clavardage.
Retirer un partage. Videz Fédéré avec. Le miroir est archivé chez le partenaire, une note l'en avertit, et rien n'est supprimé. Remettre le pair réactive le miroir et lui renvoie la carte complète.
Les menus, un à un#
Fédération > Objets fédérés liste les tâches qui ont un miroir, avec le pair et le sens du partage.
Fédération > Livrables liste les remises, dans les deux sens. Les filtres séparent ce que vous avez remis de ce que vous avez reçu, et isolent ce qui n'a pas encore d'accusé.
Fédération > Pairs est la fiche de chaque partenaire : l'état du lien, le dernier contact, ce qu'il dit savoir recevoir, ce que vous l'autorisez à vous envoyer, la personne à qui ses objets sont assignés, et la table des personnes appariées. Réservé aux administrateurs.
Fédération > Accepter une invitation ouvre la fenêtre de jumelage côté invité. Réservé aux administrateurs.
Fédération > Liens liste tous les liens, quel que soit le genre d'objet, avec leur modèle et leur pair. C'est de là qu'on ouvre le canal de discussion d'un objet. Réservé aux administrateurs.
Fédération > Boîte de sortie montre chaque envoi, son état et, le cas échéant, la dernière erreur. Réservé aux administrateurs.
Référence#
La table des personnes appariées. Un message reçu s'écrit au nom d'une personne de chez vous seulement si cette table dit que telle adresse chez le pair correspond à tel contact chez vous. Sans cela, il s'écrit au nom de l'organisation du pair, avec le nom annoncé en préfixe. Un partenaire ne peut donc pas écrire au nom d'un de vos employés en présentant son adresse.
Le marqueur d'exclusion. Un message ou une note dont le texte commence par un cadenas, ou par la mention privée entre crochets, reste chez son auteur. Le marqueur vaut depuis le fil de discussion comme depuis le canal.
Les genres annoncés. Chaque instance dit à l'autre ce qu'elle sait recevoir. Un genre dont le module n'est pas installé chez le partenaire est refusé plutôt que deviné. Un partenaire qui tourne une version antérieure n'annonce rien, et reste alors traité comme acceptant tout : on n'empêche pas ce qu'on ne sait pas.
Les rôles. Seul un administrateur jumelle, suspend ou réactive un pair, et règle ce qu'il peut vous envoyer. Un gestionnaire de projet partage et retire des objets. Un usager lit les objets fédérés de son périmètre, comme les autres.
Modules qui enrichissent cette application#
Comprendre#
Pourquoi l'objet va chez l'autre plutôt que l'autre chez vous. Symbifox sait déjà ouvrir un portail à un partenaire, et partager un projet avec droit de modification. Ces portes fonctionnent, et elles restent peu empruntées : on travaille dans l'outil qu'on ouvre le matin, pas dans celui de quelqu'un d'autre. La fédération renverse le sens et pose l'objet là où le partenaire est déjà.
Pourquoi le fil de discussion reste le registre. Le canal donne la forme du clavardage, plus vivante pour échanger. Mais un objet doit garder une seule histoire, lisible dans un an par quelqu'un qui n'était pas là. Le canal écrit donc dans le fil de discussion, jamais à côté.
Pourquoi un livrable plutôt qu'un objet partagé. Un compte rendu, une politique, une procédure, un échéancier exporté : ce sont des choses qu'on remet, pas qu'on rédige à deux. On ne rédige pas une politique de confidentialité conjointement avec son client. Le livrable dit donc ce qu'il est : une version datée, remise, dont on veut savoir qu'elle a été lue.
Pourquoi le destinataire cadre la remise. Avec un seul partenaire, la question ne se pose pas. Avec cinq, une liste qui les montrerait tous les cinq rend possible la remise au mauvais, ce qui n'est pas une coquille mais un incident de confidentialité. Le destinataire rend le mauvais partenaire impossible plutôt qu'improbable.
Dépannage#
Le miroir n'apparaît pas chez le partenaire. Regardez la boîte de sortie. Un envoi en attente part à la passe suivante, au plus deux minutes. Un envoi en erreur affiche la dernière réponse du pair : une adresse injoignable, un lien qu'il ne connaît pas, ou un refus. Un envoi est retenté avec un délai croissant pendant quatorze jours, puis abandonné.
Le partenaire refuse un genre. Sa fiche chez lui limite peut-être ce que vous pouvez lui envoyer, ou le module correspondant n'est pas installé chez lui. Les genres qu'il annonce savoir recevoir sont visibles sur sa fiche, chez vous.
Le champ Fédéré avec n'apparaît pas. Sur une tâche ou un ordre du jour, le projet doit nommer un pair. Sur un livrable, il faut un destinataire. Sur une cartographie, un client ou un projet qui nomme un pair.
Un ordre du jour reçu refuse d'être modifié. C'est voulu : un miroir se lit. Pour y ajouter quelque chose, employez Proposer un sujet, et c'est l'émetteur qui décidera de l'inscrire.
Une remise n'a plus rien à rejouer. Un envoi abandonné garde sa trace mais pas son contenu au-delà d'une semaine : les fichiers d'un envoi qui n'est jamais parti n'ont pas à vivre indéfiniment dans une file. Repartagez l'objet.
Voir aussi#
- Projet pour les tâches, les projets et leurs états d'attente.
- Rencontres pour les ordres du jour, les comptes rendus et le portail client.
- Cartographies de processus pour dessiner, valider et versionner une carte.
- Base de connaissances pour les documents versionnés et leurs diffusions.
- Discussion pour les canaux et la messagerie interne.