5.4Travail en équipe : GDS (gestionnaire de sources)
L'essentiel en 30 secondes
- Le GDS stocke les sources dans un référentiel partagé : chaque développeur extrait un élément pour le modifier, puis le réintègre, avec un historique complet.
- Le GDS est utile même en solo : retour arrière, copie de sécurité supplémentaire et traçabilité des décisions, bien au-delà de simples copies datées.
- L'équipe suit des règles : réintégrer souvent, commenter, tester, respecter des conventions et communiquer avant toute modification de l'analyse.
Mini-cas filé — Yacine organise le travail de son équipe avec le GDS
Yacine développe l'application d'une PME de négoce de matériel électrique à Oran. Samir travaille sur le portail web et Nadia sur l'application mobile : tous trois partagent la même analyse et les mêmes procédures métier. Yacine met le projet sous GDS et crée un référentiel commun. Chacun extrait les éléments sur lesquels il travaille, les teste, puis les réintègre avec un commentaire précis. Le midi, Samir et Yacine ont modifié la même procédure de calcul de remise : le GDS montre l'historique et permet de fusionner sans écraser le travail de l'autre. Avant de toucher au fichier Article, Yacine prévient l'équipe, car une modification d'analyse impacte tout le monde. Il sauvegarde aussi le référentiel, devenu l'actif le plus précieux du projet.
Cas autonome de cette section : il revient dans le cours, le schéma, le code et le défi 48h de la section 5.4.
1. Le référentiel et le cycle
Le GDS (Gestionnaire De Sources) est intégré à l'atelier WinDev. Les éléments du projet sont stockés dans un référentiel partagé. Chaque développeur extrait les éléments sur lesquels il travaille, ce qui les prend en charge, puis les réintègre une fois modifiés et testés. Ce cycle évite que deux personnes écrasent mutuellement leur travail. Le GDS conserve l'historique complet : qui a modifié quoi, quand, et avec quel commentaire. On peut ainsi comprendre une décision ancienne ou revenir à une version antérieure. C'est très supérieur à des copies de dossiers nommées « projet_final_OK ».
2. Utile même seul
Le GDS n'est pas réservé aux équipes. Même seul, Yacine y gagne un retour arrière après une fausse manœuvre, une copie de sécurité distincte de son dossier de travail et une traçabilité de ses décisions. Il ose expérimenter une refonte ou une optimisation parce qu'il sait pouvoir revenir en arrière. Les copies datées, elles, ne disent ni qui a fait quoi, ni pourquoi, et finissent par devenir impossibles à démêler. Le GDS impose aussi une discipline utile : réintégrer par étapes cohérentes et commenter ce que l'on a fait.
3. Les règles d'équipe
En équipe, l'outil ne suffit pas : il faut des règles respectées. Réintégrer souvent (idéalement chaque jour) pour ne pas bloquer les collègues. Commenter utilement chaque réintégration : « correction du calcul de remise grands comptes » plutôt que « modifs ». Tester avant de réintégrer pour ne pas casser le projet commun. Définir des conventions communes de nommage et de style. Et surtout communiquer avant de modifier l'analyse, car le modèle de données est partagé et impacte tout le monde. Enfin, sauvegarder le référentiel lui-même : il concentre désormais l'essentiel du projet.
🔎 Exemple concret — 🔎 Exemple concret — Une réintégration commentée
Yacine corrige la remise grands comptes et documente son changement :
// Calcul de la remise accordée à un client
// GDS : réintégration commentée — seuil grands comptes corrigé
PROCEDURE CalculeRemiseClient(nCA est un réel) : réel
SI nCA >= 500000 ALORS
RENVOYER 5
FIN
RENVOYER 0Résultat : l'historique explique le pourquoi du seuil, pas seulement le diff.
Réflexe : commenter la réintégration avec le métier et l'impact, pas « modifs ».
Vocabulaire de la section
- GDS
- Gestionnaire De Sources intégré à WinDev : référentiel partagé, extraction/réintégration et historique.
Exemple simple : Yacine met le projet de gestion sous GDS avec Samir et Nadia.
Ce que ce n'est pas : échanger des dossiers par clé USB sans historique.
Réflexe : GDS = sources versionnées et partagées.
- Référentiel
- Dépôt central des éléments du projet, distinct du dossier de travail de chaque développeur.
Exemple simple : Le référentiel contient l'analyse et les procédures communes.
Ce que ce n'est pas : travailler chacun sur une copie isolée du projet.
Réflexe : le référentiel est l'actif à sauvegarder.
- Extraction / réintégration
- Cycle de travail : prendre en charge un élément pour le modifier, puis le remettre dans le référentiel.
Exemple simple : Nadia extrait la procédure de stock, la teste et la réintègre.
Ce que ce n'est pas : garder un élément extrait pendant des semaines.
Réflexe : réintégrer souvent pour ne pas bloquer.
- Historique
- Conservation de qui a modifié quoi et quand, avec les commentaires et la possibilité de revenir en arrière.
Exemple simple : Yacine retrouve la version d'hier après une fausse manœuvre.
Ce que ce n'est pas : se fier à des copies nommées projet_final_OK.
Réflexe : l'historique explique et répare.
- Branche
- Ligne de développement parallèle permettant d'isoler une évolution avant de la fusionner.
Exemple simple : Yacine prépare une refonte du stock dans une branche dédiée.
Ce que ce n'est pas : développer une refonte risquée directement sur la ligne commune.
Réflexe : une branche isole, puis se fusionne.
En pratique — En pratique — Travailler avec le GDS
- Mettez le projet sous GDS et créez le référentiel, même si vous travaillez seul, pour l'historique et le retour arrière.
- Adoptez le cycle : extraire l'élément à modifier, travailler, tester, puis réintégrer rapidement en commentant ce qui a été fait et pourquoi.
- En équipe, définissez des conventions communes (nommage, style, organisation) et communiquez avant toute modification de l'analyse.
- Sauvegardez le référentiel lui-même : il est devenu l'actif le plus précieux du projet.
Script pas-à-pas — tester avant de réintégrer (10 min)
Yacine vérifie les cas critiques de la remise avant de remettre la procédure dans le référentiel.
Un test rapide des cas métier évite de casser le projet commun ; on réintègre ensuite avec un commentaire précis.
Modèle copier-coller — mon commentaire de réintégration
// Réintégration GDS — Yacine — 12/03
// Élément : PROCEDURE CalculeRemiseClient
// Modification : seuil grands comptes porté à 500 000 DZD
// Tests : remise 5 % à 600 000, 0 % à 100 000 → OK
// Impact analyse : aucun
// Règle : réintégrer souvent, commenter, tester, prévenirTravail solo
Yacine utilise le GDS seul pour revenir en arrière après une refonte risquée.
Équipe web et mobile
Samir et Nadia extraient chacun leurs éléments et réintègrent sans écraser l'autre.
Modification d'analyse
Yacine prévient l'équipe avant de changer le fichier Article.
Branche d'essai
Yacine isole une nouvelle version du stock dans une branche avant fusion.
✓ Bonnes pratiques
- Réintégrer souvent et libérer les éléments inutilisés.
- Commenter et tester chaque réintégration.
- Communiquer avant toute modification de l'analyse.
✗ Pièges fréquents
- Garder un élément extrait pendant des semaines.
- Écrire « modifs » comme commentaire de réintégration.
- Modifier l'analyse sans prévenir l'équipe.
Points clés à retenir
- Le GDS stocke les sources dans un référentiel partagé, avec extraction et réintégration.
- L'historique indique qui, quoi, quand et permet de revenir en arrière.
- Le GDS est utile même seul : retour arrière, copie de sécurité, traçabilité.
- En équipe : réintégrer souvent, commenter, tester, conventions communes et communication sur l'analyse.
Défi 48h — appliquez demain
Comme Yacine, mettez un projet sous GDS et réalisez un cycle complet : extraire une procédure, la modifier, la tester, puis la réintégrer avec un commentaire qui explique le métier et l'impact. Provoquez ensuite une fausse manœuvre et revenez à la version précédente depuis l'historique. Sauvegardez le référentiel.
- Je peux expliquer le rôle du référentiel et le cycle extraire/réintégrer.
- Je sais pourquoi le GDS est utile même en solo.
- Je connais les règles d'équipe : commenter, tester, communiquer sur l'analyse.
Questions fréquentes
Le GDS est-il utile quand on développe seul ?
Oui, nettement. Même sans équipe, il apporte l'historique et le retour arrière après une fausse manœuvre, une copie de sécurité supplémentaire distincte du dossier de travail et la traçabilité des décisions. Il permet aussi d'expérimenter sereinement : on ose une refonte parce qu'on sait pouvoir revenir en arrière. Les copies de dossiers datées ne disent ni qui, ni quoi, ni pourquoi, et l'on oublie de les faire aux moments critiques. Pour Yacine, le GDS est donc utile avant même l'arrivée de Samir et Nadia.
Quelles règles adopter pour travailler à plusieurs sur un projet WinDev ?
Des règles simples mais respectées : réintégrer souvent, idéalement chaque jour ou à chaque étape cohérente ; n'extraire que ce dont on a besoin ; commenter utilement chaque réintégration ; tester avant de remettre un élément dans le référentiel ; récupérer régulièrement les modifications des autres. Côté code, définir des conventions communes de nommage et de style, et éviter de mettre le métier dans les boutons. Côté communication, prévenir avant toute modification de l'analyse, car elle impacte toute l'équipe. Enfin, sauvegarder le référentiel lui-même.
À quoi sert le GDS même quand Yacine développe seul ?