Page 1 sur 31, 2, 3 SuivantOutil de partage de connaissance

[valinor4]

Bonjour à tous.

A partir du 3 avril prochain, je vais faire mon stage de fin d'études chez EADS Astrium.

Je dois developper un outil de partage de connaissance. Pourquoi en parler sur le forum ? Tout simplement parce que l'entreprise a décidé de basculer aux logiciels libres. Ils ne veulent plus être aux grapins d'une autre entreprise. Une partie de mon travail consiste à étudier les solutions libres existantes et le cas échéant, de développer quelque chose de A à Z pour eux.

J'ai essayé de me renseigner mais je n'ai pas trouvé chaussure à mon pied, d'où mon post.

Cahier des charges :
---------------------

En gros, c'est un Wiki mais qui pourrait être accéssible offline.

La problématique est la suivante : L'entreprise en question distribue beaucoup de manuels à leurs clients. Les clients en question voudraient bien modifier le manuel mais ils ont pas vraiment le temps d'où l'intéret du Wiki.

La 2ème problématique est la suivante : les clients en question voudraient accéder à ces manuels offline.

La 3ème problématique est la suivante : l'entreprise ne souhaite pas investir dans un serveur internet où les données seraient stockées.



Perso, j'ai beau eu fouiller sur le Net, je n'ai pas trouvé de logiciel ou de service correspondant à cette problématique. Bizarre d'ailleurs puisqu'il y a beaucoup d'offre des logiciels du côté des entreprises.

Est-ce quelqu'un a entendu parler d'un logiciel qui pourrait remplir au moins une partie de ce cahier des charges ?

Sinon, y-a-t-il un langage permettant de se simplifier la vie puisque le php/mysql me parait fortement exclu hélas.

Merci d'avance pour vos pistes.

Xavier

[joan]

Bonjour,

Comment sont distribués les documents pour l'instant ? Au formats de documents bureautiques ?
(document bureautiques = accès offline possible, modifications possibles et on renvoi le document une fois les modifs faites...)

Le wiki sera intéressant si il y a de nombreux documents interconnectés et qu'on veut éviter d'envoyer des dizaines de fichiers... Mais dans tous les cas il faudra bien une entité unique pour absorber les modifs, non ?

Sinon en partant sur ton idée de wiki, on pourrait imaginer le logiciel de wiki installé à la fois chez le client et dans l'entreprise, et un système de synchronisation des bases de données. Les modifs pourraient être faites chez le client, et une fois de temps en temps les données seraient "poussées" vers l'entreprise.
Mais attention au problèmes de versionning classiques. (modifs du même fichier en parallèle...etc.) surtout si plusieurs boîtes clientes ont accès aux mêmes données.

Dans tous les cas, je ne vois pas comment se passer d'un machin au milieu qui stocke les données et gère les modifs...

[joan]

[doublon]

[jc1]

Bonjour,

Un wiki offline me semble très difficile ou alors, cela va devenir une usine à gaz.
Il faut dupliquer le wiki référence chez chaque client et les synchroniser pour les mises à jour.

Ou alors regarde du coté du P2P, s'il n'existe pas un wiki fonctionnant en P2P ou alors très basique les bases de données distribuées et les web services.

<Humour> Tu dois construire une fusée pour Mars, et tu n'as pas 100 balles pour le faire</Humour>

Regardes ce que l'on appelle le "cloud computing" ou "SaaS" pour l'hébergement
http://en.wikipedia.org/wiki/Cloud_computing
http://fr.wikipedia.org/wiki/Software_as_a_service

[Earered]

Je pars de l'idée des manuels :

Une arborescence des documents façon dewey (chopé un (ou une suivant les gouts) documentaliste pour ça).

Puis au choix

