Résumé des modules et conclusion

Résumé des modules et conclusion




Voici le résumé de toutes les thématiques vues dans cette série formant une solution d’intranet en SharePoint 2013 :

Module #1 : La publication


Lien vers l’article complet: Module #1 : La publication


 Objectif

Gestion du processus complet de création du contenu jusqu’à son affichage. C’est ici que le choix technologique du moyen de publication est fait (publication intersites ou infrastructure de publication classique).

Besoins couverts

  • [PUB_01] Contributeur : Créer, modifier, supprimer un contenu
  • [PUB_02] Utilisateur : Visualiser les détails d’un contenu seul
  • [PUB_03] Utilisateur : Visualiser un ensemble de contenus

 Résumé

  • Les contenus de l’intranet sont créés dans un ou plusieurs sites d’auteurs à travers des catalogues (l’équivalent de listes SharePoint). Ceux-ci sont affichés dans un site de publication grâce au moteur de recherche. C’est le principe de base de la publication intersites.
  • Les contenus sont distingués selon leur cycle de vie. Ainsi on retrouve les « pages de contenu » qui ont un cycle de vie long (la page « À propos de nous » par exemple) et les « nouvelles » qui possèdent un cycle de vie court et constituent le contenu récurrent d’un intranet.
  • Tout contenu de l’intranet est obligatoirement classé avec un terme d’une arborescence de classification globale, une sorte de « carte du site ».
  • La sécurité est gérée à la fois au niveau SharePoint (permissions sur les sites et listes) mais aussi au niveau des termes de classification disponibles pour les contributeurs selon leur rôle (RH, Finances, etc.) grâce à la fonctionnalité de réutilisation de termes.

 Notions techniques

  • Sites d’auteurs
  • Métadonnées gérées
  • Catalogues de contenu
  • Web Parts de recherche
  • Types de résultats
  • Modèles d’affichages

Module #2 : La navigation


Lien vers l’article complet: Module #2 : La navigation


 Objectif

Accès à l’information dans le portail à travers différents menus.

Besoins couverts

  • [NAV_01] Utilisateur : Naviguer dans le portail

Résumé

  • La navigation SharePoint par défaut ne permet de gérer qu’un menu principal et un menu gauche. C’est pourquoi, nous utilisons des composants personnalisés possédant chacun leur source de données dédiée sous la forme d’un ensemble de termes permettant ainsi l’implémentation de multiples menus de navigation dans l’intranet de manière générique.
  • Les termes de classification sont utilisés dans la construction des URL du site de publication pour la récupération dynamique du contenu via la navigation par taxonomie.
  • Pour les éléments de catalogues (« nouvelles », etc.), les URL sont construites sur la base de « slugs» calculés automatiquement lors de la création du contenu et utilisés dans les connexions de catalogues au site de publication.

Notions techniques

  • Navigation par taxonomie
  • URL conviviales
  • Pages pilotées par les termes

Module #3 : La gestion documentaire


Lien vers l’article complet: Module #3 : La gestion documentaire


Objectif

Gestion du contenu documentaire et des contenus médias.

Besoins couverts

  • [DOC_01] Contributeur : Ajouter un média à un contenu
  • [DOC_02] Importer du contenu initial

Résumé

  • La détermination automatique du format des images sur le site de publication est réalisée par la fonctionnalité de « rendu d’images » de SharePoint tandis que les contenus médias sont gérés par le type de contenu « Vidéo » par défaut de SharePoint.
  • L’importation de données est réalisée au fur et à mesure du développement via l’utilisation de cmdlets PowerShell utilisant Sharegate et Excel.

Notions techniques

  • Rendus d’images
  • Type de contenu vidéo
  • Emplacements de navigateur de contenu suggérés
  • Sharegate™
  • PowerShell, Excel et OpenXML

Module #4 : Le multilinguisme


Lien vers l’article complet: Module #4 : Le multilinguisme


Objectif

Création et visualisation de contenus dans une ou plusieurs langues.

Besoins couverts

  • [LANG_01] Contributeur : Créer du contenu dans plusieurs langues
  • [LANG_02] Utilisateur : Voir du contenu dans plusieurs langues
  • [LANG_03] Utilisateur : Changer la langue d’affichage

Résumé

  • La fonctionnalité de variantes est mise en place à la fois sur les sites d’auteurs et le site de publication dupliquant le contenu dans des sites distincts (des branches de langues) « /fr» ou « /en ».
  • Le développement d’un composant de changement de langue est nécessaire, car SharePoint n’en fournit aucun par défaut. Dans ce cas, plusieurs contextes sont à prendre en compte.
  • L’arbre de classification de l’intranet est dupliqué dans chaque langue via un épinglage de termes pour permettre son utilisation dans les différentes branches de langues du site de publication, créées par la fonctionnalité de variantes.
  • La langue des contenus est déterminée à la création par un récepteur d’événements puis utilisée avec la variable {Site.Locale} dans les requêtes de recherche sur le site de publication.

