Forum général.hors-sujets Choix d’un outil pour gérer des projets sur Linux

Posté par  . Licence CC By‑SA.
Étiquettes :
4
27
nov.
2025

Salut à tous,

Je bosse sur plusieurs petits projets persos et j’aimerais centraliser tout ça sous Linux. J’ai vu qu’il y a pas mal de solutions de gestion de projet, mais c’est un peu le bazar pour savoir lequel choisir. Certains sont très complets avec des vues type Gantt, suivi du temps, notifications, intégrations avec d’autres logiciels… mais j’ai peur que ça devienne trop lourd à configurer pour mon usage. Je cherche quelque chose qui puisse me permettre de suivre mes tâches, avoir une vue claire de l’avancement, et pouvoir collaborer facilement avec quelques amis ou collègues sur des projets communs. J’aimerais aussi que ça reste compatible avec un environnement Linux, si possible open source ou au moins gratuit pour un usage basique. J’ai repéré quelques outils qui reviennent souvent dans les discussions, mais j’aimerais avoir votre retour concret : est-ce qu’il y en a qui tiennent bien la route sur Linux et qui restent simples à utiliser sans se perdre dans 50 fonctionnalités inutiles ? Et niveau intégration, certains permettent de linker avec Git ou d’autres dépots facilement ?

