Bonjour,
Dans un contexte professionnel, je suis amené à améliorer le fonctionnement d'une équipe, dont une bonne partie de l'activité consiste à répondre à des demandes. Ces demandes peuvent être transmises par email et appel téléphonique pour la plupart. Il s'agit généralement de transmettre des documents (un peu) ou d'apporter des réponses personnalisées, mais surtout de coordonner des interventions techniques qui doivent avoir lieu dans des bâtiments (panne de l'ascenseur, du chauffage, fuite, etc.)
Actuellement, rien n'est outillé, ou alors très peu. Dans ces conditions l'équipe à beaucoup de difficultés à connaître les demandes en cours et l'état d'avancement. Ainsi, généralement si l'intervention n'a pas eu lieu, l'équipe est relancée par le demandeur, mais il n'y a pas suffisamment de proactivité. C'est un objectif majeur pour réduire les délais et améliorer la satisfaction.
Afin de s'outiller correctement, je vois deux possibilités :
1. Soit développer un "module" dédié, intégré à nos outils existants. Cela permettrait d'avoir connaissance des bâtiments, des équipements, des propriétaires et des occupants. Ainsi que des documents. Et de consulter l'historique des problèmes sur un immeuble ou pour un propriétaire ou un occupant. Mais il faut développer beaucoup de fonctions, comme le suivi d'un historique, un SLA, des rôles, un reporting. S'interfacer avec les emails, etc.
- Soit utiliser une solution existante. Il en existe plein dont je suis loin d'avoir fait le tour. Mais dans ce cas, comment s'interfacer avec nos données ? Est-ce que les logiciels dédiés à ce type d'activité peuvent s'interfacer avec un outil externe ? Par exemple, si un locataire appelle, l'objectif est de l'identifier pour connaître son immeuble, puis s'il signale un problème sur l'ascenseur, d'automatiquement envoyer une demande à l'ascensoriste qui dispose du contrat de maintenance pour cet immeuble plutôt que d'avoir à chercher ces informations dans nos outils métiers. L'objectif serait aussi d'affecter automatiquement la demande reçue par email au gestionnaire de l'immeuble, en fonction de l'adresse email de l'expéditeur ou éventuellement de l'objet.
Chercher l'information dans l'application métier, pour faire la saisie manuellement dans l'outil de gestion de ticket est beaucoup moins intéressant.
Avez-vous été confronté à l'intégration d'une solution de gestion des demandes / des tickets / d'incidents ? Quel est votre retour d'expérience sur ce type de projet pour déterminer quelle solution semble la plus intéressante ?
Merci pour vos retours.
# Selon une étude du Dave Institute
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
42% des projets en informatique sont des gestionnaires de dossiers et pourraient être remplacé par un gestionnaire de tickets générique MAIS 100% des utilisateurs vont inventer des besoins ultra spécifiques qui mobiliseront une task force composée d'un directeur de projet, d'une chef de projet, d'un AMOA, d'une PMO, d'un Scrum Master, d'une Lead Architect, d'un Chief Ambianceur Officeur, d'une Lead Tech Manager pour encadrer un stagiaire développeur qui réinventera Redmine en moins bien, car le budget et les délais seront improbables et non négociables.
Une démarche pragmatique serait d'adopter des produits existants (Redmine) et de les intégrer aux applis métiers via un SSO et des API.
Pour t'accompagner dans cette démarche, tu peux constituer une task force composé d'un directeur de projet, d'une chef de projet, d'un AMOA, d'une PMO, d'un Scrum Master, d'une Lead Architect, d'un Chief Ambianceur Officeur, d'une Lead Tech Manager pour encadrer un stagiaire maçon pour construire la tour d'ivoire de l'architecte chargé de modéliser le processus de la démarche.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Selon une étude du Dave Institute
Posté par Tonton Th (Mastodon) . Évalué à 10.
Pierre Tramo, sors de ce corps !!!
[^] # Re: Selon une étude du Dave Institute
Posté par romrom . Évalué à 4.
Sans rire, +1 pour Redmine : même s'il a 1001 défauts et qu'il est pas très moderne dans son interface utilisateur, ça reste la solution la plus versatile que je connaisse. Et en plus c'est libre !
De base, énormément de chose sont personnalisables (workflow, champs supplémentaires, etc.) et si besoin il est relativement facile de faire des plugins (Ruby on Rails standard).
[^] # Re: Selon une étude du Dave Institute
Posté par stopspam . Évalué à 4.
Redmine, je l'ai utilisé 10 ans mal vieilli moche et tout.
Je suis passé à OneDev il y a 4 ans et je ne suis pas prêt de changer.
# Solution mais pas libre
Posté par Christophe B. (site web personnel) . Évalué à 2.
C'est dommage mais a part JIRA et JSD (Jira Service Desk) je ne crois pas qu'il y ait beaucoup d'autres solutions.
Pour un cas a peu près similaire et encore cela avait été très mal analysé à l'époque.
Avantage de JIRA : c'est souple et facile a mettre en oeuvre, le paramétrage fin est assez difficile et il vaut mieux passez du temps avant mise en exploitation et ne pas trop se lancer "tête baissée"
L'interfacage avec python est pas mal et l'extraction de données permet de faire ce que l'on veut.
Par contre : c'est cher, maintenant seul la version Cloud existe (enfin je crois) et attention car beaucoup de fonctionnalité manque mais se trouve dans le 'market'
Attention aussi il est possible de recuperer les données de JIRA mais difficile de les mettre a jour par scripts ou autrement que par la saisie
Par contre il y a plein d'outils pour afficher et stocker des informations depuis des web services.
Et puis cela avait un coté "usine a gaz compliquée", même si j'espère que les versions plus récentes ont fait des progrès de ce coté.
[^] # Re: Solution mais pas libre
Posté par BAud (site web personnel) . Évalué à 6.
o_O hein !?
Toute appli moderne propose des API… on est en 2023, plus en 2010 voire 2015…
c'est le cas de GLPI (cf. https://glpi.trigo-group.com/apirest.php pour voir tout ce qui est rendu accessible)
et sinon yavait déjà des webservices, cf.
https://servicenav.coservit.com/documentations/glpi-configurer-lintegration-ticketing/ (mais bon, tout le monde préfère des API/JSON à des WS SOAP/XML…)
[^] # Re: Solution et en libre...
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 08 mai 2023 à 17:38.
et avec méthodes GET et POST, ça va de soi… à quoi servirait un système qu'en lecture ? ça limiterait les interactions :/
[^] # Re: Solution mais pas libre
Posté par beleys (site web personnel) . Évalué à 2.
Je plussoie GLPI pur la gestion du ticket simple.
Il est relativement facile d'accès pour les utilisateurs, un peu frustre par moment mais rien d'insurmontable.
[^] # Re: Solution mais pas libre
Posté par steph1978 . Évalué à 4.
Je ne porte pas spécialement cet outil dans mon cœurs, comme tout outil propriétaire. Mais j'en ai mangé beaucoup au boulot et l'intégration par API marche très bien. Que ce soit l'export de millier de tickets, de création de ticket en masse, de recherche, modification de champ. Tout ce qui peut être fait par UI peut être fait par API JSON+REST, avec un modèle de données pas trop mal fichu et un client Python (ou powershell) qui marche bien.
D'ailleurs, certaines migrations jira nécessite de tout exporter et tout réimporter. Ce n'est pas joli joli mais prouve qu'on peut récupérer ses données.
[^] # Re: Solution mais pas libre
Posté par Nibel . Évalué à 2. Dernière modification le 09 mai 2023 à 01:00.
Je confirme pour avoir automatisé la création de fiches JIRA dans mon service en fonction de divers évènements que l'API JIRA fonctionne parfaitement bien.
Et je fais ça en shell script… Parce que je n'ai le droit qu'à ça.
Un curl pour le POST/GET et éventuellement un jq pour simplifier le parsing du JSON et c'est parti.
La version autohébergeable existe toujours et est encore maintenue mais n'est pas mise en avant. Il est clair que Atlassian cherche à faire évoluer son business model en se concentrant d'avantage sur le cloud. On auto-héberge encore chez nous.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Solution mais pas libre
Posté par Christophe B. (site web personnel) . Évalué à 2.
Ah bah je suis passé à coté, dommage
Mais je n'ai pas franchement eu le temps de m'y consacrer réellement
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 2.
Qu'entends tu par facile à mettre en œuvre ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par Christophe B. (site web personnel) . Évalué à 2.
L'installation est simple, la migration de version aussi
C'est du java donc il faut de la RAM et ça roule
Le produit repond bien si tu as des besoins simples, mais dans ce cas il vaut mieux quelque chose comme GLPI
Par contre si tu as plusieurs cas de figures, plusieurs entités, un flux de tickets complexes incluant editeurs, fournisseurs, plusieurs services etc … dans ce cas JIRA n'a pas d'équivalent.
Ce que je trouve dommage c'est que beaucoup de fonctionnalité interessante se trouve dans le JIRA MARKET ce que je trouve pénible.
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 3.
Perso j'ai l'impression que JIRA est plus proche d'un BPM avec quelques config initiales qu'on outil de gestion de ticket. Ça le rend aussi complexe que souple. C'est pour ça que quand le besoin n'est pas bien défini, c'est la réponse. Quelque soit ce que tu imagine, tu trouvera bien une manière de le faire rentrer dans JIRA. On pourrait même réécrire linuxfr au dessus de jira.
AMHA dark_moule a plus besoin d'une méthode pour comment informatiser que d'un outil par contre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par Christophe B. (site web personnel) . Évalué à 2.
JIRA a l'origine c'est un outil de suivi de projet
JIRA Service Desk est basé sur JIRA pour la gestion d'une équipe de support
C'est vrai qu'il y a un peu de BPM dedans mais ce n'est pas une finalité
Attention la définition du besoin et d'un cahier des charges reste toujours un prérequis
vu le cout des ces produits
sinon autant prendre un produit libre
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 4.
Ce genre d'informatisation pars tellement de loin qu'il est coûteux et très risqué d'essayer d'établir un cahier des charges. L'outil va influencer les usages et modifier les besoins. Partir sur un cahier des charges relève du travail d'imagination et amène facilement à des solutions qui paraissent ineptes aux utilisateurs.
Commencer simple et itérer régulièrement sur les besoins et les problèmes permet au contraire d'avoir un gain très rapidement, d'éviter les effets tunnel, d'inclure les utilisateurs dans les choix qui sont fait, de ne pas avoir besoin d'un investissement initial important avant d'en voir le début.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Et le plus simple pour commencer et itérer, c'est d'écrire un cahier des charges !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 3.
Un cahier des charges c'est un contrat, tu y formalise les besoins, une manière d'évaluer ces besoins pour pouvoir rendre objectif que le contrat a était rempli ou pas. Tu peux même y intégrer des budgets et dans bien souvent il est immuable. Surtout il a vocation a être complet, tu y décrit ton besoin complet. C'est l'opposé de ce dont je parle.
Tu commence par un recueille de besoin, mais au lieu de faire un cahier des charges, si vraiment tu souhaite parler en langage manager c'est plus un produit minimum viable.
Le cahier des charges réponds à la question : qu'est-ce que je veux dans ma solution finale ?
Le MVP à la question : si elle devait faire une seule chose que devrait faire ma solution ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je connais ces théories, mais en pratique les projets que j'ai vu réussir ont tous en commun d'avoir fait de la gestion de projet "normale" avec un soupçon d'agilité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 3.
La plupart des projets informatiques que j'ai vu avec des cahiers des charges (que je sois impliqué ou non) ont fini en procès et inversement tous les cas que je connais de projets parti en procès avaient un cahier des charges.
J'ai aussi vu des projets aller encore plus loin avec des appels d'offre. Pas de procès, mais c'était une guerre perpétuelle entre la maîtrise d'œuvre et la maîtrise d'ouvrage. Ça s'est fini avec perte (8 millions d'euros d'argent public parti en fumée) et fracas.
Les projets que j'ai vu fonctionner le plus sainement (en tout cas de mon point de vu) n'ont pas de cahier des charges.
Nous voila bien avancé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Oui mais moi je suis Senior Lead Java Architect donc mon expérience compte java.lang.Double !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Solution mais pas libre
Posté par totof2000 . Évalué à 2.
qui dit "cahier des charges" ne dit pas forcément "contrat" ni même procès". Celà dit, j'aurais plutôt parlé de définition des besoins et classification de ceux-ci par priorité, avec une définition suffisamment précise pour pouvoir choisir un outil.
Contrairement à ce que certains pensent, l'agilité ne dispense pas de spécifier clairement ses besoins - en tout cas, suffisamment clairement pour que les devs n'aient pas à revenir des dizaines de fois sur l'implémentation d'une fonctionnalité.
[^] # Re: Solution mais pas libre
Posté par barmic 🦦 . Évalué à 1.
Alors wikipedia décrit un cahier des charges comme étant :
Ce qui est la définition d'un contrat (même si tu ne le rend pas légal). Si j'essaie de trouver ailleurs des définitions je trouve ça :
ici (je connais pas plus que ça mais c'est l'un des premier résultats que j'ai)
Le journal du net parle directement de contrat.
La fabrique du net aussi.
Je veux bien qu'on imagine d'autres formes de cahier des charges, mais si c'est pour mettre autre chose que ce que la plupart des gens semblent entendre et l'ensemble des autres disciplines qui s'en servent l'utilisent, ça vaut le coût de trouver un autre nom.
La spécification des besoins ce n'est pas nécessairement un cahier des charges et il existe des manières de recueillir des besoins incompatibles avec le fait de produire un cahier des charges. Globalement toutes les méthodes itératives. Tu parle d'agilité, mais pas que le design thinking (qui est antérieur à l'agilité) ne permet pas d'avoir un cahier des charges.
Et pour revenir à ce que disait Christophe B. il est bien question d'avoir un cahier des charges tel que tout le monde l'entends puisqu'il s'agit d'avoir une définition complète de ton besoin formalisée pour savoir si JIRA rempli l'usage (comme il fait tout : oui) et qu'il en vaut le coût ou que moins chère pourrait faire le taff.
Quand tu informatise un processus, tu n'es pas en mesure d'établir les besoins à terme car l'outil va lui-même modifier le processus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution mais pas libre
Posté par orfenor . Évalué à 2.
Je suis d'accord. C'est pour ça que j'indiquais d'aller voir comment c'est fait sur Odoo (à cause de sa modularité).
[^] # Re: Solution mais pas libre
Posté par Tonton Th (Mastodon) . Évalué à 3.
C'est donc compatible avec taptempo ?
# Un gestionnaire de tickets, et il y a le choix
Posté par GG (site web personnel) . Évalué à 5.
Comme dit par ailleurs, il y a le choix.
J'en vois deux qui sont intéressants, l'un est dans NextCloud, et l'autre est dans Dolibarr.
Je connais mieux celui de Dolibarr, qui permet d'avoir une interface publique pour les demandes de tickets et le suivi (par l'utilisateur, les prestataires et le(s) gestionnaire(s)).
En particulier si vous utilisez Dolibarr pour gérer la compta des immeubles, les loyers, les paiements des fournisseurs, les maillings, etc.
Comme Dolibarr a aussi une API, il devrait être possible de connecter le système de téléphonie pour identifier le demandeur via son numéro de téléphone quand il appelle, et d'avoir alors la liste des informations concernant l'appartement, l'immeuble, l'adresse etc, et donc aussi l'ascenseurs et les autres dépendances.
Ces liaisons, dans Dolibarr sont possible de différentes manières. Par exemple en créant des ressources, et en les associant à une ressources (Parking, ascenseur --> immeuble) et en associant l'utilisateur à la ressource immeuble. Il y a le choix dans la manière de faire, c'est à étudier.
Essayer de tout automatiser va demander de mettre en place de nombreux garde-fou et penser à tout. Il ne faudrait pas essayer de complètement se passer d'humains, quoique… chacun ses projets.
À peu près possible avec n'importe quel gestionnaire de tickets en réalité.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 6.
Je réponds seulement pour ajouter un troisième logiciel, pas pour discuter les choix de CG.
À mon avis, dark_moule pourrait jeter un oeil sur des modules Odoo, peut-être seulement pour voir comment ça peut se faire. Comme le souligne CG ci-dessus, un ERP connecte plein de trucs entre eux. C'est facile de relier un numéro de téléphone à une personne, puis passer de de cette personne au prestataire et au gestionnaire de l'immeuble. C'est un peu comme une relation d'acheteur à des trucs en vente et des fournisseurs.
Ce qui est intéressant dans Odoo (et doit exister dans d'autres ERP) ce sont les modules Téléphonie qui connectent aux Contacts, les modules Feuille de temps, Services sur site, Assistance, Rendez-vous, Cartographie et Gestion automatique des déplacements (pour gérer les dates et trajets d'interventions), le tout couplé au site web avec compte prestataire et compte client pour que le presta puisse suivre et valider ce qui est fait, et pour que le locataire puisse avoir un suivi par courriel, consulter le suivi, indiquer ses préférences (si intervention chez lui) et faire un retour. Tout ça pouvant entièrement et en même temps se passer par courriels à valider (et sur smartphone pour le prestataire).
avec API ? oui
import/export de données ? oui
usine à gaz ? non, réellement pas : on ajoute les modules nécessaire peu à peu.
Bref on a bien avancé ces dernières années sur les outils de gestion d'intervention.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par rycks . Évalué à 3.
Attention à odoo: regardez le coût de maintenance et de mise à jour avant de faire votre choix (quelques recherches à ce sujet sur votre moteur de recherche préféré devrait vous donner des éléments d'information).
Nombre d'utilisateurs de odoo restent "coincés" sur des anciennes versions à cause des coûts de mise à jour / upgrade.
eric.linuxfr@sud-ouest.org
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 4.
Tu ne dois pas être utilisateur d'Odoo pour raconter un truc pareil !
D'abord il faut rappeler qu'on n'a pas forcément besoin de mettre à jour. la course à la Hype c'est pas pour les trucs pros.
Ensuite, comme tous les gros ERP (et comme Dolibarr), Odoo est paramétrable, avec du code métier développé spécifiquement. Donc comme tous les gros ERP, l'ampleur de ce code va jouer sur le coût de la mise à jour.
Enfin, la montée de version est depuis longtemps peu coûteuse, soit qu'elle passe par les service d'Odoo, soit par les outils OpenUpgrade de l'OCA.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 5.
Petite précision : on n'a pas besoin de monter en version tous les ans.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par Christophe B. (site web personnel) . Évalué à 3.
Attention piège :
OK il n'y a pas d'obligation a effectuer les montées de versions sur un ERP
mais
Si l'on prend trop de retard, le travail peut devenir énorme et remettre en question beaucoup de choses et ce n'est plus une mise a jour mais une migration
Conseil de vieux c.. : se poser la question régulièrement de manière collégiale et pas qu'avec le staff technique si l'ERP concerne toute la boîte.
Mais chaque cas est particulier.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
J'ai lancé un pavé dans la marre à ce sujet sur LinkedIn semaine dernière. Visiblement les migrations se font bien, même sur les versions libres (LGPL). Mais visiblement ce n'est pas le ressenti de tout le monde 🤷♂️
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 5.
Ah ? pas vu passer, ça m'intéresse…
Il faut bien voir qui est "tout le monde". Tu connais aussi bien que moi les geeks qui installent, ne lisent pas les docs, explorent peu la communauté et partent réinventer la roue. Les forums Odoo sont plein de gens qui l'installent et l'utilisent parce que c'est gratuit, mais ne connaissent ni la doc, ni les ressources et posent des questions sans chercher.
Mais bien au-delà de ces personnes qui ne constituent pas le public de Linkedin, trop peu d'informaticiens sur Odoo connaissent l'OCA (Odoo Community Association) et ses extraordinaires ressources pour garder des versions à jour très longtemps et faire des montées de version sans douleur (modules communautaires, OpenUpgrade, Odoo module migrator).
De même, trop peu de gens comprennent les implications de l'hébergement par la société Odoo (et quelques autres prestataires qualifiés) : montées de version gratuites!
Et enfin, plein de prestataires ne font que de l'off-shore, re-développent à tout va et ne savent pas prévenir le client qu'il ne maîtrisent pas les montées de version…
Bref, depuis 10 ans je relativise beaucoup, notre métier est plein de charlots ou de gens trop sûrs d'eux qui manquent d'expérience ou de recul.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par Christophe B. (site web personnel) . Évalué à 2.
C'est valable pour la majorité des ERPs, même les plus gros
Alors comment faire la différence : peut être les certifications ISO (9001 et 27001)
mais ce n'est plus le même tarif.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 3.
Tout à fait. Les gens perdent complètement de vue ce que veut dire un outil de travail bien foutu. Il ne viendrait à l'esprit d'aucun agriculteur de se plaindre que changer de tracteur ne soit pas gratuit.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 10 mai 2023 à 15:54.
Il y a aussi beaucoup de monde qui vend du rêve autour du logiciel libre et pour lesquels les acheteurs tombent dans le panneau.
Ce qui déséquilibre la "compétition".
Franchement, faut aller à des évènements comme OSXP et voir ce que les gens vendent en tant que logiciel libre.
Comme la plupart des personnes ne comprennent pas les subtilités des licences logicielles et des modèles économiques, il est rapide de tomber dans le panneau - et nombre d'entreprises jouent en zone grise.
Olivier Lambert, dirigeant de Vates (xcp-ng, xen orchestra) évoque aussi le contrat moral qui va avec le logiciel libre dans un excellent article de blog - https://virtualize.sh/blog/the-moral-contract/ (article en Anglais) (c'est pas directement le sujet que j'évoque, mais c'est lié)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par Christophe B. (site web personnel) . Évalué à 4. Dernière modification le 10 mai 2023 à 09:44.
Je viens de lire ton POST dans linked in
Intéressant et cela permet de faire le paralèlle entre un ERP et le secteur du batiment
Oui tout est possible, ce n'est qu'une question de temps et d'argent comme toujours :)
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 2.
Je ne l'ai pas trouvé, tu as l'URL ?
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
https://www.linkedin.com/posts/damienaccorsi_opensource-odoo-odoo-activity-7059783201686212608-2U1L
C'est un peu du troll, mais c'est aussi un problème de fond : il est super difficile de trouver des éditeurs qui proposent leurs offres sur du logiciel libre (la plupart te vendent une version propriétaire)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 4.
Ah oui, c'est provocateur quand même! Et un peu faux : plusieurs prestataires Odoo ne travaillent que sur la version communautaire, sans problème de montées de version, ni de maintenance (voir Anybox, le GRAP, Akrétion, …).
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Oui ; je me suis appuyé sur plusieurs retours et effectivement il y a des erreurs dans ce que j'ai écrit. Ces erreurs ont été rectifiées dans les commentaires.
Par contre il y a tout de même des gens qui disent que c'est compliqué avec les versions OCA - cf message de Jean-Baptiste Kempf (Vidéolan).
Et le fond du problème reste vrai : ce qui est vendu est propriétaire, pas libre (et ça fait toute la différence dans la démarche commerciale / ambassadrice du logiciel libre)
Cf le lien https://www.gnu.org/philosophy/when-free-depends-on-nonfree.fr.html
Parenthèse, en achetant une version propriétaire (je ne connais pas odoo mais je suis quasiment sûr que c'est le cas avec Gitlab par exemple) tu perds la possibilité de toucher au code de ce que tu fais tourner.
Il y a une vraie différence à acheter des services sur un logiciel libre et acheter la version propriétaire d'un logiciel qui existe en version libre limitée en fonctionnalités.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Sur le côté provocateur, c'est clair et c'était aussi une expérimentation.
Force est de constater que ça marche en terme de visibilité d'être clivant.
Est-ce bien ? Mal ? La réponse n'est pas évidente : on évolue dans un écosystème qui a ses propres règles… 🤔
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 3.
Pour Odoo c'est assez différent, seuls certains modules sont propriétaires. Ça va même plus loin : ce sont des ensembles de modules qui sont propriétaires (par exemple toute la compta). La réciproque est vrai, par exemple l'ensemble des modules et thèmes pour faire un site web sont libres. De sorte que tu peux tout à fait utiliser la version Entreprise sans utiliser aucun module propriétaire.
Pas sur Odoo. D'une part tu peux toucher au code, d'autre part la partie libre ne dépend d'aucune partie non-libre.
J'ai sans doute l'air de défendre envers et contre-tout et j'ai certainement les yeux de Chimène pour un logiciel que j'aime beaucoup, mais je m'insurge aussi contre pas mal de méconnaissances ; plein d'utilisateurs oublient de regarder dans le code ou bien trouvent trop cool d'utiliser Odoo sans être capable de l'appréhender, de sorte que beaucoup de critiques me semblent exagérées.
Odoo a été 100% libre pendant des années. C'était cool on pouvait lancer tous les modules possibles et installer une usine à gaz devant chaque co-fondateur de startup. Privatiser une partie d'Odoo a permis à Fabien Pinkaers de trouver un modèle économique qui marche (il n'avait plus de trésorerie avant cela). Les modules fermés sont plutôt pour les grosses boites (qui se fichent pas mal du libre), peu utiles aux petits effectifs. On n'est pas du tout sur de l'Open-core. Et même si le goût du clinquant et de la nouveauté rend tout le monde avide de pouvoir utiliser tel ou tel module génial et trop beau, la réalité que nous connaissons tous deux c'est qu'en entreprise il vaut mieux garder la tête froide, le personnel a des missions précises et peu de temps. Sans oublier que l'entreprise Odoo vend aussi son écosystème : les milliers de modules, les centaines de prestataires. Il faut prendre en compte cet aspect : Odoo suscite des développements libres (et non-libres) en pagaille. Ainsi, la plupart des modules proprios ont été redéveloppés en libre (et après avoir joué, on les désinstalle vite parce que ça fait trop de choses à maîtriser).
Pour finir, si on veut du 100% libre on peut avec Odoo (j'utilise Odoo en 100% libre, les modules qu'on a fait développer sont libres aussi). Mais il y a aussi d'autres solutions logicielles (Dolibarr est excellent), pas besoin de critiquer le marketing de vente de l'entreprise Odoo—je suis plutôt content que Fabien Pinkaers continue, malgré ses millions, de développer en libre la plus grande partie d'Odoo.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Heu, si on est complètement dans l'open-core, non ?
En fait le sujet n'est pas est-ce qu'on peut avoir du logiciel libre, c'est est-ce que le modèle économique propose du libre. Et à mon sens non :
Après, ça ne remet pas en cause la réussite et la qualité du logiciel, ni la dynamique de la communauté. C'est juste un modèle économique qui repose sur la vente de logiciel propriétaire.
Pour l'entreprise Odoo, le libre est un moyen (de développer la notoriété du logiciel) et non une finalité puisque Odoo ne vend aucun service sur une version libre - et c'est Fabien lui-même qui l'explique.
En tant que client, ça change pas mal les choses.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 3.
Oui tu as raison, je ne devrais pas rédiger de commentaires passé minuit :-)
Pas chez Odoo effectivement, mais chez les prestataires si.
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Heureusement qu'on peut encore critiquer la stratégie marketing et commerciale des gros contributeurs à des logiciels libres, sinon Google, Facebook, Amazon seraient les meilleurs ambassadeurs du logiciel libre !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par orfenor . Évalué à 4.
Je voulais dire que les critiques (pas ton billet) mélangent tout.
Et j'ai été influencé par la lecture du message de Gregober dans la dépêche DynFi Firewall où il dit que DynFi permet de financer des développeurs libres de haut niveau pendant des années, ce qui est aussi ce que dit Fabien Pinkaers : sa stratégie marketing lui permet de financer les devs libres sur Odoo (c'est de loin la partie qui évolue le plus).
# request tracker
Posté par palm123 (site web personnel) . Évalué à 8.
RT, écrit en Perl
https://github.com/bestpractical/rt
j'avais vu un article
http://articles.mongueurs.net/magazines/linuxmag80.html
à voir si ça peut convenir
ウィズコロナ
# Ou zammad
Posté par Tonio (site web personnel) . Évalué à 5.
Zammad is a web-based, open source user support/ticketing solution:
https://zammad.org/
https://zammad.org/screenshots
Que je trouve vraiment bien…
[^] # Re: Ou zammad
Posté par Alex G. . Évalué à 3.
Oui il est pas mal du tout, il y a la notion d'attribution, d'équipe, de temps de résolution/escalade, des modèles, etc. C'est vraiment fait pour du support.
Côté intégration, c'est très paramétrable, il y a une API bien documentée et des webhooks.
PS: attention pour la doc, bien partir de https://zammad.org/documentation car il y a des docs dédiés à chaque aspects.
[^] # Re: Ou zammad
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
En 5 minutes de test, j'ai réussi à perdre des tickets et un chat avec un client, car l'outil ne gère pas plusieurs onglets ouverts…
Peut mieux faire :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ou zammad
Posté par dark_moule . Évalué à 1.
Merci pour cette découverte. Je vais regarder ce qu'ils proposent comme intégration.
# Commentaire supprimé
Posté par ash . Évalué à -1. Dernière modification le 09 mai 2023 à 15:36.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # ??
Posté par ash . Évalué à 2.
bizarre de supprimer mon commentaire vu que plane est un logiciel libre : https://github.com/makeplane/plane
[^] # Re: ??
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
Désolée, j'ai réagi trop vite, j'ai pensé à du spam compte tenu de l'absence de contexte.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: ??
Posté par ash . Évalué à 1.
pas de soucis !
[^] # Re: ??
Posté par steph1978 . Évalué à 8.
Oh purée des fonctionnalités GTP powered
Au secours, on est en plein dans ça:
# Autre piste odoo
Posté par Alex G. . Évalué à 5.
Ce genre d'application est aussi implémentable avec odoo. Il faut une équipe technique un peu motivé et un bon accompagnement, mais odoo est vraiment pensé pour créer des applications métier de ce type, avec une base déjà faite.
Ça vaut le coup si le module helpdesk (avec quelques autres modules éventuels) couvre déjà une bonne partie de ton besoin.
Il y a vraiment une API complète et des possibilités d'extensions dans tous les sens (actions serveurs, templates, ajouts de champs, etc.).
[^] # Re: Autre piste odoo
Posté par orfenor . Évalué à 5.
Voir mon message plus haut
:-)
[^] # Re: Autre piste odoo
Posté par dark_moule . Évalué à 2.
Je vais regarder ce que propose Odoo, mais je n'ai pas du tout envie de changer d'ERP.
[^] # Re: Autre piste odoo
Posté par orfenor . Évalué à 3.
Je le répète, c'est surtout intéressant de regarder comment fait Odoo. Evidemment tu ne vas pas changer d'ERP.
# La roue tourne
Posté par wilk . Évalué à 3.
Autant ça a du être vachement difficile d'inventer la première roue autant maintenant qu'on a plein d'exemples de roues ça n'est plus du tout la même chose. Il est parfois plus facile de refaire une roue toute basique qui répond à ses seuls besoins que d'utiliser une roue déjà faite pour d'autres besoins.
# osTicket
Posté par Philippe GRAILLE . Évalué à 1.
Je ne sais pas si ça correspond au besoin mais j'ai utilisé il y a longtemps osTicket, c’était très bien.
C'était full Open Source à l'époque, c'est du premium maintenant : https://osticket.com/
[^] # Re: osTicket
Posté par dark_moule . Évalué à 1.
Je vais regarder. Merci
# Merci pour tous vos échanges
Posté par dark_moule . Évalué à 4.
Un grand merci général à tous les participants pour ces commentaires et pistes intéressantes.
Je vais voir avec l'équipe de développement pour analyser plus en détail les outils proposés et identifier la solution cible, par rapport à nos besoins.
Merci beaucoup
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.