J'aurais tendance à penser que moins il y a de projets d'équipe, mieux c'est. Les rapports sont-ils classés par "paquets" logiques ? Avez-vous absolument besoin de les gérer séparément ? Êtes-vous suffisamment flexible pour travailler avec un seul projet plutôt qu'avec plusieurs ?
Lors de la définition des projets d'équipe - quel que soit le type de solutions qu'ils contiennent - j'essaie de trouver le meilleur équilibre entre la granularité et la facilité de déploiement. N'oubliez pas que si vous allez mettre en place un suivi des éléments de travail, des constructions d'équipe ou utiliser des portails de projet, chaque projet d'équipe devient en fait une délimitation entre eux.
Pour des choses comme le WIT, il est possible d'établir une séparation par le biais de domaines fonctionnels. En ce qui concerne les constructions, vous n'en aurez qu'une par projet si vous souhaitez que les choses restent simples et directes. Les portails ne sont généralement pas un argument de vente dans un sens ou dans l'autre dans la décision finale, bien que parfois les groupes de sécurité AD que j'associe aux projets d'équipe rendent cet aspect un peu plus important.
Sans connaître les détails de votre situation, je pencherais plutôt pour votre "scénario 2". Le fait de devoir passer d'un projet d'équipe à l'autre et de savoir lequel est lequel représente quelques frappes/clics de plus que ce que je voudrais avoir à faire en permanence. Si je veux créer des branches pour quelques rapports, je ferais mieux de créer plus de branches que nécessaire plutôt que d'en maintenir plusieurs.
