Améliorations SharePoint 2016

Découvrir les étapes d’un projet SharePoint 2016

Cet article vous donne le détail de la procédure pour mettre en oeuvre un projet SharePoint. Il présente donc une démarche d’installation de SharePoint. Il s’agit d’une procédure qui cherche à couvrir tous les aspects. Aussi, il est possible que certains aspects ne concernent pas votre projet.

Bien évidemment, il n’existe aucune recette magique pour implémenter avec succès. Par contre, c’est très facile de « passer » à coté de choix structurants quand vous ne connaissez pas le sujet. Le coût pour « revenir en arrière » peut être élevée. Autant, faire au mieux dès le départ.

Par ailleurs, l’article suivant intitulé Mettre en oeuvre SharePoint : Tâches vous donne plus de détails sur les tâches à accomplir.

Notez qu’il existe d’autres approches. En particulier, il existe aussi la possibilité de transposer intelligemment les documents stockés sous Windows dans SharePoint. Il s’agit d’une technique qui est présentée dans un autre article.

Dans l’immédiat, cette démarche pour un projet SharePoint s’appuie sur les étapes suivantes :

  • Définition du périmètre du projet
  • Analyser les besoins métiers
  • Étudier l’impact organisationnel
  • Définir l’architecture technique
  • Étudier la sécurité
  • Installer l’environnement SharePoint de développement
  • Prototyper sur le site de développement
  • Installer l’environnement SharePoint de production
  • Suivre la ferme SharePoint
  • Former et accompagner

Ces étapes peuvent se chevaucher.

Projet SharePoint
Page d’accueil de SharePoint

Définition du périmètre du projet SharePoint

L’objectif est de recueillir les besoins, auditer l’existant, définir le périmètre, les objectifs de la mission et son planning du projet SharePoint. Cette étape permet aussi de chiffrer les gains attendus et de calculer le retour sur investissement d’un projet SharePoint.

A priori, il semble difficile d’évaluer le retour sur investissement (ROI) d’un projet collaboratif car les gains espérés portent généralement sur l’augmentation de l’efficacité des utilisateurs. Ce qui paraît compliqué à mesurer.

Pourtant, il existe des métriques factuelles. Ainsi, la mise en place du portail collaboratif peut conduire à la diminution du nombre de documents à manipuler,  la diminution du volume de stockage ou la diminution du temps à chercher un document.

À titre d’exemple, la diminution du volume de stockage peut atteindre 30 % des documents existants, sans perte d’informations. La diminution du temps de recherche d’un document peut passer de 30 minutes en moyenne à moins de 3 minutes. Il s’agit d’une mesure réelle faite chez un client.

Vous pouvez être encore plus précis, à travers une application métier. Un flux de travail dans SharePoint peut vous faire économiser 20 à 30% du temps nécessaire au traitement d’un dossier.

Analyser les besoins métiers

L’objectif est d’identifier les outils fonctionnels à mettre en œuvre dans le cadre du projet SharePoint.

Il est important de garder en tête que SharePoint n’est pas une solution. C’est une suite de choix à mettre en oeuvre. De la même façon que Word ne rédige pas les documents pour vous, SharePoint ne fera rien sans vous.

Cette étape nécessite de connaître le périmètre défini dans l’étape précédente, l’existant et les possibilités natives de SharePoint.

Le choix des outils à une conséquence directe sur le coût total du projet.

Prenez un besoin utilisateur, comme vouloir gérer un stock de biens.

Cela peut se traduire par une liste personnalisée avec les métadonnées ad’hoc (2 jours), ou bien par la création d’un formulaire InfoPath et d’un flux de travail SharePoint Designer (<10 jours), ou d’un développement spécifique (15-20 jours, voire plus ?).

Par ailleurs, la taxonomie est une tâche incontournable dans un projet GED.

Dans un projet SharePoint, la taxonomie consiste à chercher les propriétés d’un document, ou plus précisément ses métadonnées. Ces métadonnées servent à ranger les documents à leur place. Elles servent aussi à les retrouver plus rapidement.

Si les métadonnées sont mal analysées les utilisateurs risquent de se détourner de SharePoint car ils ne verront pas son intérêt par rapport à Windows. Et ils auront raison.

Un projet SharePoint qui n’intéresse pas les utilisateurs souffre généralement d’un manque d’analyse des métadonnées. Il s’agit de sites SharePoint qui sont comme des « windows-like ».

La taxonomie représente environ 20% du coût du projet.

Étudier l’impact organisationnel

L’objectif est d’identifier les impacts sur l’organisation, liés à la mise en place du projet SharePoint et de repenser cette organisation.

SharePoint introduit de nouvelles façons de penser les documents à travers l’Organisateur de contenu, les ensembles de documents ou les stratégies de gestion des informations.

Il faut tirer profit de ces nouveaux paradigmes bureautiques pour simplifier les tâches de l’utilisateur. Concrètement, un utilisateur peut alimenter la bonne bibliothèque au bon endroit d’un site SharePoint en connaissant uniquement l’existence de la Bibliothèque de remise, sans rentrer dans les détails du site.

L’alimentation peut aussi se faire par l’envoi d’un email avec le document en pièce jointe à SharePoint.

Quel que soit la solution retenue, elle devra toujours obéir à la règle du « pas de duplication de contenu ».

L’autre besoin concerne l’accès aux documents. Avec un site SharePoint qui utilise les métadonnées, un utilisateur peut trouver un document sans être obligé de parcourir tous les sites, grâce au panneau d’affinement du centre de recherche.

L’objectif est que chaque utilisateur trouve son document en moins de 3 clics !

Définir l’architecture technique

