Bonjour,
Dans le cadre de mon travail (qui est très éloigné de l'informatique) je suis amené à travailler sur de nombreux documents (principalement en format pdf et Microsoft Office, Word et Excel) partagés avec des utilisateurs de boîtes différentes.
Les solutions que nous utilisons actuellement sont souvent très bancales :
Echanges par email :
- Échange par email avec un incrément du numéro de version (Nom du document v16.docx)
- Échange par email avec ajout de date (2013-02-05 - Nom du document.docx)
- Échange par email avec ajout de commentaires/suivi de modification (Nom du document.docx) Et souvent un mix de plusieurs de ces solutions
Problèmes rencontrés :
- il suffit d'un destinataire soit oublié pour que quelqu'un ne soit pas au courant de la mise à jour du document
- si il y a 2 modifications concurrentes quelqu'un doit se taper le "merge" des documents sous peine de voir apparaître un "fork", et c'est souvent celui qui n'a pas fait de modification qui s'y colle et donc risque d'oubli/d'erreur
- si le document devient trop gros pour passer par email, le suivi est très difficile
- si on ne suit pas activement le développement d'un document il est très fastidieux de retrouver qui a écrit quoi pour poser les questions à la bonne personne
Avantages :
- On a assez facilement un historique temporel de l'évolution du document
- Tout le monde (sauf erreur de destinataire) est prévenu qu'un document est modifié
- Très flexible, on ne pollue pas les gens avec des modifs de documents dont ils n'ont que faire
Solution de gestion de contenu (Enterprise Content Management) type Alfresco
Problèmes rencontrés :
- Interface souvent très lourde et lente, il faut après chaque modification penser à réuploader le document modifié, au fur et à mesure les gens repassent à l'email
- Comme on n'est pas de la même boite il faut gérer les accès de chacun
- La courbe d'apprentissage est assez dure du coup on se retrouve avec des documents en double sans notion de version, etc…
- Besoin d'être online pour récupérer les documents
Avantages :
- C'est fait pour ça, on peut donc s'abonner à un document pour être au courant des modifs, regrouper par groupe de travail, etc… Mais cela seulement si les gens ont pris le temps d'apprendre à utiliser le logiciel, ce qui est rarement le cas.
Suivi des modifications
Le suivi se fait soit :
- à l'arrache (les modifs sont expliqués dans l'email accompagnant le nouveau document, et sont perdues sur la version suivante.
- Dans un tableau en page de garde qui garde la trace de qui a fait la modification et pourquoi
L'idéal
Je serais donc à la recherche d'un système de type Dropbox où les gens pourraient utiliser leur gestionnaire de fichier habituel, même offline.
En faisant le parallèle avec mes maigres connaissances en DCVS, je pense que quelque chose du type git serait intéressant:
- Possibilité de remonter dans les versions
- Nom de celui qui a fait les modifications
- Description des modifications dans le message du commit
Il faudrait qu'un programme surveille le dossier et fasse des commits de façon automatique afin de cacher la technique derrière. De plus il ajoute/met à jour les documents des autres dès que les commits sont disponibles.
J'imagine que l'on pourrait aller plus loin et que lorsqu'une modification est détectée (ajout d'un document, modification d'un document existant par l'utilisateur), une boite de dialogue s'affiche pour demander la nature de cette modification (message du commit).
Dropbox correspond quasiment à ce que je recherche, sans le coté multi-utilisateurs.
Conclusion
Dans l'idéal chacun gère les documents sur son PC et reçoit les nouveaux documents.
# GED ?
Posté par Mimoza . Évalué à -10. Dernière modification le 05 février 2013 à 14:43.
Quelque chose de type Alfresco (http://www.alfresco.com/fr) ne te conviendrais pas ?
Il y a un support pour le WebDav (dropboxlike)
Gestion des chemins de validation
Notification par mail
Outil de "merge"
etc
[^] # Re: GED ?
Posté par Gui13 (site web personnel) . Évalué à 3. Dernière modification le 05 février 2013 à 14:48.
Je cite:
T'as bien lu le journal??
Sinon j'ai vu que Dokuwiki gérait les différentes versions d'un fichier de son "pool multimedia".
Du coup, avec un plugin, il doit être possible de notifier des utilisateurs que certains fichiers sont modifiés.
Mais dans l'absolu, ce que tu veux, c'est un Google Docs collaboratif associé à un Google Drive.
[^] # Re: GED ?
Posté par Mimoza . Évalué à 1.
Non, donc c'est pour cela que je voulais modifier ma réponse … mais comme tu as répondu je ne peux plus '--
Alfresco reste la référence dans le monde libre pour ce que tu cherche à faire. Donc s'il ne te convient pas, ça va être difficile de trouver mieux …
Il support le WebDav (dropboxlike). Donc tu peux tout a fait choisir ton interface
[^] # Re: GED ?
Posté par Larry Cow . Évalué à 4.
Tu peux toujours regarder Nuxeo, l'autre "référence dans le monde libre" ;)
# Partager les sources plutôt que les binaires
Posté par ®om (site web personnel) . Évalué à 8. Dernière modification le 05 février 2013 à 15:00.
Une nimage.
Dans l'idéal, sinon, chacun écrit dans un format "source" (genre markdown/pandoc pour la simplicité), puis commite sur un git.
Un makefile s'occupe de générer le .html, .doc, .docx, .odt ou tout ce que tu veux d'autre. Ça ne couvre pas tous les cas, mais autant vérifier si le besoin ne serait pas couvert par une telle solution.
En général, en entreprise, utiliser .doc juste pour faire des titres et des paragraphes, ce n'est pas approprié du tout.
blog.rom1v.com
[^] # Re: Partager les sources plutôt que les binaires
Posté par Strash . Évalué à 10.
Je crois que l'on ne vit pas dans le même monde. Word est la référence et ça ne changera pas avant un bon bout de temps, si ça change ça sera pour un autre WYSIWYG type LibreOffice. De plus je ne vois pas quelle serait ta solution pour remplacer un tableur.
Comme je l'ai précisé je travaille en inter-entreprise, je ne suis pas du tout en position de changer le format de fichier utilisé. Donc si quelqu'un veut échanger un .doc, il échangera un .doc.
[^] # Re: Partager les sources plutôt que les binaires
Posté par ®om (site web personnel) . Évalué à -1.
Si les gens sont prêts à faire du Wiki, tu peux aussi utiliser gitit. Le résultat est très proche d'un MediaWiki classique, sauf que derrière c'est du markdown, pandoc, git, etc.
Je ne proposais pas de solution pour remplacer le tableur.
blog.rom1v.com
[^] # Re: Partager les sources plutôt que les binaires
Posté par Anonyme . Évalué à 10.
chez moi, j'ai passé les documents partageable sous SVN, serveur distant, multisite (3) une dizaine de personne. Et grace a tortoiseSVN ca se passe plutôt pas trop mal, la courbe d'apprentissage est très petite, cela conviens pour la plupart. J'avais regardé des outils plus poussé, mais l’intégration de tortoise a Windows facilite la vie des fainéants qui ne veulent rien apprendre.
en cas de conflit, on me téléphone et je le gère car c'est la merde les fichier word, avec excel ca l'est un peu moins. Quand ils y pensent ils mettent un verrou. Pas de fork, merge toussa. j'avais tenté une explication a quelques uns, sans succès, ce qui est dommage car c’était pour des sources en C++. C'etait vu comme du flicage, et que untel n'avais pas a regarder mes sources qui sont hyper compliqué pour un autre génie que moi. :D
pour les sources -> personnes n'en veut
pour les documents word, excel-> j'ai 50 % d’enthousiaste sauf en cas de conflit, ils ont un peu de mal a saisir ce qu'est un conflit. J'en ai un qui préfère télécharger sur le site web de SVN la derniere version qui l'interresse, pour la mettre dans son répertoire /o. Du coup je doit lui envoyer un mail pour le prévenir d'un commit sur ce qui l'interresse. réfractaire a ce point je n'aurai pas cru que cela existait :D
[^] # Re: Partager les sources plutôt que les binaires
Posté par yohann (site web personnel) . Évalué à 10.
je suis entièrement d'accord avec toi.
…
dans un monde parfait…
…
en attendant à chaque fois que j'ai tenté cette approche avec des utilisateurs finaux, je me suis heurté à un mur
l'informatique doit être d'abord sexy, puis simple, et en dernier lieu efficace…
idéalement il faudrait un éditeur de markdown en wysiwyg pour avoir une chance d'imposer cette méthode de travail (un truc bien opaque qui prenne les user pour des con en leur permettant de choisir moult police de caractères et moult mise en forme non supporté par markdown, mais qui n'enregistrerait au final aucune de ces fioriture inutiles)
[^] # Re: Partager les sources plutôt que les binaires
Posté par Tit . Évalué à 7.
Bel idéal!
[^] # Re: Partager les sources plutôt que les binaires
Posté par yohann (site web personnel) . Évalué à 3.
n'est ce pas …
[^] # Re: Partager les sources plutôt que les binaires
Posté par RB . Évalué à 10.
J'ai eu une expérience avec ça la semaine passée. Je vais vous raconter…
Je devais donner une spécification d'API à une grosse boîte via un consultant qui travaille pour notre société et la grosse boîte en question.
Mes docs des APIs, je les rédige en markdown, puis généralement on les convertit en html/css pour les lire plus facilement à l'écran (j'ai mis une belle css).
Évidemment, travailler en markdown permet d'avoir un suivit de version optimal avec git ou autre.
[Je ne suis pas 100% satisfait de markdown pour ma rédaction technique style API, si quelqu'un à des expériences avec un autre format de balisage léger plus adapté qu'il me le fasse savoir :)]
Donc, je génère le tout, j'exporte tant bien que mal mon html en PDF pour que cela reste joli et je fournit la doc.
Le consultant me dit qu'il faut un paragraphe initial qui indique la version et la date dans le document ainsi ce sera une garantie de la version que l'on donne…
J'ajoute un paragraphe avec ces infos un peu "inutiles" puisque le suivit des versions est déjà optimal avec mon DVCS et je renvoie en PDF.
Le consultant me dit que le format ne va pas, qu'il faut du word, comme ça on peut le modifier à plusieurs.
Je lui explique que mon format source n'est pas word et que le plus simple sera de faire du copier coller depuis la version html.
Il prend la version html et part travailler sous word…
Maintenant, voyons les changements si importants qui nécessitaient word: mettre des header/footer avec le logo de notre entreprise, fichier en l'air toute la mise en page (qui contenait des textes dans des styles subtilement différents comme du monospace) pour que ça ressemble plus à des docs que l'on a déjà, casser plusieurs bout de l'API au passage.
Il revient fièrement avec la version word, et me dit sur un ton didactique, voilà maintenant c'est un document qui peut nous servir de référence pour gérer les versions !
Sur ce je lui explique que ma doc de part son format original est synchronisée avec mes API dans un vrai gestionnaire de version et qu'il n'y a aucun risque d'avoir du mal à tracer les changements, que word n'est pas adapté à cela et que les doc techniques ne devraient pas mélanger contenu et formatage.
Après cette explication, il est partit sans rien dire. Les gens ne comprennent pas ce qu'est du markdown, ce qu'est un vrai gestionnaire de version et ce qu'on veut vraiment dire, il continuera comme ses autres collègues à ne jure que par du word et à pester lorsqu'il recevra n'importe quel autre format…
[^] # Re: Partager les sources plutôt que les binaires
Posté par patrick_g (site web personnel) . Évalué à 10.
Bah voilà l'explication. Ces gens ne vivent pas le même monde que toi. Ils ont tous des doctorats en Powerpoint et ils tiennent à te le faire savoir.
[^] # Re: Partager les sources plutôt que les binaires
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 6.
Merci de ne pas tous nous mettre dans le même panier…
Ce n'est pas parce qu'on a décidé de faire du conseil après plusieurs années de technique qu'on devient automatiquement lobotomisé à Powerpoint…
[^] # YEEEEEEEN A DES BIEEEENS
Posté par Octabrain . Évalué à 2.
https://www.youtube.com/watch?v=AimnVR0kkw4
[^] # Re: Partager les sources plutôt que les binaires
Posté par Marotte ⛧ . Évalué à 6.
Hé ! C'était une boutade, juste une caricature du travers de certains consultants, on pourrait caricaturer un libriste comme étant un doctorant en emacs qui allumerait tous les soir une bougie pour Saint Ignucius.
Étonnant ta réaction…
[^] # Re: Partager les sources plutôt que les binaires
Posté par Zenitram (site web personnel) . Évalué à 9.
Ah ouais, quand même…
Lors de l'export HTML ou PDF, la version et date du document "disparaissent", et donc c'est tout à fait utile de mettre ça dans le PDF (ou si c'est imrpimé ensuite, et j'en passe). Ne pas le mettre est même une faute!
Pareil pour le logo de l'entreprise, c'est aussi très utile et l'oublier est aussi une faute.
Pareil pour la mise en page, quand il y a des choix graphiques de l'entreprise, l'idée est de faire les mêmes choix.
Les autres sont tous des idiots, et moi je suis parfait j'ai la solution et je sais tout ce qui est inutile.
Ou pas.
Ici : 1 partout, l'un ne sait pas gérer des versions et utilise un outils complètement inadaptés à de la documentation d'API, et l'autre ne sait pas répondre au besoin sans qu'on lui dise explicitement le moindre détail de ce qu'est une entreprise. Certes, je préfère celui qui sait pas répondre au besoin, un petit coup d'information et il ne devrait pas oublier la prochaine fois de les mettre les informations utiles, alors que l'autre a beaucoup de choses à apprendre sur les principes bien plus de base de la gestion de version, par contre il y aura peut-être quand même un problème avec la personne qui croit qu'elle fait toujours mieux que les autres et que ce qu'on lui dit c'est "inutile mais je le fais pour que t'arrête de me faire chier", du coup j'hésite : non, c'est vraiment 1 partout, difficile à départager.
[^] # Re: Partager les sources plutôt que les binaires
Posté par yohann (site web personnel) . Évalué à 1.
Mouais, sauf qu'il me semble plus facile de partir du markdown, et de modifier les script de génération pour afficher un footer/header dans le document final contenant toutes les infos de version nécessaires que de versionné proprement des document binaire (word).
ensuite si le format de word est réellement comme j'ai cru le comprendre du xml compressé, il est peut être possible d'imaginer un (d)vcs qui soit capable de décompresser le document lors des commit pour stocker uniquement les diffs sur le xml et donc versionner efficacement du word
[^] # Re: Partager les sources plutôt que les binaires
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ou la solution est de générer du html collé ensuite dans un template word. Cela se passe assez bien.
"La première sécurité est la liberté"
[^] # Re: Partager les sources plutôt que les binaires
Posté par Philippe F (site web personnel) . Évalué à 2.
Je suis tout à fait d'accord que produire une documentation dite professionnelle à l'arrache en accolant 3 outils est tout à fait inadapté.
Faire une vraie doc demande plus d'investissements que ça, bienvenue dans le monde réel !
Ca me fait penser à ces lobbyistes du libres qui se moquent de moi parce que j'utilise PowerPoint et Excel alors que « LibreOffice sait tout faire de la même façon » . Sauf que quand on tombe face à des utilisations autres que extrêmement basiques, LibreOffice n'est plus un clone des outils Microsoft et on tombe sur des incompatibilités, fonctions manquantes [1], rendus incorrects, ou tout simplement une interface beaucoup plus difficile à exploiter.
[1]: j'utilise très fréquemment sous Excel les fonctions NB.SI.ENS et SOMME.SI.ENS qui sont bien pratiques, mais non dispo sous Calc. Et j'ai pas trouvé d'alternatives.
# SparkleShare, Seafile, Dropbox
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 5. Dernière modification le 05 février 2013 à 15:09.
SparkleShare ?
Seafile ?
Dans Dropbox tu peux partager des répertoires et/ou des documents entre plusieurs utilisateurs. Je le faisais chez un de mes ex-employeurs. Par contre, stockage dans le cloud chez Dropbox, bouh bouh.
Les deux solutions ci-dessus sont installables sur ta propre infra.
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par Strash . Évalué à 3.
Merci pour ces deux noms de projets, on est très proche !
SparkleShare utilise git en arrière plan.
Je me demande juste si il y a la possibilité de voir une liste des différents commits d'un fichier, ainsi que la possibilité d'avoir une description sur les commits.
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par flagos . Évalué à 2.
gitk mon_fichier ?
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2.
Pour SparkleShare flagos t'a répondu.
Pour Seafile il y a une jolie interface web… (que je n'ai pas encore essayée, ce sera un de mes tests ces prochains jours).
Par contre, la description ça va être difficile : tu veux quoi comme description vu que ce sont des synchros automatiques ?
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par Elfir3 . Évalué à 3.
Suite à ce journal, je m'y suis mis. Et je suis séduit ! L'interface web est bien foutue, possibilité de choisir les répertoires à partager, avec qui on partage, on peut travailler avec des groupes… Le seule reproche que j'ai à lui faire c'est que c'est juste un poil déroutant lors du premier lancement :
Bref, du bon, pour ne pas dire très bon pour la jeunesse du soft, mais un peu de fignolage le rendrait encore mieux.
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par Philippe F (site web personnel) . Évalué à 2.
J'ai globalement le même problème dans ma société et j'ai finalement opté pour Dropbox. C'est de loin la solution la plus simple, avec conservation de tout l'historique.
Par contre, les inconvenients de Dropbox:
si tu travailles sur le fichier en mode "brouillon", il est quand même synchronisé à chaque sauvegarde, donc des gens voient des versions non finalisées. A compenser en travaillant au brouillon dans un répertoire à part mais c'est pas pratique.
si tout le monde travaille en même temps sur le fichier, c'est la zone. Sans que ce soit en même temps, il suffit que ce soit beaucoup de gens qui consultent le fichier au même moment par exemple.
j'ai pas mal de cas où dropbox dégage des modifications déjà faites… et c'est la zone pour les retrouver.
Globalement, ca reste le plus simple sans être le plus fiable.
Avant, j'avais testé SVN qui marche pas trop mal, sauf quand tu commences à déplacer des fichiers, renommer, avoir des conflits, ou simplement SVN mal luné qui te nique ses fichiers metadata.
# Google Drive
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 6. Dernière modification le 05 février 2013 à 15:09.
Autre possibilité, utiliser Google Drive et/ou Google Apps…
Ou équivalent, je ne sais pas s'il y a d'autres solutions aussi avancées que chez Google…
Bon, par contre, comme pour dropbox, stockage dans le cloud, bouh bouh pas joli
# gérer des binaires contenant du texte avec un git like
Posté par Dreammm . Évalué à 9.
C'est possible de gérer des binaires avec git (ou autre, insérez votre poison préféré en cas d'allergie).
Le problème est de gérer le suivi entre 2 version d'un fichier, vu que le diff entre 2 binaires n'est pas tip top lisible.
Une solution est de paramétrer votre git (ou autre) pour convertir les binaires (avant et après modification) en texte, et calculer ensuite le différentiel. On continue bien sûr de stocker le binaire, la conversion en texte ne sert qu'à afficher les variations entre les 2 versions.
Un exemple avec git et des documents openoffice :
http://4d43.wordpress.com/2011/12/01/git-and-smart-diff-on-opendocument-files/
J'espère que cela peut t'aider dans ta quête
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Si les utilisateurs sont du genre à ne vouloir utiliser que Word, je les vois mal se mettre à git.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par Dreammm . Évalué à 2.
Je n'ai sûrement pas du être assez lourd avec les formulations "git (ou autre)".
Je présente dans mon commentaire un principe de solution, pas un truc tout fait.
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par Gabin II . Évalué à -2.
L'approche est mauvaise, on ne fait pas de diff sur un binaire, on lit le commentaire du commit relatif aux changements.
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
OOo et LO, peut-être aussi MSWord savent faire un diff entre 2 fichiers. Par contre, à priori, ce n’est pas accessible depuis la ligne de commande, il faut ouvrir le dernier fichier puis faire "Édition" → "Comparer le document" et choisir l’ancien fichier.
Je l’utilise régulièrement pour fusionner des documents qui ont été modifiés par plusieurs personnes sans concertation.
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par Gabin II . Évalué à 1.
Quand je parle de binaire, j'inclu les images, sons, objets 3D dont une conversion en txt est inutile.
D'ailleurs un .doc/.odf/ contient également des "objets" images, sons, fonts, composites, etc…
Soit nous avons un SVN ou GIT intégré au logiciel même (la personne ici veut utiliser ces VCS), il semble d'ailleurs que M$ ait montré sa volonté d'intégré Git dans ses logiciels, soit on utilise des "hooks", je ne connais pas l'équivalent GIT, qui nous permettrait de scripter l'étape du "diff" avec le lecteur qui va bien (ex: eog pour les images).
Sinon en effet, quitte a faire du .doc, autant utiliser ce que M$ fourni et est plutôt bien fourni de ce côté, le traçage/revue dans Office, Sharepoint (beurk), Workspace (vraiment pas mal, je l'ai utilisé sur un projet, une sorte de sharepoint ad-hoc mais bien plus).
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par steph1978 . Évalué à 3.
N'importe quoi.
Le commentaire est là pour dire le pourquoi du changement pas pour en reprendre le détail. C'est le diff qui donne le détail.
[^] # Re: gérer des binaires contenant du texte avec un git like
Posté par Tobu . Évalué à 1.
git avec
.gitattributes+filter.<type>.clean+filter.<type>.smudge+diff.type.textconv+rezip+odt2txtouunoconvmarche très bien pour un usage personnel, mais l'étendre n'est pas trivial parce que ça repose sur des modifications de~/.gitconfigdifficiles à partager. Après peut-être que la fonctionnalité est assez utile pour que certains wikis puissent intégrer des filtres et une visualisation d'historique en reposant sur les outils de git, mais Alfresco est plus spécialisé et doit avoir l'avantage sur ce terrain.# Même soucis pour les images
Posté par moi1392 . Évalué à 1.
Au boulot chez nous, on a le même soucis pour tous les binaires utilisés dans nos sources (images, sons, …)
Pour l'instant, c'est géré avec le reste des sources dans notre vcs, mais ça n'est pas idéal (prends beaucoup de place car les diff sont très mauvais et font la taille du fichier la plupart du temps)
Je ne sais pas si un vcs particulier aurait des avantages par rapport aux autres là dessus (diff adapté après reconnaissance ou tag du binaire), mais si vous avez des astuces, ou des solutions qui marchent chez vous (r), ça m'intéresse !
[^] # Re: Même soucis pour les images
Posté par phoenix (site web personnel) . Évalué à 4.
Mercurial a une extension pour gérer les gros fichiers (ou les fichiers images) d'une autre manière. (Extension largefiles)
# Un wiki?
Posté par saltimbanque (site web personnel) . Évalué à 2.
Après tout c'est presque what you see et caetera, et imbattable pour le suivi de version (par utilisateur, date..)
Une fois l'article finalisé, le copier coller dans word reste possible, et ça ne m'étonnerait guère qu'il existe mieux, au pire une horreur du genre wiki -> pdf (mais uniquement une fois le doc finalisé)
[^] # Re: Un wiki?
Posté par Strash . Évalué à 2.
Le souci est la notion d'offline.
Et également les feuilles de calcul Excel.
[^] # Re: Un wiki?
Posté par saltimbanque (site web personnel) . Évalué à 3.
Ah oui avec un tableur, là.. comme les commentaires ci-dessous, malheureusement on ne peut pas tout faire sans formation / outils spécifiques.
J'ai jamais testé la gestion de version dans une suite office, aucune idée de la qualité du truc.
[^] # Re: Un wiki?
Posté par gouttegd (site web personnel) . Évalué à 8.
Ce n’est pas mal du tout et ça peut rendre de fiers services, à condition que tous les utilisateurs jouent le jeu et fassent l’effort de s’en servir correctement — ce qui, dans mon expérience, n’a jamais été le cas…
C’est en fait le même problème dont souffrent les outils comme Alfresco ou SharePoint, ainsi que le relève l’auteur du journal : ces solutions sont efficaces, mais
C’est un peu comme les styles : les styles sont un excellent outil qui, bien utilisés (ou même, simplement, utilisés tout court), permettent de structurer un document et d’en séparer le fond de la forme (non, il n’y a pas que LaTeX qui permet ça). Mais la plupart des utilisateurs ne savent même pas que ça existe et ceux qui le savent n’en voient pas l’intérêt…¹
¹ Observations de l’Institut National de Pifométrie réalisées, d’une part, sur un échantillon représentatif (ou pas) de 107 étudiants entre septembre et octobre 2010, et d’autre part, sur un échantillon encore moins représentatif d’une dizaine de proches collaborateurs entre 2007 et 2012.
[^] # Re: Un wiki?
Posté par steph1978 . Évalué à 2.
Faut dire que c'est tellement mal géré dans la suite bureautique monopolistique ce même quand on voudrait s'en servir, on renonce vite.
Je n'arriverai jamais à comprendre comme deux titres avec le même style sélectionné n'ont pas le même rendu.
# SVN ou autre
Posté par ndv . Évalué à 2.
SVN marche également pour des documents binaires, et l'apprentissage est relativement aisé.
Marche hors ligne, propose une gestion des droits, simple à utiliser, historisation des versions, bonne intégration au système avec TortoiseSVN.
(marche également avec les autres gestionnaires de version)
[^] # Re: SVN ou autre
Posté par mahikeulbody . Évalué à 4.
C'est que j'utilisais dans mon boulot. TortoiseSVN offre une fonction très pratique où en sélectionnant deux révisions il affiche directement un doc avec les marques de révisions indiquant les différences entre les deux docs. En revanche on demandait à l'auteur de commiter lui-même afin qu'il puisse saisir la description des modifications (un simple clic-droit sur le fichier à commiter). Chaque commit déclenchait un email aux intéressés avec la description du commit. SVN était configuré pour que chacun ait une copie de tous les documents dans les répertoires qui l'intéressent (=> accès offline aux documents), un simple clic droit sur un répertoire donnant accès à la mise à jour du répertoire avec les commits fait par d'autres utilisateurs.
Je sais que SVN c'est considéré comme has-been mais pour ce genre d'usage et avec un client bien fichu comme TortoiseSVN, c'est très simple à utiliser même pour des non-informaticiens (il faut quand même un admin pour gérer le truc).
[^] # Re: SVN ou autre
Posté par case42 (site web personnel) . Évalué à 1.
Pardon, mais au XXIieme siecle, faut plus préconiser SVN. Comme un récent journal l'a indiqué, GIT, ou si la courbe d'apprentissage est un problème, Mercurial.
[^] # Re: SVN ou autre
Posté par barmic . Évalué à 4.
Quel est l'intérêt ? Tu pense que les utilisateurs vont avoir plusieurs branches locales ou plusieurs dépôts distants (généralement au contraire dans ces cas on préfère une révérenciel global) ? Sachant que tout les merges seront pourris et pour les même raison tout ce qui est manipulation de l'historique ou le cherry picking aussi.
Il ne faut pas proposer des DCVS juste parce que ça fait bien aujourd'hui de parler de ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par Adrien . Évalué à 3.
les commit en local ? genre par ex. un type pressé qui bosse dans le train… après la question reste entière si le mec ne fait pas de différence entre un bon commit et un mauvais commit.
les sous-dépôts ? On pourrais par ex. avoir un dépôt commun par équipe, qui sont ensuite merger dans un dépôt principal (par un « Con qui fait le Tri » ?) Comme ça les équipes bossent comme il faut, et quand le machine est prêt, finalisé, hop on l'envoi pour le partager avec tout le monde.
[^] # Re: SVN ou autre
Posté par barmic . Évalué à 2.
L'intérêt d'un commit local est très très très limité pour des documents binaires. Il apporte à mon avis surtout une confusion entre ce qui est poussé et ce qui est commité.
Ça ne m'a pas l'air d'être l'organisation décrite dans le journal. Il n'y a pas des équipes mais une équipe qui travail sur un document. De plus il ne parle pas d'une plateforme de publication, mais d'un groupe de personnes dans différentes entreprises qui éditent un document de manière collaborative.
(j'ai un peu l'impression de voir des commerciaux tenter de faire coller les besoins de quelqu'un à leur produi)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par Adrien . Évalué à 2.
Les préjugés c'est mal. Là je listais par exemple deux utilisations qui ont poussé à l'adoption de mercurial. Ça n'était pas exactement de la doc, mais la problématique reste similaire (fichiers binaires + texte, pb de mise à jour, etc.) Ça se passe dans la vraie vie, dans un laboratoire français, et non pas uniquement sur une brochure commerciale.
[^] # Re: SVN ou autre
Posté par barmic . Évalué à 2.
Je n'ai pas dis que les commerciaux sont ainsi, j'ai dis que des commerciaux le sont.
Je n'ai pas dis que ça n'existe pas, je dis que ça ne corresponds pas au workflow déjà défini (et à priori non modifiable).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par steph1978 . Évalué à 1.
Tous les commentaires tendent à dire que les utilisateurs ont déjà du mal a être sensibilisé à des technologies relativement simples et toi tu veux partir directement sur un système qui permet de gérer le développement du noyau Linux. Bon courage.
[^] # Re: SVN ou autre
Posté par steph1978 . Évalué à 2. Dernière modification le 10 février 2013 à 20:50.
Tu as raison, il faut plus préconiser SVN que GIT car, dans la majorité des cas, cela répond au besoin tout en étant moins compliqué qu'un DVCS.
# Problème récurrent
Posté par Benjamin Verhaeghe (site web personnel) . Évalué à 3.
Tu décris là un problème récurrent en entreprise. Il est déjà difficile d'être sûr qu'un dossier dropbox soit maintenu à jour, alors l'utilisation de la GED…
Cependant, je pense que si cela est réellement utile, il faut encourager au maximum l'apprentissage et l'utilisation des solutions adhéquates sous peine de se retrouver limiter par la suite.
# Owncloud
Posté par claudex . Évalué à 9.
Owncloud permet de gérer les versions et de partager un dossier entre plusieurs utilisateurs et offre un client de synchronisation sur le bureau.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Owncloud
Posté par denisb . Évalué à 1.
En effet Owncloud est à mon avis un bon candidat. La gestion des versions est basique, mais a le mérite d'exister, et on garde le contrôle du stockage ( et des backups ) sans avoir besoin du très haut débit.
Autre point très intéressant, la possiblité d'avoir un serveur samba en backend.
Le projet est encore jeune (et buggué !) mais très réactif.
[^] # Re: Owncloud
Posté par Zenitram (site web personnel) . Évalué à 6.
Owncloud c'est le truc qui, la dernière fois que j'ai testé et c'était il y a peu, te vire le fichier et son historique si tu appuies sur le bouton "supprimer" et synchronise.
Pour gérer les versions, c'est 0 : oui, une suppression, c'est une version!
La dernière fois que j'ai regardé, il y avait un ticket d'ouvert dessus avec plein de gens qui cherchaient comment on récupère un fichier supprimé, vu qu'ils pensaient que Ownclound gérait les versions (c'est la pub en tous cas). Perso, ça m'a pas mal refroidit sur ce projet, et retour à Dropbox.
# SVN+TortoiseSVN+Hook
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Bonjour,
Une fois j'ai eu cette problématique, et j'avais résolu cela avec:
- un dépot SVN réservé pour cela. Le svn en mode http pour passer les firewall les doits dans le nez.
- Un tortoiseSVN installé sur le windows, et un dossier "document partagé". Une mini formation: click-droit "mettre a jour" pour mettre à jour, …. Tortoise fait cela très bien avec les icones et autre. Les non informaticiens s'en sortent.
- Un petit hook sur le serveur svn, pour envoyer un mail à tout le monde pour avertir d'une version. Le contenu du mail est le message du commit. Du coup, pas plus d'effort ou de temps pour la personne, elle soigne son message de commit plutôt que de soigner un mail.
- Pour le "diff", c'est l'historique de modification de Microsoft, activé dans le document, qui le gérait.
Ca marchait bien et les gens était content
# Rien d'autres
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Je sais que Libre/OpenOffice peuvent intégrer le maintien des versions des document (activation : Édition -> Modification -> Enregistrer). MS Office peut le faire aussi, mais je n'ai jamais essayer. Donc pourquoi ne pas utiliser ça directement ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Rien d'autres
Posté par mahikeulbody . Évalué à 2.
C'est complémentaire à une gestion de docs mais ça ne la remplace pas (sauf dans le cas d'un seul auteur par document).
# Quitte à faire du Microsoft, autant y aller à fond
Posté par dinomasque . Évalué à 9.
Microsoft a pensé à ce problème et offre une solution MS Office + MS Sharepoint
http://office.microsoft.com/fr-fr/word-help/effectuer-le-suivi-des-versions-d-un-fichier-dans-une-bibliotheque-sharepoint-HA010208585.aspx
J'ai du mal à imaginer comment faire mieux sur des documents MS Office.
BeOS le faisait il y a 20 ans !
[^] # Re: Quitte à faire du Microsoft, autant y aller à fond
Posté par sifu . Évalué à 2.
Il me semble que Nuxeo et Alfresco proposait des choses similaires. Après, cela fait pas mal de temps que je n'ai pas suivi cela …
[^] # Re: Quitte à faire du Microsoft, autant y aller à fond
Posté par serianox . Évalué à 5.
Pour utiliser SharePoint au boulot, ça marche à peu près aussi mal que Word. Donc ça ne devrait pas dépayser l'utilisateur lambda. :)
Personne n'a réussi à faire marcher la gestion de version, donc pour le moment tout le monde se contente juste d'uploader manuellement la nouvelle version. Et tout ça en utilisant le suivi de modifications de Word.
[^] # Re: Quitte à faire du Microsoft, autant y aller à fond
Posté par Marotte ⛧ . Évalué à 6. Dernière modification le 05 février 2013 à 20:02.
Je compatis pour Sharepoint, je pratique aussi.
J'ai bien aimé l'un des points de la « formation » que j'ai reçue : « Quand tu modifies un document il faut choisir modification majeure, pas mineure, parce que sinon ça marche pas, le document disparaît. »
Beaucoup plus qu'un défaut intrinsèque aux solutions Microsoft c'est surtout la croyance de décideurs qui pensent qu'un logiciel va régler des problèmes de communication sans y consacrer les ressources humaines nécessaires qui pose un problème.
Maintenir la documentation d'un service, d'une entreprise, s'assurer que les employés l'utilisent correctement c'est un boulot à plein temps à partir d'un certain volume. Ça requière des compétences spécifiques. C'est pas à Bob, chef de projet intégration, de faire ça 1 heure par jour sur un coin de bureau…
# Proposition
Posté par Gastlag . Évalué à 1.
DVCS-Autosync (git+jabber)
http://www.mayrhofer.eu.org/dvcs-autosync
+
RabbitCVS
http://www.rabbitvcs.org
ou
TortoiseGit
http://code.google.com/p/tortoisegit/
égale
♥
Ou sinon :
SyncApp
http://korben.info/testez-syncapp-de-bittorrent.html
(avec liens pour télécharger le logiciel)
[^] # Re: Proposition
Posté par myocastor . Évalué à 1.
J'ai fait un truc relativement simple au boulot:
Inconvénient:
- entre deux synchro, les modifications ne sont pas tracées
- pas de nom de l'utilisateur ayant modifié le doc.
[^] # Re: Proposition
Posté par Albert_ . Évalué à 2.
DVCS-Autosync cela a l'air un peu mort comme projet…
[^] # Re: Proposition
Posté par 16aR . Évalué à 1.
Oui mais ça marche pas mal ;)
Installé et configuré sur le pc de Mme Michu (alias ma mère), ça tourne bueno :)
# Un problème courant dans le monde de l'informatique.
Posté par Kaane . Évalué à 10.
Des gens qui bossent dans leur coin sans forcément rebalancer les infos aux autres parcequ'ils veulent que "la seule bonne dernière version" soit la leur ?
Des intervenants qui ne veulent en aucun cas se remettre en cause, changer d'outils ou même simplement utiliser les templates words fournis et qui préfèrent faire du copier coller du document plus du tout à jour d'il y a 5 ans. Document dans lequel il y a pas moins de 25 éléments à changer en fonction du client, du type de projet, du cadre fiscal/social ou de l'age du capitaine (N.B : sur les 25 éléments vous serez déjà content si l'élément principal - le nom du client - est changé à toutes les pages) ?
Des gens qui téléchargent de toute façon le document sur leur poste perso avant de l'éditer (parceque sinon c'est trop long) et qui écrasent la version en ligne 3 mois plus tard avec la leur (dans laquelle ils n'ont pas fait de modif de toutes façons - ils n'ont pas eu le temps) ?
Des gens qui ne veulent bosser qu'en Word et qui font un copier-coller des tableaux Excell en mode "données uniquement" pour les éditer à la main au mépris de toutes les formules créées dans le doc Excell sus-mentionné ?
Si cette situation vous rappelle quelquechose, si vous avez vainement tenté par la pédagogie, la menace, la corruption, la supplique de faire bouger les choses.
Si tous les logiciels de GED, de CRM ou de Datastore que vous avez pu tester sont resté inutilisés malgré des configs au petit oignons et un budget formation pharaonique (formation à l'issue de laquelle 80% des utilisateurs utilisaient tous en douce le mot de passe de Veronique - parceque c'était la seule à s'en souvenir).
Ne cherchez plus, nous avons la solution : Il vous faut "Un Con Qui Fait Le Tri" !
Avec "Un Con Qui Fait Le Tri" fini les problèmes d'interopérabilité, de recherche de dernière version ou de fusion de trois documents subtilement différents sans que personne ne sache quel paragraphe de quel document est bon. Il suffit d'inviter "Un Con Qui Fait Le Tri" à toutes les réunions et de lui forwarder tous les mails.
Pour à peine le prix d'un stagiaire par mois, "Un Con Qui Fait Le Tri" c'est la garantie que vous n'aurez plus jamais à chercher un coupable quand la version du doc qui est partie à l'impression est celle qui avait fait palir de peur les avocats ou bouilloner de rage le PDG. Avec "Un Con Qui Fait Le Tri" dans votre entreprise sans rien changer à vos habitudes de travail vous disposez tout à la fois d'une excuse implacable et d'un bouc émissaire blamable à merci.
Dès aujourd'hui appelez l'agence pour l'emploi la plus proche de chez vous et demandez "Un Con Qui Fait Le Tri" - dans certaines régions celà peut même être déduit de votre IS.
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 05 février 2013 à 20:08.
Pertinage dès la lecture de la première phrase…
** slow clap ** pour le reste du message.
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par saltimbanque (site web personnel) . Évalué à 1.
La première phrase est particulièrement bonne puisqu'elle sous-entend que, quand bien même avec "un con qui fait le tri"… Ou alors, il faut un Con qui vire tout le monde.
Sinon idéalement, en s'inspirant de la consolidation, on voudrait un système où les modifications ne détruisent pas les anciennes versions mais s'y cumulent pour former un tout cohérent. Il y a un niveau "saisie", un niveau "réconcilliation", un niveau "finalisation"…
Ou comme lorsque Freud décrit Rome: les monuments modernes y cotoient les bâtiments modernes. Le collisée cotoie le gratte-ciel. La première version du document doit cotoyer la dernière / pas forcément la dernière version présentée, mais la dernière version de travail, la dernière version source.
C'est ce que font parfois les gens d'eux mêmes, par ex. en ajoutant un commentaire tout en laissant une phrase intacte.
(Que garder de ce commentaire? que l'objectif est beaucoup trop haut)
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par Marotte ⛧ . Évalué à 3.
Non. Le « Con Qui Fait Le Tri » est le seul à décider la version de qui est la bonne. Il n'y a qu'un con qui décide. (à lui d'être parfois plus con que certains)
Je suis tout à fait du même avis que Kaane. Il faut UNE personne, responsable de TOUTE la documentation, pour pouvoir bien faire les choses. Choix techniques et fonctionnels, formation continue des utilisateurs, résolution des conflits de versions, etc…
De plus, s'il part d'une documentation complètement disparate faite à l'arrache chacun dans son coin, dans une entreprise de 50-100 employés c'est un projet de 3 à 5 ans pour un profil très qualifié (donc pas un stagiaire) : gestion de projet, psychologie, pédagogie, expertise technique. Je pense que le qualifier de con était justement très ironique.
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par saltimbanque (site web personnel) . Évalué à 1.
Les conflits dans la rédaction d'un truc en commun peuvent s'appliquer à des documentations du genre "que dois faire la boîte". Dans ce cas, difficile de placer un responsable arbitre, encore plus un con (bien que ce soit pratiqué)
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par Kaane . Évalué à 10.
Je suis tout à fait du même avis que Kaane. Il faut UNE personne, responsable de TOUTE la documentation, pour pouvoir bien faire les choses. Choix techniques et fonctionnels, formation continue des utilisateurs, résolution des conflits de versions, etc…
Je te remercie grandement des nobles intentions que tu me prettes. Si il est vrai qu'un vrai service documentation peut aider, il y aura toujours le moment ou le documentaliste se verra obligé d'insister lourdement pour qu'un supérieur hiérarchique quelconque (très quelconque même, mais aussi très supérieur hiérarchique), d'insister donc pour qu'il veuille bien arreter de faire de la rétention d'information et pour qu'il utilise les outils mis en place.
Celà se traduit généralement par le broyage méthodique dudit documentaliste, avec humiliations publiques, séances de vexations et finalement licenciement pour faute lourde soit parcequ'il refuse de faire le travail, soit parcequ'il essaye de le faire.
Utiliser "Un Con Qui Fait Le Tri" ne permet donc en aucun cas de résoudre le moindre problème en terme de communication interne au sein de l'entreprise - et encore moins d'identifier les parasites sociaux qui bloquent les processus sans réellement fournir de travail, ca n'est d'ailleurs pas son but. Le but d'"Un Con Qui Fait Le Tri" est multiple.
Son avantage premier est de permettre de gagner du temps : Ca évite à la personne dont ca serait éventuellement le métier de devoir monter au créneau pour se prendre une balle hiérarchique en pleine tête. Au prix de quelques stagiaires par an on sauve ainsi des documentalistes.
Son deuxième avantage est le calme relatif qu'il procure au responsable DSI. Pour prendre une anologie voiture (que je réprouve vertement sauf quand c'est moi qui les utilise, là elles sont totalement à propos); Le DSI est le garagiste à qui sa hiérarchie (le client) demande comment moins polluer sans changer ni la voiture, ni le carburant, ni la façon de consuire. Il peut soit tenter de convaincre de changer au moins un des trois aspect et se lancer dans une croisade ou chaque bataille gagné sera annulé par decret dès le lendemain, ou sinon il peut vendre un additif très cher qui fait "des miracles" et être tranquille pendant six mois. C'est bien six mois de tranquilité…
Son troisième avantage est celui d'avoir sous la main un bouc émissaire. En cette période de crise, et malgré l'arrivée de la gauche au pouvoir - il est diplomatiquement maladroit de réprimander ses chefs (surtout quand on a de bonnes raisons de le faire), alors que la claquette à l'arrière de la tête du stagiaire c'est gratuit. Au final quand tout explose on fout dehors la seule personne qui n'avait aucun moyen de faire changer les choses et on repart pour un tour en esperant que la prochaine restructuration fera que la prochaine fois ca explosera à la tête de quelqu'un d'autre.
[^] # Re: Un problème courant dans le monde de l'informatique.
Posté par dinomasque . Évalué à 2.
C'est lumineux !
BeOS le faisait il y a 20 ans !
# Problématique d'école
Posté par Marotte ⛧ . Évalué à 0.
Et un mix entre un outil comme rsync mêlé à une gestion manuel des répertoires avec un truc comme
./projet
./projet/WIP
./projet/Prod
./projet/Test
./projet/Test2
./projet/TestAlice
et une nomenclature des noms de fichiers simple et imposée, genre
<time stamp>_<user>_<document base name>?Bon courage en tous cas !
# bug mental
Posté par Yao Kuramoto . Évalué à 7.
c'est bizarre, en vous lisant tous là, j'ai l'impression qu'en fait le problème est pas technique…. et que vous vous débatez à trouver une solution technique à la négligence des
baltringuescollègues avec qui vous bossez.peux-t-on patcher la bêtise humaine ?
[^] # Re: bug mental
Posté par claudex . Évalué à 6.
C'est un problème à la fois technique et humain, on peut comprendre que des gens n'ai pas envie de passer du temps à gérer les versions, surtout si on peut trouver des moyens simples.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bug mental
Posté par Strash . Évalué à 4.
Pour moi l'informatique doit être simple, de nombreuses choses que l'on fait tout le temps devraient être automatique. De plus la gestion de version est quelque chose de trop important pour la laisser entre les mains d'humains, on le voit bien dans le monde du développement logiciel, personne ne nie l'intérêt d'un gestionnaire de version, pourquoi cela devrait être différent pour les non développeurs ?
[^] # Re: bug mental
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Il suffit d'utiliser VMS, par défaut tous les fichiers sont versionnés.
Non ? J'ai dit une connerie ?
[^] # Re: bug mental
Posté par Zenitram (site web personnel) . Évalué à 4.
Le problème n'est pas technique, mais la technique peut aider à faciliter le non technique.
Mais malheureusement, personne n'a encore trouvé une bonne solution technique qui aide pour gérer les fichiers pas prévus pour la gestion de version multi-utilisateurs genre les document Word ou Excel tout en facilitant la vie des utilisateurs afin qu'ils adhèrent.
[^] # Re: bug mental
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
La solution, c'est de prendre son courage à deux mains et d'utiliser un format prévu pour la gestion de version.
Dans les boites où j'ai été, j'ai toujours vu:
Petite devinette: qui produit des documents immondes, passe son temps à fusionner ligne à ligne et se plaint de perdre des versions?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: bug mental
Posté par gouttegd (site web personnel) . Évalué à 10.
Tu as probablement raté ce passage de la discussion :
Ce n’est donc pas une question de courage, sauf si tu proposes à l’auteur de pousser une bonne gueulante pour tenter de convaincre ses interlocuteurs — auquel cas à mon avis ce n’est pas de courage qu’il aura besoin, mais d’une promesse d’embauche dans une autre boîte…
Par ailleurs :
Tous ceux qui ne savent pas utiliser leurs logiciels, quels qu’ils soient.
Encore une fois, il est tout-à-fait possible de travailler efficacement avec un traitement de texte (que ce soit MSO Word ou LO Writer). La séparation du fond de la forme, la génération de documents esthétiquement corrects, la possibilité de gérer différentes versions et de suivre les modifications ne sont pas l’apanage des solutions à base de LaTeX, DocBook ou autres markdown ou assimilés.
La différence est que les utilisateurs de LaTeX/DocBook/etc. ont nécessairement appris à se servir de leurs outils (parce que ces outils sont inutilisables sans un minimum (?) d’apprentissage), alors que la plupart des utilisateurs de traitement de texte pensent que ce n’est pas la peine.
Tant que ces utilisateurs ne comprendront pas que pour être efficaces ils doivent apprendre à utiliser leur logiciel (même s’il semble très intuitif) au même titre qu’un ouvrier doit apprendre à utiliser sa machine, toute solution technique est vouée à l’échec.
[^] # Re: bug mental
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Probablement pas avec un ton hautain de technocrate qui à la solution parfaite pour des utilisateurs idéaux.
# GED + Dropbox-like
Posté par Re_ . Évalué à 2.
Salut,
Je n'ai pas testé, mais tu coupler une GED type Alfresco/Nuxeo avec un dropbox-like, par ex CmisSync (http://cmissync.com/).
D'un côté tu as l'avantage d'avoir une plateforme documentaire solide, et d'un autre la souplesse d'une solution à la dropbox.
[^] # CmisSync
Posté par Nicolas Raoul (site web personnel) . Évalué à 2.
Je valide pour CmisSync + Alfresco/Nuxeo, ça forme exactement ce que le posteur décrit dans le paragraphe "L'idéal".
CmisSync est aussi simple que le client Dropbox, et peut se connecter à n'importe lequel de ces logiciels de GED, grâce au protocole CMIS.
Tutoriels:
Note: Mon entreprise (une SSLL) a créé et maintient CmisSync, parce qu'un de nos clients en avait désespérement besoin. Logiciel Libre, on recrute des volontaires :-)
Nicolas Raoul
http://nrw.free.fr
# add-in office pour alfresco
Posté par aem_ . Évalué à 2.
d'un autre côté, sur alfresco avec ms office
tu n'est -pas- obligé de faire un upload systématique :
http://code.google.com/p/alfresco-ms-office-plugin/
tu as un plug-in pour les softs "office" pour "committer"
directement tes docs/versions depuis ton soft
sans avoir à uploader/charger sur ton poste.
directement dans l'interface de ms office.
[^] # Re: add-in office pour alfresco
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Et dans la version à venir le LibreOffice, il y a une intégration d'Alfresco & co.
[^] # Re: add-in office pour alfresco
Posté par gouttegd (site web personnel) . Évalué à 1.
Pour information, c’est déjà présent dans la version actuelle (3.6), mais « caché » dans les experimental features parce que pas encore suffisamment stable.
[^] # Re: add-in office pour alfresco
Posté par C2RIK . Évalué à 0.
Pour information, ce greffon est pour les versions les plus anciennes d'Alfresco. Les versions plus modernes (>3.3) implémentent le protocole Sharepoint: http://wiki.alfresco.com/wiki/Microsoft_Office
# Ça pourrait être pire…
Posté par Fopossum . Évalué à 10.
Vous pourriez tous être obligés d'utiliser Lotus Notes pour stocker les documentations…
Toute autre solution est meilleure !
cd /pub && more beer
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.