Évolution de l’intranet d’entreprise avec Office 365: quelles approches?

Évolution de l’intranet d’entreprise avec Office 365: quelles approches?


Au fait, c’est quoi un intranet?

Ha, le fameux « intranet »: derrière ce mot se cachent souvent de nombreuses définitions. Bien souvent lorsque l’on parle d’intranet d’entreprise, on s’imagine naturellement la page d’accueil façon « site web » avec les nouvelles de l’entreprise, les liens vers les outils aux employés, etc. Bref du « classique » quoi. Un intranet a en effet, historiquement, une forte connotation « publication de contenu » avant tout mais pas que. Dans certains projets, la partie « collaboration » y est également de mise. Par ce terme, j’entends la partie plus « métier » de l’entreprise et la mise en place de fonctionnalités plus spécialisées comme des flux de travail, sites d’équipes ou autres répondant à des problématiques plus opérationnelles, liées directement à l’activité de l’entreprise.

Comme j’ai pu l’écrire dans mes précédents articles et notamment la série sur la réalisation d’un intranet en SharePoint 2013, les besoins et fonctionnalités de ce genre de solution sont bien souvent les mêmes d’un projet à l’autre (en tout cas pour la partie publication de contenu) et sont, à ce titre, agnostiques de toute technologie sous-jacente. Quant bien quand même nous arrivons à un tournant avec l’arrivée d’Office 365, je vais essayer d’exposer à travers cet article les changements inhérents à cette nouvelle plateforme concernant la manière de gérer ce type de projet par rapport aux approches plus traditionnelles connues avec SharePoint.

Notez que je compare volontairement SharePoint à Office 365 et non SharePoint « On-Premise » à son homologue « Online » car il s’agit ici plus que d’une simple comparaison technico-fonctionnelle mais belle et bien de deux philosophies différentes qu’il est important d’aborder globalement, en tant que mouvance.

Un intranet avec Office 365, quelles différences?

Du point de vue de l’approche…

Commençons tout d’abord par s’intéresser à la philosophie derrière ces deux plateformes:

SharePoint: L'intranet monolithique

Avec SharePoint comme seul outil, l’intranet demeure quelque chose de finalement très monolithique, lobjectif étant de faire rentrer tous vos besoins dans une seule et même plateforme. La raison? tout simplement car vous n’avez pas vraiment le choix!

SharePoint a toujours été un outil à tout faire, pouvant s’accommoder plus ou moins des deux aspects de ce genre de projet (publication et collaboration). Étant donné les coûts élevés de licences, il est donc peu courant qu’une entreprise ait recours à différents services/produits spécialisés pour chacun des ses besoins, d’abord pour des raisons financières évidentes, mais aussi pour respecter une certaine cohérence entre les outils au sein de son organisation. Comme je l’avais déjà expliqué lors de mon premier ouvrage, dans le petit monde Microsoft, le produit est souvent vendu avant même de connaître les « vrais » besoins métiers. Si l’on devait faire l’exercice rigoureusement, le résultat serait bien souvent d’utiliser une multitude de produits ou solutions spécialisées pour chacun des besoins (ou SharePoint serait simplement utilisé pour une sous partie du projet), cependant cette vision demeure assez utopique.

SharePoint est essentiellement un grosse boîte de Lego vous laissant la possibilité de construire à peu près tout ce que vous voulez, pour le meilleur comme le pire (rappelez-vous vos souvenirs de jeunesse ;)). L’outil nécessite des connaissances spécialisées pour pouvoir être exploité pleinement et dispose d’un modèle de développement assez lourd pour des personnes non initiées. Résultat: l’outil n’est bien souvent utilisé qu’a 20% de ses capacités, le modèle de licence n’arrangeant en rien les choses car n’étant pas très granulaire. Enfin, SharePoint est, il faut se le dire, une charge de support conséquente pour Microsoft devant anticiper et maintenir les « trips » de tous ses clients (même si pour cela, ils s’appuient beaucoup sur leurs partenaires).

