Conseils aux entreprises sur SharePoint Framework

Le SharePoint Framework (SPFx) est un nouveau modèle de développement pour l’extensibilité de l’interface utilisateur SharePoint. Il est utilisé par les premiers et les tiers, en complément des options de personnalisation existantes et d’extensibilité telles que le modèle de complément SharePoint. La SharePoint Framework permet une approche structurée et prise en charge pour enrichir et étendre l’interface utilisateur de SharePoint à l’aide d’infrastructures côté client. Basé sur des normes web modernes, il offre un ensemble unique de fonctionnalités pour rendre les personnalisations SharePoint largement disponibles pour les développeurs et les entreprises, tout en s’alignant sur les modèles et modèles précédents dans SharePoint. Sur cette page, nous fournissons aux administrateurs l’arrière-plan, les avantages et les connaissances dont ils ont besoin pour gérer correctement les composants basés sur SharePoint Framework dans leurs environnements SharePoint.

Contexte

Pendant longtemps, SharePoint a servi de plateforme d’application et de développement. Elle proposait de nombreuses options de personnalisation et de développement, notamment des codes de confiance totale à exécuter sur des serveurs SharePoint, des solutions bac à sable (sandbox), des compléments et des personnalisations d’interface réalisées avec des fonctionnalités prêtes à l’emploi ou des codes JavaScript/CSS incorporés.

Dans SharePoint Online multi-clients, les codes de confiance totale n’étaient pas pris en charge et l’utilisation du service de code en mode sandbox était déconseillée. Dans SharePoint Online, les motifs de personnalisation les plus courants utilisaient les compléments, l’exécution de code à distance (code à exécuter depuis un autre emplacement, comme Azure) via les API standard et l’incorporation de code JavaScript. Même si l’incorporation d’un code JavaScript permettait d’étendre SharePoint, il était difficile de conserver cette méthode en raison du modèle persistant de SharePoint Online. SharePoint Framework a pour but de résoudre ces problèmes en offrant un cadre normalisé pour créer des extensions personnalisées de l’interface utilisateur et des applications prises en charge et évolutives, basées sur SharePoint Online.

SharePoint Framework étend l’interface utilisateur SharePoint avec composants WebPart côté client et des extensions .

Composants WebPart côté client

Les composants WebPart côté client s’appuient sur le célèbre modèle des composants WebPart, qui a contribué au succès de SharePoint au fil des années. Ce modèle peut être ajouté dans les pages et personnalisé de façon indépendante par les utilisateurs finals. Ils peuvent être ajoutés aux pages et personnalisés indépendamment par les utilisateurs finaux. Les composants WebPart côté client fonctionnent sur les pages modernes et classiques, ainsi que sur l’application mobile SharePoint.

Remarque

Pour plus d’informations, consultez Vue d’ensemble des composants WebPart côté client SharePoint.

Extensions

Les extensions SPFx permettent aux développeurs d’implémenter certaines personnalisations d’interface utilisateur dans l’expérience « moderne » qui étaient possibles dans l’expérience SharePoint « classique ». Les développeurs peuvent ajouter JavaScript à n’importe quelle page, ajouter des en-têtes et des pieds de page, ajouter des éléments de menu à la liste et aux bibliothèques, et personnaliser l’affichage d’un champ dans une liste.

Modèle de développement et outils

SharePoint Framework est conçu de bout en bout à l’aide d’un TypeScript, JavaScript, HTML et CSS moderne basé sur une pile web. Toutes les parties des artefacts générés sont exécutées dans le navigateur de l'utilisateur final. SharePoint Framework comprend également de nouveaux outils. Ces outils ne dépendent d’aucune plateforme. Ils fonctionnent sur Windows, macOS, Linux, et sont basés sur des technologies open source telles que Node.js, Gulp, Webpack et Yeoman. Ces infrastructures et ces outils sont utilisés au moment de la génération pour simplifier l’expérience de génération, d’empaquetage et de déploiement du développeur. Ils ne sont pas utiles à l’exécution du code SharePoint Framework.

État actuel de SharePoint Framework

SharePoint Framework a été publié sur SharePoint Online en février 2017. La dernière version et toutes les versions précédentes de SharePoint Framework sont hébergées et disponibles dans SharePoint Online.

SharePoint Framework est également disponible pour SharePoint Server 2016 (avec Feature Pack 2) comme version 1.1 et SharePoint Server 2019 comme version 1.4.1.

Côté développeur

Les développeurs SharePoint, qu’ils soient débutants ou chevronnés, ont tous quelque chose à gagner de l’utilisation de l’infrastructure SharePoint. En privilégiant l’extensibilité de l’interface utilisateur, la version actuelle permet au développeur d’étendre, de façon sûre et structurée, les fonctionnalités de l’interface utilisateur SharePoint en utilisant, dès le départ, les composants WebPart côté client. En plus de s’exécuter côté client, les composants peuvent utiliser des données dans SharePoint, Microsoft 365 via Microsoft Graph, voire même avec vos propres API web personnalisées utilisant des méthodes standard OAuth et REST.

