« couteau Suisse », c’est le nom que je donne à SharePoint pour illustrer l’étendu des usages possibles. Pourtant, pour l’essentiel de ses utilisateurs, SharePoint c’est essentiellement un serveur de fichiers amélioré, sans plus. C’est un erreur, SharePoint peut proposer bien plus. Mais peut-on vraiment tout faire avec SharePoint, sans limite ? SharePoint, brique de la digitalisation interne J’en ai déjà parlé et j’en reparlerai : SharePoint est selon moi une des briques essentielles de la Digitalisation interne de l’entreprise, au même titre qu’un RSE pour la partie conversationnelle. Par du simple paramétrage, il permet de mettre en œuvre des solutions qui permettront de fluidifier les échanges entre les équipes dans leur travail de tous les jours, et ainsi limiter le flux de mails sans cesse grossissant. Pour cela, du simple paramétrage natif suffit dans la plupart des cas : tout est terminé en quelques heures, maximum un jour ou deux, en parfaite agilité et pour un coût économique sans concurrence. Mais parfois, ça ne suffit pas. Pour apporter les quelques fonctionnalités qui manquent, il est parfois nécessaire alors de faire des paramétrages plus poussés ou de développer des fonctionnalités supplémentaires qui s’intégreront dans un site SharePoint. Reste à savoir si c’est vraiment nécessaire, et si ça l’est, de connaître les limites de l’outil pour ne pas les dépasser. Surveiller la complexité SharePoint est un outil hautement paramétrable (trop, lui reprocheront ses détracteurs). Par du simple clic vous pouvez faire d’un site SharePoint un classique outil de Gestion documentaire, un outil métier de gestion d’informations structurées, un outil de gestion de Workflow, ou plein d’autres choses encore. L’important c'est de mesurer la complexité de ce que vous voulez réaliser. Car en fonction de cette complexité, les hommes qui le feront (de l’utilisateur lamba en toute autonomie, jusqu’au développeur informatique, en passant par l’expert SharePoint), et les moyens pour le faire seront différents. Sans parler du coût qui peut aller de quasi rien à beaucoup (trop). Afin d’expliquer cela à des clients internes qui avaient coutume d’en demander trop à l’outil, j’avais réalisé ce schéma. Il illustre la nature des moyens à mettre en oeuvre pour répondre à des besoins selon la complexité de ce qu’on demande à SharePoint.
Si les limites entre chaque zone sont franches sur le dessin, elles sont nettement moins faciles à appréhender dans la réalité du terrain. Ici, l’expertise du professionnel est capitale pour savoir déterminer dans quelle zone on se trouve et quels moyens à mettre en oeuvre. Elle est également essentielle pour « sentir » approcher la limite au delà de laquelle SharePoint n’est pas la bonne réponse. Savoir reconnaître la limite à ne pas franchir Les possibilités de SharePoint sont immenses, mais comme pour tout progiciel, il y a une limite qu’il est souhaitable de ne pas franchir, tout simplement parce qu’au delà d’une certaine complexité technique et fonctionnelle, cela revient à contraindre fortement l’outil. Le danger serait alors de dénaturer SharePoint pour lui faire offrir des fonctionnalités qu’un développement spécifique aurait pu fournir mieux, plus rapidement, et moins cher. A lire mon article qui évoque ce phénomène, non sans humour : "Histoire de progiciel". Ici, l’expertise et l’expérience sont essentielles pour « sentir » approcher cette limite floue entre la zone de confort de SharePoint et la zone dans laquelle il ne faut pas s’aventurer. L’expert doit savoir dire stop à son client (interne ou pas). Sa position ne plaira peut-être pas, mais les conséquences (pour lui et pour l’entreprise) seront moindres qu’un échec à l’issue d’un projet qu’il sait par avance long, coûteux et fortement risqué. Reste que cette limite se franchit souvent progressivement, au fur et à mesure de l’avancement d’un projet agile, et de l’ajout de petites fonctionnalités supplémentaires qui finissent par surcharger la barque. C’est le principe de la goutte d’eau qui, à force, fait déborder le vase. Avec Office 365, Microsoft adopte une posture beaucoup plus affirmée sur ces questions, en recommandant clairement de ne plus faire certains types de développements dont la pérennité ne pourra plus être assurée du fait de l’évolution de versions en mode Cloud, sans que le client n’ait le choix de migrer, ou pas. Ca fera l’objet d’un prochain bilet.