Avec Office 365, la donne est maintenant différente: un découpage en services/produits ayant chacun un périmètre fonctionnel restreint et bien défini. Dans Office 365, on utilise les choses pour lesquelles elles ont été pensées et seulement pour ça. En d’autres termes, Office 365 est orienté selon des usages communs rencontrés en entreprise via des services dédiés et intégrés entre eux (et cela se traduit même jusque dans les plans de licences!).

 

Office 365: l'intranet des services

Pour vous en convaincre, je pourrais faire le parallèle entre des fonctionnalités de SharePoint et leurs contreparties dans Office 365. Après avoir utilisé un calendrier dans Outlook Online, utiliseriez-vous un calendrier SharePoint pour la gestion de vos événements? De même, préfériez-vous une bibliothèque de médias pour la gestion de vos vidéos ou bien le portail vidéo d’Office 365? etc. Vous l’aurez compris, pour les mêmes usages, SharePoint se contente du strict minimum pour permettre une cohérence avec tout le reste de la plateforme alors qu’Office 365 propose des fonctionnalités pensées pleinement pour eux. Voici une liste non exhaustive de ceux-ci. Attention quelques nuances sont à mettre là dedans, il ne s’agit pas forcément d’une correspondance un pour un!:

Usage commun

Ce qu’Office 365 propose

Ce que l’on aurait fait en SharePoint

Gérer des événements, rappels, échéances

Outlook Online et sa fonctionnalité de calendrier pleinement intégrée avec les courriels

Une liste de type « calendrier » avec intégration bancale avec Outlook

Échanger sur un sujet

Yammer

Une liste de discussion ou un fil d’actualité sur une page

Travailler à plusieurs sur de l’information

La fonctionnalité « Groupes » et toute la suite Office Online (Word, Excel, etc.)

Un site d’équipe configuré comme il se doit

Cependant, cette nouvelle philosophie vient avec son lot de contreparties qu’il est bien important de saisir:

  1. Tous les usages qui étaient faits dans SharePoint n’ont pas systématiquement leur équivalent dans Office 365 et tous ne sont « associables » un pour un entre les deux plateformes. Dans ces cas là, vous aurez soit à créer votre service par vous même, soit utiliser SharePoint (encore), soit attendre qu’ils arrivent un jour dans votre tenant sous la forme de nouvelle applications.
  2. Que vous jouiez selon les règles. Ce que vous offre Office 365, vous devez l’utiliser tel quel (ou presque)Là où SharePoint vous laissait configurer ou bricoler des améliorations pour rendre la fonctionnalité plus proche de vos besoins (de manière plus ou moins simple), Office 365 vous impose ici un cadre d’utilisation très strict, et c’est sûr celui-ci que je vais m’attarder dans la suite de cet article. Si vous faites attention au discours, la notion de « prêt à l’emploi » revient assez fréquemment.
  3. Que vous vous fassiez à l’idée d’intelligence du portail et la relative perte de contrôle sur les métadonnées et la manière dont l’information est affichée. En effet, dans Office 365, les actions comptent maintenant bien plus que les métadonnées sur l’information elle-même. On parle ici bien entendu de Microsoft Graph, l’outil « Delve » constituant son interface principale. Comparé à SharePoint c’est un peu un revirement de situation.

SharePoint, le mouton noir dans l’enclos Office 365…

Dans Office 365, si vous regardez le portail vidéo, « Delve » ou même la plateforme en général, pouvez-vous configurer l’outil de manière poussée? Pas vraiment. Bien souvent, cela se limite aux permissions et quelques options ici et là. Rien à voir avec SharePoint donc.