SVN+TRAC+TortoiseSVN (ou script pour nautilus)?
Alfresco avec partage SMB+synchronisation de dossier/rsync? (le plus facile à faire passer, mais pas forcément l'idéal AMHA)
Partage Webdav+ groupware?
(ou d'autres montages en décentralisé éventuellement)

Et enfin une doc pas à pas avec moult capture d'écran expliquant les fonctionnalités présente sur la plupart des systèmes pour faire du partage de fichiers et de la gestion de version

Par contre, il faut voir que cet éventuel prototype n'est pas nécessairement un outil en préparation mais éventuellement un outil de négociation pour le renouvellement d'une licence.

P.S. pour le coté wiki je vois mal l'usage pour _plusieurs_ manuels/projets (à moins d'une ferme à wiki façon sharepoint, mais là on revient vers Alfresco).

[valinor4]

Tout d'abord merci pour vos reponses.

Pour l'instant, je n'ai eu qu'un entretien avec mon futur tuteur qui m'a expliqué le topo. J'en saurais plus la premiere semaine de mon stage.

Il est clair que sans serveur central, il est dur de synchroniser tout ça. J'avais pensé à rassembler tous les documents dans un gros XML et à partir de là, les différents clients pourraient d'échanger leurs XML entre eux mais je ne sais pas encore quels sont leurs besoin (images, latex, diagrammes, etc...).

Je vais etudier vos propositions et je vous recontacterai dans tous les cas dans quelques semaines, merci encore.

Xavier

[jc1]

Bonjour,

Pour l'instant, je n'ai eu qu'un entretien avec mon futur tuteur qui m'a expliqué le topo. J'en saurais plus la premiere semaine de mon stage.

Je serais toi j'essayerai d'avoir plus d'informations avant le début de ton stage.

J'avais pensé à rassembler tous les documents dans un gros XML et à partir de là, les différents clients pourraient d'échanger leurs XML entre eux mais je ne sais pas encore quels sont leurs besoin (images, latex, diagrammes, etc...).

XML => texte seulement, sauf si ce sont des images en svg.
Pourquoi un fichier et pas des fichiers dans une base de données soit relationnelle ou native XML

http://www.xml.com/pub/a/2003/05/07/bdb.html

eXist http://exist.sourceforge.net/
Xindice http://xml.apache.org/xindice/

Ron Bourret: “XML and Databases,” http://rpbourret.com/xml/XMLAndDatabases.htm (November 2002).
Avec la traduction fr de Patrick Peccatte http://peccatte.karefil.com/software/RBourret/xmlBD.htm

[joan]

Ou alors regarde du coté du P2P, s'il n'existe pas un wiki fonctionnant en P2P

[Hors sujet (ou pas)]
Mine de rien je crois qu'on a là une idée du tonnerre. je ne sais pas si ça serait viable, mais il y a un quelque chose dans ce concept qui sonne comme une innovation ingénieuse.
L'idée mérite d'être creusée.
Je n'ai trouvé que Buzm, qui est présenté comme un wiki sur P2P ( mais non libre, windows only et utilisant TiddlyWiki (donc on ne peut pas vraiment parler de wiki))

[jc1]

Bonjour,

Alors, je regarderai différentes choses :
1/ les bases de données distribuées et les transactions.
2/ le commit à 2 phase (2PC) et 3PC (base de données) et surtout avec les améliorations des "Consensus Algorithm" (pour choisir le nouveau chef en cas de panne de celui-ci).
3/ le fonctionnement théorique du P2P
4/ le fonctionnement de bittorent et de kad
5/ le choix du wiki. Je dirai, médiawiki (wikipedia) ou un autre (avec ou sans BD).
6/ il y a des filtre OpenOffice.org pour médiawiki (et dokuwiki).
7/ la sécurité au niveau du P2P, cryptage des flux (µtorrent ou deluge), firewall (comment entrer dans un SI) tunneling, etc...
8/ gestion des client
9/ Web services (SOAP ou REST).

C'est une petit usine à gaz que l'on te demande, attention !!!!

Ton stage dure combien de temps (3, 4, 5, 6 mois ?)
Et à quel niveau d'étude (Bac+2, 3, 4 , 5) ?

Rien que le cahier des charges, ce n'est pas une mince affaire.
Faire les états de l'art dans les différents dommaines va déjà prendre du temps (BD réparties, P2P, wiki, sécurité).


Autre idée, regarde SETI@home (http://setiathome.free.fr/).
Tu pourrais faire la même chose au niveau des traitements et des données qui pourraient être hébergés par tous les PC d'un entreprise sans serveur et par les clients de cette entreprise.

[valinor4]

Mon stage dure 6 mois.

Je suis en 5ème année d'école d'ingénieur et je passe en même temps un Master in Applied Computing à l'Université de Dundee (Ecosse).

Merci pour votre idée du P2P, je n'y aurai pas pensé.

Mon principal soucis est le fait que je ne vois pas très bien comment utiliser Apache ou une quelconque base de données offline... le client peut bien sûr installer XAMPP sur son PC mais je suis pas sûr que cela lui fasse plaisir.

Sinon, mon responsable de stage n'est pas celui à qui profite le logiciel donc je dois attendre d'aller dans l'entreprise et rencontrer les client pour savoir vraiment ce qu'ils veulent.

Xavier