Cartographier les changements et les responsabilités
Objectif : Distinguer les changements de contenu, de code et de configuration à intégrer dans le dépôt.
Quand un site statique devient un produit suivi par plusieurs personnes, une demande apparemment simple peut toucher des éléments très différents. Une modification de texte, une correction de comportement et un réglage de dépôt ne présentent ni les mêmes risques ni les mêmes besoins de vérification. Vous allez apprendre à les distinguer avant de décider qui contribue et comment valider le changement.
Pourquoi cartographier les changements
Une cartographie des changements consiste à relier chaque demande à sa nature, aux fichiers qu’elle peut affecter et aux vérifications nécessaires. Elle rend visible le périmètre de travail avant que plusieurs modifications soient mélangées dans une même proposition. Elle aide aussi l’équipe à solliciter les bonnes compétences au bon moment, sans supposer qu’une seule personne maîtrise tous les aspects du dépôt.
Dans le projet fil rouge, le contrat fixe quatre fichiers suivis : index.html, style.css, README.md et .gitignore. Ce périmètre n’est pas une invitation à ajouter des fichiers selon les besoins du moment : il sert à identifier les responsabilités du dépôt et à examiner les propositions avec les contraintes déjà convenues. Une demande qui semble nécessiter une nouvelle structure doit donc être clarifiée avant d’être intégrée.
Distinguer les trois familles de changements
Un changement de contenu modifie l’information présentée aux visiteurs : par exemple, reformuler l’introduction de la page ou corriger une consigne dans une carte. Dans le dépôt actuel, ce contenu se trouve dans index.html. La vérification porte notamment sur l’exactitude du texte, sa cohérence avec les autres sections et le maintien des liens vers les ancres existantes.
Un changement de code modifie la structure ou le comportement technique de la page. Dans le projet, une correction de balisage HTML dans index.html relève de cette famille, même si le fichier contient aussi du texte destiné aux visiteurs. Il faut alors vérifier que la page reste valide et que les éléments conservent leur rôle. Un même fichier peut donc contenir plusieurs types d’informations : classez la modification d’après son intention et son effet, pas uniquement d’après son extension.
Un changement de configuration ajuste les règles qui gouvernent la présentation ou le fonctionnement du dépôt. Une modification des variables CSS autorisées dans style.css concerne la configuration visuelle du site ; une règle d’exclusion dans .gitignore concerne les fichiers à ne pas suivre ; une mise à jour des consignes dans README.md concerne la documentation du projet. Ces changements doivent être examinés à la lumière du contrat du dépôt : les valeurs, les fichiers et les règles permis ne sont pas interchangeables.
| Famille | Exemple dans le projet | Vérification à prévoir |
|---|---|---|
| Contenu | Reformuler une explication dans index.html | Exactitude, lisibilité et cohérence des liens |
| Code | Corriger la structure HTML dans index.html | Balisage cohérent et affichage de la page |
| Configuration | Ajuster une règle dans style.css ou .gitignore | Respect du contrat et effet sur le dépôt |
| Documentation | Clarifier une consigne dans README.md | Consigne exacte, applicable et cohérente avec les règles |
Attribuer les responsabilités sans créer de silos
Une responsabilité de contribution désigne la personne ou la compétence chargée d’apporter une modification ou d’en vérifier un aspect. Pour une correction de contenu, la personne qui connaît le sujet peut valider l’exactitude ; une personne familière avec la structure de la page peut contrôler les liens et le balisage. Pour une modification de configuration, demandez une vérification par quelqu’un qui comprend les règles affectées, puis consignez le résultat dans la proposition de changement.
La responsabilité ne signifie pas qu’une personne possède seule un fichier ou qu’elle peut fusionner sans regard extérieur. Elle sert à rendre explicites les questions à poser : qui confirme le besoin, qui réalise le changement et qui vérifie ses conséquences ? Selon la taille de l’équipe, une même personne peut assumer plusieurs de ces rôles, mais les vérifications doivent rester adaptées au risque et au périmètre.
Appliquez cette méthode à la demande « préciser comment l’équipe vérifie une contribution ». Elle relève principalement de la documentation et concerne README.md ; la vérification consiste à confirmer que les consignes correspondent aux pratiques convenues et qu’elles n’entrent pas en conflit avec le contrat du dépôt. Si le travail révèle qu’une règle de configuration doit également changer, traitez cette conséquence explicitement au lieu de la masquer dans une modification de documentation.
À retenir
- Classez une modification selon son intention et son effet, pas seulement selon le fichier qu’elle touche.
- Reliez chaque changement aux fichiers du contrat et aux vérifications correspondantes.
- Distinguez la personne qui connaît le besoin de celle qui peut contrôler les conséquences techniques.
- Clarifiez les changements mélangés et leur périmètre avant de commencer le travail.
Dans la suite, vous vous appuierez sur cette cartographie pour choisir une stratégie de branches adaptée aux changements de l’équipe.