Comme je l’ai expliqué un peu plus haut dans cet article, l’approche entre les deux outils est radicalement différente. Avec SharePoint, nous disposons d’un outil configurable à souhait nécessitant un investissement conséquent pour bien le maîtriser, même de la part d’un « Power User » (tout le monde n’est pas forcément à l’aise avec les notions de « types de contenus », « colonnes » ou bien « Web Part »). Avec Office 365,  fini la boîte de Lego on l’on peut tout modifier! On utilise maintenant les fonctionnalités telles quelles, les seuls points d’extensions ou configurations étant limités et pensés dans un mode bac à sable. Si pour la partie développement, le problème à été plus ou moins reglé dans SharePoint avec les « Add-Ins », la partie configuration est, elle, toujours présente. Et cela fait un peu tâche dans le paysage car cela ne cadre pas vraiment avec les autres services disponibles.

SharePoint, le mouton noir de la bande

Récemment, un de mes collègues, m’a rappelé une analogie très intéressante concernant SharePoint dans Office 365.

SharePoint, c’est un peu comme le menu « Démarrer » sous Windows, un truc historique qu’il va être très difficile de bouger, les gens y étant trop habitués

Je trouve effectivement l’analogie décrivant bien la réalité actuelle. Rappelez vous de ce qui s’était passé avec ce fameux bouton en bas à gauche de l’interface Windows ;). SharePoint représente tellement un produit emblématique dans l’écosystème Microsoft, que ces derniers ne peuvent tout simplement pas se permettre de le retirer du décor d’un claquement de doigts sous peine de s’attendre à un déferlement de critiques de part et d’autres. Ayant toutefois moins d’impact qu’un produit destiné au grand public, on peut s’imaginer que Microsoft réussira à le faire disparaître progressivement ou du moins à changer significativement sa forme actuelle sous forme d’améliorations ponctuelles dont nous pouvons déjà voir les prémisses.

Extensions et personnalisations

Un intranet n’est jamais vraiment « générique ».  SharePoint ou Office 365 n’arriveront jamais à couvrir totalement les besoins d’une entreprise avec les fonctionnalités « Out-Of-The-Box ». Tantôt, un intranet devra répondre à des normes cosmétiques bien particulières (design, identité visuelle, etc.) qui constituent bien souvent les demandes prioritaires, tantôt il devra s’adapter au métier de l’entreprise (flux de travail, applications, etc.). Par conséquent, il est nécessaire de mettre à disposition des points d’extensions par-ci par-là pour permettre la personnalisation selon le contexte. Je ne vais pas revenir sur les moyens de le faire en SharePoint mais vais plutôt m’attarder sur ceux disponibles avec Office 365. Je classe les possibilités de personnalisations selon plusieurs niveaux en fonctions des attentes. Voici donc, à date, les possibilités que je recense (à vous de me dire si vous en voyez d’autres auxquelles je n’ai pas pensé):

Personnalisations dans Office 365

Le « out of the box »

On commence par le plus simple, je pense que le mot suffit à lui même… 😉

La configuration simple

La plupart des services proposés par Office 365 permettent une configuration « light » (SharePoint restant une exception pour une raison historique). Bien souvent, celles-ci se limitent à la gestion des permissions et à quelques autres préférences fonctionnelles comme sur le portail vidéo, les groupes ou bien même OneDrive. L’administration de la plateforme au complet va également dans ce sens où, par exemple, les possibilités de personnalisations graphiques sont réduites au minimum syndical (un logo, une couleur et c’est pas mal ça).

 L’initiative Pattern & Practices

Étant donné que SharePoint est toujours de la partie, vos options de personnalisations reste (presque) les mêmes que ce que vous pouviez connaître avec la version On-Premise (parce que au final ça reste du SharePoint hein). Cependant, vous disposez d’un allié de poids pour vous aider à les mettre en place: l’initiative Pattern & Practices. Il s’agit d’une suite d’exemples de code et de bonnes pratiques, open source, créés et maintenus par Microsoft et la communauté à travers le monde. À l’intérieur, on y retrouve des librairies, des exemples, des composants réutilisables, etc, pour SharePoint On-Premise et Online. Par exemple, des mécanismes de « templating » de site pour SharePoint ou tout un framework PowerShell (via un module complet) et C# (via un package Nuget) pour la manipulation programmatique de l’outil. L’initiative ne s’arrête pas à SharePoint (même si il reste majoritaire) mais aborde également tous les sujets de développements annexes d’Office 365 (Azure, Graph, Yammer, etc.).

