Dans ce 4e billet, le lecteur renoue pleinement avec les sections No Code et Low Code qui ont structuré les deux premiers chapitres du livre consacrées à Power Apps et à Power Automate. En effet, Power Virtual Agents a de particulier que la création de chat bot peut se faire, au chapitre 3, en mode No Code et lorsqu'il s'agit d'étendre les capacités du canevas de conception, le concepteur de chat bot peut faire appel à un flux Power Automate. Le chapitre 4 est consacré à Power BI, l'outil de conception de rapports et de tableaux de bord. Suivant la logique du livre, ce chapitre a été conçu pour qu'un Power User sache utiliser Power BI pour obtenir des informations d'analyse issues de données gérées sur SharePoint, en intégrant les différents outils à sa disposition et les différents plans de licence associés. La fonction SharePoint Exporter sur Excel n'étant pas toujours connu des utilisateurs, la conception de solution de reporting fait néanmoins partie des types de fonctionnalités qu'un Power User souhaitera mettre en œuvre dans une application Métier, bouclant ainsi la boucle applicative, j'agis sur les données avec Power Apps, j'automatise certaines actions avec Power Automate, j'automatise certaines séquences de conversation avec Power Automate et maintenant, avec Power BI, j'analyse les données pour réagir le plus rapidement possible. Les extraits choisis vont refléter les différents passages du livre. Une méthodologie de conception d'application pour créer un rapport ou un tableau de bord Comme pour toute application, il est nécessaire de respecter un cadre méthodologique de conception que l'interface de Power BI rappelle, à savoir, se connecter aux données, nettoyer et traiter les données, concevoir les représentations visuelles puis publier Extrait de la page 304 Créer une application de visualisation de données hébergées sur SharePoint Dans le livre, je décris comment utiliser Power BI en mode No Code pour se connecter à notre source de données SharePoint, puis à nettoyer et transformer les données en information. Comme je l'ai écrit dans l'extrait précédent, cette étape est la plus conséquente en termes de temps : dans cette section du livre, on va retrouver la logique de structuration du contenu, à savoir une partie No-Code précédent la partie Low Code. Extrait de la page 344 La partie Low Code de Power BI est très impressionnante car elle permet l'ajout de code suivant différents langages de développement et je me suis contenté de partager des bouts de code en DAX, le langage le plus apte à servir de langage d'initiation à destination d'un Power User. Extrait de la page 353 Publier dans SharePoint, publier dans Power Apps, publier dans Teams Enfin, des pas à pas précis concluent ce chapitre pour publier l'extension des analytiques que vous aurez produit depuis SharePoint, via la production dans Power BI Service jusqu'à la publication dans SharePoint, dans Power Apps ou dans Ms Teams. Extrait de la page 328 Power BI est fait pour qu'un Power User ou un professionnel du traitement de la donnée puissent "faire parler" les données, qu'elles soient hébergées sur Excel, SharePoint ou Dataverse, avec un accent particulier mis sur l'apprentissage du DAX. Power BI est vraiment une pleine réussite, qui justifie pleinement une table des matières et un index détaillés. Extrait de la table des matières Extrait de l'index Dans le dernier billet, je vous partagerai des éléments de la conclusion du livre.

Après Power Apps, après Power Automate, voici le 3e billet qui présente l'intégration entre SharePoint et Power Virtual Agents. Comme pour les précédents billets, je partage des extraits de mon dernier livre (lien "Ma bibliothèque en ligne" dans la barre de navigation). Power Virtual Agents est l'outil le moins connu de la Power Platform : il sert à fabriquer des agents virtuels, des chat bots, en lien avec Microsoft 365 et tout le monde ne sait pas comment fonctionne un chat bot. Ca marche comment un Chat bot ? Au début du chapitre, j'ai commencé par expliquer à un Power User les principes de fonctionnement d'un chat bot et à présenter le type de chat bot que vous pouvez créer avec Power Virtual Agents Extrait de la page 266 Comme vous pouvez le lire ci-dessus, j'explique pourquoi le chapitre sur Power Virtual Agents arrive après celui sur Power Automate, comparant le mode de fonctionnement d'un agent virtuel au fonctionnement d'un flux. Les concepts de base de Power Virtual Agents, comparés à ceux de Power Automate J'ai continué sur ma pensée dans les pages suivantes en introduisant les concepts de base de Power Virtual Agents : les rubriques Power Virtual Agents qui peuvent s'apparenter à des actions de déclenchement Power Automate, les entités et un canevas de conception graphique de l'arbre conversationnel qui donne un sérieux coup de vieux à l'interface de Power Automate. Extrait des pages 269 et 270 Power Automate, au service de Power Virtual Agents Enfin, la création d'un chat bot en lien avec Microsoft 365, et donc avec SharePoint, passe par Power Automate. C'est dans ce chapitre que l'on ne sait plus si c'est Power Virtual Agents qui étend les capacités de SharePoint ou si c'est le contraire. Mais, quoiqu'il en soit, on a besoin de Power Automate en mode Low Code, lorsqu'il s'agit de faire interagir Power Virtual Agents et SharePoint. Extrait de la page 287 Comme les autres outils de la Power Platform, on retrouvera la logique de conception partagée entre le Power User (No Code) et l'IT Pro (Low Code) mais pour ce qui concernera l'intégration entre Power Virtual Agents et SharePoint à proprement parler, il faudra passer par Power Automate en mode Low Code.