Un développeur SharePoint chevronné connaît normalement les composants WebPart et le modèle de données SharePoint. Cependant, les outils de génération, d’empaquetage et de déploiement des composants WebPart côté client sont de nouvelles fonctionnalités. Par conséquent, les développeurs doivent apprendre à utiliser TypeScript, qui est le principal langage de développement utilisé pour créer des artefacts dans l’infrastructure SharePoint. TypeScript offre d’autres avantages que JavaScript, tels que les objets fortement typés, l’héritage des objets, des classes et des interfaces ; des concepts que doivent connaître les développeurs .NET, Java et C/C++ d’aujourd’hui. Concernant la génération et l’empaquetage, Visual Studio n’est plus la seule option des développeurs pour écrire des solutions SharePoint. Grâce à l’utilisation des technologies et des projets open source comme node.js, npm et Gulp, il est désormais possible de développer SharePoint Framework sur une plateforme dotée de l’éditeur de code ou de l’environnement IDE du développeur, tel que Visual Studio Code, Sublime ou même l’application Bloc-notes.

Pour les développeurs qui n’ont jamais créé de solutions SharePoint auparavant, mais qui sont familiarisés avec les technologies web modernes, il n’existe pas de courbe d’apprentissage significative. De nombreux développeurs ont déjà migré vers le développement côté client, ou une combinaison de celui-ci. L’expérience du développement côté client peut être plus dynamique et plus réactive pour les utilisateurs, voire même plus simple pour les développeurs. Grâce à la flexibilité de l’éditeur de code et à l’utilisation de technologies et d’infrastructures open source connues et populaires, de nombreux développeurs qui ne connaissent pas l’écosystème Microsoft peuvent facilement commencer à générer des extensions SharePoint.

Un des motifs les plus communs de l’extensibilité de SharePoint Online est l’utilisation de l’incorporation de code JavaScript (également appelée « injection JavaScript »). Cette méthode consiste, par exemple, à utiliser le composant WebPart Éditeur de script pour insérer dans la page un code JavaScript arbitraire, puis la manipulation du DOM (Document Object Model) du navigateur web pour injecter un script HTML, CSS et JavaScript nécessaire à la génération d’une solution ou d’une application. Cette méthode a beaucoup d’inconvénients et, dans de nombreux cas, empêchait les clients de profiter des nouvelles fonctionnalités de SharePoint Online, car elle dépendait de la façon dont SharePoint concevait la structure HTML et CSS. L’infrastructure SharePoint permet de personnaliser plus efficacement le code JavaScript incorporé. SharePoint Framework utilise TypeScript pour faciliter la transition des codes JavaScript incorporés de façon normalisée et évolutive. L’initiative PnP OfficeDev propose également des exemples de projet et des conseils pour réaliser cette transition.

Mise en perspective de SharePoint Framework dans la plateforme SharePoint

Le nouveau modèle de SharePoint Framework complète les méthodes existantes, tout en accordant plus d’importance aux personnalisations de l’interface utilisateur, telles que les composants WebPart côté client. Cette infrastructure est conçue pour fonctionner en complément des modèles d’utilisation déjà existants et faciliter la création des personnalisations de la nouvelle interface utilisateur de manière prise en charge et durable.

Importante

Le DOM HTML de la page SharePoint n’est pas une API. Vous devez éviter d’extraire des dépendances sur la structure DOM de page ou les styles CSS, lesquels peuvent être modifiés et rompre potentiellement vos solutions. SharePoint Framework fournit une API complète pour personnaliser l’expérience SharePoint de façon fiable, et est le seul moyen pris en charge pour l’interaction avec le DOM HTML de la page SharePoint.

Comparaison avec les compléments

Les Compléments SharePoint, introduits dans SharePoint 2013 en tant qu’applications SharePoint, mais renommés ultérieurement, sont l’une des seules options disponibles pour ajouter des personnalisations à SharePoint Online de manière prise en charge et régie. Néanmoins, les compléments SharePoint requièrent une infrastructure plus grande lorsqu’une personnalisation simple de l’interface utilisateur est nécessaire.

Il existe deux types de compléments SharePoint : les compléments hébergés par SharePoint et les compléments hébergés par un fournisseur. Les compléments hébergés par SharePoint servaient à exécuter le code côté client dans SharePoint de manière prise en charge. Cependant, il est plus difficile d’inclure un seul composant WebPart (JavaScript) côté client. Dans de nombreux cas, les compléments hébergés par SharePoint ont été créés uniquement pour déployer des artefacts, tels que des listes et des composants WebPart, sur un site SharePoint. Ces compléments se trouvent dans un site spécial appelé « site web d’application », qui propose des fonctionnalités limitées.

Les compléments hébergés par un fournisseur s’exécutent à distance à partir de SharePoint (Online) et peuvent utiliser du code côté serveur ou côté client. Cette méthode est utile pour les éditeurs de logiciels indépendants qui souhaitent protéger leur propriété intellectuelle/code/logique, et pour les scénarios qui ne peuvent pas être exécutés côté client avec JavaScript (par exemple, des opérations de longue durée ou nécessitant de lourds calculs, ou l’accès à des données à distance impossibles à collecter à l’aide d’un script côté client).

Le principal avantage des compléments est l’isolement : étant donné que le code réel n’est pas exécuté dans le navigateur du site SharePoint, les protections du script intersites empêchent le complément d’obtenir les mêmes niveaux d’accès que l’utilisateur. Les compléments reçoivent uniquement les autorisations qui leur sont accordées au moment de l’installation. Ainsi, les compléments représentent une option plus sûre quand les administrateurs acquièrent un complément auprès d’un tiers. De plus, cela vous permet de télécharger vos compléments uniquement à partir de Microsoft Store.

SharePoint Framework fonctionne avec les compléments hébergés par SharePoint ou un fournisseur. SPFx peut également être utilisé dans les scénarios qui requièrent uniquement un script côté client. Par exemple, les compléments peuvent ajouter des composants d’application sur le site où ils sont hébergés. Ces composants d’application sont semblables aux composants WebPart, mais au lieu de s’exécuter dans le contexte de la page, ils s’exécutent dans leur propre domaine (site web d’application ou site web hébergé par un fournisseur) dans un iFrame de la page. Ainsi, le complément ne peut pas obtenir le contexte utilisateur à partir du reste de la page.

Par contre, SharePoint Framework ne s’exécute pas dans un iFrame. De cette manière, elle peut s’exécuter de façon plus transparente dans le contexte de la page lorsque l’utilisateur affiche le composant. C’est la solution pour exécuter SharePoint Framework avec des fonctionnalités enrichies. Cependant, elle ne bénéficie pas des mêmes contrôles de sécurité que les compléments. C’est pour cette raison que les solutions SharePoint Framework sont également appelées solutions de confiance totale côté client. Les iFrames rencontrent un réel problème : leur affichage n’est pas dynamique. Par conséquent, la page web ne s’affiche pas de manière aussi fluide que sur un téléphone mobile ou sur un appareil avec un écran d’une autre taille.

Au moment de la rédaction de cet article, les solutions SharePoint Framework peuvent être téléchargées et installées depuis une boutique dédiée, en raison de l’aspect sécuritaire mentionné précédemment. Dans de nombreux scénarios, nous vous recommandons d’utiliser le contexte utilisateur avec SharePoint Framework.

Incorporation de JavaScript au format HTML

L’incorporation du code JavaScript (également appelée « injections JavaScript ») est l’une des méthodes les plus utilisées par les développeurs. Cette méthode consiste à insérer un code JavaScript arbitraire dans les sites et les pages en utilisant, par exemple, des actions personnalisées, des pages maîtres, des mises en page, voire même des composants WebPart Éditeur de script. Il est plus simple d’utiliser cette méthode que de créer des compléments hébergés par SharePoint. De plus, il est possible d’exécuter le code du script dans un contexte utilisateur complet. Il existe néanmoins un inconvénient : un grand nombre de ces incorporations demandent aux développeurs de manipuler le DOM.

De plus, si les développeurs incorporent (même accidentellement) des dépendances sur la structure ou le style des pages SharePoint, les solutions créées en incorporant du code JavaScript peuvent s’interrompre pendant les mises à jour de SharePoint Online en raison de sa nature persistante. Les mises à jour SharePoint, même mineures et discrètes, peuvent avoir un impact considérable sur ces solutions et entraîner l’arrêt total du code JavaScript incorporé.

Désormais, avec SharePoint Framework, il est possible de mettre en place, de façon normalisée et prise en charge, une grande partie des solutions créées via les incorporations du code JavaScript.

Composants WebPart Éditeur de script

Pour insérer des personnalisations arbitraires du code HTML, JavaScript ou CSS dans SharePoint, il est courant d’utiliser les composants WebPart Éditeur de script ou Éditeur de contenu. Les composants WebPart Éditeur de script sont devenus populaires en simplifiant l’ajout de scripts personnalisés sur n’importe quelle page. N’importe quel éditeur de site peut ajouter un composant WebPart Éditeur de script sur la page, y copier-coller un code JavaScript et demander à ce code d’effectuer les personnalisations nécessaires. Comme pour les incorporations du code JavaScript, les administrateurs peuvent avoir des difficultés à contrôler les composants WebPart Éditeur de script.

Dans de nombreux cas, SharePoint Framework peut remplacer les configurations des composants WebPart Éditeur de script.

Contrôle des fonctionnalités d’écriture dans SharePoint Online

Dans SharePoint Online, les administrateurs peuvent contrôler la fonctionnalité d’ajout de scripts personnalisés dans les sites et les pages, pour renforcer la sécurité et l’intégrité du client. Pour cela, ils utilisent la fonctionnalité « Script personnalisé » dans le site de l’administrateur SharePoint Online, ou PowerShell au niveau de chaque site.

Les scripts personnalisés peuvent être désactivés sur tous les sites ou uniquement sur les sites personnels. Par défaut, les nouveaux clients ne disposent pas de droits d’écriture sur les sites personnels, les sites créés en libre-service et la collection de sites racine du client.

Lorsque la fonction de scripts personnalisés est désactivée, les éditeurs de sites ne peuvent pas ajouter de composants WebPart, à l’instar du composant WebPart Éditeur de script. En revanche, les solutions SharePoint Framework sont autorisées, car elles sont jugées fiables une fois qu’elles sont approuvées par un administrateur dans le catalogue d’applications.

Différences concernant la création des solutions SharePoint Framework

SharePoint Framework propose aux développeurs de SharePoint un nouveau modèle qui modifie la façon de concevoir, générer et déployer les personnalisations de SharePoint, en tirant parti des piles web modernes et en privilégiant les personnalisations côté client, basées sur un navigateur.

Ce nouveau modèle révolutionne l’approche de développement de SharePoint.

En utilisant des technologies et des infrastructures telles que TypeScript, Node.js, Yeoman et Gulp, SharePoint Framework attire un public de développeurs non familiarisés avec l’écosystème SharePoint ou Microsoft, tout en encourageant les développeurs SharePoint existants à adopter une approche moderne et normalisée pour générer des personnalisations SharePoint.

Création de solutions

En raison de la nécessité de disposer d'outils spécifiques et ciblés fournis par Visual Studio, le développement SharePoint s'est fait via Visual Studio sur un environnement de développement basé sur Windows avec une instance de SharePoint installée et configurée localement. Cela a limité les préférences matérielles et utilisateur et augmenté les coûts de développement. SharePoint Framework, en revanche, utilise différents outils web open source adaptés à différentes plateformes, telles que macOS et Linux, pour offrir plus de flexibilité de développement.

Les solutions SharePoint Framework sont créées à l’aide d’un outil appelé Yeoman et d’un générateur SharePoint Framework spécifique, basé sur Node.js. Yeoman génère automatiquement les modèles du projet : il crée votre projet, génère les artefacts requis, installe les packages Node.js nécessaires et configure le système de génération.

Une fois le projet généré, il peut être modifié dans un éditeur sur n’importe quel système d’exploitation tel que Visual Studio, Visual Studio Code, Sublime ou Atom. Ainsi, les équipes peuvent travailler selon leurs préférences et leur style. Le générateur Yeoman peut être exécuté plusieurs fois sur le même projet pour ajouter des artefacts supplémentaires, tels que des composants WebPart côté client.

Développement et génération des solutions

Le système de génération est basé sur Gulp. Gulp est un exécuteur de tâche qui génère, met en package et éventuellement déploie les artefacts SharePoint Framework. Comme Yeoman, Gulp est également basé sur Node.js et permet aux développeurs d’utiliser n’importe quel système d’exploitation.

Workbench est un outil dédié à la génération de SharePoint Framework. Cet outil permet au développeur d’héberger et de tester sa solution de l’infrastructure SharePoint. Workbench est un outil dynamique qui recharge automatiquement vos artefacts quand le développeur enregistre un fichier pour afficher et tester rapidement la solution.

Il existe deux versions de Workbench. Il existe une version hébergée localement en dehors de SharePoint sur l’ordinateur de développement qui fonctionne hors connexion, sans accès à SharePoint et sans les données de SharePoint. Cette version permet à l’équipe et aux concepteurs de générer et de concevoir des solutions avec des données fictives ou fausses pour se concentrer sur l’interface utilisateur.

L’autre version de Workbench est hébergée dans SharePoint et sert à tester et à vérifier la solution SharePoint Framework avec les données et le contexte réels de SharePoint.

Importante

Le Workbench local nécessite un navigateur persistant moderne. Le service Workbench local ne prend pas en charge Internet Explorer 11.

Déploiement des solutions SharePoint Framework

Pour déployer des solutions SharePoint Framework, déployez un package de solutions dans le catalogue d’applications et approuvez-le pour l’utiliser dans votre client ou collection de sites.

Pour les solutions déployées sur SharePoint Online, vous pouvez utiliser le CDN hébergé par Microsoft 365 pour stocker et servir les artefacts de la solution qui sont utilisés pour implémenter les composants côté client. Pour plus d’informations, consultez la section CDN public de Microsoft 365.

Pour les solutions déployées sur SharePoint Server, vous devez déterminer où vos artefacts seront stockés. Il s'agit d'une étape de déploiement supplémentaire qui n'est pas requise par SharePoint Online. La seule exigence est que les artefacts soient accessibles par les utilisateurs de votre solution.

Alternatives au CDN SharePoint Online

Les développeurs de la solution SharePoint Framework peuvent choisir d’utiliser n’importe quel service CDN, par exemple Stockage Azure, Microsoft Azure Content Delivery Network ou même SharePoint, en utilisant de préférence les fonctionnalités CDN de SharePoint (voir plus loin). En utilisant un CDN public, c’est-à-dire un service où les composants déployés dans le CDN sont accessibles au public sur Internet, la solution SharePoint Framework est mise à la disposition de plusieurs clients. Dans une solution SharePoint Framework déployée sur un CDN SharePoint, les ressources et les scripts déployés sont uniquement accessibles sur le client où ils sont déployés.

Par défaut, les outils de génération comprennent une tâche pour déployer la solution empaquetée dans le stockage Blob Azure. Cette tâche est généralement étendue, par un intégrateur de système ou un éditeur de logiciels indépendant, aux configurations ou aux emplacements CDN personnalisés.

Après avoir modifié le code et généré la solution, la chaîne d’outils SharePoint Framework produit un nouveau package de solution (*.sppkg) et un ensemble de fichiers de script. Ces fichiers de script incluent un code de hachage unique dans leur nom de fichier, ce qui indique que le contenu de ces fichiers diffère de leurs versions déjà déployées. Pour utiliser une nouvelle version de la solution, déployez le nouveau jeu de scripts sur votre CDN et mettez à jour le package de solution dans le catalogue d’applications. En théorie, vous pouvez remplacer le contenu des fichiers de script existants et éviter la mise à niveau du package de solution, mais cette opération n’est pas fiable et n’est pas recommandée. Selon la configuration de votre CDN, il se peut que les fichiers de script précédemment téléchargés soient mis en cache pendant un certain temps sur les ordinateurs clients, ce qui complique le déploiement de la solution sur les utilisateurs finaux.

L’emplacement du CDN joue un rôle important. L’emplacement qui héberge les composants SharePoint Framework doit disposer d’une disponibilité élevée. C’est pourquoi nous vous recommandons d’utiliser les fournisseurs de CDN approuvés, tels qu’Azure, Akamai ou un fournisseur similaire, et SharePoint lui-même. En matière de sécurité, vous devez savoir quels CDN utilisent les solutions SharePoint Framework déployées. Un CDN dont la sécurité est rompue peut également compromettre la sécurité des solutions SharePoint Framework et, dans le pire des cas, un CDN dont la sécurité est menacée peut également menacer la sécurité des données présentes dans le client SharePoint (Online).

Au moment d’approuver les solutions SharePoint Framework tierces, nous vous recommandons de vérifier l’auteur et le niveau de confiance de l’emplacement du CDN et des tiers susceptibles de les héberger. En effet, une fois l’application installée et utilisée dans des collections de sites SharePoint, ces collections de sites dépendent de l’emplacement du CDN. À ce jour, il n’existe aucune solution simple pour contrôler ce point de terminaison. Le fournisseur tiers du CDN peut effectuer des modifications désirables et indésirables à l’insu de l’utilisateur, exposant ainsi une surface d’attaque, dans la mesure où SharePoint Framework est exécuté dans le contexte utilisateur et peut réaliser les mêmes actions que l’utilisateur.

Nous recommandons aux administrateurs informatiques de suivre les CDN utilisés et approuvés par l’organisation et de communiquer ces informations aux développeurs de l’entreprise.

CDN public Microsoft 365

Le CDN public Microsoft 365, nouvelle fonctionnalité de Microsoft 365 et de SharePoint Online, permet aux administrateurs d’héberger automatiquement des composants statiques, tels que des fichiers JavaScript, des images et des styles CSS, dans un CDN pour obtenir de meilleures performances. Le CDN public Microsoft 365 est une fonctionnalité mise en cache distribuée géographiquement, qui conserve les composants statiques le plus près possible des navigateurs des utilisateurs finals qui en font la demande.

Les administrateurs peuvent activer cette fonctionnalité sur une ou plusieurs bibliothèques de documents, qui serviront d’emplacement source aux composants statiques. Les bibliothèques et le CDN sont administrés à l’aide des cmdlets SharePoint Online PowerShell. Les composants de la bibliothèque de documents seront répliqués dans le CDN Microsoft 365 et seront accessibles via les URL du CDN public Microsoft 365 générées et associées à la bibliothèque de documents. Les modifications apportées aux composants seront reflétées sur les points de terminaison CDN dans un délai de 15 minutes. Toutes les ressources des bibliothèques de documents seront disponibles pour les utilisateurs anonymes, via le point de terminaison CDN.

SharePoint Framework dans l’entreprise

SharePoint est l’une des plateformes de collaboration d’entreprise les plus efficaces. Une des raisons de son succès est l’extensibilité des options et son utilisation en tant que plateforme pour les applications et les intégrations. SharePoint Framework consolide ce succès en offrant une plateforme plus moderne sur laquelle les développeurs pourront générer des personnalisations côté client de façon normalisée et prise en charge.

Développeurs d’entreprise

SharePoint Framework permet aux développeurs d’entreprise (il s’agit généralement de développeurs qui créent des applications pour les entreprises) d’étendre SharePoint (Online) avec de nouvelles fonctionnalités de façon structurée et prise en charge. SharePoint Framework propose une infrastructure de développement, un pipeline de génération et un déploiement réel, et permet aux développeurs de fournir rapidement à toutes les collections de sites des solutions et des fonctionnalités contrôlées par le catalogue d’applications. Dans un scénario d’entreprise, vous avez également un contrôle total des emplacements CDN, qu’ils soient externes ou internes à SharePoint, et vous pouvez déployer facilement les correctifs et les mises à jour dans l’ensemble de votre organisation.

Les administrateurs et les développeurs de votre entreprise doivent créer conjointement un plan d’action pour organiser le déploiement des solutions SharePoint Framework. Ce plan d’action doit contenir des détails sur les infrastructures côté client par défaut, les emplacements CDN, etc.

Pour plus d’informations, consultez la section Création d’une stratégie pour les personnalisations de SharePoint Framework.

Développeurs amateurs

Les développeurs amateurs utilisent depuis longtemps SharePoint pour générer des applications d’entreprise à l’aide de nombreuses méthodes et techniques.

Dans certains scénarios, notamment l’incorporation de codes JavaScript et les composants WebPart Éditeur de script, SharePoint Framework représente une bonne solution : notamment pour obtenir des solutions normalisées et durables. Les développeurs amateurs devront sûrement passer par une phase d’apprentissage pour se familiariser avec cette nouvelle méthode de génération structurée qui, à long terme, s’avérera plus stable, plus sécurisée et plus facile à gérer.

Étant donné que les méthodes de contrôle Script personnalisé mentionnées ci-dessus sont en place, les développeurs amateurs ne pourront pas ajouter du code JavaScript arbitraire ou des composants WebPart Éditeur de script. Même si votre environnement SharePoint risque de devenir plus stable et plus facile à gérer, cela risque de freiner l’innovation dans votre entreprise. Assurez-vous que vos développeurs amateurs et vos développeurs d’entreprise sont d’accord pour continuer d’utiliser SharePoint Framework.

Concepteurs d’expérience utilisateur et développeurs frontaux

Pour les développeurs web ou les concepteurs d’expériences utilisateur/d’interface, les SharePoint Framework seront utiles. Le Workbench permet aux développeurs frontaux d’utiliser une solution SharePoint Framework sur n’importe quel système d’exploitation, avec leurs outils de modification préférés, sans SharePoint, puisqu’ils utilisent des données fictives et qu’ils s’intéressent uniquement à l’expérience utilisateur.

SharePoint Framework est publié parallèlement à Office UI Fabric, qui est l’infrastructure de développement frontal officielle pour Office et Microsoft 365 et permet aux concepteurs d’expérience utilisateur de créer une expérience transparente sur Office, Microsoft 365 et les solutions personnalisées.

Intégrateurs de système

Si des intégrateurs de système ou des sociétés de conseil vous aident à générer vos solutions SharePoint et Microsoft 365, définissez des recommandations, voire même des exigences, sur la méthode à utiliser pour générer les solutions SharePoint Framework pour que votre plan d’entreprise relatif à SharePoint Framework soit bien respecté.

En règle générale, les intégrateurs de système ont leur propre façon de générer leurs solutions, et celle-ci risque d’être incompatible avec votre gouvernance. C’est pourquoi il est important de discuter avec les intégrateurs pour faciliter la collaboration entre toutes les parties.

Imaginons le scénario suivant : les intégrateurs de système viennent de terminer la génération d’une solution pour votre entreprise. Désormais, vous devez vous occuper du maintien, de la mise à niveau et de la mise à jour de la solution. Pour cela, vous devez vous mettre d’accord avec l’intégrateur de système sur la méthode à utiliser pour créer et héberger les solutions SharePoint Framework.

Éditeurs de logiciels indépendants

Les éditeurs de logiciels indépendants sont des entreprises qui créent des solutions tierces destinées à la grande distribution. Il se peut qu’ils ne respectent pas toujours votre plan d’action concernant les solutions SharePoint Framework. Généralement, les éditeur de logiciels indépendants possèdent leur propre code et des droits de propriété intellectuelle, ce qui vous empêche de changer la façon dont ils implémentent et hébergent leurs solutions.

Lorsque vous utilisez des solutions SharePoint Framework provenant de fournisseurs tiers, vous devez vérifier comment ces derniers gèrent les mises à jour et comment leurs solutions sont hébergées. Par exemple : acceptez-vous que votre solution soit mise à jour à votre insu ? Acceptez-vous que les composants statiques soient hébergés sur l’emplacement du CDN de l’éditeur de logiciels indépendant sans votre contrôle ? Quelle est votre relation de confiance avec cet éditeur de logiciels indépendant ?

N’oubliez pas que tous les codes côté client de SharePoint Framework s’exécutent dans le contexte utilisateur en cours. Vous n’avez aucun moyen de restreindre cette action, sauf si vous utilisez des Compléments SharePoint.

Mise au point d’une stratégie pour les personnalisations de SharePoint Framework

Lorsque vous envisagez d’utiliser l’infrastructure SharePoint pour étendre vos instances SharePoint (Online), vous devez mettre au point une stratégie. Pour cela, vous devez commencer par présenter la nouvelle pile technologique utilisée pour créer les solutions de l’infrastructure SharePoint. Les développeurs devront peut-être suivre une formation sur TypeScript (principal langage à utiliser pour écrire le code de SharePoint Framework).

Un autre aspect de SharePoint Framework avec lequel vos développeurs devront se familiariser est la chaîne d’outils dédiés à SharePoint Framework, tels que Node.js, NPM et Gulp. Ils devront également savoir comment vous générez, mettez en package et déployez des solutions à l’aide des tâches Gulp. Pour cela, ils peuvent consulter la documentation officielle de SharePoint Framework ou les référentiels GitHub dédiés à SharePoint.

Les développeurs souhaiteront peut-être s’aligner sur une infrastructure côté client spécifique ou sur des infrastructures différentes. Les frameworks côté client incluent, sans s’y limiter, React, Knockout, Angular, Handlebars, jQuery, etc. La normalisation sur une seule infrastructure présente des avantages, car cela permet aux développeurs de générer davantage de code réutilisable et d’avoir une meilleure cohérence dans la façon dont ils créent et gèrent leurs solutions.

Il existe des avantages à autoriser l’utilisation de plusieurs infrastructures. En effet, chaque infrastructure côté client a des aspects positifs et négatifs, ainsi que des cas d’utilisation. En contrepartie, cela peut fragmenter vos solutions d’entreprise et allonger la durée de chargement des pages, car vous chargez un plus grand nombre de bibliothèques externes.

Le générateur Yeoman pour SharePoint Framework prêt à l’emploi propose des modèles pour deux infrastructures côté client : React et Knockout. À terme, on peut s’attendre à ce que la communauté ajoute d’autres générateurs ou sous-générateurs pour utiliser d’autres infrastructures côté client. Si vous choisissez React comme votre infrastructure côté client par défaut, vous pourrez profiter de l’apparence de personnalisation Office et Microsoft 365 puisque Microsoft a créé une version React d’Office UI Fabric.

Lors de la mise au point de votre stratégie, vous devrez également prévoir la méthode et l’emplacement à utiliser pour déployer les artefacts de votre solution, c’est-à-dire l’emplacement de CDN où vos groupes de script et vos composants seront stockés. Seuls le stockage Blob Azure et Azure CDN prêts à l’emploi sont pris en charge dans les tâches Gulp comprises dans la chaîne d’outils. Cela peut vous être utile si vous devez gérer un abonnement Azure et partager vos ressources entre plusieurs clients. Un autre scénario très courant consiste à utiliser SharePoint Online et sa fonction CDN en tant qu’hôte pour les artefacts. À compter de SharePoint Framework v1.4, les ressources statiques sont incluses par défaut dans le package SharePoint Framework. Lorsque le package est déployé dans le catalogue d’applications, elles sont automatiquement hébergées dans le CDN Microsoft 365 (si activé) ou dans l’URL de catalogue d’applications.

Enfin, les développeurs devront réfléchir à la gestion du cycle de vie des applications (ALM) : la façon dont vous gérez le code source et le contrôle de version, la génération automatique, les tests et le déploiement, etc. Les systèmes de gestion de version de code source les plus courants peuvent être utilisés, tels que Git, GitHub ou Visual Studio Team Systems.

Il n’existe aucun outil par défaut dédié à l’intégration continue. Vous pouvez donc utiliser n’importe quel outil qui prend en charge node.js, comme Visual Studio Team Systems, Travis CI ou Jenkins. À l’aide de ces outils, vous pouvez automatiser le processus de génération et de test. En cas de génération réussie et approuvée, vous pouvez même déployer automatiquement les artefacts dans l’emplacement de CDN pour automatiser toutes les opérations (vérification du code par le développeur, déploiement, production, etc.).

Fonctionnalités de gestion des solutions SharePoint Framework

Toutes les solutions de l’infrastructure SharePoint déployées dans un client doivent être approuvées par un administrateur client. Pour ce faire, chargez le package SharePoint Framework, le fichier *.sppkg, dans la bibliothèque Applications pour SharePoint. Quand une nouvelle solution est ajoutée à la bibliothèque, une boîte de dialogue s’affiche pour demander à l’administrateur s’il accepte d’approuver la solution à utiliser dans le client. La boîte de dialogue explique qu’il s’agit d’un code côté client de confiance totale sans restriction de ressources, qui s’exécute dans le contexte utilisateur. La boîte de dialogue affiche également le domaine d’où proviendra le contenu, c’est-à-dire l’emplacement de CDN des scripts de l’infrastructure SharePoint. Toute application SharePoint Framework peut charger des données à partir d’autres emplacements, après le chargement initial du CDN. Une fois approuvée, la solution SharePoint Framework peut être activée sur une collection de sites.

Un administrateur du catalogue d’applications peut à tout moment supprimer le package du catalogue en supprimant le package de solution de la bibliothèque Applications pour SharePoint. Ainsi, la solution ne pourra pas être utilisée dans les collections de sites. La solution peut également être désactivée en modifiant la propriété Activé du package chargé. Ainsi, la solution sera désactivée dans toutes les collections de sites. De plus, les pages existantes qui utilisent des composants WebPart côté client n’afficheront pas le composant WebPart et l’application ne sera pas disponible sur les collections de sites ou ne pourra pas être ajoutée aux collections de sites existantes. Quand vous supprimerez une solution SharePoint Framework, aucune donnée ou information créée par la véritable solution côté client ne sera supprimée dans SharePoint ou dans n’importe quelle source de données externe utilisée par la solution.

L’administrateur peut également modifier d’autres propriétés du package dans le catalogue d’applications pour améliorer la visibilité de la solution dans les collections de sites. Par exemple, l’icône, la catégorie, la description et le statut proposé peuvent être modifiés.

Si vous devez mettre à jour le package de solution, notamment en cas de modification de nouveaux artefacts de SharePoint Framework ou d’autres modifications effectuées au niveau du package, l’administrateur a uniquement besoin de charger une nouvelle version du package dans la bibliothèque.

Un administrateur client peut également contrôler les solutions SharePoint Framework, comme les Compléments SharePoint. Dans le Centre d’administration SharePoint, sous Applications, l’administrateur SharePoint peut ajouter les solutions SharePoint Framework et vérifier le nombre d’emplacements installés pour une solution donnée, que ce soit pour les compléments SharePoint ou pour les solutions SharePoint Framework.

Pour activer une solution SharePoint Framework sur une collection de sites, l’administrateur de collection de sites doit l’ajouter à la collection de sites. Tout comme pour les compléments SharePoint, il doit sélectionner Ajouter une nouvelle application sur la collection de sites, puis choisir la solution dans la liste des applications. Une fois l’application ajoutée, elle est disponible dans la collection de sites. L’administrateur de collection de sites peut également supprimer SharePoint Framework de la collection de sites. Pour cela, il doit aller dans Contenu du site, puis sélectionner Supprimer sur l’application.

Étendues de déploiement de SharePoint Framework

