Tag : Sharepoint

SharePoint, développement et performance ne sont pas des concepts incompatibles. S’il n’est pas rare que « fin de projet » rime avec « chantier d’optimisation » ou encore « taskforce », cela résulte plus souvent de manquements durant la conception que de la technologie en elle-même.

Une chose est sûre (et cela est applicable à tout projet logiciel) : la performance se réfléchit, se pense et se conçoit dès le début.

Définir les critères d’acceptabilité de la performance

La première action à mener est de qualifier la performance par des critères objectifs et chiffrés. C’est ainsi que des indicateurs tels que « temps de réponse de pages » (comprendre le temps que met l’application à envoyer une page à votre navigateur), en utilisation normale ou en pic de charge, doivent être définis en amont de toute activité. Ils constitueront les critères d’acceptabilité de la performance de l’application.

Définir l’utilisation de l’application

Une fois ces objectifs établis, il conviendra d’établir des hypothèses qualifiant l’activité attendue pour l’application. En effet, un portail intranet pour 50 utilisateurs n’impose pas les mêmes précautions que la mise en place d’un site internet world wide affichant plus de 100 000 visiteurs uniques par jour.

On cherchera alors à définir :

• Combien d’utilisateurs cibles utiliseront l’application
• La répartition sur une journée « type » des utilisateurs de l’application
• Les usages auxquels est destinée l’application (recherche, affichage de pages, contribution documentaire, etc…)
• En somme, tout ce qui doit permettre de conceptualiser et d’anticiper l’usage de l’application, et les différents services pour lesquels une attention particulière devra être apportée.

En général, suite à ces travaux, on pourra définir l’architecture de la plateforme, ou plus simplement : Combien de serveurs, quels rôles pour chaque serveur, etc…

La communication entre IT et Développeurs : indispensable

Etablir des relations entre équipe IT (appelés communément « infras ») et équipe projet (appelés les « dévs ») est un atout pour assurer la cohérence de votre projet. Chaque équipe a son expérience, ses activités, ses idées préconçues sur l’autre équipe… et pourtant leurs expertises sont complémentaires.

Ne demandez pas à un développeur de parler I/O disque, ne demandez pas à un IT de parler JQuery… mais sensibilisez chacune des parties aux contraintes de l’autre, et vous serez surpris par le nombre d’écueils qui seront évités.

En résumé, impliquer chacune des parties dès la phase de conception, créer des vecteurs de communication dépassant les phases de validation, permettre l’échange sans jugement de valeur: Etablir une synergie entre ces expertises couvrant l’ensemble des tenants et des aboutissants de votre projet.

L’architecte : pièce maitresse de votre projet

Il n’existe pas une seule définition du rôle d’architecte.

Je le résumerais ainsi : Garant de la cohérence de tous les aspects techniques de votre projet ; du respect des contraintes, des objectifs et des attentes du métier.

Concrètement, quel doit être le rôle de votre « architecte » pour la performance ?

Il ne peut pas tout savoir, c’est vrai. Il ne peut pas tout concevoir, c’est sûr. Mais il doit être capable de comprendre, de voir, d’anticiper… Il est indispensable, par exemple, qu’il puisse, à partir d’une expression de besoins (qui parfois se traduiront par des spécifications fonctionnelles…), prédire quelles seront les briques mises à contribution, les points d’attention, les risques.

In fine, il doit mettre en corrélation « usages de l’application », « hypothèses d’utilisation », « expression de besoin », « technologie », et ainsi définir l’architecture la plus à même de satisfaire à tous ces aspects.

Connaître SharePoint, rechercher l’efficacité et être pragmatique

Si votre lecture vous amène jusqu’à ces quelques lignes, vous avez pu vous apercevoir que tout ce qui est expliqué ici peut s’appliquer à n’importe quel projet applicatif, à n’importe quelle technologie.

Parlons donc un peu « SharePoint ».

Encore et toujours, deux faces d’un même projet : Infrastructure et Développement.

Deux chantiers liés, présentant des dépendances, et devant donc être cohérents, en particulier durant la phase de conception.

Le design d’une infrastructure SharePoint doit prendre en compte les développements qu’elle va héberger. Inversement, la conception d’une application ne peut pas faire abstraction de l’infrastructure sur laquelle elle repose.

Mon expérience m’amène à penser que la conception de l’application doit être initiée en amont. C’est elle qui permettra d’identifier les contraintes et les besoins de la plateforme tels que les services SharePoint nécessaires (ex : la recherche) et la manière dont ils seront sollicités. Par exemple, une ferme hébergeant une application de type « Search Driven Architecture » (application conduite par la recherche) ne présentera pas la même architecture qu’une application de GED collaborative, disposant d’un centre de recherche.

L’un des facteurs fondamentaux devant assurant la performance de votre application : être pragmatique, à la recherche constante d’efficacité.

Cela se traduira par :

• Challenger les expressions de besoin présentant un risque technique, dans le but d’assurer leur criticité au regard des impacts potentiels,
• Assurer son devoir de conseil lorsque l’on anticipe qu’une fonctionnalité native du produit ne sera pas en mesure de répondre à l’usage envisagé,
• Ne pas hésiter à penser la mise en œuvre de scénarios fonctionnels pouvant atteindre les limites du produit sur une brique tierce,
• Penser à des mécanismes de cache applicatif (mémoire, cache redis, base SQL, etc…)

Enfin, pour parler purement SharePoint, espérer tirer le meilleur parti de la technologie sans discuter de concepts tels que Blob Cache, Object Cache, Ouput Cache est illusoire. D’ailleurs, au-delà d’en discuter, connaître leur opportunité, leurs contraintes, leurs limites… et en quoi ils vont influencer la conception des développements.

Valider la performance

Enfin, comment valider la performance ?

Quel que soit votre choix, vous vous devez de disposer d’un outillage vous permettant de procéder à différentes campagnes de tests de charge et performance.

SharePoint étant un progiciel, reposant sur une infrastructure, il sera nécessaire d’établir une base de référence. On entend ici le fait de procéder à l’exécution d’une campagne de test, présentant un plan de montée en charge similaire à vos hypothèses, mais ne sollicitant que des composants « standards » du produit sur un environnement vierge de toute application développée.

Vous aurez ainsi :

• Etabli un bilan de santé de l’infrastructure, hors de toute couche applicative supplémentaire, et donc valider ses performances
• Une grille de comparaison utile lorsque vous procéderez à des campagnes de tests sur votre application
• Vous pourrez ensuite mener les campagnes de tests et analyses nécessaires pour estimer si vos ambitions de performance sont atteintes.

Si cette démarche n’exclut pas de devoir conduire des « chantiers d’optimisation » en fin de projet, mon expérience, basée sur la mise en œuvre d’applications reposant sur SharePoint à destination de plus de 50.000 utilisateurs aux quatre coins du monde (organisme d’état, grand groupe français dans le domaine du luxe, …), m’amène à la considérer comme un garde-fou permettant d’éviter de nombreux écueils. Elle assure surtout de ne pas avoir à « tout refaire » à deux semaines de l’ouverture en production.

Article rédigé par Guillaume VINCENT, Software Architect chez AEROW.

Retrouvez cet article sur Linkedin : Lien vers l’article