"SharePoint et Power Automate" est le second épisode de la série de billets que je consacre à SharePoint et la Power Platform. C'est aussi le chapitre 2 du livre que j'ai écrit car j'ai commencé par Power Apps comme expliqué dans le premier billet de cette série. Or, j'aurai pu commencer le livre avec Power Automate car l'outil de création de flux - baptisé Flow jusqu'en 2019 - est bien le premier outil (date de lancement 2016) de la Power Platform à permettre aux concepteur d'applications métier d'étendre les fonctionnalités de SharePoint. Power BI, plus ancien encore (2015 sur le Cloud Office 365; il fera l'objet de l'épisode 4 de cette série), n'étends pas les fonctionnalités de traitement d'une application mais en présente les données sous forme de rapports et de tableaux de bord. D'abord SharePoint et Power Automate, seuls Avec Power Automate, SharePoint a largement bénéficié de fonctionnalités de flux de données : le livre développe par conséquent les liens de complémentarité directe qui existent entre Power Automate et SharePoint : flux d'approbations, flux d'informations, flux de traitements. Je vous offre un passage complet du livre qui prend l'exemple de l'utilisation de Power Automate pour décompresser automatiquement des fichiers .zip dans une bibliothèque de documents SharePoint, un petit flux très simple et qui démontre très rapidement à son bénéficiaire la valeur apportée par Power Automate. J'ai également élargi la présentation de cette complémentarité qu'offre Power Automate et son cadre de connecteurs pour interagir avec d'autres produits de la suite M365 : Ms Teams, Yammer, Outlook, Planner et To Do, OneNote, Ms Excel, OneDrive, Forms… Dans le livre, j'ai choisi l'exemple de la mise en place d'un flux d'alerte sur OneDrive, puisque cette fonctionnalité si utilisée sur SharePoint n'est pas présente sur OneDrive. Extrait de la page 209 Extrait de la page 210 Power Automate, solution facilitant l'intégration entre SharePoint et Power Apps L'exemple choisi tiré des pages extraites de mon livre démontre également la complémentarité qui existe entre Power Automate et Power Apps pour étendre les capacités de SharePoint. J'ai ainsi choisi d'expliquer dans un pas à pas comment gérer la prise d'une photographie depuis Power Apps, enregistrée sur SharePoint avec l'aide de Power Automate en lui associer des métadonnées. Extrait de la page 257 Extrait de la page 258 Extrait de la page 259 Du mode No Code au mode Low Code dans Power Automate Pour respecter la logique des concepteurs des produits composant la Power Platform, j'ai bien entendu présenter les éléments à connaitre en partant des fonctionnalités No Code de Power Automate, en présentant les modèle de flux proposés par Microsoft et les communautés. Familiariser le lecteur à l'utilisation des modèles de flux Power Automate est le point d'entrée pour le Power User et l'IT pro dans l'adoption de Power Automate car de cette manière, Microsoft est parvenu à largement abaisser la barrière à l'entrée grâce aux bénéfices de cette bibliothèque de flux prêts à l'emploi, qu'ils peuvent configurer sans écriture d'une seule ligne de code. Le livre décrit également la logique de création d'un flux pour qu'un Power User ou un IT Pro soit en mesure de faire fonctionner leur propre flux : le lecteur commence par l'identification des types d'action de déclenchement, puis passera en revue les différents types d'action de traitement et, enfin, intégrera les types d'action de terminaison. Dans le livre, chaque chapitre étant composé d'une section No Code puis d'une section Low Code, comme pour Power Apps, je présente évidemment le versant Low Code de Power Automate avec son éditeur de contenu dynamique et les capacités d'extension additionnelles apportées par Azure Logic Apps pour les IT pro désireux d'aller plus loin dans l'écriture de code dans Power Automate. Pour toutes ces raisons, le livre comporte : • Évidemment une table des matières pour s'aider dans la navigation, une section No Code puis une section Low Code structuration reprise dans les différents chapitres dédiés aux outils de la Power Platform, Extrait des pages 379 et 380 • Mais également l'index permettant d'aller droit aux paragraphes désirés. Extrait page 376 index Enfin, SharePoint et la Power Platform, c'est aussi Power BI, plus connu, et Power Virtual Agents, moins connu et dont le fonctionnement s'appuie largement sur Power Automate. Voyons donc dans l'épisode 3 ce que peut apporter SharePoint à Power Virtual Agents et vice-versa.

Dans le livre consacré à SharePoint et la Power Platform, pourquoi avoir commencé par Power Apps (2018), et non pas par Power BI (2015) ou Power Automate (2016) ? La raison principale qui m'a poussé à faire ce choix est que Power Apps est l'application qui va le plus changer la bureautique Microsoft. Power Apps est l'application qui va le plus changer la bureautique Microsoft En effet, Power Apps permet de créer des formulaires tout en y ajoutant des actions qui touchent aussi bien aux données qu'à l'expérience utilisateur. Comme je l'avais fait pour les autres tomes de la collection "Adopter SharePoint sans développer", lorsque j'ai écrit ce livre, je me suis mis à la place d'un utilisateur de type Power User, désireux d'acquérir de bonnes bases sur le fonctionnement du logiciel de conception d'application, à savoir ici, Power Apps Studio. Mais spécifiquement pour ce 4e tome dédié à l'adoption de SharePoint, j'accompagne les Power Users, jusqu'à l'écriture de lignes de codes, conformément à l'esprit de la Power Platform. Ceux d'entre vous qui ont connu la conception d'applications bureautiques avec Ms Access reconnaitront un lien de parenté théorique entre Power Apps et Ms Access. Cependant, ce qui différencie les deux outils, c'est que Power Apps possède un cadre de connecteurs de données qui permet de choisir son système de gestion de bases de données en fonction de la complexité : Excel, SharePoint, Dataverse ? Attention au coût également car des abonnements Power Apps Premium vont être requis pour certaines sources de données. SharePoint est le meilleur point de départ pour débuter avec Power Apps Dans le livre, avant les pages consacrées à l'intégration avec SharePoint, j'aborde la relation entre Power Apps et Excel, dans son fonctionnement et surtout ses limites. Ce n'est d'ailleurs pas pour rien si le concepteur d'une liste SharePoint se voit proposer de partir d'un fichier Excel. Voici, l'extrait du livre dans lequel j'évoque des impératifs et des limites qui existent à l'utilisation d'Excel avec Power Apps. Extrait de la page 26 Extrait de la page 27 Que la source de données soit Excel, SharePoint ou Dataverse, l'expérience de conception d'application en mode No Code puis en mode Low Code est quasiment la même, avec certaines différences développées dans l'ouvrage. Ensuite, pour ce qui est du choix entre SharePoint et Dataverse, le Power User préférera vraiment commencer par adopter SharePoint plutôt que Dataverse, même si la source de données qui fonctionne naturellement avec Power Apps, c'est Dataverse. En effet, Grâce aux efforts de l'expérience de liste Moderne, Microsoft a réussi à remettre SharePoint dans le coup, particulièrement depuis l'été 2020 avec l'arrivée de List dans Microsoft 365, en général, et dans Teams, en particulier. Par conséquent, comme Microsoft, je suis convaincu que SharePoint constitue le meilleur point de départ pour un débuter dans la création d'application Power Apps, avant d'aller s'essayer sur des sources de données plus complexes comme Dataverse ou SQL Server ! Du code en français (FR) et un chemin d'apprentissage gradué Dans le livre, lorsque je présente les très nombreuses fonctions au lecteur de type Power User, je ne les présente pas suivant un ordre alphabétique : j'ai plutôt développé la présentation des éléments pouvant entrer dans la composition des formules suivant l'objectif recherché. Cette page présentant les fonctions dans un ordre alphabétique existe sur le site de la documentation officielle Référence sur les formules pour Power Apps - Power Apps | Microsoft Docs ce qui reste très pratique quand on sait ce que l'on y recherche ! Extrait de la page 124 Extrait de la page 132 Toujours dans l'optique de respecter le chemin d'apprentissage des Power Users, je suis parti de formules dont les fonctions sont déjà connues dans Ms Excel : la raison est que ce point est un point de départ voulu par les concepteurs de la Power Platform, i.e. offrir à un Power User familier de Ms Excel de commencer à écrire des formules dans Power Apps avec les mêmes fonctions et la même syntaxe. Un Power User reconnaitra plus certainement une fonction IF qu'une fonction SWITCH, même si les 2 fonctions sont bien présentes dans le livre ; un lecteur IT pro ne sera pas réduit à une expérience de conception Power User. Toujours suivant mon exemple de l'utilisation de la fonction IF, le lecteur se fera exposer, dans le livre, des exemples non seulement pour manipuler des données que pour enrichir l'expérience utilisateur dans ses applications. Par exemple, le Power User pourra se sentir un peu désemparé lorsqu'il se rendra compte que certaines opérations de présentation des données ne sont pas aussi abouties dans Power Apps qu'elles ne le sont dans Ms Excel (pas encore en 2022) ; le concepteur d'application devra alors passer par des fonctions qu'il n'a peut-être jamais écrites dans Ms Excel. Extrait de la page 139 Extrait de la page 140 Comme vous l'avez peut-être observé par vous-mêmes avec les exemples choisis ci-avant, j'ai également pris le parti de donner des bouts de code en français et donc dans un environnement Power Apps européen. La raison est que le temps d'assimilation de l'utilisation des séparateurs dans la syntaxe est rendue plus long par le fait que la plupart des exemples publiés sur Internet concerne généralement des environnements nord-américains. Pour toutes ces raisons, le livre comprend : Non seulement, une table des matières, pour aider à la navigation, avec une section pour expliquer le fonctionnement de Power Apps Studio en mode No Code puis une seconde section consacrée au Low Code, structuration reprise dans les différents chapitres dédiés aux outils de la Power Platform, Extrait de la table des matières de la page 378 Mais également un index permettant d'aller droit au but (droit aux bouts... de code devrais-je oser !), ce qui pratique lorsque l'on cherchera à retrouver un paragraphe particulier. Extrait de l'index à la page 375 Voilà donc pour ce premier billet concernant SharePoint et Power Apps ; voyons dans le prochain épisode ce que j'ai mis dans le seconde chapitre qui traite de "SharePoint et Power Automate".

