« Alors là, tout le monde se dit, ça y est, il a craqué, il a trop fait de SharePoint, son cerveau a fondu… Bien-sûr qu’un SharePoint ça existe, j’en connais même plein… ».

Et je vous répondrai : « Non ». Non, vous ne connaissez pas de développeurs SharePoint, mais des développeurs, voire des développeurs Web spécialisés sur SharePoint. Il s’agit de sémantique, mais la nuance est importante, comme j’espère vous en convaincre dans cet article. Voici donc un double coup de gueule sur base de sémantique : pour les développeurs et pour les SSII/recruteurs.

Mon premier coup de gueule concerne donc les développeurs eux-mêmes

(et surtout ceux qui travaillent sur SharePoint On-Premise). Je rencontre de plus en plus de « développeurs  SharePoint » qui ont oublié que SharePoint est avant tout une techno web, basée sur ASP.Net et donc sur .Net. Travailler avec une techno web implique d’en connaître les spécificités ET d’en accepter les conséquences : HTML, CSS, JavaScript. Car c’est bien de cela qu’il s’agit, dans les projets les développeurs rechignent quand il faut faire du CSS, sont rebutés à l’idée de claquer un bout de JS à droite à gauche, et considère que le HTML ce n’est pas assez bien pour eux… Cependant cela fait partie intégrante du développement sur SharePoint (notez que je n’ai pas parlé de « développement SharePoint »).

Tout sur SharePoint sait qu’il existe des spécificités à cette plate-forme telles que les fonctionnalités (features), les gestionnaires d’évènements, les types de contenu, etc… Il faut bien évidemment maîtriser ces concepts, mais il faut également garder à l’esprit que faire du développement sur SharePoint c’est avant tout faire du développement ASP.Net, et donc faire du développement Web (certes avec un peu de retard sur ce qu’il se fait par ailleurs…). Il arrive parfois que l’on ait la chance d’avoir un intégrateur HTML/CSS dans une équipe, mais quand ce n’est pas le cas, il faut se rappeler que HTML/CSS/JS c’est AUSSI du développement SharePoint.

Nous avons tous envie de faire des trucs techno-hype-blingbling (+ digital, puisque c’est le mot à la mode en ce moment), et nous sommes tous enclins à vouloir déléguer les actions que l’on considère rébarbatives (comme la doc par exemple). Cependant, j’ai appris de mon premier employeur en que pour qu’un projet arrive pleinement à son terme, tout le travail doit être fait, y compris les tâches les plus insignifiantes. Et il n’existe pas de « préposé aux tâches que personne ne veut faire » (non, un stagiaire ça ne sert pas à ça…).

Voici donc mon conseil aux développeurs qui officient sur SharePoint : n’oubliez pas que vous êtes avant tout des développeurs Web. D’ailleurs, avec Office 365, le modèle d’Apps et le SharePoint Framework, Microsoft a remis au centre du scope SharePoint les technos web : CSS / HTML / JavaScript. Il serait exagéré de dire que développer pour Office 365 se résume à gérer ces langages, cependant leur utilisation est dans ce cas bien plus importante qu’un langage comme C#.

 

Mon deuxième coup de gueule concerne les SSII et les recruteurs : être développeur SharePoint ce n’est pas une fin en soi !

Je comprends le besoin de staffer les projets, je comprends le besoin de répondre à l’urgence d’une demande, et je connais bien la difficulté de trouver des ressources compétentes sur SharePoint. Cependant, comme dit précédemment, un développeur sur SharePoint c’est avant tout un développeur, et s’il est probable que celui-ci ait eu une vie avant SharePoint, il est certain qu’il en aura une après.

D’ailleurs, ce que j’indique ici pour le développeur est valable pour tous les autres rôles liés à SharePoint : chef de projet, administrateur, architecte,…  SharePoint est une plate-forme pleine de spécificités mais cela ne reste qu’un outil. Les démarches, les bases et les concepts peuvent tout aussi bien s’appliquer à d’autres outils ou d’autres domaines.

Il est tentant pour une SSII de cantonner ses collaborateurs dans un domaine particulier, d’autant plus que les développeurs sur SharePoint sont parfois « déconnectés » de la réalité de leur domaine (comme indiqué précédemment). Cependant il me semble important de ne pas oublier de maintenir leurs compétences à jour. L’arrivée du SharePoint Framework devrait être un bon moyen pour les développeurs de se remettre à niveau sur les frameworks et outils actuellement en vogue dans le développement Web.

De la même façon il est tentant pour un recruteur de se cantonner à la demande initiale, mais il est important selon-moi de voir plus loin, et d’inclure pleinement les développeurs sur SharePoint dans l’écosystème des développeurs (et non pas comme un être à part qui ne pourrait pas faire autre chose que du SharePoint…).

Bien que SharePoint ne soit pas menacé à court-terme, il est probable qu’un jour ce produit soit remplacé par autre chose. Cet « autre chose » sera peut-être complètement différent de ce que nous connaissons aujourd’hui… Tout miser sur SharePoint est un risque important, sauf si l’on se souvient encore une fois que cette plate-forme repose sur des bases qui sont bien plus large que cet outil : le développement web et le framework .Net. En tant que recruteur ou « responsable de pôle » dans une SSII, ne pas imaginer ce futur est selon moi une faute importante, qui amènera inéluctablement à devoir gérer des profils « hors du marché du travail ».

En attendant ce changement, je retourne à mes projets, j’ai du CSS à finir. Oui on peut être architecte et mettre les mains dans le cambouis. Et en plus j’aime ça.

Edgar Maucourant

edgar maucourant

Edgar Maucourant est Architecte logiciel spécialisé sur SharePoint
Retrouvez son article et son profil sur LInkedin