Présentation des notions de gouvernance SharePoint lors de notre Agile Brown Bag de novembre 2015 par Bernard Muller

1. Agile Brownbag
Gouvernance SharePoint
25 Novembre 2015

2. Sujets
 Pourquoi une gouvernance
SharePoint ? Pour qui ? Pour quels
aspects ?
 Rôles et responsabilités dans la mise
en œuvre de SharePoint.
 Les règles de gouvernance à définir et
à mettre en place.
 Mythes de la gouvenance SharePoint.
 Le plan de gouvernance

3. L’ère du numérique

4. La boite à outils SharePoint

5. Une ferme SharePoint

6. Les exigences de
gouvernance
Relation entre la gouvernance et le type de site (=> nombre d’utilisateurs)
Le but de la gouvernance est de garantir que les investissements effectués permettent
d’atteindre les objectifs métier de l’entreprise

7. Qu’est ce la Gouvernance ?
La gouvernance est un ensemble de
politiques, de règles, de rôles, de
responsabilités et de processus qui ont
pour but de définir comment les entités
métier et l’informatique d’une organisation
travaillent ensemble à la réalisation de leurs
objectifs
(Microsoft).

8. Personne n’aime la gouvernance
 La gouvernance
 Est une discipline (contraignante)
 Impose des règles
 Nécessite un engagement des acteurs
métier concernés
 Est chronophage
 Est coûteuse (temps, ressources, €)
 Produit des résultats concrets difficiles à
identifier / appréhender

9. Rôles et responsabilités

10. Organes de gouvernance
 Organes techniques
 Problématiques opérationnelles
 Environnements techniques
 Organes de décision
 Stratégie d’implémentation de SP
 Objectifs de l’entreprise

11. Organe de décision
Dirigeants Les principaux dirigeants doivent définir les objectifs généraux du comité de
gouvernance et évaluer périodiquement la réussite des stratégies et des pratiques
mises en œuvre.
Acteurs financiers Les acteurs financiers doivent s’assurer que les processus et règles de gouvernance
favorisent l’augmentation du retour sur investissement de votre organisation dans
les produits Produits SharePoint.
Responsables informatiques Les responsables informatiques contribuent au développement des offres de
services et déterminent la manière d’assumer leurs responsabilités informatiques
(par exemple, améliorer la sécurité et garantir la fiabilité) tout en prenant en charge
les fonctionnalités requises par les équipes commerciales.
Responsables du service commercial Les responsables commerciaux sont les équipes qui effectuent les tâches
fondamentales de l’entreprise et qui orientent les besoins fonctionnels et
architecturaux du déploiement. Ils travaillent avec les architectes des informations
pour structurer les normes de taxonomie et d’architecture des informations. Ils
collaborent également avec les responsables informatiques pour créer des contrats
de niveau du service et d’autres stratégies de support.
Architectes ou taxonomistes des
informations
Les membres de ces groupes conçoivent des taxonomies et des systèmes
d’informations. En se basant sur leur analyse des besoins du public en matière
d’informations, ils développent des plans qui soutiennent les objectifs de
l’organisation et définissent la navigation et l’architecture du site.
Formation Les membres de ce groupe définissent la politique de formation aux outils et aux
technologies mises en oeuvre, les objectifs des formations, les pré-requis et
l’accompagnement des utilisateurs au regard des solutions déployées

12. Les sujets à adresser
En fonction de la vision du projet et de
objectifs métier assignés:
Gouvernance informatique
Gouvernance de l’information
Gouvernance des applications

13. Gouvernance informatique
 Sécurité, infrastructure
 Comment le système est maintenu ?
(HW, SW, updates, backups..)
 Qui a accès à quoi dans l’infrastructure.
(rôles et accès exploitation, support, utilisateurs clef)
 Politique de déploiement
 Configurations, installations
 Mises à jour des composants logiciels
 Politiques de mise à jour des applications

14. Gouvernance informatique
 Permissions
 Partage des données avec des personnes extérieures ?
(qui, quoi, quelle procédure..)
 Gestion des groupes utilisateurs ?
(qui, quels droits, comment)
 Lien avec AD
 Protection des données
 Backups, restore (fréquence, niveau de granularité)

15. Gouvernance informatique
 Gestion du cycle de vie des sites collections
 Création
 Mise à jour
 Suppression ( !)
 Quotas
 Quota par site (500 Mb, 2 Gb, 5 Gb par ex)
 Taille maximale des fichiers (20 Mb)
 Prévisions, suivi, seuils d’alerte
 Type de fichiers
 Bureautiques
 Images, vidéos
 Objets métiers (autocad ...)
 Impact sur l’architecture de la ferme

16. Gouvernance de l’information
 Gestion de l’information
 Record management
 Architecture de l’information
 Versionning
 Taxonomies
 Thésaurus, vocabulaires contrôlés
 Gestion du Central repository
 Gestion des Managed metadata

17. Gouvernance des applications
 Gestion des développements spécifiques
 Cycle de vie des applications
Source contrôle
Versionning
Test et validation
Des nouvelles applications
et des mises à jour
Déploiements

18. Gouvernance des applications
 Branding
 Logos
 Thèmes personnalisés
 Design
 Master pages
 Localisation (pays)

19. Mythe n° 1
La gouvernance n’est nécessaire que pour le grandes
entreprises: nous voulons simplement collaborer
 Création de composants sans plan prédéfini
(pas d’infrastructure ni d’architecture de l’information)
 Pas de gestion de contenu de l’entreprise
(gestion des droits, règles d’archivage, poltiques de rétention)
=> Explosion (croissance non contrôlée)
Cela arrive rapidement même avec un petit volume de contenu.

20. Pas de gouvernance

21. Mythe n° 2
Le plan de gouvernance est un guide de référence qui
décrit l’administration, la maintenance et la gestion
des environnements. Il est pérenne.
 C’est un document complexe
(plusieurs dizaines de pages techniques)
 C’est un document figé
(à mettre de côté quand il a été défini)
=> le plan de gouvernance n’est pas la cible, mais le chemin
(et comme un chemin, il peut changer et doit être adapté au fur
et à mesure de l’avancement du projet)

22. Un plan de gouvernance simple et évolutif

23. Mythe n° 3
L’organe de gouvernance doit être composé des
personnes qui savent de quoi elles parlent
 Les décideurs n’ont pas de temps à consacrer à ces
problématiques opérationnelles
(et pourtant l’outil est le moteur de l’activité de l’entreprise)
 Les responsables métier ne comprennent rien à la technique
(il ne s’agit pas de technique mais des aspects métier,
fonctionnels)
=> l’organe de gouvernance est souvent abandonné aux
interlocuteurs techniques de l’entreprise

24. Erreur !

25. Développement du Plan de gouvernance
 Planning et organisation
 Création organes de gouvernance
 Identification des objectifs métier, mise à jour business plan
 Définition du catalogue de service et des politiques idoines
 Change management, communication
 Acquisition et implémentation
 Achat des solutions et outils
 Identification des systèmes à contrôler
 Création des équipes pour chaque service
 Delivery
 Implémentation
 Meetings réguliers des organes
 Monitoring et évaluation
 Suivi, monitoring
 Communication
 Mise à jour du plan de gouvernance selon les évolutions de l’entreprise

26. Plan de gouvernance (ex. 1)

27. Plan de gouvernance (ex. 1)

28. Plan de gouvernance (ex. 2)

29. Plan de gouvernance (ex. 2)

30. Questions ?