Vous avez le dossier. Il est dans Fichiers, il s'ouvre, les pages se suivent correctement. Et vous cherchez une phrase que vous savez être dedans : une valeur de couple, une contre-indication, le paragraphe qui explique quoi faire quand le module refuse de démarrer.
Sur un ordinateur, vous ouvririez le dossier dans un éditeur et vous chercheriez dans tous les fichiers en trois secondes. Sur un iPad, il n'existe pas d'équivalent. Voici pourquoi, et ce qui permet de s'en sortir.
La recherche de l'app Fichiers cherche des noms de fichiers, pas leur contenu. Spotlight indexe ce que les apps lui donnent, et un dossier HTML déposé dans un espace de stockage ne lui donne rien d'exploitable : ni sommaire, ni titres, ni texte.
Quant à Safari, il n'ouvre pas un dossier local. Et même s'il ouvre une page isolée, son « Rechercher dans la page » ne regarde que cette page. Sur une documentation qui en compte trois mille, cela revient à chercher une phrase dans un livre en n'ayant le droit de regarder qu'une page à la fois. Si vous n'en êtes pas encore là, commencez par ouvrir un fichier HTML sur iPhone.
Quand on cherche dans un corpus technique, on ne cherche pas une occurrence. On cherche un endroit. Trois choses comptent, et elles sont rarement réunies :
Une bonne partie de la documentation ancienne est scannée. Un PDF scanné n'est pas du texte : c'est une image de texte. Aucune recherche ne peut y trouver quoi que ce soit tant que quelqu'un n'a pas lu l'image.
C'est faisable sur l'appareil, sans rien envoyer nulle part. Deux points font la différence dans la pratique : que ce soit à la demande (reconnaître automatiquement des centaines de PDF viderait la batterie pour rien), et que les tableaux restent des tableaux. Sur une fiche produit ou une notice, une ligne de tableau qui se transforme en bouillie de mots rend le résultat inutilisable, alors que c'est précisément là que se trouvent les valeurs qu'on cherche.
Le vrai obstacle n'est souvent pas technique. Vous savez ce que vous cherchez, mais pas le terme employé par la personne qui a rédigé le manuel : elle a écrit « purge du circuit », vous cherchez « vidange des freins ».
Poser la question en langage courant règle ce problème, à une condition : que la réponse reste le document. Sur une documentation technique, une réponse rédigée est une réponse reconstituée. Elle mélange volontiers deux procédures voisines et garde une valeur qui appartenait à l'autre modèle, avec le même aplomb. Sur un couple de serrage ou une posologie, cela ne se rattrape pas.
Ce qu'on veut, c'est le passage : le document, le chapitre, les pages. Et le texte d'origine, dans son contexte, pour voir ce qu'il y a autour.
Regardez où cette documentation est réellement lue. Sous un capot, dans un atelier au sous-sol. Dans un service hospitalier où le réseau s'arrête à la porte. À bord, en vol, en mer. Dans un train.
Une recherche qui a besoin d'envoyer votre requête à un serveur ne marche à aucun de ces endroits. Et une documentation d'entreprise, un dossier patient ou une revue technique sous contrat n'ont de toute façon rien à faire sur le serveur de quelqu'un d'autre. Une recherche qui s'exécute entièrement sur l'appareil règle les deux questions en même temps : elle marche sans réseau, et il n'y a rien à se demander sur ce qui est parti.
C'est ce que fait Pagira depuis la version 2.0. Vous ouvrez le dossier, vous tapez vos mots, et il cherche dans toutes les pages et tous les PDF d'un seul coup. Les résultats arrivent groupés par document, ouvrir l'un d'eux vous emmène à la bonne page avec vos mots surlignés, et l'onglet à côté accepte une question posée avec vos propres mots quand le terme exact vous échappe. Les PDF scannés se rendent cherchables à la demande. Tout se passe sur l'iPhone ou l'iPad, sans compte et sans connexion.