Un précédent billet détaille les différentes réglages permettant de configurer l'utilisation du GDS afin de l'adapter aux besoins de chacun : GDS – synthèse sur les réglages proposés pour adapter son usage à ses habitudes et/ou contrainte de configuration.

Le billet a été complété par les "ne plus afficher" qui permettent également d'intervenir sur les interactions avec le GDS :

En effet, les "ne plus afficher" permettent de supprimer de nombreux échanges avec le GDS, pour les extractions et réintégrations dans la base de sources. Si cela peut être très pratique au quotidien, j'observe parfois chez les développeurs une "dérive" qui conduit à valider très rapidement toutes les demandes du GDS qui restent obligatoires.

En effet il faut dans tous les cas rester attentif lors des synchronisations. C'est encore plus vrai lorsque l'on travaille en équipe sans échange direct entre les développeurs (télétravail, sites géographiques différents) :

• les informations saisies lors des réintégrations, deviennent primordiales pour les développeurs qui récupèrent ensuite les éléments,
• la récupération des modifications doit toujours se faire en vérifiant le picto de tous les éléments :
  
  Cette étape ne doit surtout pas être validée "machinalement", même lorsque l'on doit faire une modification "pour hier".
  
  Dans l'exemple suivant la synchronisation à l'ouverture, va provoquer la suppression d'un élément dans la copie locale du projet :
  
  Une telle suppression est normale dans la vie d'un projet, un autre développeur a fait la suppression de l'élément dans la base du GDS, sans purger le dossier du GDS. Mais cela peut donc avoir des conséquences qu'il faut savoir évaluer. Idem si un travail a du être fait en local sur des fichiers en mode déconnecté sans extraction préalable, il faut contrôler les éventuels conflits et être très attentif aux tranferts lors de la reconnexion. Il est possible de perdre un code ou une modification de l'UI par une synchronisation trop hâtive.