SharePoint ne sait pas ce que « version finale » veut dire

Prenons une recherche pour un contrat approuvé. SharePoint répond avec une pile de documents contenant contrat, mais la bonne version reste cachée. Pour comprendre pourquoi, il faut suivre le contenu avant la requête.

Le moteur de recherche ne lit pas directement toutes les bibliothèques à chaque mot tapé. Un composant d’exploration parcourt périodiquement les sources, ouvre les documents avec les filtres disponibles, extrait le texte et les propriétés, puis alimente un index. La requête consulte cet index préparé. C’est ce qui rend la réponse rapide, mais aussi ce qui crée un délai entre une modification et sa présence dans les résultats.

bibliothèques -> crawl -> extraction du texte et des propriétés
             -> index -> requête -> classement -> sécurité -> résultats

Le moteur connaît les mots de version finale.doc; il ne connaît pas l’intention derrière le nom. Si TypeDocument=Contrat, Projet=Alpha et Statut=Approuvé sont conservés comme propriétés et mappés pour la recherche, la requête peut enfin exprimer le besoin métier au lieu de chercher un mot vague.

contrat AND Projet:"Alpha" AND Statut:"Approuvé"

L’index doit respecter les mêmes portes

Un index central contient des références à beaucoup de contenu. Il ne doit pas devenir une façon de découvrir un document auquel l’utilisateur n’a pas accès. SharePoint applique un filtrage de sécurité aux résultats selon l’identité et les listes de contrôle d’accès connues. Une permission mal configurée à la source reste toutefois une permission mal configurée dans la recherche.

Le changement d’accès pose aussi une question de fraîcheur. Si un droit est retiré maintenant mais que l’index ne reçoit la mise à jour que plus tard, il faut comprendre comment la plateforme rafraîchit cette information et tester le délai. Pour un contenu très sensible, je ne me contenterais pas de supposer que « security trimmed » couvre toutes les mauvaises configurations.

Les métadonnées peuvent facilement devenir leur propre panne. Quinze champs obligatoires poussent les gens à choisir la première valeur. Une fausse valeur Approuvé est pire qu’un champ vide, parce que la recherche lui donne une apparence officielle. Je commencerais avec trois propriétés alimentant une vue ou une requête réelle, des valeurs contrôlées et un défaut seulement lorsque le contexte le garantit.

Il faut enfin surveiller le crawl. Un filtre incapable d’ouvrir un nouveau format, un compte d’exploration sans accès, un document corrompu ou un index plein peut laisser une partie du contenu derrière. Je voudrais voir la dernière exploration réussie, le nombre d’erreurs et un document témoin dont on connaît le texte. Une recherche vide ne permet pas de distinguer « aucun résultat » de « source jamais indexée ».

Je comparerais aussi l’heure de modification du document et celle de sa dernière présence dans l’index. Ce délai de fraîcheur devient un engagement compréhensible : une recherche qui accepte quinze minutes de retard n’a pas besoin de promettre l’instantané.

Pour un pilote, je choisirais dix contrats connus, j’ajouterais trois propriétés, puis je testerais les résultats avec un lecteur autorisé et un utilisateur qui ne doit rien voir. Le moteur n’invente pas le contexte. Il peut toutefois l’exploiter rapidement si nous le conservons au moment où quelqu’un le connaît encore.

Mise à jour de 2026

Le support de SharePoint 2007 a pris fin le 10 octobre 2017. SharePoint Online et SharePoint Server Subscription Edition ont remplacé cette génération, avec des moteurs et des expériences de recherche beaucoup plus modernes.

Le moteur ne peut toujours pas montrer un contenu que les permissions cachent, ni inventer tout le contexte que personne n’a conservé. Les références officielles donnent le cycle de vie de SharePoint 2007 et celui de SharePoint Server Subscription Edition.