none
Architecture des Sites - Recherches de Bonnes Pratiques RRS feed

  • Discussion générale

  • Bonjour,

     

    Je m'apprête à mettre en place un MOSS 2010 Entreprise dans mon entreprise et je suis en pleine réflexion  sur la meilleur manière d'architecturer mes différents sites.

    Je souhaiterais avoir si possible un retour d'expérience sur les raisons qui mènent à créer des sites :

    • Est ce que je doit créer un site par entités regroupant des personnes physiques ( ex : Informatique, Comptabilité)
    • Est ce qu'il faut créer un site par domaines fonctionnels ( ex : Projets, Applications  ... )
    • les 2

    Le fait est qu'aujourd'hui je doit implémenter des bibliothèques et des listes de tâches et je ne sais pas comment je doit m'y prendre sachant que pour creer une tache dans un site il faut que je soit membre de ce site et que j'ai les droits sur cette liste ;

    j'arrive rapidement alors à la chose suivante : si un membre du site "Informatique" veut affecter une tache à un membre du pôle "Comptabilité" il doit être membre au pôle comptabilité , ce qui est adhérent à première vue.


    Comment puis-je envisager que tous les utilisateurs puissent correctement naviguer dans SharePoint sans avoir besoin d'être membres de sites représentant des entités organisationnelles dont il n'ont pas à faire partis.

    J'attend surtout des conseils en tout genre qui puissent m'éclairer sur la meilleur façon de concevoir une base pérenne pour cet espace collaboratif.

     

    Merci d'avance

    lundi 31 janvier 2011 15:24

Toutes les réponses

  • Bonjour,

    C'est un sujet bien vaste que vous lancez là et je pense personnellement qu'il n'y a pas vraiment de "Best Practice" concernant la manière de structurer une collection de site. Je suis consultant spécialisé en SharePoint et force est de constater que la manière dont je structure mes sites dépend beaucoup des besoins du client. Quelque part c'est un peu là que se situe la force de SharePoint, tout est malléable et extensible...

    Généralement je pars du principe  de créer un site (le root) comme étant le "hub" de l'Intranet. C'est là que je vais centraliser les différentes informations que je souhaite exposer à l'ensemble des utilisateurs. Concernant les droits d'accès je pars du principe que tout le monde y a accès au moins en lecture seule. Après je crée autant de sous-site que j'ai de domaines d'activités (entités, département ou domaine fonctionnel). A ce niveau, chaque personne faisant partie de ce domaine d'activité à les accès en tant que contributeurs.

    Concernant votre cas (liste des tâches) plusieurs options sont possibles. Soit vous partez du principe que chaque domaine d'activité à sa propre liste de tâche et cette liste est gérée par un contributeur faisant partie de ce domaine d'activité. Dans ce cas, un contributeurs du domaine A ne saura pas encoder une tâche à un utilisateur du domaine B.  Il est bien entendu toujours possible d'élever les privilèges du contributeurs afin qu'il ai accès à l'ensemble des listes de tâche mais cela compliquera la gestion des accès par la suite.

    La deuxième option serait de configurer une seule liste de tâches au niveau de la racine (le root), de déterminer qui peut contribuer à cette liste et d'y ajouter une colonne  pour différencié les domaines d'activités (via la banque de terme par exemple). Après dans les sous sites il suffira de configurer un WebPart de type "Requête de contenu" et d'y appliquer un filtre sur ces métadonnées afin de ne montrer que les tâches  du domaine courant.

    Voilà un exemple d'implémentation mais loin de moi l'idée d'en faire un Best Practice, comme je vous l'ai dit précédement, tout dépend de la manière dont vous voulez gérer les droits d'accès et toute personne habituée à travailler dans un environnement SharePoint vous le dira, on peut obtenir un résultat identique par de nombreux procédés ;-)

    En espérant vous avoir donner une piste de réflexion ;-)


    Pascal P
    http://sharepoint-afterwork.com
    http://pascalp.dotnet-france.com/
    mardi 1 février 2011 11:02
  • Pour le découpage, c'est tes utilisateurs qui te diront leurs pratiques, et toi qui choisit après :)

    Pour les taches, si informatique et compta travaillent ensemble, c'est "transverse" à mon avis. Soit piloté par le haut, soit dans un emplacement à part.

    Sinon, pour être précis, il suffit que ton informaticien ait des droits sur la liste de taches en question, pas sur le site compta. on pourrait donc aussi le voir simplement comme une liste supplementaire du site compta avec des droits custom. 

    Dans tous les cas, il vaut mieux faire des cas d'utilisation, faire tourner ca sur papier, puis proposer une maquette, avant de lancer le projet en live!


    Emmanuel ISSALY - Sharepoint MCTS, MCNEXT (FR).
    mardi 1 février 2011 11:05
  • A la base, on peut techniquement gérer l'intégralité d'un intranet sur un seul et unique site. Mais comme les autres, je pense que tout cela est avant tout fonction des besoins fonctionnels des utilisateurs. Interviennent ensuite des besoins liés aux droits d'accès, à la remontée d'informations, à la navigation, aux notions d'héritages qu'apportent SharePoint, aux audiences, etc.

    Comme bonne pratique, j'impose de gérer un projet SharePoint ... via un espace SharePoint.

    mercredi 2 février 2011 12:25