Par ce billet, je vous annonce une série de 5 billets pour traiter de la place de SharePoint dans le dispositif Power Platform. Vous n'êtes peut-être pas sans savoir que j'ai publié, fin décembre 2021, un livre de plus de 350 pages, disponible aux formats papier et ebook. Par ces billets, je vais vous partager des passages de celui-ci. Les billets seront organisés comme suit : EP1 : SharePoint et Power Apps (lien direct) EP2 : SharePoint et Power Automate (lien direct) EP3 : SharePoint et Power Virtual Agents (lien direct) EP4 : SharePoint et Power BI (lien direct) Enfin , je vous partagerai des éléments de la conclusion du livre dans un 5e et dernier épisode (lien à venir). Pour ce qui concerne l'introduction, vous trouverez ci-dessous un lien vers les 20 premières pages comprenant l'intégralité de l'introduction du livre, tel qu'il est mis gracieusement à disposition depuis le site de l'éditeur : J'y définis ce que représente un "Power User" au yeux de Microsoft depuis plus de 30 ans Je présente également de la complémentarité avec Ms Teams au travers des listes M365 Enfin la structure du livre entre en adéquation avec la philosophie de la Power Platform, à savoir que chaque chapitre du livre comporte une section d'apprentissage NO CODE et une section d'apprentissage LOW CODE, pour le Power User et l'IT Pro. Cliquer ci-dessous pour ouvrir le lien pour lire l'extrait.

