Quand plus personne ne parle du projet SharePoint, c’est souvent bon signe : le portail est devenu une habitude. C’est aussi le moment où les responsabilités se brouillent. L’équipe plateforme garde les serveurs debout; elle ne peut pas décider si la procédure de remboursement affichée dans une bibliothèque est encore valide.

Le service complet possède au moins quatre couches. L’infrastructure fournit les frontaux, services SharePoint et bases SQL. La configuration définit collections de sites, recherche et quotas. Les espaces d’équipe portent bibliothèques, types de contenu et permissions. Enfin, les propriétaires métiers gèrent la validité des documents. Une seule équipe ne peut connaître ces quatre réalités.

Deux files de travail, deux propriétaires

Je séparerais les incidents techniques des problèmes de contenu. Une requête comme « le site retourne 500 » va à l’exploitation avec URL, heure et identifiant de corrélation. « Cette politique est périmée » va au responsable inscrit dans la métadonnée du contenu. Le catalogue du site doit indiquer les deux contacts.

Pour une bibliothèque de procédures, le fonctionnement pourrait être :

1. l’auteur soumet une nouvelle version;
2. le responsable métier approuve et fixe la prochaine révision;
3. SharePoint publie la version majeure et le crawler l’indexe;
4. quatre semaines avant l’échéance, une tâche est créée;
5. sans réponse, la page affiche à revoir et cesse d’être favorisée dans la recherche.

Le workflow ne juge pas le texte. Il rend l’absence de décision visible. Une escalade vers le gestionnaire après un départ évite que le rappel tourne indéfiniment vers un compte désactivé.

Exploiter l’usage réel

Les métriques doivent dépasser le nombre de sites. Je suivrais disponibilité, latence au 95e percentile, croissance des bases, erreurs de crawl, âge des sauvegardes et propriétaires manquants. Côté contenu : recherches sans résultat, pages officielles jamais revues, sites sans activité et part des accès individuels.

Fermer un site exige un flux prudent. On confirme qu’il n’héberge aucun processus actif, on exporte ce qui a une obligation de conservation, on retire les groupes externes, puis on place l’espace en lecture seule avant suppression. Une période de récupération protège contre la mauvaise décision. Archiver tout éternellement ne règle rien : les recherches restent polluées et les sauvegardes grossissent.

La plateforme peut aussi tomber pendant une mise à jour ou à cause de SQL. Les fenêtres, dépendances, comptes de service et solutions personnalisées doivent être inventoriés. Une restauration testée d’une collection de sites vérifie mieux la reprise qu’un rapport disant seulement que le job de sauvegarde est vert.

Je traiterais SharePoint comme un produit interne permanent : une petite feuille de route, un catalogue clair, des objectifs de service et un réseau de propriétaires métiers. Quand l’outil devient invisible, l’entretien doit devenir plus visible, sinon la tuyauterie continue de couler pendant que le contenu perd tranquillement sa valeur.