Merci d’avance pour vos conseils et vos expériences, ça m’aiderai vraiment à trier tout ce qui existe.

  • # Tu as l'air de décrire un outil style github/gitlab ...

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 27 novembre 2025 à 17:29.

    Il y a bien sûr gitlab en self-hosted (mais un peu gros pour tes besoins), gogs et forjeo. Ils ne font que du git. Il y a aussi RhodeCode community edition - qui lui semble-t-il gere d'autre types de dépots. tout ça c'est en self hosted. Ces outils incluent la gestion de features, taches, etc …. via dashboards. Personnellement j'utilise surtout gitlab en ce moment, je ne peux donc pas juger des autres. Pour gitlab, les fonctionnalités de gestion de projet dans la version gratuite sont basiques, mais suffisantes à mon avis pour ce que tu décris (c'est plus ou moins mon besoin et gitlab me suffit).

  • # Expérience Redmine (limitée)

    Posté par  . Évalué à 5 (+4/-0).

    Avant Redmine

    La première fois que je l'ai utilisé, c'était après une petite étude des outils du domaine. Je me rappelle vaguement Trac, pas les autres.
    Malgré les bémols qui suivent, j'ai choisi Redmine parce que plus simple à installer et auto-héberger (chez OVH ou à la maison).

    Redmine

    Petit retour d'expérience sur Redmine, par un type qui est carrément plus codeur qu'adminsys, mais qui s'est retrouvé à gérer de tels outils, au taf ou pour lui-même.

    TL;DR : je déconseille s'il faut le garder à jour en permanence. Sauf à être nettement plus versé que moi dans l'admin.

    • au taf : j'ai géré deux Redmine dans des machines virtuelles sur un serveur OVH pour notre petite équipe.

    • chez moi : pour mes (tout) petits projets perso, ou pour dépanner quand j'ai filé un coup de main à un pote pour une création de boîte, pareil, machine virtuelle.

    Pour toutes ces VM, la Debian du moment, parfois en testing, pour avoir une version un peu plus récente de Redmine.
    De base, c'est quasiment aussi simple qu'un apt(-get) install redmine.
    Mais ça tire beaucoup de dépendances, dont Ruby on Rails, que je ne maîtrise absolument pas.

    Autre problème, surtout si la VM est en Debian testing, une mise à jour, et surtout, un saut de version Debian (ex: 12 - Bookworm vers 13 - Trixie) a tendance à tout casser. C'est pour ça que je déconseille si Redmine doit rester à jour tout le temps.

    Git & cie; remarque repo

    Redmine gère à peu près tous les gestionnaires de code/version. Le site dit : "SVN, CVS, Git, Mercurial and Bazaar".

    Petite remarque concernant git. Je ne sais pas si la proportion d'utilisateur de git connaissant ceci est grande ou petite. Donc je case ça ici "okazou" : pas besoin de GitHub (ou autre) pour avoir un repo centralisé sur un serveur.
    Par centralisé, je veux dire : commun à une équipe par exemple, que ce soit en entreprise, ou au quatre coins de la planète.

    Un répertoire, un coup de git init --bare, c'est terminé.
    Il est possible d'accéder à ce répertoire via ssh, avec une URL du genre ssh://<user>@<serveur>:<port>/path/to/the/repo (git clone ..., git remote ..., etc).

    De par ma faible expérience de GitHub, je dirais que :

    • GitHub crée automatiquement des "pull requests" quand quelqu'un pousse du code (propos à nuancer par des utilisateurs intensifs).

    • repo "manuel" : en cas de grosse équipe (à partir de 2 !), la rigueur s'impose, essentiellement dans la gestion des branches et de l'intégration, afin que les gens ne se marchent pas sur les pieds.

    Mais un repo créé "a la mano" fera aussi bien le boulot.

    • [^] # Re: Expérience Redmine (limitée)

      Posté par  . Évalué à 5 (+3/-0).

      J'ai un super souvenir de Redmine : spartiate, simple, rapide, frugal (l'inverse de Jira en fait :D).

      Niveau administration pour Redmine, j'ai utilisé la méthode download du tgz et lancement des migrations pour passer d'une version à l'autre. À voir si c'est mieux.

      Sinon, il y a les des forges dispos chez des CHATONS, qui contiennent des modules de gestion de projet : Recherche de forges logicielles
      .

      • [^] # Re: Expérience Redmine (limitée)

        Posté par  . Évalué à 3 (+2/-0).

        Yep, sympa à utiliser.

        Très "customizable", en particulier la gestion des tickets ("issues"), pour l'adapter à la méthode de gestion des bugs (par exemple, ajout de champs "Contexte", "problème constaté", "résultat attendu", etc). + possibilité de hiérarchiser les tickets.

        Au passage, lien faciles dans tous les sens, entre les tickets, le Wiki intégré et les commit dans les repo lié au projet.
        Avec par exemple, des liens ticket --> commit, mais aussi commentaire de commit --> ticket(s) concerné(s).

        Fun fact (comme disent les djeunz !) : pas au top quand il s'agit d'extraire une liste de tickets, avec les commentaires et images jointes. Du coup, je m'étais fait un utilitaire qui parcourait la database Redmine, permettait de filtrer et de générer une page Web. Ensuite, c'était facile à transformer en PDF, pour l'envoyer à un fournisseur par exemple, si on ne veut pas lui donner un compte Redmine.

        Faudra que j'essaye de passer par le tgz, parce que là, après quelques mois d'inutilisation, je constate que mon Redmine perso est cassé, et les logs ne sont pas mes amis pour comprendre d'où ça vient …

        • [^] # Re: Expérience Redmine (limitée)

          Posté par  . Évalué à 4 (+2/-0).

          Ça me rappelle que l'export de tout le Wiki sous forme de PDF avec sommaire est bien pratique ! Par exemple pour avoir une copie papier de tes procédures dans la salle machine, utile en cas de panne totale :).

      • [^] # Re: Expérience Redmine (limitée)

        Posté par  . Évalué à 3 (+2/-0).

        Très bon souvenir de Redmine aussi. Le seul manque que j'avais à l'époque c'était une vue Kanban, je ne sais pas si c'est toujours d'actualité…

        • [^] # Re: Expérience Redmine (limitée)

          Posté par  . Évalué à 4 (+2/-0). Dernière modification le 28 novembre 2025 à 11:07.

          En regardant ce matin, suite à tous les messages ici, j'ai vu qu'il y avait deux plugins pour ça.

  • # Tracm - Simple à utiliser (pas d'intégration Git)

    Posté par  (site web personnel, Mastodon) . Évalué à 6 (+4/-0).

    Disclaimer: je suis le créateur de Tracim

    • Inconvénients : tu n'auras pas de Gantt, pas de fonctionnalités avancées
    • Avantages : simple à utiliser, tout intégré (kanban, documentation en ligne, discussions, gestion de fichiers, appli mobile)

    C'est une appli web à déployer (avec Docker si tu ne veux pas t'embêter)

    Tu peux tester en créant un compte personnel gratuit sur Tracim HOME.

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.