J'ai publié en 2017 le 1er tome de "Adopter SharePoint sans développer", dans lequel je faisais le tour des fonctionnalités de gestion documentaire, noyau de base historique des fonctionnalités de SharePoint. Je regrette de ne pas y avoir décrit la fonctionnalité que je mentionne dans le titre du billet et, pour me faire pardonner, j'ai décidé d'écrire ce billet de blog, un peu compliqué... Systèmes de gestion de version, d'extraction obligatoire, de statut d'approbation : ce livre écrit il y a 5 ans est toujours à jour puisque SharePoint a gardé toutes ses fonctionnalités à chaque nouvelle édition Server et mises à jour Online. En introduction des formations que je donne, j'aime beaucoup évoquer l'enrichissement des fonctionnalités de SharePoint à travers le temps voulus par l'équipe Produit de Redmond : D'outil de gestion documentaire traditionnel qui ont marqué sa première partie de vie (éditions 2001, 2003 et 2007), SharePoint a connu, avec l'édition Serveur de 2010, l'arrivée de fonctionnalités d'intranet collaboratif et social. Dans l'édition Serveur de 2013, SharePoint devient l'outil pour lequel les fonctionnalités de moteur de recherche apparaissent désormais incontournables, pour construire des solutions de recherche personnalisées (chapitre V) et publier du contenu de façon dynamique : les WebParts Recherche de contenu (FR) // Content search (EN) et Contenus pilotés par la recherche (FR) // Search-Driven Content (EN). Il n'y a pas de nouvelle fonctionnalité qui permet de décrire l'apport de l'édition 2016 si ce n'est l'apparition de l'expérience Modern dans la bibliothèque de documents OneDrive. Enfin dans l'édition de 2019, SharePoint Serveur se voit affubler de l'expérience Modern dans ses listes, bibliothèques et pages, celle que Microsoft déploie sur Online (la version de février 2018 de Online correspond à l'édition de SharePoint 2019). Cette édition fait de SharePoint un outil d'intranet moderne. C'est une réussite indéniable : par exemple, les WebParts de recherche classiques cités plus haut se sont tous vus remplacés dans l'expérience moderne par un WebPart unique appelé Contenu mis en évidence (FR) // Highlighted content (EN). C'est aussi le début de la coopération entre SharePoint avec Ms Teams pour les usages collaboratifs "simples" (sujet traité dans le tome 2 de Adopter SharePoint sans développer : de SharePoint à Teams) et avec Power Apps pour les usages collaboratifs "avancés" (tome 4 : SharePoint et la Power Platform Etendre les fonctionnalités de SharePoint avec Power Apps, Power Automate, Power BI et Power Virtual Agents). Dans ce billet, je n'évoque pas de nouvelle fonctionnalité. Au contraire, comme indiqué dans son titre, je vais mettre en lumière une "vieille" fonctionnalité méconnue de SharePoint qui peut tout régler, lorsqu'il s'agit d'organiser la gestion des fichiers dans une bibliothèque de documents : je parle du bon vieux débat entre l'approche "Serveur de fichiers avec arborescence de dossiers" et "l'utilisation des métadonnées de Gestion Electronique de Documents". Cette fonctionnalité permet de concilier les 2 approches, et en évitant de les opposer, de mettre ainsi tout le monde d'accord. L'idée est de permettre par une simple opération de chargement de fichier dans un dossier de lui voir appliquer de façon automatique une ou plusieurs métadonnées héritées du document. On comprendra alors le plein intérêt lorsqu'on se rendra compte qu'avec cette façon de procéder, on retrouvera non pas le dossier mais directement les documents qui y sont rangés ! Comment faire ? En suivant les 3 étapes décrites ci dessous. Etape 1. Commencer par construire l'arborescence de dossiers Etape 1. Vous devez commencer par construire l'arborescence de dossiers dans le contenu de la bibliothèque Evidemment, je vais prendre pour exemple une arborescence à plusieurs niveaux puisque c'est de cette manière que sont utilisés les serveurs de fichiers. Je rappellerai néanmoins deux choses à ce sujet : Pour le premier niveau de dossier, pourquoi ne pas plutôt créer, à chaque fois, une bibliothèque de documents séparée ? Dans le contenu d'un site, vous pouvez ainsi gérer jusqu'à 200 bibliothèque ou listes, ce qui permet de mieux répartir les documents ; c'est d'autant plus vrai que SharePoint s'est vue dernièrement dotée d'une nouvelle fonctionnalité permettant de naviguer entre les bibliothèques de documents au sein d'un même site Attention à la longueur d'URL comprenant l'adresse du site, le nom de la bibliothèque, le nom des dossiers et le nom du fichier ; elle est limitée à 400 caractères sur les dernières éditions de SharePoint Server et Online (256 sur les éditions 2013 et 2016). Comme nous trouvions sur le serveur de fichier des sous-dossiers à l'intérieur du dossier Formations A, je les ai recréés dans la bibliothèque de documents SharePoint. Etape 2. Ajouter une colonne de métadonnée Pour l'étape 2, vous devez ajouter une colonne de métadonnée de type Métadonnées gérées (FR) // Managed Metadata (EN) (si plusieurs niveaux de classement hiérarchiques, comme ci-dessus, de manière à reprendre l'arborescence de dossiers) mais vous pouvez également utiliser d'autres types de colonne comme celle de type Choix (FR) // Choice (EN), si un seul niveau de classement hiérarchique. Vous créez un groupe de termes qui partira du nom de la colonne (vous pouvez réutiliser un ensemble de termes qui préexistait) qui reprend la structure de dossiers et de sous-dossiers que l'on souhaite voir appliquer. Etape 3. Associer à chaque dossier la bonne métadonnée L'étape 3 va permettre d'associer à chaque dossier la métadonnée que l'on souhaite voir appliquer automatiquement ; pour ce faire, il ne vous restera plus qu'à aller sur la page Paramètres des valeurs de colonne par défaut (FR) // Column default value settings (EN) dans les paramètres de bibliothèque. Cette page de paramétrage permet de faire la connexion entre le contenu du dossier et la (ou les métadonnées) que l'on souhaite appliquer par défaut : Pour sélectionner le dossier, il faut cliquer dans la marge gauche de la page Cliquer ensuite sur le lien représentant le nom de la colonne de métadonnées qui contient vos termes Dans la fenêtre pop-up qui s'ouvre, dans l'exemple d'une colonne de métadonnées gérées, sélectionner le terme à appliquer par défaut puis cliquer sur OK pour valider Reproduire cette manipulation autant de fois que vous aurez de valeur par défaut à "accrocher" à un dossier. Le tour est joué ! Et maintenant ? Le tour est joué ! Vos utilisateurs n'auront ainsi pas à appliquer manuellement des valeurs aux documents. La métadonnée est appliquée automatiquement sur le document dès que le fichier est chargé. Quel bénéfice maintenant pour retrouver le document ? Nul besoin de cliquer sur les dossiers puis sur les sous-dossiers pour trouver où se cache le document recherché : vous pouvez utiliser la fonctionnalité de filtrage sur les valeurs de la colonne de métadonnée pour retrouver le document. Vous retrouverez maintenant le fichier recherché et non son dossier de classement. Vous allez certainement vous rendre compte qu'il est plus judicieux de se passer des dossiers, en créant une vue sans dossier : pour ce faire, il faut simplement créer un affichage en passant par le formulaire de création d'affichage (tout en bas de la page Paramètres de bibliothèque) et de cliquer dans la section +Dossiers // Folders (EN) pour cliquer sur Afficher tous les éléments sans dossiers pour afficher tous les documents à la fois. Enfin, dans la recherche, si vous ajoutez la colonne de métadonnées comme affineur, vos utilisateurs apprécieront de filtrer sur le mot clé qui correspond au nom du dossier, pour retrouver les fichiers qui s'y trouvent ; cela demande une manipulation particulière que j'avais détaillé dans les toutes dernières pages de mon premier livrer (Cf. page 290 chapitre 5 du tome 1 "Adopter SharePoint sans développer") ! En conclusion, je dirais qu'évidemment, cette fonctionnalité ne sera pas déployée pour gérer des documents dans un petit espace collaboratif éphémère, à faible audience ou enjeu ; par contre, je déploie généralement cette fonctionnalité et j'adapte les pages de recherche en conséquence lorsqu'il s'agit d'un site SharePoint servant à la mise à disposition de documents de référence, dans un intranet de publications.

