SharePoint 2010 relance les ambitions de portail. La vraie différence ne se trouve pas dans une fonctionnalité précise : elle apparaît entre une collection de sites pour vingt personnes et une ferme qui héberge deux mille espaces, des bibliothèques critiques et des workflows quotidiens.

Une ferme SharePoint répartit plusieurs rôles. Les serveurs web reçoivent les requêtes, les serveurs d’application exécutent entre autres la recherche et certains services partagés, puis SQL Server conserve la configuration, le contenu et les index associés. Un répartiteur peut distribuer le trafic entre plusieurs frontaux. Cette séparation offre de la capacité et de la redondance, mais ajoute des dépendances à surveiller.

La croissance se cache dans les bases de contenu

Un site d’équipe ajoute des listes, versions de documents, permissions, corbeilles et historique. Deux mille sites multiplient tout cela. Si toutes les collections vivent dans une seule énorme base de contenu, une sauvegarde, une restauration ou une maintenance SQL peut devenir trop longue. Je répartirais les collections selon leur taille et leur criticité, avec des seuils et un chemin de croissance connus.

Un exemple de fiche de création pourrait contenir :

• propriétaire principal et remplaçant;
• usage prévu et niveau de confidentialité;
• quota initial;
• date de révision;
• base ou groupe d’hébergement;
• règle d’archivage.

Le service crée ensuite le site à partir d’un modèle approuvé et enregistre ces informations dans un inventaire. La création reste rapide, mais elle laisse une trace exploitable. Quand le propriétaire quitte, le remplaçant reçoit une demande; sans réponse, l’espace passe en lecture seule avant archivage.

Les permissions individuelles sont un autre multiplicateur. Dans une petite équipe, ajouter Marie directement semble innocent. À grande échelle, ce lien survit au changement de rôle et devient invisible. Les groupes SharePoint reliés à des groupes Active Directory rendent le modèle plus explicable. Les bibliothèques très sensibles peuvent rompre l’héritage, mais l’exception doit être rare et auditée.

Concevoir la reprise avant la panne

Une sauvegarde SQL cohérente est nécessaire, mais elle ne répond pas à toutes les restaurations. Pour récupérer un document supprimé, la corbeille ou une restauration granulaire peut suffire. Pour perdre une base de contenu, il faut remettre la base, rattacher les collections et vérifier la compatibilité avec la configuration de la ferme. Pour perdre toute la ferme, il faut aussi reconstruire les services, comptes, certificats, solutions déployées et paramètres.

Je donnerais à chaque scénario un RPO et un RTO. Le RPO indique combien de données on accepte de perdre; le RTO, combien de temps le service peut rester indisponible. Une sauvegarde nocturne donne au mieux un RPO proche de vingt-quatre heures. Si une bibliothèque de procédures ne peut perdre que quinze minutes, le mécanisme doit être différent.

La performance se dégrade souvent par accumulation : grandes listes mal filtrées, trop de versions, web parts coûteuses, crawls de recherche et croissance du journal SQL. Ajouter un serveur web ne corrige pas une requête lente dans la base. Il faut mesurer temps de réponse, files d’attente, erreurs, taille des bases, latence SQL et durée des opérations de sauvegarde.

Je ne monterais pas une police du portail. Je fournirais un landing zone : quelques modèles, un catalogue, des groupes standards, des limites connues et un processus de fermeture. Puis je testerais chaque trimestre la restauration d’une collection de sites choisie au hasard. Le deux millième site reste facile à créer; l’architecture prouve sa valeur lorsqu’on peut encore l’expliquer, le déplacer et le restaurer.