Intranet, documents, calendrier, tâches, formulaires, workflows : toutes ces réponses complètent « SharePoint sert à… ». Pour une équipe, cette polyvalence devient du flou. Pour l’architecture, ce sont surtout différents assemblages de listes, pages, permissions et services.

Une Web Part sur la page d’accueil n’est pas la donnée elle-même. Elle exécute du code côté serveur, lit une liste ou un service, puis produit du HTML. Deux Web Parts peuvent afficher des vues différentes de la même liste. Si chaque composant conserve sa propre copie, le portail ne rassemble rien; il juxtapose des états divergents.

page d'équipe
  |-- Web Part Documents -> bibliothèque Projet
  |-- Web Part Tâches    -> liste Tâches
  `-- Web Part Nouvelles -> liste Communications
                              |
                              `-> base de contenu SQL Server

Je ne travaille pas nécessairement avec SharePoint dans mon rôle actuel, mais le produit illustre bien une décision d’architecture : quel objet est la source de vérité et quel geste la page doit-elle rendre plus court?

Exemple : suivre une demande d’équipe

Je commencerais avec une liste contenant Demandeur, Sujet, Responsable, Statut et Échéance. Le formulaire crée un élément avec un identifiant. Une vue montre les demandes ouvertes de la personne connectée; une autre montre celles en retard pour le responsable.

Nouvelle -> Assignée -> En cours -> Résolue -> Fermée
                 |                    |
                 `-> En attente ------'

Les transitions peuvent déclencher une alerte, mais l’état reste dans la liste. Le courriel attire l’attention; il ne devient pas la base de données. Une règle empêche de fermer sans résolution et un historique indique qui a changé le statut.

Les permissions méritent une vraie frontière. Une vue filtrée ne protège pas les éléments : elle ne fait que les afficher différemment. Si une demande contient de l’information sensible, il faut des droits au niveau approprié ou une liste distincte, puis tester avec un compte non autorisé. Une personnalisation qui cache un bouton n’empêche pas un appel direct.

La page peut aussi devenir lente. Chaque Web Part exécute une requête, et une liste sans index sur la colonne filtrée doit examiner beaucoup d’éléments. Ajouter quinze composants crée autant de dépendances et de modes d’échec. Je mesurerais le temps de rendu et retirerais une Web Part dont l’usage ne justifie pas le coût.

La recherche suit encore un autre cycle. Le crawler découvre les éléments après leur création et les place dans son index; il peut donc y avoir un délai avant qu’une demande soit trouvable par mots-clés. La vue de travail doit rester capable de montrer immédiatement l’élément par son identifiant et son statut, sans dépendre du prochain crawl.

Le cycle de vie reste important. Qui corrige le workflow si son auteur part? Comment exporte-t-on les demandes? Que se passe-t-il si l’alerte SMTP tombe? Une vue des éléments bloqués et une procédure de réassignation empêchent le processus de dépendre d’un seul message.

Avant d’ajouter la prochaine Web Part, je terminerais encore la phrase « dans cet espace, on vient d’abord pour… ». Puis je suivrais un élément de sa création à sa fermeture, avec un compte autorisé et un autre qui ne l’est pas. Un petit espace compris de tous vaut mieux qu’une page complète dont chaque composant possède sa propre vérité.