Discussion :

[Nothus]

Bonjour à tous,

J'espère poster au bon endroit et vous remercie par avance de votre lecture...

---

J'ai débuté un outil qui ne me semble pas (encore ! ) exister dans le domaine de la micro-gestion de connaissances. L'outil répond à un besoin personnel (j'y reviendrai) mais je souhaite partager le fruit de mon développement... dans l'espoir éventuellement de trouver des personnes dans mon cas prêtes à démarrer un projet plus collectif.

Contexte

Je suis à un poste professionnel (très) solitaire (et pas du tout en rapport avec la technique) avec de nombreuses données variées à gérer (en nature, en quantité, en format, etc.) et un « grand » nombre de demandes.

J'aimerais pouvoir avec un simple bouton « transférer », envoyer l'intégralité de mes recherches vers la personne qui me demande...

Je ne me suis pas retrouvé dans les outils aujourd'hui disponibles pour différentes raisons (temps de mise en œuvre, exploitation toujours par le prisme d'un groupe/d'une communauté, sécurité (très) relative, coûts, etc.).

Or, si les CMS type wikiwiki ont beaucoup de mérites en ce qui concerne la gestion de connaissances, ils restent sur des systèmes qui sont assez lourds à mettre en place (le forum developpez.com regorge de personnes perdues sur l'installation et la maintenance d'une BDD...) et souvent à destination d'une communauté donc regorgeant d'options (multiédition, etc.) qui ne m'intéressaient souvent pas. Ici, la base est avant tout personnelle (mais le projet lui, est collectif ! ), avec la possibilité marginale d'envoyer une fiche de connaissances à quelqu'un.

Alors autant essayer de faire par soi-même un autre outil en partant d'une feuille blanche...

Présentation générale

Les principes de départ de mon idée sont simples :

• La base de connaissance est avant tout personnelle, discrète, intégrée à un outil déjà fortement/naturellement utilisé et le partage des informations doit être simple ;
• La base est faite de fiches ayant des liens entre elles. Mais ces liens sont faibles : ils peuvent ou non exister (volontairement) (= ambiguïté). Elle doit travailler à l'inverse d'un système d'identifiant fort (exemple : un identifiant numérique absolu).
• La base doit pouvoir exister en lecture quoiqu'il arrive (y compris sans accès au net).
• La base doit être sur des outils gratuits ou au moins utilisant des outils libres et si possible ouvert en terme de format.

Un seul outil me semble résoudre (pratiquement) tous ces principes : une simple boîte mail (1 fiche de connaissances = 1 courriel), en utilisant le protocole IMAP et les fonctions de PHP associées.

Présentation technique (1)

En voici le fonctionnement :

• L'outil est développé pour ne rien héberger, juste fournir un service d'édition et de lecture supplémentaire au client mail (lourd ou non).
• L'outil ne gère aucun profil et ne garde aucune donnée personnelle : on indique ses identifiants (serveur, identifiant, mot de passe) à chaque nouvelle connexion.
• L'outil se sert du principe de parties des courriels pour avoir à disposition : du contenu riche (formaté), des images (intégrées ou jointes), des documents (joints).
• L'outil doit pouvoir permettre de gérer les liens faibles, ce qu'une boîte mail ne permet pas directement (avec un système de lien qui renvoie vers un mail interne à la boîte).

Présentation technique (2)

En voici un exemple simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
From: {$this->Requete['identifiant']}
Subject: {$Sujet}
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium

{$Corps}

{$Sujet} est décomposé sous la forme itemId:itemTitre, où itemId est en quelque sorte l'identifiant faible de la fiche, itemTitre est le titre « visible » et le corps du courriel intègre les données de connaissance... (ici juste du texte HTML simple). Le corps permet le renvoi vers d'autre itemId, que l'outil PHP peut retrouver (le client lourd non, mais les outils de recherche le peuvent de manière indirecte).

On fait le lien dans l'outil web grâce au format wiki et le formatage reste du HTML simple. Par exemple*: {CRPC|Conseil régional de Poitou-Charentes} donnera un lien affichant « Conseil régional de Poitou-Charentes » ambiguë (= plusieurs raisons possibles) vers tous les courriels dont le titre débute par «*CRPC*» (= homonymie de l'abréviation).

Présentation technique (3)

Il s'agit de travailler sur un dossier qui ne soit pas INBOX, pour éviter tout problème.

On ne peut pas éditer un courriel classique dans une boîte : l'ancienne version est supprimée (flag + expurge) au profit d'un nouveau courriel, ajouter grâce à imap.append().

Les fiches sont traitées comme des courriels, avec des parties texte, HTML et PJ. Ici, seul un fonctionnement simple HTML est implémenté.

Captures d'écran

Voir PJ de ce post.

Lien vers la source PHP

Afin de ne pas surcharger ce post, j'ai mis le code sur le blog.

nb : les commentaires du code arrivent...

La suite...

Vos conseils, remarques et éventuellement votre aide si vous êtes intéressé par le projet sont les bienvenus !

---

Bonne journée,

Julien.

[Nothus]

Bonjour,

J'ai débuté le projet ! Je ne sais pas si le temps me sera donné d'aller jusqu'au bout mais j'y crois. N'hésitez pas à me rejoindre ou de tout conseil que vous jugeriez utile

Un fichier ZIP est est disponible ici, qui remplace la démo initiale très moche.

La connexion au serveur (en IMAPS seulement), la création et modification de fiches (avec support des courriels multipart) ainsi que la recherche sont disponibles. Le code est d'une qualité plus que moyenne, mais opérationnelle et j'espère suffisamment clair pour commencer.

Le format « par défaut » est de type 0 (une seule partie, qui est du HTML ; voir imap_fetchstructure). Les courriels venant de l'extérieur de l'outil (notamment ceux ajoutés dans le dossier par tout autre moyen) sont modifiables et sauvegardés dans le "bon" format (les autres parties, notamment les PJ, sont perdues).

Je pense que le format HTML natif du courriel, qui permet de disposer des attributs dans les éléments, est le mieux ; plutôt d'une PJ qui contiendrait les infos dans un format peut-être plus « riche » mais qui ne alourdirait l'ensemble, en obligeant à disposer d'une version « d'affichage ».

Je pense notamment à une balise « info » de ce style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Le <info type="personne" uid="PereNoel">Père Noël</info> est une <info type="concept" uid="ordure">ordure</info>.

[Rappel : connaissance = agglomérat d'informations. Information = agglomérat de données.]

L'outil pourrait ensuite utiliser les outils du DOM de PHP (ou Python ou JS, ou que sais-je), pour faire de chaque courriel (chaque fiche donc), une relais vers d'autres connaissance comme sur wikipédia, tout en restant parfaitement lisible sur les clients mail traditionnel (webmail ou clients lourds).

Bonne journée,

Julien.