Versionner les livrables UX avec Git et GitHub

1. Objectifs

   • Expliquer l'intérêt du versionnement pour les livrables UX
   • Distinguer Git et GitHub
   • Organiser un dépôt selon les phases du processus UX
   • Choisir ce qu'il faut versionner, et ce qu'il ne faut pas publier
   • Utiliser le cycle pull, add, commit, push avec des messages clairs
   • Faire relire un livrable avec une branche et une demande de fusion, et marquer les versions importantes

1. Présentation

   • Depuis le début du cours, vous déposez vos travaux sur GitHub. Dans un projet UX réel, cette habitude devient essentielle : les maquettes évoluent après chaque test, plusieurs personnes y travaillent et il faut pouvoir retrouver la version présentée au client ou testée avec les utilisateurs.
   • Cette leçon explique comment utiliser Git et GitHub pour les livrables UX : comptes rendus, wireframes, exports de maquettes, liens vers les prototypes. L'objectif n'est pas de devenir développeur, mais de ne plus jamais se demander quelle est « la bonne version ».

• Nous continuons avec BiblioCampus, notre application fictive de réservation de livres. Pour les activités, créez le dossier 15-git-livrables/ dans votre dépôt GitHub ui-ux-design-bts.

1. Pourquoi versionner ?

   • Sans outil de versionnement, les copies de fichiers se multiplient et plus personne ne sait laquelle est à jour. Avec Git, on garde un seul fichier et un historique de toutes ses versions :

1. Git et GitHub

   • Git est le logiciel qui enregistre les versions sur votre ordinateur. GitHub est le site qui héberge votre dépôt en ligne et permet de le partager :

• Un commit est un instantané de votre dossier à un moment donné, accompagné d'un message qui explique ce qui a changé. On peut toujours revenir à un commit précédent.

1. Organiser le dépôt

   • Un dépôt bien rangé se comprend sans explication. Pour un projet UX, nous proposons un dossier par phase du processus :

1. Que mettre dans le dépôt ?

   • Tous les fichiers n'ont pas leur place dans un dépôt, surtout s'il est public :

• Les fichiers Figma restent dans Figma : on versionne leurs exports (PNG, PDF) et un fichier liens-figma.md qui donne le lien de chaque fichier. Ainsi, même si l'outil change, le travail reste lisible.
• Les données des participants aux entretiens et aux tests ne doivent jamais être publiées. Anonymisez-les (P1, P2…) et gardez les originaux hors du dépôt.

1. Le cycle de travail

   • Chaque séance de travail suit le même cycle de commandes :

1. Exemple 1 : déposer un wireframe

   • Ines vient de terminer le wireframe de la fiche d'un livre et l'a exporté dans 04-prototyper/wireframes/:

git pull
git status
git add projet-bibliocampus/04-prototyper/wireframes/fiche-livre.png
git commit -m "Ajoute le wireframe de la fiche d'un livre"
git push

• Après le test, elle corrige le contraste du bouton et exporte à nouveau le même fichier, avec le même nom. Un nouveau commit (« Corrige le contraste du bouton Réserver après le test 1 ») suffit : l'ancienne version reste disponible dans l'historique.

1. Écrire de bons messages

   • Le message de commit est ce que l'équipe lira dans l'historique. Il doit dire ce qui change et pourquoi :

1. Marquer les versions importantes

   • Une étiquette (tag) donne un nom à un commit important : la version testée, la version rendue. On la retrouve facilement plus tard :

git tag -a v1.0 -m "Version testée le 18 novembre"
git push origin v1.0

1. Faire relire avec une demande de fusion

   • Pour un livrable important, on travaille sur une branche, puis on ouvre une demande de fusion (pull request) sur GitHub. L'équipe voit les images, les commente, et on ne fusionne qu'après accord :

git switch -c wireframe-fiche-livre
git add projet-bibliocampus/04-prototyper/wireframes/fiche-livre.png
git commit -m "Ajoute le wireframe de la fiche d'un livre"
git push -u origin wireframe-fiche-livre

• GitHub propose alors d'ouvrir la demande de fusion. C'est le moment où la carte Trello correspondante passe dans la liste « À relire ».

1. Le README, page d'accueil du projet

   • Le fichier README.md s'affiche automatiquement sur la page du dépôt. Pour un projet UX, il présente le projet, l'équipe, l'avancement et les liens utiles :

1. Exemple 2 : retrouver la version testée

   • Le client demande : « Montrez-moi l'écran tel qu'il était pendant le premier test. » Grâce à l'étiquette v1.0, l'équipe le retrouve en quelques secondes sur GitHub (onglet Tags), alors que l'écran a été modifié trois fois depuis.
   • Sans versionnement, il aurait fallu chercher parmi des fichiers « finale_v2 » et « VRAIE_finale », sans certitude.

