Répartir et suivre les tâches sans post-it ni fichier Excel
Gérer son projet avec GitHub — Issues et Projects
Utiliser les Issues et les Projects de GitHub pour découper le travail en tâches, les assigner, et suivre l'avancement en équipe.
Pré-requis :
Logiciels :
Machines/Outils :
L’interface GitHub évolue régulièrement — les libellés de boutons ci-dessous correspondent à l’interface actuelle.
Un post-it ou une liste partagée fonctionne les deux premières semaines, puis se perd. Les Issues et Projects de GitHub vivent au même endroit que le code et la documentation, restent visibles par toute l’équipe, et gardent un historique — qui a fait quoi, et quand.
bug,
mécanique, urgent…).Une Issue représente une tâche, un bug, ou une question à trancher.
Sur votre repo GitHub, onglet Issues, bouton New issue. Donnez un titre précis (pas « Faire l’élec », plutôt « Choisir et commander le driver moteur »), et une description : quoi, pourquoi, comment on sait que c’est fini. Dans le panneau de droite, ajoutez un Assignee (qui s’en occupe) et éventuellement un Label (bug, mécanique, urgent…).
Titre : “Problème moteur”
Description : (vide)
Titre : “Le moteur pas à pas ne tourne pas avec le driver A4988”
Description : Le moteur reste bloqué, le driver chauffe après 10 secondes. Câblage vérifié deux fois. Piste : mauvais réglage du courant sur le potentiomètre du driver. Besoin d’un avis avant demain matin.
Un Project GitHub est un tableau kanban (colonnes À faire / En cours / Terminé) qui affiche vos Issues.
Sur votre repo, onglet Projects, bouton New project, choisissez le modèle Board. Trois colonnes apparaissent par défaut : Todo, In Progress, Done (renommables).
Dans le Project, cliquez sur + Add item, puis recherchez et sélectionnez les Issues déjà créées. Elles apparaissent comme des cartes que vous glissez d’une colonne à l’autre au fil de l’avancement.
Une carte reste dans « En cours » depuis 3 semaines ? C’est un signal à en parler au prochain point de synchro — voir Communiquer en équipe — pas juste un chiffre à ignorer.
Reprenez le tableau de rôles de Constituer et organiser son équipe : chaque grande brique a un responsable, qui crée et assigne les Issues de sa brique. Une Issue sans assignee est une tâche que personne ne fera.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Le Project est vide malgré des Issues créées | Les Issues ne sont pas encore liées au Project | Utilisez + Add item dans le Project |
| Personne ne sait qui fait quoi | Issues créées sans Assignee | Prenez l’habitude d’assigner à la création, pas après |
| Trop d’Issues ouvertes, illisible | Granularité trop fine ou tâches jamais fermées | Fermez les Issues terminées, regroupez les micro-tâches |
Ce qui précède suffit pour la plupart des équipes. Si votre équipe
grandit ou que plusieurs personnes travaillent souvent sur les mêmes
fichiers, le guide
Utiliser les Pull Requests et résoudre un conflit Git
va plus loin : faire relire son travail avant de le fusionner dans
main, et s’en sortir proprement quand deux modifications se
percutent. Pas une étape obligatoire — seulement si le besoin s’en fait
sentir.
En équipe : créez une Issue par tâche restante sur votre projet (précise, comme dans l’exemple ✅ ci-dessus), assignez-les, et mettez en place un Project pour les suivre.