L’objectif de l’architecture technique est de dimensionner l’architecture pour 10 ou 10000 utilisateurs.

Il s’agit d’une étape technique où des hypothèses sont faites sur l’utilisation future de SharePoint.

L’intérêt de SharePoint est aussi son évolutivité, qui été encore améliorée dans SharePoint 2016. Concrètement, l’architecture peut évoluer d’un serveur unique à une ferme de 30 serveurs sans perdre le travail déjà réalisé.

Cette étape permet aussi de poser les bonnes questions comme par exemple, sur les accès anonymes (autorisés ou non), qui accédera à SharePoint (utilisateurs de l’Active Directory ou pas).

L’étape de définition de l’architecture technique permet aussi d’identifier les sources de contenu externes auxquels SharePoint devra accéder, soit pour les indexer, soit pour les lire ou les mettre à jour. Dans tous les cas, les méthodes d’accès sécurisées sont à définir.

Étudier la sécurité

L’objectif est de garantir au maximum la sécurité des données de SharePoint.

Les utilisateurs confient leurs précieuses données à SharePoint. Il faut donc s’assurer qu’elles restent disponibles. De plus le coffre-fort de données que contient SharePoint devient appétissant pour de nombreux prédateurs.

Les solutions à étudier couvrent donc les autorisations des utilisateurs et des applications,  la sauvegarde et la redondance des données, le chiffrement des données et des échanges, la lutte contre les malwares et les tentatives de pénétration.

Dès la phase de conception, il est nécessaire d’intégrer les besoins de sécurité, car ils ont un impact certain sur le « design » global des sites SharePoint. Il s’agit d’un outil collaboratif mais cela ne signifie pas que tout le monde peut accéder à toutes les informations sans discernement.

Installer l’environnement SharePoint de développement

L’objectif est de disposer d’un environnement de type « bac à sable » pour les tests, formation et développement. Pour des raisons de sécurité, cet environnement doit être totalement déconnecté de l’environnement de production.

N’acceptez jamais de travailler directement sur l’environnement de production. De même, n’acceptez pas non plus que l’environnement de développement devienne le futur environnement de production. Dans ce cas, vous allez récupérer toutes les scories liées au développement.

Cette étape est très opérationnelle. Il s’agit de créer et paramétrer l’environnement. C’est l’occasion de s’habituer à automatiser les tâches à accomplir avec PowerShell.

Prenez aussi l’habitude de mettre en place des outils pour vous faire des remontées automatiques en cas de changement de la configuration : droits, services, etc. Au début, certains font des manipulations hasardeuses sans le savoir.

Prototyper sur le site de développement

L’objectif est de réaliser un prototype opérationnel avec SharePoint afin de montrer à quoi va ressembler le futur site et à quoi il va servir. C’est aussi l’occasion de tester toutes les hypothèses précédentes.

Cette étape est très opérationnelle. Il s’agit de créer ou paramétrer tous les objets identifiés précédemment.

Le livrable est un ensemble de sites SharePoint.

Vos interlocuteurs ont tendance à préférer voir des petites parties opérationnelles rapidement plutôt  que d’attendre longtemps pour voir un résultat « parfait ».

Une mise en œuvre progressive permet également d’introduire des corrections mineures de trajectoire au fur et à mesure, ce qui conduit finalement à un meilleur résultat.

Dans cette étape, il est malin de chercher à automatiser le plus possible. En effet, le processus de création est itératif car les utilisateurs modifient leurs perspectives au fur et à mesure de l’avancement du prototype.

C’est aussi un entraînement utile lors du futur passage en production.

Installer l’environnement SharePoint de production

L’objectif est de disposer d’un environnement réel de production pour SharePoint.

Cette étape est très opérationnelle. Il s’agit de créer et paramétrer l’environnement.

L’utilisation de scripts PowerShell pour automatiser le plus possible l’installation est indispensable. Certaines tâches, comme la configuration des serveurs de cache, ne peuvent se faire qu’avec PowerShell.

Le passage de l’environnement de développement en production mérite une attention particulière. En particulier, chaque nouveau cycle de mise à jour ne doit pas être destructif en production. C’est évident mais cela va mieux en le disant.

Le suivi de votre ferme SharePoint est indispensable pour son contrôle et sa sécurité.

Suivre la ferme SharePoint

L’objectif est de s’assurer de la pertinence de la solution mise en œuvre et de surveiller la ferme SharePoint afin de contrôler sa sécurité.

Dans cette étape, il s’agit d’activer avec discernement les très nombreux journaux et rapports liés à SharePoint.

La lecture manuelle de tous les journaux est impossible. Il faut disposer d’outils maisons ou d’éditeurs, afin d’avoir une remontée pertinente et automatique sur des activités anormales de la ferme.

Outre les aspects sécurité, le suivi de la fréquentation des sites, ainsi que les requêtes de recherche des utilisateurs permet de s’assurer de la pertinence des informations contenues dans SharePoint.

Il n’est pas rare qu’un utilisateur recréé une information déjà existante parce qu’il ne sait pas utiliser correctement SharePoint. Les besoins de formation peuvent être aussi détectés par l’analyse des requêtes de recherches.

Former et accompagner

L’objectif est de sensibiliser la Direction Générale à l’arrivée de SharePoint et de former les utilisateurs à l’utilisation de ce nouvel outil.

Pour la Direction Générale, il est suffisant de procéder à quelques démonstrations bien introduites. Ces démonstrations doivent plus mettre en valeur les avantages de SharePoint que ses fonctionnalités.

Outre les formations présentielles, il faut penser à mettre à disposition des utilisateurs des mémos, fiches pratiques et modes d’emploi afin de prévenir les questions qu’ils vont se poser.

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *