Déployer des fonctionnalités personnalisées vers des collections de sites mises à niveau dans SharePoint Server 2013

S’APPLIQUE À :oui-img-132013 no-img-162016 no-img-192019 no-img-seÉdition d’abonnement no-img-sopSharePoint dans Microsoft 365

Cet article explique comment déployer des fonctions personnalisées par le biais de packages de solution vers une batterie SharePoint Server 2013 mise à niveau depuis SharePoint Server 2010. Il comporte des informations et procédures liées aux scénarios pris en charge. Il présente également le masquage de fonction.

Choses à savoir

Cette section décrit les informations préalables que vous devez connaître avant de commencer. Cela comprend les éléments suivants :

Qui doit lire cet article et pour quelle raison

Cet article est destiné aux professionnels devant travailler avec les développeurs afin de déployer et de mettre à jour des fonctions personnalisées basées sur un code de confiance totale dans plusieurs collections de sites sur une batterie SharePoint Server 2013. Pour savoir comment utiliser les fonctionnalités personnalisées héritées lors de la mise à niveau vers SharePoint 2013, et ce qu’il faut faire pour vous assurer qu’elles fonctionnent en toute transparence pour vos utilisateurs lorsque les collections de sites sont mises à niveau à partir du mode de compatibilité, consultez cet article. Cet article est relié à des articles supplémentaires fournissant davantage de détails à vos développeurs.

Après la mise à niveau d'une batterie SharePoint Server 2010 vers SharePoint Server 2013, toutes les collections de sites fonctionnent en mode de compatibilité SharePoint 2010. Elles restent dans ce mode jusqu'à ce que chaque collection de sites soit mise à niveau vers le mode SharePoint 2013. Ainsi, les utilisateurs peuvent utiliser l'interface utilisateur SharePoint Server 2010 et les fonctionnalités qu'ils connaissent jusqu'à la mise à niveau de la collection de sites particulière. Vous pouvez également utiliser les fonctions personnalisées héritées que vous pouvez avoir utilisées dans SharePoint Server 2010. Vous souhaiterez peut-être mettre à niveau vos collections de sites vers le mode SharePoint 2013 pour bénéficier des nouvelles fonctionnalités qu'offre ce mode. Lorsque vous effectuez cette mise à niveau, des fonctions personnalisées qui fonctionnaient en mode de compatibilité SharePoint 2010 risquent de ne plus fonctionner. Vous devez vous assurer de la continuité entre les modes SharePoint avec les mêmes fonctions utilisées. Cet article décrit comment procéder.

Applets de commande Microsoft PowerShell avec lesquelles vous devez vous familiariser

Pour les besoins de cet article, vous devez connaître les cmdlets Microsoft PowerShell suivantes :

Nom Quelle est l'action effectuée ? Exemple
Add-SPSolution
Ajoute la solution au magasin de solutions de la batterie.
Add-SPSolution -LiteralPath c:\contoso_solution.wsp
Install-SPSolution
Déploie une solution qui a été ajoutée au magasin de solutions de la batterie.
Install-SPSolution -Identity contoso_solution.wsp -GACDeployment -CompatibilityLevel 15
Uninstall-SPSolution
Retire une solution déployée.
Uninstall-SPSolution -Identity contoso_solution.wsp
Remove-SPSolution
Supprime une solution déployée.
Remove-SPSolution -Identity contoso_solution.wsp

Remarque

Pour plus d’informations sur l’utilisation de PowerShell et sur les autorisations minimales requises pour exécuter une applet de commande PowerShell pour SharePoint, voir Utiliser Windows PowerShell pour administrer SharePoint 2013.

Vue d’ensemble du déploiement d’un package de solution

Pour comprendre les sections suivantes, vous devez savoir comment une fonction personnalisée est déployée sur une batterie SharePoint 2013.

Lorsque vous mettez à niveau depuis SharePoint Server 2010 vers une batterie SharePoint 2013, l’ajout de vos fonctionnalités personnalisées est une étape importante.

Figure : Ajout des fonctionnalités personnalisées dans le processus de mise à niveau

Ajout de fonctionnalités personnalisées dans des phases de mise à niveau

Vous pouvez utiliser un package de solution pour ajouter vos personnalisations à la nouvelle batterie. Un package de solution est un package de distribution qui fournit votre travail de développement SharePoint 2013 personnalisé aux serveurs web ou aux serveurs d’applications de votre batterie de serveurs. Vous pouvez utiliser des solutions pour mettre en package et déployer des fonctionnalités personnalisées, des modèles de sites, des modèles web, des pages de présentation, des composants WebPart, des feuilles de style en cascade et des travaux de minuteur.

Pour déployer un package de solution vers une batterie SharePoint 2013, vous devez :

  1. Ajouter le package de solution à la batterie . Utilisez l’applet de commande PowerShell Add-SPSolution pour charger le package de solution SharePoint dans la batterie de serveurs. Vous ajoutez ainsi la solution au magasin de solutions de la batterie, situé dans la base de données de configuration de la batterie.

  2. Déployer le package de solution sur la batterie. Utilisez l’applet de commande PowerShell Install-SPSolution pour déployer le package de solution SharePoint dans la batterie de serveurs. Vous décompressez ainsi le paquet de solution et copiez tous les fichiers contenant une fonction personnalisée dans un répertoire « Fonction » situé sur le serveur web frontal de la batterie. Un sous-dossier est créé pour chaque fonction personnalisée et il comprend un fichier Feature.xml. Ce fichier définit les propriétés de base de la fonction et les éléments liés, ainsi qu'un ou plusieurs fichiers de manifeste de l'élément (elements.xml) qui définissent les éléments composant la fonction.

Remarque

Pour plus d’informations sur le mode de déploiement d’un package de solution sur une batterie SharePoint 2013, reportez-vous à l’article Installer et gérer des solutions pour SharePoint Server.

L’applet de commande PowerShell Install-SPSolution inclut également un paramètre de niveau de compatibilité pour déployer le package de solution sur des emplacements du dossier racine désignés pour les collections de sites en mode SharePoint 2010 ou En mode SharePoint 2013. Il s'agit des dossiers racines « 14 » et « 15 » (ruches) et, lorsque vous déployez la solution, des fichiers tels que des fonctionnalités, des fichiers de mise en pages, des images et des modèles de contrôles, sont ajoutés ici.

Figure : Dossiers racines de SharePoint 2010 et 2013

Dossiers racine SharePoint 2010 et 2013

Vous devez également savoir que lorsque vous déployez un package de solution sur une batterie de serveurs SharePoint 2013, certains fichiers sont copiés vers des emplacements spécifiques, quel que soit le niveau de compatibilité. Pour plus d'informations sur les emplacements où sont copiés les fichiers, voir le blog détaillant la planification du déploiement de solutions de batteries pour SharePoint 2013.

Quel que soit le mode dans la batterie, les collections de sites pointent vers la ruche correspondante, pour qu’elles puissent utiliser les fonctions personnalisées fournies dans le package de solution.

Figure : Déploiement des fonctionnalités personnalisées héritées après la mise à niveau vers SharePoint Server 2013

Déployer les fonctionnalités personnalisées héritées

La fonction personnalisée peut avoir été testée pour savoir si elle fonctionne correctement en mode SharePoint 2010 et SharePoint 2013. Si c'est le cas, les fichiers d'assemblage de fonctions peuvent être identiques. Par exemple, si la fonction personnalisée Feature1 est connue pour fonctionner en mode SharePoint 2013 et SharePoint 2010, le même package de solution peut être utilisé pour déployer la même fonction personnalisée (Feature1) dans les dossiers « 14 » et « 15 ».

Toutefois, si le test montre que la fonction personnalisé héritée risque de ne pas fonctionner dans les collections de sites en mode SharePoint 2013, vous devrez peut-être apporter les modifications suivantes :

  • Mettre à jour le package de solution pour inclure une logique conditionnelle qui active la fonctionnalité basée sur le mode de collection de sites SharePoint.

  • Créer un package de solution distinct, avec la fonctionnalité mise à jour pour la fonction en cas d’utilisation par des collections de sites mises à niveau.

Le masquage de fonction consiste à utiliser un nouveau package de solution distinct pour la même fonction pour les sites et les collections de sites mis à niveau (quand une fonction est limitée à un site ou à une collection de sites). Le masquage de fonction permet aux collections de sites mises à niveau de trouver et d'utiliser automatiquement les assemblages corrects de fonctions personnalisées. Ainsi, les utilisateurs peuvent utiliser la même fonction personnalisée de façon transparente.

Fonctionnalités personnalisées héritées sur une batterie SharePoint Server 2013

Lorsque vous utilisez des fonctions personnalisées héritées sur une batterie SharePoint 2013, vous risquez de vous retrouver dans l’une des trois situations suivantes :

  • La fonction personnalisée fournie par le package de solution fonctionne actuellement pour les collections de sites en mode SharePoint 2010. Elle fonctionne également pour les collections de sites en mode SharePoint 2013.

  • La fonction personnalisée fournie par le package de solution fonctionne actuellement pour les collections de sites en mode SharePoint 2010. Elle fonctionne également pour les collections de sites en mode SharePoint 2013. Vous devez également tenir compte des fonctionnalités supplémentaires de la fonction personnalisée que vous souhaiterez peut-être ajouter de manière incrémentielle à l'avenir aux collections de sites en mode SharePoint 2013.

  • La fonction personnalisée fournie par le package de solution fonctionne actuellement pour les collections de sites en mode SharePoint 2010. Toutefois, elle ne fonctionne pas pour les collections de sites en mode SharePoint 2013.

Scénarios pris en charge

Lorsque vous déployez des fonctions personnalisées sur une batterie SharePoint 2013 mise à niveau depuis SharePoint Server 2010, trois scénarios différents de déploiement sont pris en charge :

   
Scénario 1
Solution héritée pour le mode de compatibilité SharePoint 2010, avec maintien des mêmes fonctionnalités lors de la mise à niveau vers le mode SharePoint 2013.
Scénario 2
Solution héritée pour le mode de compatibilité SharePoint 2010, avec régénération de la solution pour l'ajout incrémentiel de fonctionnalités pour le mode SharePoint 2013.
Scénario 3
Solution héritée pour le mode de compatibilité SharePoint 2010 et génération d’une nouvelle solution pour l’implémentation de nouvelles fonctionnalités pour SharePoint 2013.

Remarque

Pour plus d'informations sur les emplacements où sont installés les fichiers de packages de solution dans la batterie en fonction du niveau de compatibilité, voir le blog TechNet détaillant la planification du déploiement de solutions de batteries pour SharePoint 2013.

Scénario 1 : solution héritée pour le mode de compatibilité SharePoint 2010, avec maintien des mêmes fonctionnalités lors de la mise à niveau vers le mode SharePoint 2013

Dans ce scénario, la fonction personnalisée fournie par le package de solution fonctionne actuellement correctement dans les collections de sites en mode de compatibilité SharePoint 2010. De plus, elle est censée fonctionner lorsque la collection de sites est mise à niveau vers le mode SharePoint 2013. Par exemple, un composant WebPart personnalisé a été créé pour SharePoint 2010. Il a été testé pour fonctionner dans SharePoint 2013 sans modification du code. Vous savez que vous pouvez l’ajouter à votre batterie de serveurs SharePoint 2013 et qu’il fonctionne pour les utilisateurs des collections de sites en mode de compatibilité SharePoint 2010 et lorsque vous mettez à niveau le site vers SharePoint 2013.

Comme la fonction personnalisée est censée fonctionner dans les deux modes SharePoint, vous pouvez utiliser les mêmes ensembles de fonctions personnalisées. Toutefois, il est important de déployer le package de solution pour les deux modes SharePoint, ce que vous pouvez faire à l'aide d'un paramètre lorsque vous utilisez l'applet de commande Install-SPSolution. Le masquage de fonction n'est pas utilisé dans ce scénario car les collections de sites dans les deux modes utilisent le même code (duplication des ensembles de fonctions situés dans les dossiers correspondants des modes 2010 et 2013).

Les étapes de ce scénario sont les suivantes :

  1. Créez le package de solution contenant la fonction personnalisée.

  2. Ajoutez le package de solution à la batterie. Pour ce faire, vous pouvez utiliser l’applet de commande PowerShell Add-SPSolution . Par exemple :

    Add-SPSolution -LiteralPath c:\Solution.wsp

  3. Déployez le package de solution.

  4. Déployez le package de solution pour la compatibilité SharePoint 2010. Pour ce faire, utilisez l’applet de commande PowerShell Install-SPSolution . Assurez-vous que vous définissez le paramètre -CompatibilityLevel sur 14. Par exemple :

    Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14 -GAC ...

  5. Déployez le package de solution pour la compatibilité SharePoint 2013. Pour ce faire, utilisez l’applet de commande PowerShell Install-SPSolution . Veillez à définir le paramètre -CompatibilityLevel sur 15. Par exemple :

    Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 15 -GAC ...

Remarque

Le paramètre -CompatibilityLevel dans l'applet de commande Install-SPSolution de Windows PowerShell vous permet également d'installer un package de solution dans les répertoires racine 14 et 15 en même temps. Vous pouvez le faire en utilisant les valeurs « 14,15 » ou « All ». Par exemple : >Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14, 15 -GAC ...> pour plus d’informations sur le paramètre CompatibilityLevel dans l’applet de commande Install-SPSolution Windows PowerShell, consultez Install-SPSolution .

La fonctionnalité personnalisée héritée fonctionne dans les deux modes

Remarque

Lorsque vous utilisez la commande Install-SPSolution pour installer les deux modes SharePoint, utilisez les mêmes nom et ID de solution.

Scénario 2 : solution héritée pour le mode de compatibilité SharePoint 2010, avec régénération de la solution pour l’ajout incrémentiel de fonctionnalités pour SharePoint 2013

Dans ce scénario, la fonction personnalisée fonctionne correctement dans SharePoint Server 2010. Vous souhaitez créer un package de solution en ajoutant cette fonctionnalité à une batterie de serveurs SharePoint 2013, mais vous souhaitez également vous assurer que vous pouvez ajouter de manière incrémentielle des fonctionnalités pour les collections de sites en mode SharePoint 2013 qui utilisent ce package de solution. Par exemple, un composant WebPart personnalisé a été créé pour SharePoint 2010. Il a été testé pour fonctionner dans SharePoint 2013 sans modification du code. Toutefois, vous savez que vous souhaiterez peut-être ajouter des fonctionnalités supplémentaires pour vos utilisateurs SharePoint 2013, mais vous souhaitez continuer à utiliser les mêmes ensembles de fonctions pour permettre la compatibilité descendante.

Comme la fonction personnalisée est censée fonctionner dans les deux modes SharePoint, vous pouvez utiliser les mêmes ensembles de fonctions personnalisées. Vous devez installer le package de solution pour les deux modes SharePoint, comme vous l’avez fait dans le scénario précédent. La différence clé de ce scénario réside dans le fait que le package de solution doit inclure une logique qui active la fonctionnalité de la fonction de manière conditionnelle par rapport à la compatibilité de la collection de sites.

Par exemple, disons que vous avez une méthode nommée Sample() mise en œuvre dans une fonction personnalisée conçue pour SharePoint 2010. Si vous souhaitez modifier sa mise en œuvre en mode SharePoint 2013, votre code doit inclure une logique conditionnelle qui utilise la propriété SPSite.CompatibilityLevel :

void Sample()
{
if (site.CompatibilityLevel == 14) { /*Existing O14 implementation*/}
else {/*New O15 implementation*/}}
}

Ainsi, le même ensemble de fonctions sert aux deux versions SharePoint 2010 et SharePoint 2013 de la fonction. Le masquage de fonction n'est pas utilisé dans ce scénario parce que vous utilisez le même ensemble de fonctions, mais également le même package de solution. Les mêmes fichiers pour la fonction personnalisée sont copiés dans les répertoires \Template\Features « 14 » et « 15 ». Pour plus d'informations, voir la section relative aux considérations de planification du blog TechNet, qui détaille la planification du déploiement de solutions de batteries pour SharePoint 2013 .

Les étapes de ce scénario sont les suivantes :

  1. Créez le package de solution contenant la fonction personnalisée. Incluez une logique conditionnelle qui active la fonctionnalité de la fonction basée sur la compatibilité de la collection de sites.

  2. Ajoutez le package de solution à la batterie. Pour ce faire, utilisez l’applet de commande PowerShell Add-SPSolution . Par exemple :

    Add-SPSolution -LiteralPath c:\Solution.wsp

  3. Déployez le package de solution.

  4. Déployez le package de solution pour la compatibilité SharePoint 2010. Pour ce faire, utilisez l’applet de commande PowerShell Install-SPSolution . Assurez-vous que vous définissez le paramètre -CompatibilityLevel sur 14. Par exemple :

    Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14 -GAC ...

  5. Installez le package de solution pour la compatibilité SharePoint 2013. Pour ce faire, utilisez l’applet de commande PowerShell Install-SPSolution . Veillez à définir le paramètre -CompatibilityLevel sur 15. Par exemple :

    Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 15 -GAC ...

Remarque

Le paramètre CompatibilityLevel dans l’applet de commande Install-SPSolution de Microsoft PowerShell vous permet également d’installer un package de solution dans les répertoires racine 14 et 15 en même temps. Vous pouvez le faire en utilisant les valeurs « 14,15 » ou « All ». Par exemple : >Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14, 15 -GAC ...> pour plus d’informations sur le paramètre -CompatibilityLevel dans l’applet de commande Microsoft PowerShell Install-SPSolution , consultez Install-SPSolution .

La fonctionnalité personnalisée héritée nécessite une logique conditionnelle

Remarque

Lorsque vous utilisez la commande Install-SPSolution pour installer les deux modes SharePoint, utilisez les mêmes nom et ID de solution.

Scénario 3 : solution héritée pour le mode de compatibilité SharePoint 2010 et génération d’une nouvelle solution pour l’implémentation de nouvelles fonctionnalités pour SharePoint Server 2013

Dans ce scénario, la fonctionnalité personnalisée est connue pour fonctionner correctement dans SharePoint Server 2010, mais elle n’est pas connue pour fonctionner dans SharePoint 2013. Vous devez créer un package de solution nouveau et distinct dans lequel les fonctionnalités de la fonctionnalité personnalisée ont été corrigées pour fonctionner correctement dans SharePoint 2013. Dans ce scénario, vous avez deux packages de solution différents avec des ensembles de fonctions différentes. Ce scénario utilise le masquage de fonction. Comme les utilisateurs sont passés du mode de compatibilité à SharePoint 2013, ils sont « masqués » car la fonction personnalisée qu'ils utilisent est passée d'une base de code à une autre.

Dans ce scénario, vous devez ajouter et déployer deux packages de solution distincts, qui contiennent deux ensembles de fonctions différents. Les deux versions de la fonction doivent avoir le même nom, le même ID de fonction et le même emplacement de manifeste de fonctions, même si les ensembles et ressources de fonctions sont différents.

Exigences du masquage de fonction

Configuration requise Identiques ou différents Package de solution - exemple du mode 2010 Package de solution - exemple du mode 2013
Noms de package de solution
Différents
POC14
POC15
ID de package de solution
Différents
000000-0000-0000-0000-000000000000
11111111-1111-1111-1111-111111111111
Nom de la fonction
Identique
Feature1
Feature1
ID de la fonction
Identique
12345
12345
Noms de dossier de fonction XML
Identique
POC15\Features\Feature1.feature\
POC15\Features\Feature1.feature\
Emplacement du manifeste de fonction
Identique
POC15_Feature1\Feature1.Template.xml
POC15_Feature1\Feature1.Template.xml

Figure : Packages de solution pour le masquage de fonction

Packages de solution pour masquage de fonctionnalité

Les étapes de ce scénario sont les suivantes :

  1. Créez deux packages de solution différents avec des noms distincts. Les versions de la fonction que vous déployez doivent avoir les mêmes nom et ID de fonction.

  2. Ajoutez le package de solution pour la compatibilité SharePoint 2010 à la batterie. Pour ce faire, vous pouvez utiliser l’applet de commande PowerShell Add-SPSolution . Par exemple :

    Add-SPSolution -LiteralPath c:\POC14.wsp

  3. Ajoutez le package de solution pour la compatibilité SharePoint 2013 à la batterie. Vous pouvez également le faire via l’applet de commande PowerShell Add-SPSolution . Par exemple :

    Add-SPSolution -LiteralPath c:\POC15.wsp

  4. Déployez le package de solution pour la compatibilité SharePoint 2010. Pour ce faire, utilisez l’applet de commande PowerShell Install-SPSolution . Assurez-vous que vous définissez le paramètre -CompatibilityLevel sur 14. Par exemple :

    Install-SPSolution -Identity POC14.wsp -CompatibilityLevel 14 -GAC ...

  5. Installez le package de solution pour la compatibilité SharePoint 2013. Vous pouvez également le faire via l’applet de commande PowerShell Install-SPSolution . Veillez à définir le paramètre -CompatibilityLevel sur 15. Par exemple :

    Install-SPSolution -Identity POC15.wsp -CompatibilityLevel 15 -GAC ...