1. Activité 1 : Git ou GitHub ?

   • Pour chaque phrase, indiquez s'il s'agit de Git ou de GitHub :
     • a) il enregistre les versions sur mon ordinateur ;
     • b) l'enseignant y consulte mes livrables ;
     • c) il affiche mon README mis en forme ;
     • d) la commande commit lui appartient ;
     • e) on y ouvre une demande de fusion.
   • Vérifier : a) Git ; b) GitHub ; c) GitHub ; d) Git ; e) GitHub.

1. Activité 2 : réorganiser un dépôt

   • Observez le dépôt de cette équipe. Listez les problèmes, puis proposez une nouvelle arborescence et un fichier .gitignore:

• Vérifier : dossier vide mal nommé ; plusieurs « versions finales » au lieu d'un seul fichier ; compte rendu qui révèle le nom d'un participant ; vidéo de 1,8 Go refusée par GitHub ; mot de passe à supprimer immédiatement (et à changer) ; fichier système Thumbs.db ; messages de commit vides de sens.

1. Activité 3 : créer le dépôt du projet

   • Créez dans votre dépôt le dossier projet-cantinecampus/ avec les cinq sous-dossiers des phases, un README.md par dossier et un .gitignore.
   • Vérifier : sur GitHub, chaque dossier affiche son README, et les fichiers listés dans .gitignore n'apparaissent pas.

1. Activité 4 : réécrire des messages de commit

   • Réécrivez ces messages : « modif », « maj maquette », « ok », « ajout fichiers », « test ».
   • Vérifier : chaque message commence par un verbe et dit précisément ce qui change, par exemple « Ajoute le compte rendu du test du 20 novembre ».

1. Activité 5 : versionner trois états d'un écran

   • Exportez trois versions successives de votre wireframe « Mes emprunts » (activité de la leçon précédente) en gardant le même nom de fichier. Faites un commit après chaque version.
   • Sur GitHub, ouvrez l'historique du fichier et comparez les versions.
   • Vérifier : l'historique montre trois commits pour le même fichier, chacun avec un message clair.

1. Activité 6 : anonymiser un compte rendu

   • Rédigez le compte rendu d'un test fictif avec trois participants, en Markdown. Remplacez les noms par P1, P2 et P3, et supprimez toute information qui permettrait de les reconnaître.
   • Vérifier : un lecteur extérieur ne peut identifier aucun participant, mais il comprend les résultats du test.

1. Activité 7 : faire relire par une demande de fusion

   • Par deux, travaillez sur le même dépôt. L'un crée une branche, y ajoute un wireframe et ouvre une demande de fusion ; l'autre la relit et laisse au moins deux commentaires.
   • Après correction, fusionnez la branche.
   • Vérifier : la demande de fusion contient l'image, les commentaires et la réponse aux commentaires avant la fusion.

1. Activité 8 : marquer une version

   • Créez une étiquette v1.0 sur la version de vos wireframes que vous présenteriez à un test utilisateur, et envoyez-la sur GitHub.
   • Vérifier : l'étiquette apparaît dans l'onglet Tags du dépôt et donne accès aux fichiers de cette version.

1. Activité 9 : rédiger le README du projet

   • Rédigez le README de projet-cantinecampus/: présentation, équipe, avancement par phase avec cases à cocher, liens vers le tableau Trello et le prototype Figma.
   • Vérifier : quelqu'un qui découvre le dépôt comprend en une minute le projet, son avancement et où trouver chaque livrable.

1. Activité 10 : déposer votre travail sur GitHub

   • Regroupez dans 15-git-livrables/README.md vos réponses et une capture de l'historique de votre fichier wireframe, puis envoyez le tout :

git add 15-git-livrables projet-cantinecampus
git commit -m "Ajoute la leçon sur le versionnement des livrables UX"
git push

• Vérifier : le dossier projet-cantinecampus/, vos README et votre étiquette v1.0 apparaissent bien sur GitHub.

1. Erreurs fréquentes

1. À retenir

   • Git enregistre les versions sur votre ordinateur ; GitHub les partage en ligne.
   • On organise le dépôt par phase, avec des noms clairs et un README par dossier.
   • On versionne les documents, les exports et les liens ; jamais les données personnelles ni les secrets.
   • Le cycle : git pull, travail, git add, git commit, git push.
   • Un bon message de commit commence par un verbe et dit ce qui change.
   • Les branches et les demandes de fusion permettent de faire relire ; les étiquettes marquent les versions clés.

Avec Git, il n'y a plus de « version finale » : il y a un historique, et chaque version y a sa raison d'être.