Dans le dispositif de mise en place de Microsoft 365 en général et de SharePoint en particulier, j'ai généralement dû constater que l'approche "Projet" était utilisée par mes clients, que les principes de gouvernance qu'ils souhaitaient appliquer se limitaient généralement à former : Des administrateurs techniques dont la mission est de rendre opérationnel l'accès (utilisateurs, licences et permissions), Les utilisateurs Membres et les Propriétaires, la typologie d'utilisateurs que l'on retrouve sur MS Teams. Avec cette approche, sur la durée et l'échelle, l'adoption des utilisateurs n'est généralement pas au rendez-vous et les échecs sont plus courants que les succès : au cours de ma session au MWCP22, j'avais argumenté ce constat en utilisant une étude de Skyhight Network de 2016 qui relevait que seulement 2,1 % des utilisateurs de Microsoft 365 déclaraient utiliser activement SharePoint (1,2 % concernant Yammer, sur lequel je vais revenir plus bas). Cette étude datait de 2016 mais les choses n'ont pas changé avec le déploiement de Teams : on va ainsi devoir expliquer l'usage des équipes à des utilisateurs qui n'utilisent que les fonctionnalités de Chat et de réunion en ligne (les anciennes fonctionnalités de Skype for business...) et n'utilisent pas les fonctionnalités collaboratives des équipes ! La raison essentielle qui explique cette situation me parait être la faiblesse du dispositif de gouvernance fonctionnelle, une fois que le projet de déploiement est terminé. La première erreur vient de l'approche "Projet" du déploiement de Microsoft 365 Vous avez mis en place un projet SharePoint il y a 1 an déjà et vous souhaitez pendre des nouvelles de celui-ci chez votre client ? Le dispositif alors en place est généralement beaucoup moins fourni que pendant le projet mais il se peut même que vous ne connaissiez plus les interlocuteurs encore "sur le pont". Leur rôle est généralement le suivant : Un administrateur technique qui est en charge de la gouvernance opérationnelle de SharePoint, assurant la gestion des accès et des licences sur Online ou l'infra quand on est en environnement Server, Un développeur pour la gouvernance applicative lorsqu'il y a à gérer les éventuels compléments achetés ou développés maison, Une équipe Help Desk "Utilisateur" pour gérer les incidents que je rattacherais comme dispositif appartenant à la gouvernance fonctionnelle. Si vous leur posez la question sur la qualité de l'adoption de la solution mise en place, quand vous aurez des réponses, vous n'obtiendrez généralement hélas pas une analyse partagée entre les 3 parties prenantes citées plus haut, basée sur des données sur la qualité de l'adoption : au mieux, vous obtiendrez le nombre d'incidents et leur taux de résolution, le nombre d'interventions de type TMA corrective, adaptative ou évolutive, le nombre de visites sur la page la plus visitée quand il s'agit d'un intranet (la fameuse page affichant le menu de la cantine...). L'équipe Projet est partie sur d'autres projets : plus personne ne semble encore s'intéresser à la qualité de l'adoption, au fait que la solution proposée rencontre ou non son public, que l'organisation, au travers d'elle, atteigne ou non les objectifs fixés à son lancement. La solution serait de considérer que l'adoption de pareils outils (SharePoint en particulier et M365 en général) requiert la mise en place d'un dispositif continu qui doit survivre à la phase Projet. La seconde erreur est de sous-estimer le dispositif d'adoption après le projet de déploiement Lorsqu'il s'agit de déployer SharePoint ou Yammer en organisation, vous avez sans doute déjà entendu parler de la pertinence de mettre en place un rôle d' "ambassadeur" ou de "champion" (terminologie plus "US"). Concept adopté par Microsoft au moment de la sortie de Teams en 2018 dans sa documentation (c'est le terme utilisé dans la documentation officielle sur le site plus récent "Become a champion"), ce rôle a été repris de ce que faisaient des entreprises spécialisées dans la conduite du changement. Ces entreprises ont été confrontées à des défis importants lorsqu'il a fallu accompagner leurs clients dans le déploiement d'outils de type réseau social d'entreprise. Pour y répondre, elles ont ainsi proposé à leurs clients de les accompagner dans la mise en place de ce rôle de relais entre le Community Manager et les participants au réseau social interne à l'organisation. Si votre organisation a connu l'échec lors du déploiement de son réseau social d'organisation (souvenez-vous, plus haut, quand je citais que seuls 1,2 % des utilisateurs déclaraient en 2016 utiliser activement Yammer) vous tenez là une des raisons majeures expliquant cet échec : ce n'est évidemment pas la seule raison mais j'y reviendrai plus bas lorsque je parlerai du "Why". Ce rôle d'ambassadeur ou de champion s'inspire de celui de "correspondant bureautique", mis en place dans les organisations dans la décennie 1990-2000. En effet, au moment du déploiement à grande échelle de la micro-informatique, les organisations se sont aperçu qu'accompagner les utilisateurs dans l'adoption du Pack Office ne répondait pas à la même logique que de former des opérateurs sur un système informatique transactionnel, i.e. qui permet de créer, de corriger ou de supprimer un enregistrement dans une application métier. Avec le Pack Office, les organisations ont eu besoin de former les utilisateurs à des outils de création de fichiers et, pour gagner en pertinence avec les sujets propres à chacun, le correspondant bureautique était identifié au sein d'un service autant pour sa connaissance du fonctionnement de ce service que pour ses aptitudes à former ses collègues. Ce rôle d'ambassadeur ou de champion s'inspire donc bien de celui de correspondant bureautique mais il est différent et requiert des qualités supplémentaires. La raison à cela est que les outils informatiques n'appartiennent pas à la même catégorie : le pack Office est une suite de productivité individuelle alors que SharePoint, Yammer et Teams sont des outils collaboratifs. Par conséquent, les qualités requises pour être un bon ambassadeur ou un champion sont différentes : pour parvenir à ancrer de nouveaux usages, permettre ainsi une nouvelle étape de digitalisation de processus dans les organisations, nous devons compter sur les relais, les correspondants bureautiques et les champions/ambassadeurs mais également intégrer dans le dispositif un troisième type de personnage clé qui va exploiter les outils de la Power Platform : le "Power User" ou "Citizen Developer". Chaque rôle a une fonction différente, nécessitant des qualités différentes pour les endosser, variant suivant la typologie d'outil : Outil de productivité individuelle (comme Word, Excel, PowerPoint, Outlook avec ses différentes dimensions e-mail, calendrier, tâches et notes mais également To Do, OneNote, OneDrive et Forms en conception solo) qui requiert une fibre de pédagogue, de formateur et de coach individuel (pas besoin d'être interne à l'organisation) ; important par le passé, ce rôle de correspondant bureautique est sous-estimé actuellement dans le dispositif, alors qu'il reste d'actualité quand on prend en compte le flux de mises à jour Office Online qui se déverse en continu ; Outil de productivité de groupe (comme SharePoint, Yammer, Stream, Kaizala, MS Teams, Planner, et Forms en conception d'équipe) qui nécessite des qualités supplémentaires de "leader" convaincu et stimulant et faisant preuve d'empathie, avec des qualités de communication et d'animation ; en plus de ses qualités de formateur-démonstrateur, l'ambassadeur/champion doit porter le changement en étant exemplaire ; pour ne pas être déconnecté de la réalité quotidienne de l'organisation, je suis convaincu qu'il ne peut être qu'interne à l'organisation ; Outil de création d'application Métier (les outils de la Power Platform Power BI, Power Automate, Power Apps, Power Virtual Agents mais également les Lists 365 dans Ms Teams et donc dans SharePoint dans lequel on peut ajouter des listes, bibliothèques et des applications pour créer des applications Métiers) dont le casting nécessite de faire appel à un personne qui est pour le changement, qui plus est technologique, connait les données et les processus Métier concernés, être légitime aux yeux des collègues qu'elle représente et enfin, elle doit rester dans le cadre imposé par la gouvernance du dispositif ; pour toutes ces raisons, le Power User est interne à l'organisation. Changer de scénario ne va pas se faire tout seul J'emprunte maintenant une formule à l'excellent Christophe Coupez : "Adopter Microsoft 365, c'est changer de scénario". Pour changer de scénario, je n'ai pas trouvé d'autres solutions que de répéter l'importance de la gouvernance, en y intégrant ces rôles dans un chapitre fonctionnel, pour piloter l'atteinte des objectifs d'adoption, en suivant des métriques en lien avec la qualité de l'expérience utilisateur ressentie, de manière à apporter des réponses aux difficultés... Pour faire vivre le projet de transformation initial au-delà de la phase de gestion du projet, je parle donc de programme d'adoption : "Adopter M365, ce n'est pas un projet ; c'est un programme qui s'étendra sur plusieurs années". Ce "programme" sera donc un dispositif permanent qui survivra à la phase Projet, permettant de rencontrer le succès sur la durée et à l'échelle visée. Enfin qui dit "Programme", dit "Direction de programme" : voilà pourquoi que je milite pour la mise en place d'un Monsieur-Madame Microsoft 365 dont la fonction sera de mettre en place le dispositif de gouvernance fonctionnel, définir les articulations entre ces rôles plus ou moins nouveaux : relais bureautiques, ambassadeurs/champions, Power Users. Lorsque j'évoque la gouvernance du dispositif d'adoption de Microsoft, j'introduis la nécessité de mettre en place ce rôle de "M. Mme 365". Ce rôle sert à définir, coordonner et mesurer l'efficacité et ainsi ne pas se retrouver à n'utiliser que 10% des fonctionnalités alors que l'on paie 100% de la licence. M. Mme 365 va permettre d'installer de façon durable le "Why ?", i.e. les enjeux du programme à communiquer, et à ordonner les projets dans une feuille de route réaliste, au-delà de la nécessaire explication préalable : « quel outil pour quels usages ». Pour veiller à la bonne visibilité du cap suivi et du dispositif auprès des métiers, M. Mme 365 surveille la cohérence de l'ensemble, de la bonne gouvernance des données surtout sensibles. Il va ainsi orchestrer les 4 rôles mentionnés ci-dessus, en fonction de ce cap, en mettant en place une stratégie avec des objectifs à déterminer en équilibre avec les contraintes. En effet, M. Mme 365 aura un rôle en lien avec la gouvernance opérationnelle (déploiement des licences avec une approche Conduite du changement) et avec la gouvernance applicative (relations concernant la fabrique des applications avec les développeurs). Voilà donc quelques-unes de mes idées que je vous partage aujourd'hui par écrit mais je vous propose de nous retrouver prochainement à la conférence aMS Lausanne le 19 avril prochain (possible de la suivre en ligne) pour aller plus loin dans cette réflexion. A très bientôt sur ce thème.

Comment un Power User, un utilisateur "non informaticien" ou un IT pro à la recherche d'outils de productivité accrue peuvent étendre les capacités de SharePoint au travers des 4 logiciels composant la Power Platform : Power Apps Power Automate Power Virtual Agent Power BI Ce livre de 380 pages (aperçu : cliquer ICI) a été conçu en respectant l'esprit No Code et Low Code de ces outils, avec des exemples que l'on retrouve dans un index détaillé. Pour accéder à la page de la boutique en ligne de mon éditeur, cliquer sur https://www.bod.fr/librairie/catalogsearch/result/?q=frank+poireau+adopter+sharepoint A bientôt

SharePoint et la Power Platform est sorti, après plus de 2 années d'écriture et de test. (Cliquer pour ouvrir) Inspiré des formations que j'anime, l'ambition de ce quatrième livre de la série "Adopter SharePoint sans développer", a été de documenter de façon la plus précise possible comment un Power User, un utilisateur "non informaticien", ou un IT pro à la recherche d'outils de productivité accrue, pourront étendre les capacités de SharePoint en utilisant les 4 logiciels composant la Power Platform : Power Apps Power Automate Power Virtual Agent Power BI Ce livre a ainsi été conçu avec Marie-Aude, une assistante de direction, qui possédait uniquement l'expérience de l'utilisation du pack Office (Excel, Power Point et Access sans code) et a été relu par Anne, une fervente utilisatrice de SharePoint. Pour aider à concevoir des solutions et leur tableau de bord, le lecteur trouvera : un index listant des exemples précis une table des matières structurée en 2 parties "No Code" puis "Low Code" Extraits ci-dessous Pour accéder à la page de la boutique en ligne de mon éditeur, cliquer sur https://www.bod.fr/librairie/catalogsearch/result/?q=frank+poireau+adopter+sharepoint Vous y trouverez également un lien de lecture d'un extrait : https://www.bod.fr/booksample?json=http%3A%2F%2Fwww.bod.fr%2Fgetjson.php%3Fobjk_id%3D3652735%26hash%3Dac599eea68493f4b7944d81539645c43 Je vous souhaite bonne lecture si vous me faites l'honneur de vous le procurer.

RDV les 18 et 19 Novembre 2021 pour la 2° édition du Power Platform French Summit, l'événement qui rassemble Business (le 18/11) et l'IT (le 19/11) à Paris autour de la Power Platform ! Mon sujet sera : Réussir l'adoption des Power Users. " Microsoft aime les Power Users : SharePoint, Teams et la Power Platform ont besoin des Power Users. - Qui sont les power Users ? Les qualités d'un Power User... - Comment réussir l’adoption des Power Users ? La matrice de l'adoption... - Comment parvenir à l'échelle visée et sur la durée ? L'ambassade permanente de l'adoption des usages M365... Il n' est pas trop tard pour consulter l'agenda et s'inscrire sur cet événement 100% gratuit en présentiel et en distanciel : Agenda — Power Platform French Summit

RDV le 7 Octobre 2021 pour la 2° édition du Power 365 Lille ! L'événement qui rassemble IT et métiers au Nord de Paris. Mon sujet sera : Réussir l'adoption des Power Users. Microsoft aime les Power Users : SharePoint, Teams et la Power Platform ont besoin des Power Users. - Qui sont les power Users ? Les qualités d'un Power User... - Comment réussir l’adoption des Power Users ? La matrice de l'adoption... - Comment parvenir à l'échelle visée et sur la durée ? L'ambassade permanente de l'adoption des usages M365... Lien de l'événement : https://www.weezevent.com/power-365-2021

Il y a un an, on pouvait saluer l'arrivée des listes modernes. Depuis leur apparition, j'appelle d'ailleurs ces listes des "lists 365" car elles peuvent être créées sur SharePoint, prendre la forme de liste personnelle sur OneDrive et bien sûr apparaître comme des listes d'équipe via l'onglet MS Teams. Dans SharePoint, un concepteur de solution SharePoint peut ajouter, dans n'importe quel modèle de site, une liste Moderne en cliquant depuis la page d'accueil sur + Créer puis choisir Liste. Dans le pop-up qui s'ouvre alors, le concepteur SharePoint prend la mesure de ce qu'est une liste puisque une galerie de modèles permet de l'inspirer pour lui démontrer que SharePoint n'est pas limité à son usage premier depuis plus de 20 ans, à savoir la gestion de fichiers. Comme on le voit sur l'image précédente, on peut continuer à créer autant de bibliothèques de documents que nécessaire. Avec la liste SharePoint que j'ai présentée l'an passé (billet de blog), les utilisateurs gèrent des informations au travers de tableaux et de formulaires de saisie et de modification (cf. 1/ note de page de page), i.e. des listes SharePoint. Cliquer sur + Créer puis choisir Liste fonctionne ainsi depuis l'arrivée de ces listes 365. Le changement de la rentrée 2021 vient d'un autre bouton de fonction : le bouton de fonction Ajouter une application (EN : Add an app) qui est présent depuis la roue Paramètres SharePoint ou depuis la page de contenu de site + Nouveau puis Application. Au travers des nombreuses éditions Server de SharePoint, avant que SharePoint Online n'existe sur Office 365, on a pu apprécier les différents usages de listes au travers des différents modèles proposés sur la page Ajouter une application : calendrier, contacts, tâches, enquête, liens, liens promus... Ces listes qui nous étaient donc proposées constituent autant de listes qui disparaissent en cette rentrée 2021 au profit de solutions qui gravitent autour de SharePoint Online, l'éloignant fortement des versions Serveur de SharePoint désormais... Le bouton de fonction Ajouter une application (EN : Add an app) évolue Le lien Ajouter une application (EN : Add an app) ne permet plus d'accéder à la page de l'inventaire des bibliothèques et des listes que l'on pouvait ajouter dans SharePoint, depuis l'édition 2013. Avant de faire l'inventaire de ce que l'il est encore possible d'ajouter comme liste et bibliothèque et de ce qu'il n'est plus possible d'ajouter, je tiens à préciser que le lien Ajouter une application ne disparaît pas (et l'ancienne page Ajouter une application existe toujours cachée et vous pourrez l'afficher à l'adresse de votre site https://xxx.sharepoint.com/_layouts/15/addanapp.aspx) Le lien Ajouter une application est conservé pour vous amener désormais sur la nouvelle page Mes Applications présentée ci-dessous, laquelle propose des pages Web publiées sur le Store Microsoft. Cette nouvelle page est un bon moyen de remettre en lumière le Store Online SharePoint de Microsoft. Un utilisateur qui clique sur le bouton de fonction Mes demandes peut saisir et suivre ses demandes de mise à disposition d'applications, gérées par son organisation ou listées sur le SharePoint Store. A part cette page "Moderne Experience" déployée, il n'y a pas là de nouveautés car ces possibilités ont toujours existé sur SharePoint Online de Microsoft 365 et sur Server depuis l'édition 2013 : en effet, ces applications, ainsi que les banques d'informations sécurisées et les connecteurs de type BCS restent gérés par l'administrateur SharePoint Online depuis la page Plus de fonctionnalités du centre d'administration. Mais revenons-en à ce que l'on peut ressentir comme une cure d'amaigrissement fonctionnelle sur SP Online : la disparition de nombreux types de listes et bibliothèques SharePoint comme outil de conception fonctionnelle et les solutions trouvées ailleurs sur M365. Les applications de site de type liste et bibliothèque que l'on ne peut plus ajouter et la solution sur M365 Revenons à SharePoint et aux types de listes et de bibliothèques qui étaient à la main des concepteurs de site SharePoint. Même si les colonnes de site existent toujours, de nombreux modèles de bibliothèques et de listes SharePoint disparaissent avec l'évolution du bouton de fonction Ajouter une application (EN : Add an app). Concernant les bibliothèques LA BIBLIOTHEQUE D'IMAGES (EN : Picture Library) Ajouter le WebPart Bibliothèque d'images dans une page permet de gérer des images qui seront stockées dans la bibliothèque nommée Eléments de site (Site Pages), dans le dossier correspondant au nom de la page ; on ne peut donc plus ajouter de bibliothèque d'images. Je ne sais pas si une mise à jour du WebPart va arriver rapidement mais il est jusque-là possible de choisir entre plusieurs bibliothèques et la fonctionnalité semble donc caduque (image ci-dessous). LA BIBLIOTHEQUE DE BIENS (EN : Site Assets Library) La bibliothèque de biens avait vocation à stocker les fichiers multimédias du site ; elle disparaît et c'est évidemment Stream qui constitue la réponse fonctionnelle à cette disparition, même si Stream ne gère pas les fichiers audio. Ce qui peut vous décontenancer, c'est d'apprendre que la version Moderne de Stream de 2021 héberge les fichiers sur SharePoint et OneDrive (pour en savoir plus, cliquer sur le lien Nouvelle version de Microsoft Stream - Microsoft Stream | Microsoft Docs). LA BIBLIOTHEQUE DE PAGES WIKI (EN : Wiki Pages Library) On ne peut plus ajouter une bibliothèque pages wiki ; dans les versions Server, le concepteur de solution avait le choix entre ajouter cette bibliothèque ou... créer un sous-site de type Wiki. La réponse à cette disparition est celle que vous utilisez depuis l'introduction de la Modern Experience en 2018, à savoir créer un sous-site pour tirer bénéfice de sa bibliothèque de pages. LA BIBLIOTHEQUE D'ENREGISTREMENT (EN : Record Library) Avec le remplacement de la page Ajouter une application, vous ne pourrez plus ajouter de bibliothèque d'enregistrement pour y ranger les archives intermédiaires d'un site projet ou d'équipe. Techniquement parlant, cette bibliothèque d'enregistrement était une liste et il n'était pas possible de "déplacer vers" ou de "copier vers" depuis une bibliothèque de documents. La réponse à cette disparition peut être apportée simplement en ajoutant une bibliothèque de documents et d'activer la mise en enregistrement, ce que je faisais déjà depuis la généralisation de l'expérience Moderne dans les bibliothèques. LA BIBLIOTHEQUE DE FORMULAIRES (EN : Forms Library) Vous n'avez peut-être jamais utilisé la bibliothèque de formulaires : c'est dans cette bibliothèque que les développeurs y déposaient des formulaires personnalisés qu'ils avaient réalisés avec InfoPath ou autre. Si vous utilisez les formulaires Power Apps, vous n'aurez plus besoin de cette bibliothèque puisque les formulaires sont appelés depuis SharePoint dans l'environnement Power Apps dans lequel ils sont gérés. Concernant les listes LA LISTE ANNONCES (EN : Announcements) La liste d'annonces a été remplacée par la fonctionnalité de page de sites modernes que l'on peut promouvoir en tant que billet d'actualités (fonctionnant avec la colonne de métadonnées "promoted state") ; même si la gouvernance éditoriale dans la bibliothèque de pages devient un sujet d'attention (je l'ai traité dans un précédent billet de blog), on ne va pas regretter cette liste d'annonces, même si j'aurais préféré que l'on nous offre la possibilité d'ajouter des bibliothèques de News et de pages pour les wiki (la disparition de la bibliothèque de pages Wiki traitée plus haut). LA LISTE ENQUETE (EN : Survey) La liste enquête n'a pas connu de relooking Modern même partiel depuis 2018 et c'est connu de la majorité des utilisateurs de M365 : c'est Forms la solution pour réaliser, organiser et analyser des enquêtes, des sondages au sein de l'organisation au travers de formulaires et de questionnaires avec logique de branche possible. Si on veut toucher une population d'utilisateurs externes à M365, il est important de noter qu'une version Pro de Forms existe mais elle est intégrée à Dynamics 365 dans son module Customer User Voice. LA LISTE FORUM DE DISCUSSIONS (EN : Announcements) La disparition de la liste de forums de discussion appelle également la disparition du modèle du site de communauté qui avait fait sa réapparition depuis l'édition 2013 Server (2010 Server ne possédait pas cette fonctionnalité alors que l'édition 2007, oui). Le réseau social d'entreprise de Microsoft, depuis 2012, c'est Yammer et ne voyant pas de relooking Modern, même partiel depuis 2018, c'est bien Yammer qui s'affiche désormais dans SharePoint (WebPart Conversations et recommandations Yammer) et MS Teams (Communauté Yammer) ; personnellement, je regretterai toujours le module de réputation qui disparaîtra avec le site de communauté puisque celui-ci permettrait à tous ses utilisateurs de bénéficier de l'avance de SharePoint en ce qui concerne les fonctionnalités de RSE par rapport à Yammer et Teams (Cf. Chapitre 6 - Tome 2 Adopter SharePoint sans développer : De SharePoint à MS Teams) LES LISTES LIENS ET LIENS PROMUS (EN : Discussion Board) Ces listes sont remplacées - et c'est beaucoup mieux ainsi - par des WebParts de pages Modernes ; le WebPart Bannière Principale fait oublier la liste Liens Promus et le WebPart Liens rapides donne plus de visibilité à ce type d'enrichissement fonctionnel, dans un site de communication ou d'équipe que la liste Liens. LA LISTE CALENDRIER (EN : Calendar) Pour ajouter un calendrier à un site de communication (le site d'équipe Moderne en possède un par défaut), cela reste possible, en insérant le WebPart Evénements dans une page (lorsque l'on effectue l'ajout à travers l'insertion du WebPart, on se croirait être revenu à SharePoint 2010 (clin d'œil pour ceux qui ont utilisé cette édition) ou en activant un nouveau modèle de conception de site qui en possède un. Cela signifie que jusque-là, je ne suis pas parvenu à ajouter un second calendrier dans un site, après cette mutation du bouton de fonctionnalité Ajouter une application. A noter que la liste calendrier est renommée Liste d'événement mais ne bénéfice pas d'emblée d'un relooking Modern par défaut ; après quelques petites manipulations, vous pouvez habiller votre affichage de calendrier classique en Modern : Se rendre sur la page du calendrier, ouvrir l'onglet Calendrier du ruban Choisir l'affichage Tous les événements (la liste apparaît en mode Modern par défaut ; dans le cas contraire, passer en mode Modern via les paramètres de liste - Paramètres avancés) Dans le ruban "Modern", cliquer sur Créer un affichage Saisir le nom et choisir d'afficher comme un calendrier Cliquer sur Créer pour valider Dans le ruban "Modern", cliquer sur le nom de l'affichage puis sur Définir en tant qu'affichage par défaut LES LISTES DE CONTACTS ET DE TACHES (EN : Contacts list & Tasks list) J'ai regroupé les listes de contact et de tâches ; j'aurais pu y ajouter la liste Calendrier vue juste au-dessus car ces 3 listes classiques ont pour point commun qu'elles pouvaient se connecter à Outlook. Concernant la liste de tâches qui se connectait en plus à Ms Project, je vous avais fait part dans un précédent billet de mon intime conviction concernant la disparition programmée des listes de tâches SharePoint sur M365 avec la montée en puissance des outils de suivi d'action comme Tasks (qui fusionne Planner et To-Do), Project For The Web et la Power Platform qui va vous permettre de créer vos applications de gestion de tâches Métiers. Concernant la disparition de la liste Contacts, c'est un petit peu flou pour moi : - Cette liste SharePoint a bénéficié d'un relooking Modern partiel - MS Teams, outil le plus collaboratif qui soit, ne propose rien alors que calendrier et tâches s'y trouvent - J'y vois, là aussi, les ombres de Dynamics 365, outil de gestion de contacts par essence, et de sa Power Platform mais je suis actuellement bien embêté pour le conseiller en tant que remplaçant de la liste SharePoint "Contacts". Je choisis plutôt de créer ma liste dans SharePoint à partir de colonnes de site. LA LISTE BOITE AUX LETTRES DE SITE (EN : Site Mail Box) La liste Boîtes aux lettres de site n'en était pas une ; en fait, lorsque vous cliquez dessus (sur Online ce n'est plus possible depuis l'avènement des Office Groupes en 2016), SharePoint demande à Exchange de créer une boîte aux lettres partagée entre les membres de l'équipe. Si vous connaissez MS Teams, vous savez déjà que, fonctionnellement, la boîte aux lettres de site SharePoint a été remplacée par la boîte aux lettres de canal d'équipe dans Ms Teams. LES LISTES SUIVI DES PROBLEMES, LISTE PERSONNALISEE ET IMPORTER UNE FEUILLE DE CALCUL (EN : Issue tracking list, Custom list, Import Spreadsheet list) Pour ceux qui connaissent bien les "lists 365" que j'ai évoquées en début de billet de blog, il est évident qu'elles sont les remplaçantes des listes Suivi des problèmes, Liste personnalisée et Importer une feuille de calcul !! Il est temps de conclure ce billet qui a pour but de vous accompagner dans cette nouvelle étape, celle de devoir gérer un impressionnant fossé entre les éditions Serveur et Online de SharePoint en cette rentrée 2021, fossé qui était jusque-là essentiellement marqué par la modernisation des interfaces des listes et bibliothèque. Le "gap" entre SharePoint Online et ses versions Serveur s'élargit d'un coup. Il n'est pas disproportionné qu'écrire qu'il existe désormais un important "gap" entre SharePoint Online et ses éditions Serveur ; cet été, Microsoft a annoncé que la prochaine version Server de SharePoint ne sera plus alimentée par des cumulatives updates et ne nécessitera plus de migration applicative à proprement parler. La richesse fonctionnelle de M365 et la montée en puissance grandissante de la Power Platform fait que les deux mondes SharePoint Server et Microsoft 365 devraient de moins en mois se ressembler. Au moment où la relecture et la correction du tome 4 de "Adopter SharePoint sans développer : l'apport de la Power Platform" ont commencé, ce gap énorme provoque, dans les prochains semaines, une réédition actualisée de mon livre Tome 1 "Adopter SharePoint sans développer : Mon Digital WorkSpace". Note de page de page 1/ Avec ces exemples de liste, on comprend que l'on peut créer des petites applications et les "pros" SharePoint auront remarqué que les types de colonnes "valeur calculée" et "recherche" peuvent apparaître quelque peu "cachés" pour un concepteur de liste de type "End-User" (utilisateur final) par rapport à d'autres types de colonnes mais doivent être connus du "Power User" (il faut créer une colonne par les paramètres de liste).