Sur le terrain ce mois-ci, un utilisateur me lance la phrase qui résume tout : « Je sais que le document existe, je l’ai vu y’a deux mois, mais je suis pus capable de le retrouver. » On a déployé SharePoint 2007 avec sa recherche intégrée, qui est franchement bonne pour l’époque — un vrai moteur, pas juste une recherche de noms de fichiers. Pis pourtant, le monde cherche encore comme dans une chasse au trésor. Mon mandat d’architecte, c’est de comprendre pourquoi le moteur déçoit, alors qu’il est correct.

La réponse, je la connais, mais faut la montrer : un moteur de recherche, c’est aussi bon que ce qu’on lui donne à manger. Si tous les documents s’appellent « Document1.doc », « version finale.doc », « truc.xls », pis qu’y’a aucune métadonnée, le moteur a rien pour s’accrocher. Il indexe le texte, oui, mais il peut pas deviner que ce fichier-là, c’est un contrat, qu’il appartient au projet X, qu’il est approuvé. La recherche échoue pas à cause de la techno; elle échoue à cause de ce qu’on a négligé à l’entrée.

J’ai dessiné la chaîne pour le client, parce que c’est plus parlant qu’un long discours.

flowchart TD
    A[Document téléversé] --> B{A-t-il des métadonnées?}
    B -->|Non, juste un nom flou| C[Moteur indexe le texte brut]
    B -->|Oui: type, projet, statut| D[Moteur comprend le contexte]
    C --> E[Recherche: 200 résultats sans ordre]
    D --> F[Recherche: filtrée, pertinente]
    E --> G[L'utilisateur abandonne]
    F --> H[L'utilisateur trouve]

La vraie aventure, donc, commence avant la recherche : c’est au moment du classement. Ce que je propose, c’est d’arrêter de demander au monde de bien nommer leurs fichiers — ça marche jamais — pis de mettre plutôt des colonnes obligatoires sur les bibliothèques. Type de document, projet, statut. L’utilisateur choisit dans une liste au lieu d’inventer un nom. Pis là, le moteur a de quoi travailler. On peut filtrer, trier, raffiner. La recherche arrête d’être un coup de dés.

Côté technique, quand on bâtit une vue ou une recherche personnalisée, on s’appuie sur ces colonnes-là. Une requête CAML bien faite, ça cible les bons documents au lieu de tout ramener.

<!-- Requête CAML: les contrats du projet X encore actifs -->
<Where>
  <And>
    <Eq><FieldRef Name='TypeDocument' /><Value Type='Choice'>Contrat</Value></Eq>
    <Eq><FieldRef Name='Statut' /><Value Type='Choice'>Actif</Value></Eq>
  </And>
</Where>

Là où ça brasse, c’est que personne aime remplir des champs. Demander à un utilisateur pressé de choisir un « type » pis un « projet » à chaque téléversement, c’est une vente difficile. Le truc, c’est de réduire au strict minimum : deux ou trois colonnes, pas quinze. Pis de mettre des valeurs par défaut intelligentes selon l’endroit où il téléverse. Si la bibliothèque s’appelle « Projet X », ben le projet est déjà rempli. Moins on demande, plus les données restent propres.

Le piège que je nomme au client, c’est l’illusion que « la recherche va tout régler ». Le monde pense souvent qu’un bon moteur compense un mauvais classement. C’est le contraire. Un bon moteur sur un dépotoir, ça te donne une recherche rapide… dans le dépotoir. Tu trouves vite deux cents résultats, pis t’es pas plus avancé. La recherche amplifie l’ordre quand y’en a, pis amplifie le chaos quand y’en a pas.

Sur le terrain, je commence petit pis concret. On prend une seule bibliothèque, celle qui fait le plus mal, on ajoute deux colonnes, on reclasse les documents les plus consultés, pis on montre la différence : avant, trente secondes pour rien trouver; après, trois clics pour la bonne affaire. Cette petite démonstration-là convainc plus que n’importe quel argumentaire. Le monde voit le gain dans son propre quotidien.

L’autre affaire que je surveille, c’est ce que le monde cherche vraiment. Les requêtes qui reviennent, les mots qu’ils tapent, les affaires qu’ils trouvent jamais — ça me dit quelles métadonnées rajouter pis quelles vues créer. La recherche bien réglée, c’est jamais fini : ça s’ajuste à mesure qu’on comprend comment les gens pensent.

Ce que je retiens de ce mandat, c’est que retrouver un document, c’est pas un problème de moteur, c’est un problème d’organisation déguisé en problème technique. SharePoint 2007 a les outils; reste à les nourrir correctement. Mon rôle d’architecte, c’est moins de configurer la recherche que d’aider le client à structurer son contenu pour que la recherche ait une chance.

La suite, sobre : ajouter le minimum de métadonnées utiles, mettre des valeurs par défaut pour pas écœurer le monde, reclasser ce qui sert le plus, pis écouter les requêtes pour ajuster. C’est moins glamour que d’installer un moteur, mais c’est ça qui fait qu’un jour, retrouver un document arrête d’être une aventure.