Masquage de fonctionnalité pour déployer une fonctionnalité personnalisée

Désinstallation d’un package de solution

Vous n’aurez plus besoin du package de solution hérité que vous avez déployé pour les collections de sites en mode compatibilité SharePoint 2010 après que toutes les collections de sites ont été mises à jour en mode SharePoint 2013. Lorsque cela se produit, le package de solution hérité peut être retiré et supprimé de votre batterie SharePoint Server 2013. Vous pouvez le faire grâce aux applets de commande Uninstall-SPSolution et Remove-SPSolution PowerShell.

Importante

Nous vous recommandons d’utiliser l’applet de commande Uninstall-SPSolution de PowerShell lors du retrait d’une solution d’une batterie SharePoint Server 2013. Le retrait d’une solution à l’aide de l’Administration centrale retire la solution des dossiers racines de SharePoint 2010 et de SharePoint 2013 par défaut. Il est particulièrement important de noter ce phénomène lorsque vous utilisez le masquage de fonction pour déployer une fonction personnalisée.

Pour retirer et supprimer le package de solution :

  1. Retirez le package de solution en mode SharePoint 2010 de la batterie : vous pouvez le faire à l'aide de l'applet de commande Uninstall-SPSolution de Windows PowerShell. Par exemple :

    Uninstall-SPSolution -Identity POC14.wsp -CompatibilityLevel 14

    Importante

    Veillez à utiliser le paramètre CompatibilityLevel sur « 14 » pour retirer le package de solution pour le mode de compatibilité 2010 uniquement. Par exemple : Uninstall-SPSolution POC14.wsp -CompatibilityLevel 14

  2. Supprimez le package de solution du magasin de solutions de la batterie de serveurs : vous pouvez le faire via l’applet de commande PowerShell Remove-SPSolution . Par exemple :

    Remove-SPSolution -Identity POC14.wsp

Retirer et supprimer le package de solution

Autres considérations

Cette section comporte des informations sur des considérations supplémentaires, notamment les suivantes :

  • Déploiement d’une fonctionnalité sur des collections de sites en mode mixte

  • Considérations relatives à la Page maître

Déploiement d’une fonctionnalité sur des collections de sites en mode mixte

Si votre fonction personnalisée est limitée à une batterie ou une application web, vous pouvez la déployer même si toutes les collections de sites au sein de la batterie ou de l'application web ont été mises à niveau vers le mode de compatibilité SharePoint 2013.

Pour les fonctions limitées par des applications web, si la collection de sites racine n'a pas été mise à niveau, vous ne pourrez pas activer la fonction en utilisant l'applet de commande Install-SPSolution de PowerShell. Vous devez alors utiliser le site SharePoint Administration centrale pour activer la fonction.

Considérations relatives à la Page maître

En ce qui concerne les personnalisations, les pages maîtres personnalisées sont réinitialisées par défaut à seattle.master après une mise à niveau de la collection de sites dans SharePoint 2013. Si vous utilisez le scénario de masquage de fonction, vous devez rétablir toutes les pages maîtres personnalisées que vous avez créées pour les collections de sites SharePoint 2013. Pour plus d'informations sur la manière de procéder, consultez l'article MSDN décrivant l'utilisation de la mise à niveau de fonctions pour appliquer de nouvelles pages maîtres SharePoint Server 2013 lors de la mise à niveau depuis SharePoint 2010.

Remarque

Pour plus d’informations sur les personnalisations d’image de marque que vous devez effectuer lorsque vous mettez à niveau des collections de sites dans SharePoint 2013, consultez la page Problèmes de personnalisation pouvant se produire pendant la mise à niveau vers SharePoint 2013.

Voir aussi

Autres ressources

Créer un échéancier des personnalisations actuelles lors de la mise à niveau vers SharePoint 2013

Pack de solutions SharePoint 2013 et SharePoint dans Microsoft 365 pour la personnalisation et l’approvisionnement de sites

Problèmes de personnalisation pouvant se produire lors de la mise à niveau vers SharePoint 2013