Notions techniques

  • Variantes SharePoint
  • Récepteurs d’événements pour le calcul de la langue
  • Épinglage de termes
  • Contextes de navigation

Module #5 : Le cycle de vie de l’information


Lien vers l’article complet: Module #5 : Le cycle de vie de l’information


Objectif

Contrôle de l’expiration et la publication des contenus.

Besoins couverts

  • [LFCL_01] Contributeur : Soumettre un contenu pour approbation
  • [LFCL_02] Contributeur : Contrôler la période d’affichage d’un contenu

Résumé

  • Le processus d’approbation des éléments de listes par défaut de SharePoint étant trop simpliste et les flux de travail étant eux, au contraire, bien trop compliqués, nous avons développé un « entre-deux » permettant de notifier par courriel avant approbation sous la forme d’une action du ruban dans les catalogues.
  • Les contenus sont soumis à une période de publication avec une date de début et une date de fin. Si la granularité doit descendre jusqu’à la minute près, il est nécessaire d’adapter le Web Part de recherche par défaut en utilisant le langage FQL et l’opérateur « range» car le langage KQL ne supporte pas ce cas.

Notions techniques

  • Action du ruban
  • Processus d’approbation de liste
  • Langages KQL/FQL
  • Affinements de recherche

Module #6 : Le social


Lien vers l’article complet: Module #6 : Le social


Objectif

Commentaires et interactions entre utilisateurs.

Besoins couverts

  • [SOCIAL_01] Utilisateur : Commenter et aimer un contenu

Résumé

  • La fonctionnalité de forum de discussions est utilisée pour la gestion des commentaires et « likes» dans l’intranet. L’interface par défaut n’étant pas utilisable autre part que dans la liste elle-même, il est nécessaire de la réimplémenter.

Notions techniques

  • Forum de discussions
  • Évaluation de contenus
  • Knockout.js

Module #7 : Le ciblage de contenu


Lien vers l’article complet:  Module #7 : Le ciblage de contenu


Objectif

Filtrage de l’information à une ou plusieurs catégories d’individus selon des critères précis.

Besoins couverts

  • [TARGET_01] Contributeur : Créer du contenu ciblé
  • [TARGET_02] Utilisateur : Voir du contenu pertinent à mon profil

Résumé

  • Le ciblage de contenu est réalisé exclusivement grâce aux possibilités de la recherche et des propriétés du profil de l’utilisateur.
  • Chaque contenu peut être ciblé à une ou plusieurs audiences correspondant à des termes de taxonomie.
  • L’opérateur « | » est utilisé conjointement à une propriété de profil contenant toutes les audiences dont un utilisateur fait partie. Celles-ci sont déterminées de manière automatique via à un travail du minuteur sur la base de termes de taxonomie.

Notions techniques

  • Métadonnées gérées
  • Récepteur d’événements
  • Opérateur KQL « | »
  • Variable de recherche {User.xxx}
  • Source de résultats de recherche
  • Travail du minuteur
  • Propriétés de profils utilisateurs

Module #8 : La recherche


Lien vers l’article complet: Module #8 : La recherche


Objectif

Accès optimisé à l’information du portail.

Besoins couverts

  • [SEARCH_01] Utilisateur : Rechercher du contenu

Résumé

  • La recherche est organisée en « secteurs verticaux » comme les documents, le contenu web et les personnes permettant d’appliquer des requêtes différentes pour chacun.
  • Certaines propriétés sont configurées pour que leur valeur puisse être utilisée via la recherche « plein texte ».
  • L’opérateur XRANK est utilisé pour le classement des résultats.
  • Les affinements sont déterminés automatiquement via la navigation par facettes.

Notions techniques

  • Secteurs verticaux de recherche
  • Source de résultats de recherche
  • Panneau d’affinements de recherche et résultats de recherche
  • Règles de requêtes
  • Types de résultats
  • Navigation par facettes
  • Boîte de recherche

Module #9 : Le design et l’identité visuelle


Lien vers l’article complet: Module #9 : Le design et l’identité visuelle


Objectif

Intégration de l’image de marque de l’entreprise.

Besoins couverts

  • [DSGN_01] Utilisateur : Visualiser l’image de marque de l’entreprise