Quand vous générez des solutions SharePoint Framework, les développeurs peuvent indiquer si leur solution prend en charge le déploiement à l’échelle du client ou si elle doit être déployée sur chaque site séparément. Choisissez la deuxième option quand la solution doit configurer des ressources supplémentaires, telles que des listes, après son déploiement sur un site.

Les développeurs qui génèrent la solution sont ceux qui décident si elle prend en charge le déploiement à l’échelle du client ou non, mais ce sont les administrateurs qui prennent la décision finale concernant le déploiement de la solution. Même si une solution peut être déployée sur tous les sites dans le client, les administrateurs peuvent choisir de la déployer uniquement sur les sites spécifiques. Si la solution ne prend pas en charge le déploiement à l’échelle du client, les administrateurs peuvent la déployer uniquement sur des sites spécifiques.

Importante

Le déploiement à l’échelle du client est disponible uniquement dans SharePoint Online. Si SharePoint est hébergé localement, les solutions SharePoint Framework peuvent être déployées uniquement sur des sites spécifiques.

Le SharePoint Framework n’a pas de magasin, contrairement aux compléments SharePoint. Pour cette raison, tous les déploiements doivent toujours être initiés par l’administrateur client en ajoutant et en approuvant un package de solution au catalogue d’applications.

Sauvegarde et restauration des composants de SharePoint Framework

Les solutions SharePoint Framework ne bénéficient pas de fonctionnalités de sauvegarde et de restauration particulières. La seule chose qui est recommandée d’un point de vue administratif est qu’il peut être judicieux d’avoir une copie de tous les fichiers de package de solution installés (*.sppkg), si un package de solution est supprimé par erreur du catalogue d’applications. Le catalogue d’applications est une bibliothèque SharePoint. Il dispose des mêmes fonctionnalités que n’importe quelle bibliothèque de documents, telles que la gestion des versions principales ou la corbeille.

Vous ne pouvez pas sauvegarder les artefacts de la solution réelle, tels que les groupes de scripts et les composants qui sont hébergés dans un CDN. Si vous contrôlez le CDN ou si le CDN est un site SharePoint, vous pouvez les sauvegarder. Si vous utilisez des solutions de SharePoint Framework tierces, votre organisation ne pourra pas les sauvegarder.

Feuille de route de SharePoint Framework

L’infrastructure SharePoint a atteint la disponibilité générale en février 2017. Cette version permet aux informaticiens et aux développeurs d’utiliser SharePoint Framework en mode production d’une manière prise en charge. De plus, les scénarios où les composants SharePoint Framework sont générés et utilisés doivent inclure des scénarios qui utilisent d’autres éléments que les composants WebPart, et concerner d’autres domaines, tels que la personnalisation des sites et des listes.

Pour plus d’informations sur SharePoint Framework, consultez l’article Feuille de route de SharePoint Framework.

Les principales modifications ou les nouvelles fonctionnalités majeures seront annoncées via le Centre de messages Microsoft 365, situé dans votre administrateur client (les administrateurs Microsoft 365 doivent le consulter tous les jours). Une autre ressource importante est le blog des développeurs Office où vous trouverez davantage d’informations et de mises à jour.

Prise en charge et contrat SLA

Microsoft ne prend pas en charge les solutions personnalisées créées pour SharePoint via les canaux de prise en charge de SharePoint Online standard. Tous les problèmes liés à la création de solutions SharePoint doivent être consignés sur GitHub à l’adresse https://github.com/SharePoint/sp-dev-docs/issues. Le groupe des ingénieurs de SharePoint trie régulièrement des problèmes dans ce référentiel et s’efforce de répondre aux demandes entrantes aussi rapidement que possible.

Si votre organisation dispose d’un contrat Support Premier, c’est ce canal que vous devez utiliser par défaut pour demander une assistance lorsque vous rencontrez des problèmes liés à la création de solutions SharePoint. Les ingénieurs en charge de la remontée d’information de Microsoft géreront vos demandes en fonction de leur urgence.

SharePoint Framework est adapté à la compatibilité descendante. Microsoft garantit que les solutions créées à l’aide de l’une des versions de SharePoint Framework généralement disponibles continueront à fonctionner jusqu’à ce que soit envoyée au préalable une notification de désapprobation explicite pour la version concernée.

Résumé

SharePoint Framework enrichit les outils de personnalisation SharePoint qui permettent aux développeurs d’étendre SharePoint d’une manière prise en charge et contrôlée. SharePoint Framework repose sur des technologies modernes open source et permet aux développeurs d’étendre votre stratégie de développement SharePoint à l’équipe SharePoint, mais aussi à des développeurs plus diversifiés. En fournissant une gouvernance et une prise en charge appropriées de l’infrastructure SharePoint au sein de votre client, vous, administrateurs, offrez à vos développeurs la possibilité de créer des solutions plus attrayantes, de manière rapide et efficace.

Créé pour les développeurs SharePoint et tiers, SharePoint Framework est une valeur sûre pour votre entreprise. Cette infrastructure est de plus en plus utilisée par Microsoft pour produire des fonctionnalités SharePoint avancées. Nous pouvons espérer que de nombreuses mises à jour et nouveautés viendront enrichir l’infrastructure SharePoint au fil des années, afin de combler l’écart existant entre la version classique et la version moderne de SharePoint.