SharePoint, le portail collaboratif historique de Microsoft est un produit très complet qui permet de dynamiser le travail en équipe et qui facilite la gestion, le partage et la recherche de contenu. Il est proposé dans la plupart des abonnements à la suite Office et s’y intègre harmonieusement. Cependant, en presque deux décennies, SharePoint a beaucoup changé, particulièrement en ce qui concerne son écosystème et ses usages. Les métiers des consultants SharePoint sont-ils eux aussi voués à évoluer ? Dans ce premier article nous nous pencherons sur le cas du développeur SharePoint en fonction des tendances du marché.
Le consultant SharePoint est né dans l’ancien monde
SharePoint est un produit déjà ancien. Dans ses versions 2001 et 2003, SharePoint était un outil collaboratif principalement orienté GED (Gestion Électronique de Documents), apprécié mais assez peu répandu.
À partir de la version MOOS 2007, et consacré par SharePoint 2010, un véritable engouement a eu lieu autour de cette technologie. Un produit de qualité couplé à un effort marketing ont été le facteur de la réussite de SharePoint. Par ailleurs, l’investissement particulièrement cher en machines et en licences a poussé Microsoft à s’adresser avant tout aux grands groupes. La tendance pour amortir cet investissement a alors été d’utiliser au mieux les nombreuses possibilités offertes par le produit : Intranet, GED, sites d’équipes, sites personnels, centre de recherche, et bien plus encore (sites institutionnels publics, forums, sites événementiels, etc.). Cela allait de pair avec la stratégie de SharePoint comme portail d’entreprise.
Afin de rentabiliser au mieux l’infrastructure, en plus des projets SharePoint à proprement parlé, beaucoup de nouveaux projets web portés par les BU ayant investi dans SharePoint ont commencé à être hébergés dans la ferme SharePoint, voire même directement implémentés dans une collection de sites dédiée. Ce fut du pain béni pour les développeurs web connaissant asp.net : une fois bien assimilées, l’architecture de SharePoint et les bonnes pratiques de développement qui lui sont liées, un eldorado s’est ouvert devant eux. Le développement sur SharePoint était exigeant et fastidieux, mais bien rémunéré. Et c’est à partir de ce moment que de nouveaux challenges (ou obstacles) sont apparus pour l’IT : l’installation d’une ferme de manière à pouvoir s’adapter à de nouvelles exigences, la maintenance des serveurs, la quête aux bonnes performances… autant de spécialités particulièrement demandées.
C’est par cette demande que de nouveaux profils très recherchés sont nés : le développeur SharePoint et l’administrateur SharePoint.
Le cloud a tout bousculé
Le « Cloud » n’est pas qu’un mot magique. C’est l’aboutissement d’un long processus de rationalisation des coûts d’infrastructure (on retrouve la problématique évoquée juste au-dessus). Depuis le début des équipements informatiques, les entreprises ont dû gérer un parc de serveurs dédiés à leurs applications. Petit à petit, le nombre d’applications se multipliant, la mutualisation des machines a été une réponse indispensable. Le plus grand pas a été fait avec la généralisation des hyperviseurs et la virtualisation des serveurs.
Le Cloud est un pas supplémentaire dans ce sens : on s’affranchit de l’hébergement en salle blanche de certains hyperviseurs et autres serveurs dédiés, et on loue l’utilisation de ressources à un fournisseur. Pour aller vite, et sans rentrer dans les grandes familles de services Cloud, ce modèle de rationalisation peut réduire de nombreux coûts et permet aux entreprises d’investir davantage dans leurs métiers que dans leur IT.
À partir de 2012, Microsoft a commencé à rendre disponible SharePoint sur le modèle « Software as a Service » (avec SharePoint Online) puis l’a intégré dans son offre Office 365 en 2013. Un client d’Office a ainsi directement la main sur SharePoint, à un prix très raisonnable, sans avoir à se préoccuper ni des machines hébergeant cet outil, ni d’aucune administration autre que fonctionnelle. Il s’en est suivi plusieurs révolutions pour nos métiers.
Microsoft hébergeant lui-même les serveurs SharePoint, il était hors de question qu’il s’aventure dans la maintenance des édifices applicatifs construits par-dessus le socle de base. C’est à partir de ce moment que les modèles de développement ont dû s’adapter : impossibilité de livrer sur SharePoint Online des packages contenant du code s’exécutant sur le serveur, déportation de l’hébergement des applications métier vers d’autres infrastructures et promotion du développement de code s’exécutant côté client.
SharePoint étant désormais accessible aux petites entreprises, l’évolution du produit s’est faite au profit de l’utilisateur final afin qu’il puisse s’affranchir de plus en plus facilement de sa dépendance vis-à-vis de l’équipe technique (IT ou développeur), minime ou inexistante dans ces structures. L’administration d’un tenant SharePoint Online couvre un spectre beaucoup moins large que l’administration d’une ferme SharePoint : il s’agit avant tout d’administration fonctionnelle et, avec de l’accompagnement, elle peut être faite par un profil non technique. De la même manière, la création ou la suppression d’un site SharePoint est maintenant à la portée des utilisateurs finaux (alors que de plus amples réflexions étaient nécessaires il y a quelques années). Avec l’interface Modern UI, il est plus simple que jamais d’ajouter des WebParts et des pages de contenu dans les sites.
Les versions On-Premise de SharePoint ne font que suivre, avec quelques années de retard, la révolution qui s’est ainsi opérée. Elles sont encore là pour quelque temps, mais leurs pratiques et usages restent anciens et vont devoir s’adapter.
SharePoint donne le pouvoir aux utilisateurs
Tous ces chamboulements ont permis à Microsoft de libérer SharePoint des usages un peu forcés qui ont précédé, et de le recentrer vers son but premier : la collaboration et le travail en équipe.
Beaucoup d’outils et de solutions ont été ajoutés à l’écosystème de SharePoint : Yammer, Teams, Power BI, Graph, Flow, PowerApps, etc. En contrepartie, SharePoint n’est plus le principal point d’entrée du poste de travail numérique : c’est un peu la colonne vertébrale de la suite Office 365 ; il n’est plus en façade mais centralise les communications et facilite la mise en commun des flux.
Les processus de création et de développement de solutions s’appuyant sur SharePoint ont été simplifiés et ne nécessitent plus beaucoup d’expertise technique. Avec ces évolutions, on peut avoir du mal à voir ce que deviendront les consultants spécialisés en développement et en administration SharePoint. Pour l’un, le modèle de développement qui a été majoritaire (asp.net) n’est plus vraiment justifié, et n’est de toute façon pas supporté par SharePoint Online ; pour l’autre, une grande part de ce qui faisait sa spécificité tend à se raréfier.
En effet, les futurs profils de développeurs SharePoint seront très différents de ce qu’a été dans le passé le développeur SharePoint. Certains se spécialiseront dans le développement autour de l’écosystème SharePoint Framework et tendront à devenir des développeurs web FRONT END ou FULL STACK classique, tant par les technos utilisées, que par les outils ou les méthodes. D’autres développeurs glisseront petit à petit vers le développement Azure, tout en mettant à profit leur connaissances de Microsoft Graph ou l’API REST de SharePoint.
La grande tendance qui vient est le développement d’applications low code / no code, via la Microsoft Power Platform, l’idée étant de faire gagner beaucoup de productivité avec très peu de lignes de code et un contexte d’exécution sans surprise. Et, dans cette tendance, un développeur SharePoint aura des atouts majeurs tant par sa connaissance de SharePoint (qui est en quelque sorte le liant entre les différentes interfaces utilisateur) que par ses expériences dans le développement d’applications et par le soutien technique qu’il pourra apporter aux utilisateurs “avec pouvoir”. Ce sujet fera l’objet d’un prochain article.
Vous souhaitez en savoir plus ? Découvrez notre playground Distributed Cloud