Résumé

  • Une page maître personnalisée est créée contenant des zones prédéfinies pour l’insertion a posteriori de composants (menus de navigation, etc.) via le mécanisme de « delegate controls».
  • Le Framework Bootstrap est utilisé pour la gestion de l’affichage mobile en mode responsive.
  • Un fichier CSS de correction d’anomaliesentre Bootstrap et SharePoint doit être maintenu.
  • La technologie des modèles d’affichages est majoritairement utilisée pour le rendu des éléments dans l’intranet.
  • Plusieurs libraires tierces sont utilisées pour améliorer l’expérience utilisateur

Notions techniques

  • Page maître
  • « Delegate Controls»
  • Modèles d’affichages
  • Bootstrap
  • js

Rétrospective du projet

Les difficultés rencontrées

Voici les principales difficultés que nous avons rencontrées pour ce type de projet :

  • Le développement quasi nécessaire pour obtenir un résultat satisfaisant

Comme vous avez pu le constater dans les différentes thématiques, l’utilisation de la publication intersites nécessitera parfois d’être « complétée » par des développements personnalisés pour répondre pleinement aux attentes et s’intégrer avec le reste des fonctionnalités format un intranet SharePoint (multilingue, social, etc.). De même, certains concepts impliqués sont très peu documentés dès lors qu’il s’agit de les manipuler par code (variantes, classes de recherche, etc.). Nous avons en quelque sorte appris « à la dure » …

  • Le développement avec les variantes SharePoint

Cette fonctionnalité est définitivement la plus compliquée à manipuler dès lors que le développement devient nécessaire. Heureusement (pour vous), nous sommes passés à travers la plupart de ces difficultés et avons implémenté toutes les commandes/méthodes que vous aurez besoin pour réaliser ce genre de solution. Toutefois, si vous souhaitez partir de zéro, nous vous souhaitons bon courage ;).

  • Le « on boarding » difficile de nouveaux membres dans l’équipe

La solution utilise des concepts parfois complexes de SharePoint. Par conséquent, ajouter quelqu’un à l’équipe nécessitera un temps d’adaptation et de formation non négligeable qui peut avoir un impact sur le projet et ses prévisions. À prévoir donc.

  • L’expérience de création des contenus assez lourde

Le concept fondamental de la solution étant basé sur la recherche, on ne peut s’éviter un temps d’indexation plus ou moins long entre le moment de création du contenu et son affichage sur le site de publication. S’ajoutant à cela le temps d’attente des variantes pour la synchronisation des contenus entre les branches de langues et vous avez réussi à assommer vos contributeurs. Pour nuancer ce point, une formation sera donc OBLIGATOIRE pour les contributeurs pour leur expliquer les concepts clés de la solution et le fonctionnement de la création de contenu. Si toutefois, ce comportement n’est pas acceptable, il est toujours possible de combiner la publication intersites avec l’expérience de création de page classique de SharePoint.

Les bons coups

Voici ce que nous pensons être les bons coups issus de ce type de projet :

  • La préservation des possibilités d’évolution de la solution

L’avantage d’utiliser des concepts OOTB permet une grande flexibilité pour l’évolution de la solution. Ainsi, le client n’est pas pied et poings liés aux développeurs. Quelqu’un avec des connaissances « SharePoint » au sens propre pourra s’en sortir pour effectuer des améliorations mineures portant sur le comportement (source de résultats) ou l’affichage (modèles d’affichages) sans avoir à mettre les mains dans le cambouis. C’est aussi cela le grand avantage de la recherche par rapport au CAML : la possibilité de modifier les comportements très facilement via les assistants de l’outil.

  • L’organisation du backlog de la solution

Un vrai plus pour l’organisation et le découpage de la charge de travail. Le fait de définir plusieurs thématiques et des « User Stories » très granulaires permet de sortir du piège des fonctionnalités qui ne se terminent jamais, car étant trop grosses (un classique avec SharePoint).

  • L’automatisation des déploiements.

Sans une procédure automatique de déploiement des éléments et configuration des paramètres SharePoint sur tous les environnements impliqués, la mise en place de ce genre de projet n’aurait tout simplement pas été possible. C’est donc un prérequis.

  • L’importation des contenus au fur et à mesure du développement (Cf. module #3)

Avec cette technique, nous avons réduit de plusieurs semaines (voire mois) le lancement de l’intranet. Certes, nous utilisons un outil que nous connaissons bien (Sharegate) mais le gain est non négligeable quand on connait la quantité de travail nécessaire après déploiement pour remplir une « coquille vide » d’intranet (sans compter les tests supplémentaires à réaliser). Toutefois, avec la publication intersites, l’importation concerne uniquement des éléments de listes. La même technique avec des pages dans une bibliothèque est faisable, mais est plus compliquée, notamment à cause des limitations de Sharegate et des variantes SharePoint.

 

+ There are no comments

Add yours