PnP

Tout ça pour dire que cette initiative vient combler un manque de longue date dans SharePoint: la configuration et le provisionning automatique des fonctionnalités. Avant, chaque entreprise devait plus ou moins inventer son propre moteur de provisionning pour rendre ses développements soit plus réutilisables soit, tout simplement les intégrer dans une chaine de production logicielle digne de ce nom. PnP vient maintenant uniformiser les façons de faire en mettant à dispositions des outils et techniques testées et éprouvées. Quand on pense que ces opérations peuvent représenter plus de 50% (c’est du vécu) du coût total de développement d’un projet pour un gain clairement moindre que si vous l’aviez investi dans des développements de fonctionnalités métier, pourquoi s’en priver? La communauté est très active sur ce sujet et il serait dommage de passer à côté!

L’extension de fonctionnalités

Ici on regroupe tous les mécanismes permettant de compléter une fonctionnalité existante à l’intérieur de son cadre d’utilisation.

Les « Add-ins » SharePoint

Apparus déjà depuis un certain temps avec l’arrivée de SharePoint 2013, les « Add-Ins » SharePoint constituent un autre moyen d’aller un peu loin dans la personnalisation. Ici, deux types:

  • Les « SharePoint Hosted Add-Ins »: limités au seul language JavaScript, ils sont principalement utilisés pour la réalisation de petites fonctionnalités et le déploiement d’artefacts (listes, types de contenus ,etc.) dans SharePoint.
  • Les « Provider Hosted Add-Ins »: reprenant le fonctionnement de base du premier type, ils permettent en plus d’exécuter du code depuis un serveur distant, celui-ci pouvant utiliser une technologie quelconque (PHP, C#, etc.). L’interaction avec SharePoint se fait alors via CSOM pour du C# ou bien REST/JSOM pour le reste.

L’intégration dans SharePoint peut se faire de 3 manière différentes:

  • Sous la forme d’une page complète.
  • Sous la forme d’un « App Part » qui n’est ni plus ni moins qu’un Web Part.
  • Sous la forme de « Custom action ».

Dans tous les cas, sachez que le rendu visuel sera affiché à travers un « iframe » rendant de fait, très difficile toute communication avec l’extérieur du composant. Un « Add-In » agit donc de manière isolée mais tout de même intégrée dans le contexte SharePoint (authentification, accès aux éléments du site, etc.). De mon avis personnel, ce mécanisme ne m’a jamais vraiment séduit. Le seul véritable intérêt des SharePoint « Add-Ins » se trouve dans la distribution via un magasin pour répondre à un besoin de « self-service ». Passé cette considération, je vous dirais plutôt de privilégier davantage le modèle de « remote provisionning » proné par PnP ou bien l’implémentation de fonctionnalités en JavaScript directement dans la page, quittes à prendre un « Script Editor Web Part ».

Pour cette dernière technique, je propose d’ailleurs un modèle alternatif via l’utilisation de composants Knokout JS et JSOM SharePoint (en substitution des « delegate controls »). Cette technique est disponible dans PnP via un exemple de menu de navigation.

Les « Office Add-Ins »

Une des plus grande force d’Office 365 et globalement sous estimés pour le moment selon moi, les « Office Add-Ins » sont le parfait complément au métier de l’entreprise. Ils constituent une possibilité d’extension de choix lorsqu’il s’agit de rejoindre au plus près les utilisateurs, c’est à dire lors de la création de l’information. Qu’on se le dise: Word, Excel, Outlook et même PowerPoint consituent de manière générale les principaux outils de production d’information dans les entreprises. Si vous pouviez mettre à disposition des compléments « métier » pour les aider dans leurs tâches au quotidien (comme des points d’entrée pour un flux de travail, des informations complémentaires adaptés au contexte,  des commentaires en temps réel, etc.), c’est bien par ici que vous devriez commencer.

Là encore, plusieurs types sont disponibles:

  • « Task pane »
  • « Content Add-In»
  • « Outlook Add-In»

Office Add-Ins

Je ne vais pas rentrer dans le détail de chacun de ces types mais sachez que la technologie en arrière repose sur du JavaScript/Html et peut donc potentiellement intéragir avec l’ensemble de la plateforme Office 365 à travers les API REST disponibles (comme le Graph par exemple), vous ouvrant pléthore de possibilités.

Les connecteurs de groupes

Apparus très récemment dans Office 365 (25/03/2016), ceux-ci permettent d’intégrer une multitude d’applications directement à l’intérieur d’un groupe. Concrétement, les informations de la dite application sont affichées dans le fil de conversations du groupe. Actuellement, une cinquantaine d’applications est disponible (GitHub, JIRA, Twiter, etc.) Là où cela devient plus intéressant, c’est que vous pouvez envoyer vos propres informations via une application « spéciale » servant simplement de point d’ancrage (via WebHook).

Connecteurs Office 365

N’ayant pas pu trop jouer avec, je vous renvoie donc à l’excellent article de Wictor Wilen sur la manière de créer vos propres connecteurs qui montre comment l’utiliser (et cela semble ridiculement simple d’ailleurs).

Application personnalisée

Étape utlime de la personnalisation mais non des moindres: l’application totalement personnalisée. Ici, plus de limites donc, vous êtes libre d’utiliser la technologie que vous voulez et cela comme bon vous semble (application MVC, console, etc.). Office 365 vous met pour cela à disposition une multitude d’API:

  • Pour SharePoint: CSOM, JSOM ou REST (pas spécifique à SharePoint Online d’ailleurs).
  • Office 365: des API REST pour chacun des services ou maintenant une API unifieé « Office 365 Unified API » plus connue sous le nom de « Graph API » (un seul endpoint pour tous les services). Au passage, on remarque encore une fois SharePoint, le mouton noir, ne fait pas partie de cette API et continue d’avoir la sienne séparée (ce qui n’est pas anodin).

Sachez toutefois qu’avant de jouer avec ces API, il vous faudra maîtriser le concept d’authenfication dans la plateforme (via OAuth notamment).

Interactions entre les services dans Office 365

Un découpage en services distincts ne signifie pas que ceux ci soient nécéssairement isolés, bien au contraire. Office 365 reposant sur un socle commun nommé Azure, le premier niveau d’intégration constitue évidemment l’authentification entre les différents outils. Ensuite, au niveau des données, le « Graph » se charge de compiler les contenus des sources hétérogènes (SharePoint, Yammer, OneDrive, etc.). Enfin, de manière plus ponctuelle, soit des fonctionalités sont explicitement prévues (comme celle le cas pour l’inclusion de vidéos dans un page SharePoint provenant du portail vidéo), soit un mécanisme d’inclusion par « snippet » de code est disponible pour certains outils. Pour cette dernière technique, vous pouvez donc tout à fait enrichir une page SharePoint classique avec un feed Yammer, un document Word ou une présentation Sway.

Le cas « épineux » de la publication de contenu

Comme je l’ai mentionné au début de cet article, la publication de contenus a toujours été la fonctionnalité centrale d’un intranet et encore plus aujourd’hui avec la montée en flèche de la contrainte « mobile ». Cependant, avec Office 365, nous nous trouvons actuellement au beau milieu d’une « zone grise » concernant ce point. Si vous avez suivi mon raisonnement jusqu’à présent, vous comprendrez alors qu’avec Office 365, la publication de contenu devient un usage comme un autre et donc un service comme un autre…Cependant, force est de constater qu’actuellement (au 16/04/2016), SharePoint est le seul outil viable de création de contenu dans Office 365 via sa fonctionnalité de CMS. N’en déplaise à certains, c’est bien la réalité. Sway? trop peu structuré pour répondre aux besoins d’une entreprise en termes de gestion de contenu (navigation, métadonnées etc.). À l’heure où Microsoft nous rabâche sans cesse le fameux « mobile first », il est important de faire un point.

Pour réaliser cette partie, plusieurs options s’offrent donc à vous:

Créer son propre « service » (MVC ou autre)

Utiliser le CMS de SharePoint Online

 Avantages

  • Totale flexibilité technologique, aucune limite dans la personnalisation (mobile, etc.).
  • SharePoint est utilisé en back-end et vous bénéficiez donc de toute sa puissance en terme de gestion de contenus (métadonnées, permissions, taxonomie, etc.). La création des contenus se fait dans des éléments de listes par les contributeurs.

 Inconvénients

  • Effort de développement conséquent nécéssitant un apprentissage non négligeable pour un développeur SharePoint « classique ».
  • Intégration bancale avec le reste de la plateforme pour le moment. À titre d’exemple, la « suite bar » avec les différentes tuiles n’est pas disponible pour les applications personnalisées rendant ainsi l’expérience de navigation moins évidente. Seule la « Chrome bar » est disponible.
  • Réinvention de la roue. Sauf si vous avez l’intention d’en faire un nouveau produit CMS pour Office 365 basé sur SharePoint (ce que des entreprises font déjà au passage http://www.hoozin.fr/), vous risquez fortement de réinventer la roue pour des choses que finalement, SharePoint vous donne déjà et dont le gain à redévelopper est assez faible pour une entreprise. Parmi elles, je pense notamment à:
    • La gestion de la navigation et de son contexte.
    • Le système de pages et de gabarits avec les options de personnalisations qui viennent avec.
    • La gestion des rendus d’images.
  • Un peu overkill pour afficher les nouvelles et le menu de la cantine peut être?

 Avantages

  • Moindres coûts si vous savez réduire votre périmètre fonctionnel en pensant « service » et en regardant les autres outils de la plateforme autour. Par exemple, réduire la portée à la simple création et au parcous de contenu web (nouvelles et pages) semble être le minimum viable.
  • Beaucoup d’exemples et d’outils disponibles testés et éprouvés par la communauté (PnP, Office UI Fabric, etc.)
  • Possiblité même de le faire en ShrePoint On-Premise dans un scénario hybride!

 Inconvénients

  • Modification de la page maître déconseillée. Sur ce point, je tiens juste à nuancer car ce que nous dit Microsoft, c’est de ne pas modifier la page maître sur un site SharePoint sous peine de ne pas profiter des potentielles améliorations. Cependant, lorsque vous réalisez un intranet, vous ne souhaitez justement pas que l’interface fasse trop « SharePoint » et donc le fait de modifier la page maître de manière « légère » (par exemple juste pour y insérer la structure HTML permettant l’affichage mobile des pages) ne me paraît pas être une aberration en soit, au contraire. En revanche, cette assertion est totalement vraie pour les sites d’équipes ou autre qui n’ont effectivement aucun intérêt à être modifié.
  • Connaissances spécialisées requises (car cela reste du SharePoint tout de même).
  • Moins de flexibilité (mobile ,etc.) tout dépendamment de ce que vous souhaitez faire.
  • Coûts élevés si vous répliquez le modèle monolithique de SharePoint (c’est à dire continuer à tout mettre dans le même bloc).

Pour ce qui est du choix de la solution, vous avez surêment compris de quel côté je me range ;). Je ne vois en effet aucun intérêt de redévelopper des éléments qui forment la base d’une solution de publication (et qui donc n’apporte aucune valeur intrinsèque à un client) pour la simple contrainte « mobile ». Une application personnalisée prend bien plus son sens pour répondre à un usage « métier » dans l’entreprise. À moins d’en faire un produit, le jeu n’en vaut, à mon avis, pas la chandelle et SharePoint peut très bien s’acquitter de cette tâche, pour le moment.

Quelques conseils

Avant de partir tête baissée dans un projet d’intranet avec Office 365, voici quelques conseils:

  • Si du développement est nécessaire, pensez avant tout « services » et « usages ».
  • Identifiez, découpez et limitez le périmètre de chacune de vos fonctionnalités pour les rendre plus facile à implémenter et à intégrer (et ne pas retomber ainsi dans le modèle monolithique de SharePoint).
  • Avec SharePoint Online, évitez les variantes ou de manière générale, tout ce qui dépend d’un travail du minuteur. En effet, vous n’avez plus le contrôle sur l’éxécution de ceux-ci (au même titre que la recherche).
  • N’allez jamais « all in » dans un outil ou une API particulière. Vous n’avez plus le contrôle également des mises à jour. Pour anticiper les futurs changements à venir, n’hésitez pas à vous en référer à la roadmap Office 365.
  • Ne cédez pas aux « trips» technologiques et revenez en toujours aux besoins. Office 365 n’est pas une « nouvelle technologie » en soit, mais bel et bien un produit final qui répond déjà à un certain nombre de besoins par défaut qu’il est important de comprendre avant toute chose.
  • Rappellez vous que vous réalisez un intranet d’entreprise, restez modéré dans vos attentes et privilégiez l’efficacité avant tout. J’ai déjà mentionné ce point dans un article précédent.

L’avenir?

Étant donné la situation actuelle concernant les solutions de publication de contenu pour un intranet dans Office 365, il paraît clair que Microsoft se doit de combler ce manque d’une manière ou d’une autre tout simplement car la différence de philosophie entre SharePoint et les autres services/outils va devenir trop importante au fil du temps. Lors de la conférence Ignite de 2015, la firme de Redmond a d’ailleurs déjà esquissé les prémisses d’une nouvelle solution lors de présentations autour des « Next-Gen Portals » sous la forme des services « InfoPedia » et « Knowledge Management Portal »:

L'avenir?

Le chantier des « Next-Gen Portals » est déjà en marche, le portail vidéo et « Delve faisant partie de ses premières composantes. Pour le reste, il faudra certainement attendre encore un peu car disposant pour le moment, de solutions de subsitution, on peut comprendre que la priorité ne soit pas mise sur ces problématiques dans l’immédiat. Ce que l’on sait en revanche, c’est que la ou les prochaines solutions seront très problablement implémentées directement sur SharePoint comme c’est le cas avec le portail vidéo et Delve. La raison est assez simple: Microsoft n’allait pas repartir de zéro pour des fonctionnalités comme la gestion de contenus ou bien même la gestion des permissions.

Finalement, c’est peut être ça, l’avenir de SharePoint: on garde le coeur et on repense toute l’expérience pour s’adapter au reste de la plateforme.

La forme maintenant…

Microsoft insistant beaucoup sur la mobilité et la simplicité, on peut se douter que les prochains outils de gestion de contenu iront clairement dans ce sens en plus de s’intégrer avec le reste. En ce qui concerne l’expérience de création, nous pouvons déjà imaginer ce qu’elle pourrait être. Il suffit de regarder du côté de Sway, ou mieux, du côté de la fonctionnalité de blog de « Delve » pour s’en convaincre:

Blog Delve

Si les équipes de Sway et Delve se parlent (ce qui ne semble pas être le cas si l’on compare les deux canvas), on pourrait alors se retrouver avec un mélange entre les deux, ce qui serait une très bonne chose. Une chose est sûre cependant, le prochain « canvas » ne devra pas trop limiter les utilisateurs dans leurs possibilités notamment dans le fait de pouvoir gérer la navigation, les différents gabarits de pages et la possibilité d’y inclure des composants spécifiques. Pour ce qui est des développeurs, la possiblité de pouvoir créer ses propres « Widgets » semble elle aussi, un incontournable.

Et vous, vous en pensez quoi de l’intranet dans Office 365? Allez-vous attendre une éventuelle solution de la part de Microsoft? Développer votre propre application ou continuer à utiliser SharePoint?

+ There are no comments

Add yours