5 évidences sur la gouvernance SharePoint | évidence 1 : sauteriez-vous d'un avion sans parachut
Ce billet ouvre une série de 5 billets sur le thème "5 évidences sur la gouvernance SharePoint".
évidence 1 : sauteriez-vous d'un avion sans parachute ?
évidence 2 : le gourou de la gouvernance n'existe pas
évidence 3 : la gouvernance est un projet documentaire à part entière
évidence 4 : la gouvernance constitue une sécurité pour garder le "client" au centre du jeu
évidence 5 : en suivant la Road Map de Microsoft, vous n'y couperez pas
Se lancer dans un projet SharePoint sans établir clairement les rôles et les tâches de chacun, cela revient à sauter d'un avion sans parachute et à prendre le risque de ne pas parvenir à "poser le projet en douceur".
Cela s'explique par le fait que notre réflexion est historiquement basée sur la croyance que le développement informatique, seul, peut tout : nous pensons que les outils technologiques vont nous sauver. Or, SharePoint est un projet à fort impact organisationnel.
Vous pouvez être d'accord avec la nécessité de vous organiser mais, le jour venu du lancement du projet, comme souvent, vous allez être happé par le quotidien et le plan de gouvernance ne verra jamais le jour ; on compte sur vous pour que le projet aboutisse à un succès et vous n'avez pas forcément le soutien de votre management pour structurer une démarche de gouvernance plus formelle que de coutume, surtout par rapport aux utilisateurs finaux que l'on implique pas plus que la définition des besoins et des tests d'acceptation.
Généralement, la raison est que vous disposez d'un interlocuteur pour l'infrastructure informatique et que vous vous occupez de la supervision des développements en relation avec vos utilisateurs finaux.
Vos "Best Practices" vous imposent généralement des règles en matière de "Business Continuity" et "Disaster Recovery", de sécurité et d'autorisation mais la gouvernance d'un projet SharePoint dépasse les aspects d'infrastructure et de sécurité.
Si vous êtes soumis à des règles de documentation concernant la documentation du code développé sur-mesure, là aussi, le plan de gouvernance devra comporter une partie Développement mais qu'en sera-t-il du paramétrage sur-mesure de votre SharePoint ?
Comme SharePoint est une plateforme personnalisable, elle requiert un effort de gouvernance plus fort pour l'équipe de conception de la solution.
La gouvernance concerne également la dimension "fonctionnelle" ; les choix de paramétrage avancé et de développements spécifiques devront être pris en fonction du degré de maturité des utilisateurs et de la nature de l'information traitée : la personnalisation des vues de liste/bibliothèque, fonctionnalités avancées de version, d'extraction ou de coédition, d'approbation, de workflow de publication, l'utilisation des ensembles de documents, la mise en archive courante, intermédiaire ou définitive, la personnalisation du moteur de recherche, les fonctionnalités liées aux pratiques sociales et communautaires… Parmi les 3 types de gouvernance à intégrer à votre plan général, j'ai coutume de dire que la gouvernance fonctionnelle est le parent pauvre de la gouvernance au niveau outils et méthodes. C'est bien là une raison d'une AMOA forte autour du projet : SharePoint est un généralement un projet à impact organisationnel élevé et la conception de la solution doit être centrée sur la nécessaire adhésion des utilisateurs. Oui, des méthodes existent pour réaliser des analyses "métier" et maquetter des cas d'usages mais on ne parle là que de la conception et non de la gouvernance fonctionnelle tout au long de la vie du projet. Par exemple, savez-vous qu'il existe 33 types d'éléments SharePoint que vous devrez paramétrer pour chaque niveaux d'autorisations ? Il existe également des outils tiers pour automatiser certaines tâches non prévues initialement par Microsoft mais ces outils ne sont que des assistants pour réaliser les tâches dévolues à la bonne gouvernance fonctionnelle de votre solution. En fonction de votre SharePoint, il faudra déterminer la gouvernance fonctionnelle dont vous aurez besoin : éditoriale, communautaire, taxonomique…? Bâtir un plan de gouvernance pour votre projet SharePoint peut vous apparaître comme une énorme charge de travail supplémentaire ; s'ajoutant à votre quotidien qui est de mettre le projet sur les rails, de le livrer et… c'est tout car, ensuite vous devrez de toute façon passer à autre chose… Cela peut vous paraître d'autant disproportionné et superflu au regard du périmètre de votre projet : en soi, ce n'est pas une mauvaise chose car cela pourrait signifier qu'au moins, votre premier projet SharePoint est de taille modeste (ce qui est recommandé, j'ai entendu Xavier Vanneste parler de l'effet "nénuphar", "les nénuphars s'ouvrant les uns après les autres pour remplir progressivement la mare"). Or, c'est justement ce premier petit projet qui constituera l'occasion la plus facile à saisir pour établir votre premier plan de gouvernance et introduire des Best Practices liés à votre SharePoint. Si vous n'établissez pas de plan de gouvernance, il est possible que ce soit tout le contraire qui se produise et que vous ne puissiez jamais passer complètement à autre chose.
Ne pas établir les règles de gouvernance est un excellent moyen pour se rendre indispensable et ne jamais pouvoir sortir du projet.
Le plan de gouvernance représente donc à mes yeux le parachute qui va vous aider à atterrir en douceur, comprenez à livrer le projet de la façon la plus contrôlée aux différentes parties concernées : avoir repris la charte de vision qui comporte les enjeux, objectifs et impératifs du projet puis avoir établi qui (?) fait quoi (?) et pourquoi (?), quand (?) et comment (?) pour couvrir toute la vie de votre projet SharePoint, de la conception-réalisation à la phase de maintenance continue. La seconde évidence est "le gourou de la gouvernance SharePoint n'existe pas".
