Disclamer : je suis le responsable du projet tracim.
Je pense que git en terme de fonctionnalités répond à tes besoins d'un point de vue fonctionnalités. Par contre, si tu as besoin d'outils confortables, il faut une interface au dessus de git et de son versionning.
Développant tracim pour ce type de problématique (versionning, collaboration et simplicité de prise en main), je pense que Tracim correspond "presque clé en main" à cela :
tu mets l'ensemble de tes documents standardisés (principaux et optionnels) dans une arborescence définie et figée. Le versionning est natif dans tracim, donc pas de question à ce poser par rapport à cela.
tu crées une branche d'arborescence dédiée aux options sur mesure.
Chacun de tes documents va évoluer à son rythme via les éditions des différents collaborateurs. Un équipement est une combinaison de documents standards ou spécifiques, chacun dans une version spécifique.
Je vois 3 manques potentiels dans cette solution :
le fait de mettre des tags "nommés" sur des versions de document (le versionning de tracim est suffisant techniquement, mais il ne permettra pas d'avoir des tags explicites, juste des numéros de version)
la configuration de la représentation d'un équipement (combinaison de l'ensemble des versions de chaque document).
un outil pour agréger les documents dans les versions requises.
Je vois du coup deux concrétisations possibles de ton projet avec tracim :
tu définis qqpart un fichier yaml ou json qui définit quels documents sont utilisés pour documenter tel équipement et quelle version de chaque document, et tu as un script qui récupère l'ensemble des documents via l'api REST de Tracim. Toute l'édition et l'historisation est faite via l'interface graphique et le script se charge juste de rappatrier les bons éléments de documentation,
tu fais la même chose avec une application tracim faite sur mesure qui se charge de faire le travail d'agrégation et le stockage des configurations de documents. Dans ce cas tout est graphique (mais il faut faire + de développement).
Dans les 2 cas on (la société algoo, derrière tracim) peut t'accompagner. Dans le premier cas au vu de ce que tu dis, ça ne me semble pas nécessaire : tu développes, tu as les compétences pour faire les bons appels d'API et configurer / stocker / parser un fichier de description en yaml/json. On pourra te faire gagner du temps en t'accompagnant ; tu pourras aussi t'en sortir seul. Dans le second cas, ça me semble plus avancé comme développement (modèle supplémentaire en base représentant une configuration + application sur mesure). La seconde solution est pour moi une évolution naturelle de la première : tu valides le concept avec un script "bricolé", et une fois que le prototype est validé, tu fais l'interface sur mesure adaptée au quotidien.
Par rapport à ce que tu évoques, il y a des avantages en terme d'ergonomie et de fonctionnalités dans tracim : fichiers (uploadés) et documents rédigés sous forme de wysiwyg sont au même endroit. Les images intégrés dans tracim sont directement intégrés en glissé/déposé. Tout est versionné ; tu pexu identifier le statut de chaque document.
Pour en savoir plus sur tracim : https://www.tracim.fr/demo (video de 2 minutes et démo accessible et testable directement en ligne)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Tracim avec éventuellement module dédié ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Gestion de documentation. Évalué à 10.
Disclamer : je suis le responsable du projet tracim.
Je pense que git en terme de fonctionnalités répond à tes besoins d'un point de vue fonctionnalités. Par contre, si tu as besoin d'outils confortables, il faut une interface au dessus de git et de son versionning.
Développant tracim pour ce type de problématique (versionning, collaboration et simplicité de prise en main), je pense que Tracim correspond "presque clé en main" à cela :
Chacun de tes documents va évoluer à son rythme via les éditions des différents collaborateurs. Un équipement est une combinaison de documents standards ou spécifiques, chacun dans une version spécifique.
Je vois 3 manques potentiels dans cette solution :
Je vois du coup deux concrétisations possibles de ton projet avec tracim :
Dans les 2 cas on (la société algoo, derrière tracim) peut t'accompagner. Dans le premier cas au vu de ce que tu dis, ça ne me semble pas nécessaire : tu développes, tu as les compétences pour faire les bons appels d'API et configurer / stocker / parser un fichier de description en yaml/json. On pourra te faire gagner du temps en t'accompagnant ; tu pourras aussi t'en sortir seul. Dans le second cas, ça me semble plus avancé comme développement (modèle supplémentaire en base représentant une configuration + application sur mesure). La seconde solution est pour moi une évolution naturelle de la première : tu valides le concept avec un script "bricolé", et une fois que le prototype est validé, tu fais l'interface sur mesure adaptée au quotidien.
Par rapport à ce que tu évoques, il y a des avantages en terme d'ergonomie et de fonctionnalités dans tracim : fichiers (uploadés) et documents rédigés sous forme de wysiwyg sont au même endroit. Les images intégrés dans tracim sont directement intégrés en glissé/déposé. Tout est versionné ; tu pexu identifier le statut de chaque document.
Pour en savoir plus sur tracim : https://www.tracim.fr/demo (video de 2 minutes et démo accessible et testable directement en ligne)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo