Je suis devant une problématique où il me manque des outils informatique pour accomplir une tache qui me semble de l'ordre du faisable techniquement avec des briques existante.
Je vais commencer par te dire que ton problème il n'est pas — je pense — principalement technique, mais humain. Si tu ne tiens pas énormément compte du facteur humain dans ta solution, ça foirera à coup sûr.
La solution que je te propose, je l'ai mise en place pour des gens qui ne voulaient pas décoller d'un outil Word-like, ce qui sera sûrement le cas pour toi. Saches que mon expérience a été un échec complet, parce que je n'ai pas dû prendre en compte assez le facteur humain, malgré une prise en compte aiguë des contraintes techniques (compatible Windows, sans déranger les habitudes). Donc peut-être à ne pas suivre, mais comme ça ressemblait à ton problème, je viens en témoigner ici.
Un prérequis était de travailler en groupe à distance, comme à peu près tous les outils aujourd'hui, même si aucun ne me satisfait toujours aujourd'hui (éternel problème). Pour ça, et pour éviter trop d'envois par e-mail (car c'est inévitable, ça arrivera) ainsi que les copies locales pas à jour, j'ai mis en place un partage WebDAV qui contient les fichiers sur lesquels travailler. Ça se monte bien sous Windows si on veut, et surtout ça s'ouvre directement dans LibreOffice et permet l'enregistrement direct avec le bouton « enregistrer ». Ça peut paraître un détail mais ça compte beaucoup dans l'acceptabilité utilisateur.
Et donc ensuite, il faut travailler avec LibreOffice, mais avec une particularité : les documents inclus dans le document « final », comme les images, les schémas, voire les sous-chapitres si tu le fais en mode « bien fait », doivent être inclus en précisant de ne pas inclure les données dans le document. Ainsi, seule une référence (relative) sera faite, et on pourra ainsi mettre à jour les images/schémas sans avoir à faire de la ré-inclusion dans le document maître. C'était un des besoins, pour ne pas avoir à se retaper des inclusions à chaque fois. En pratique, ça marche assez mal parce que les dimensions des contenus sont quand même enregistrées dans le document maître, et si tu modifies le ratio ça apparaît déformé. Également, ça ne permet pas de copier-coller le document dans un e-mail, vu qu'il ne contient pas toutes les images... Bref, c'était une « bonne idée » au départ, mais en pratique ça merde trop.
Et comme moi je bossais avec un montage davfs et qu'en plus je voulais du git, j'avais ajouté un script marrant : un cron tournait toutes les heures pour voir les modifications du répertoire faites en WebDAV, et créait un commit du nom de l'utilisateur qui avait modifié le ou les fichiers. Ainsi, moi je bossais en git (avec un hook post-push qui checkout automatiquement les modifications dans le partage WebDAV) et les modifications des autres apparaissaient également dedans. Ça n'est pas complètement dans l'esprit traçable et textuel de git (bien qu'en utilisant du Flat ODF pour ce dernier point, ça aurait pu le faire, mais là j'en demandais malheureusement trop), mais ça faisait l'affaire.
Alors là-dedans je ne parle pas du tout de branche, car je n'en avais pas, et que ça ne faisait pas partie de nos problématiques. Pour ton cas, je ne sais pas trop comment faire, mais du git même en graphique sous Windows était complètement hors de portée de mon public. En adaptant la solution ci-dessus avec un répertoire différent par branche (un working-tree par branche) ça pourrait éventuellement se faire, je pense, en réservant les opérations de merge au « spécialiste » qui utilise git, et les utilisateurs lambda qui choisissent le bon répertoire. Mais bon, ça peut sembler alambiqué.
Sachant que tout ça ne passe pas le test du « ça ne doit pas reposer sur une seule personne », ce qui sera donc sûrement également rédhibitoire.
Au final, le problème pour moi est bien plus profond : il est très difficile de faire ce genre de chose de manière bien structurée avec des outils WYSIWYG, et seuls les langages structurés basés sur du texte peuvent réellement résoudre le problème. Malheureusement on a « décidé » d'éduquer notre population à l'utilisation d'outils fermés et privateurs WYSIWYG, et nous payons aujourd'hui très très cher cette dépendance. C'est comme si la population aujourd'hui n'avait pas appris à écrire, et dépendais de la médiation de grand éditeurs américains pour s'exprimer. En fait, c'est même exactement la situation actuelle.
# LibreOffice + WebDAV
Posté par benoar . En réponse au journal Gestion de documentation. Évalué à 4.
Je vais commencer par te dire que ton problème il n'est pas — je pense — principalement technique, mais humain. Si tu ne tiens pas énormément compte du facteur humain dans ta solution, ça foirera à coup sûr.
La solution que je te propose, je l'ai mise en place pour des gens qui ne voulaient pas décoller d'un outil Word-like, ce qui sera sûrement le cas pour toi. Saches que mon expérience a été un échec complet, parce que je n'ai pas dû prendre en compte assez le facteur humain, malgré une prise en compte aiguë des contraintes techniques (compatible Windows, sans déranger les habitudes). Donc peut-être à ne pas suivre, mais comme ça ressemblait à ton problème, je viens en témoigner ici.
Un prérequis était de travailler en groupe à distance, comme à peu près tous les outils aujourd'hui, même si aucun ne me satisfait toujours aujourd'hui (éternel problème). Pour ça, et pour éviter trop d'envois par e-mail (car c'est inévitable, ça arrivera) ainsi que les copies locales pas à jour, j'ai mis en place un partage WebDAV qui contient les fichiers sur lesquels travailler. Ça se monte bien sous Windows si on veut, et surtout ça s'ouvre directement dans LibreOffice et permet l'enregistrement direct avec le bouton « enregistrer ». Ça peut paraître un détail mais ça compte beaucoup dans l'acceptabilité utilisateur.
Et donc ensuite, il faut travailler avec LibreOffice, mais avec une particularité : les documents inclus dans le document « final », comme les images, les schémas, voire les sous-chapitres si tu le fais en mode « bien fait », doivent être inclus en précisant de ne pas inclure les données dans le document. Ainsi, seule une référence (relative) sera faite, et on pourra ainsi mettre à jour les images/schémas sans avoir à faire de la ré-inclusion dans le document maître. C'était un des besoins, pour ne pas avoir à se retaper des inclusions à chaque fois. En pratique, ça marche assez mal parce que les dimensions des contenus sont quand même enregistrées dans le document maître, et si tu modifies le ratio ça apparaît déformé. Également, ça ne permet pas de copier-coller le document dans un e-mail, vu qu'il ne contient pas toutes les images... Bref, c'était une « bonne idée » au départ, mais en pratique ça merde trop.
Et comme moi je bossais avec un montage davfs et qu'en plus je voulais du git, j'avais ajouté un script marrant : un cron tournait toutes les heures pour voir les modifications du répertoire faites en WebDAV, et créait un commit du nom de l'utilisateur qui avait modifié le ou les fichiers. Ainsi, moi je bossais en git (avec un hook post-push qui checkout automatiquement les modifications dans le partage WebDAV) et les modifications des autres apparaissaient également dedans. Ça n'est pas complètement dans l'esprit traçable et textuel de git (bien qu'en utilisant du Flat ODF pour ce dernier point, ça aurait pu le faire, mais là j'en demandais malheureusement trop), mais ça faisait l'affaire.
Alors là-dedans je ne parle pas du tout de branche, car je n'en avais pas, et que ça ne faisait pas partie de nos problématiques. Pour ton cas, je ne sais pas trop comment faire, mais du git même en graphique sous Windows était complètement hors de portée de mon public. En adaptant la solution ci-dessus avec un répertoire différent par branche (un working-tree par branche) ça pourrait éventuellement se faire, je pense, en réservant les opérations de merge au « spécialiste » qui utilise git, et les utilisateurs lambda qui choisissent le bon répertoire. Mais bon, ça peut sembler alambiqué.
Sachant que tout ça ne passe pas le test du « ça ne doit pas reposer sur une seule personne », ce qui sera donc sûrement également rédhibitoire.
Au final, le problème pour moi est bien plus profond : il est très difficile de faire ce genre de chose de manière bien structurée avec des outils WYSIWYG, et seuls les langages structurés basés sur du texte peuvent réellement résoudre le problème. Malheureusement on a « décidé » d'éduquer notre population à l'utilisation d'outils fermés et privateurs WYSIWYG, et nous payons aujourd'hui très très cher cette dépendance. C'est comme si la population aujourd'hui n'avait pas appris à écrire, et dépendais de la médiation de grand éditeurs américains pour s'exprimer. En fait, c'est même exactement la situation actuelle.