Recherche IA sur site
Comment transformer la barre de recherche de votre site en chat IA
Reliez un chat IA à la recherche du site, validez le sélecteur, conservez les résultats classiques et testez l’accessibilité mobile.
6 min de lecture
Un champ de recherche existant peut lancer des réponses IA fondées sur des sources sans supprimer la recherche classique. Choisissez l’apparition de l’IA, validez l’input ciblé, préservez l’accès aux résultats ordinaires et testez la qualité des réponses comme le fallback avant tout déploiement.
Michael Shamanoff, fondateur d’Achla AI. Ce guide repose sur l’inspection du produit et du widget actuels, la recherche concurrentielle approuvée et un plan de recette reproductible. L’IA a aidé à la rédaction ; chaque affirmation matérielle est reliée au claim ledger. Sources revues le 3 août 2026.
Choisissez ce qui se passe quand un visiteur appuie sur Enter
Une « barre de recherche IA » peut désigner trois interfaces. Le choix dépend de la tâche et de la stabilité de la page. Le code Achla propose attach, inline et bubble, mais cela ne prouve pas leur fonctionnement avec chaque thème, formulaire, navigateur ou technologie d’assistance.
| Placement | Expérience | Meilleur usage | Risque principal |
|---|---|---|---|
| Attach | L’input familier ouvre un dialog lors de la soumission. | Un input stable de type text ou search. | Changement du selector, conflit de formulaire, autocomplete, focus et écran étroit. |
| Inline | Une zone IA dédiée se trouve dans la page. | Une page de contenu ou d’aide. | Clarté, responsive layout et expériences dupliquées. |
| Bubble | Un contrôle flottant ouvre l’interface. | Aucun champ fiable ou fallback d’attach. | Découverte, chevauchement, mobile et parcours keyboard. |
Attach préserve le point d’entrée familier ; inline rend l’IA explicite ; bubble est indépendant mais pas universellement supérieur. Voyez pourquoi les visiteurs peuvent préférer une réponse à une liste de pages.
Conservez les résultats classiques lorsqu’ils répondent au besoin
La recherche traditionnelle reste utile pour les noms exacts, documents, termes proches d’un SKU, filters, facets, autocomplete et navigation exhaustive. L’IA sert une question naturelle et une réponse concise avec sources. Ces rôles sont complémentaires.
L’implémentation attach inspectée comprend « Show regular results », qui ferme l’interface et soumet le formulaire hôte lorsqu’il existe. C’est un fait du code actuel, pas une garantie. Un input sans formulaire, des résultats pilotés par JavaScript ou un framework qui remplace submit exigent un browser test.
- préservez l’URL et le comportement de soumission ;
- vérifiez autocomplete, filters, analytics et keyboard submission ;
- rendez les résultats accessibles si la réponse manque ;
- ne présentez pas l’IA comme une couverture exhaustive ;
- documentez la désactivation de l’interception.
Voir ajouter une recherche IA sans créer de backend.
Configurez attach comme un test réversible
- Notez le baseline natif : Enter, bouton, autocomplete, URL, filters, analytics et focus sur desktop et mobile.
- Choisissez un input stable : le selector doit résoudre exactement un
inputtextousearchsur chaque template. - Validez le selector :
querySelector()lèveSyntaxErrorpour un CSS invalide et renvoienullsans correspondance, selon MDN. - Utilisez du contenu public vérifiable : définissez questions connues, pages attendues et cas no-answer ; consultez la préparation des titres pour RAG.
- Activez sur staging : répétez le baseline sur templates, breakpoints, zoom, parcours keyboard et une assistive technology ; vérifiez SPA et inputs tardifs.
- Fixez pass, fail et rollback : acceptez seulement si la recherche ordinaire fonctionne, les réponses connues citent les bonnes pages, les questions non prises en charge échouent honnêtement, le focus est utilisable et le viewport suffit.
Le widget bascule vers bubble si le selector est invalide, ne trouve pas d’input approprié ou ne peut pas le revendiquer. Ce comportement défensif doit être confirmé sur le vrai staging.
Testez les échecs du selector avant la production
| Condition | Résultat sûr attendu | Observation dans le browser |
|---|---|---|
| CSS invalide | Attach ne se lie pas ; fallback disponible. | Recherche intacte, aucune error non gérée. |
| Aucun résultat | Aucun autre élément n’est pris. | Bubble/alternative apparaît ; recherche inchangée. |
| Mauvais type | Le control non textuel est refusé. | Aucun button, container ou input caché intercepté. |
| Plusieurs templates | Chaque page respecte le contrat. | Header, mobile, contenu et locales sont cohérents. |
| Propriété dupliquée | Une cible occupée n’est pas réutilisée. | Une interface, aucun submit ou UI double. |
| Input tardif/remplacé | Le lookup initial peut le manquer. | SPA, hydration, modal headers et délai testés. |
Le succès sur une page ne prouve pas une compatibilité universelle avec thèmes ou frameworks.
Rendez le dialog utilisable au clavier et au lecteur d’écran
Le code contient un accessible name, des controls nommés, une région aria-live="polite", Escape, retour du focus et confinement de Tab. Ce sont des mécanismes utiles, pas un résultat de conformité WCAG.
Utilisez le dialog pattern officiel du W3C : un modal garde Tab à l’intérieur, accepte Escape, possède un nom, déplace puis rend le focus. L’interface utilise role="dialog" ; initial focus et modalité doivent être décidés et testés.
Vérifiez labels, focus visible, Enter/Escape/Tab/Shift+Tab, annonces programmatiques, reduced motion et zoom. Le guide Status Messages explique l’exposition des changements ; WCAG 2.2 contient les critères normatifs. Lire JavaScript ne suffit pas.
Exécutez le test mobile à 320, 360, 390 et 412 CSS pixels
Le code attach calcule un dropdown d’au moins 360 pixels. À 320 CSS pixels, il existe donc un risque concret d’overflow ou d’obstruction. Testez zoom, agrandissement du texte, virtual keyboard, sticky headers, paysage, fermeture, défilement, liens et retour aux résultats. Le guide Reflow du W3C prend l’équivalent de 320 CSS pixels comme cible. Ce n’est pas une affirmation de conformité.
Évaluez les réponses et la sortie avec les mêmes requêtes
| Type de requête | Preuve attendue |
|---|---|
| Réponse connue | Citation de la page publique attendue qui soutient la formulation. |
| Paraphrase | Source adaptée sans changement de sens. |
| Question ambiguë | Clarification ou absence de réponse trop sûre. |
| Question non prise en charge | État no-answer honnête. |
| Page périmée/supprimée | Besoin éventuel d’étudier refresh/removal. |
| Titre exact/navigation | Sortie vers les résultats ordinaires. |
Consignez question, réponse visible, cited URL, source attendue, no-answer, action de résultats, viewport, browser et pass/fail. Voir comment citations et refus honnêtes créent la confiance.
Sachez quand ce chatbot n’est pas adapté
L’article concerne des réponses fondées sur le contenu public du site. Il n’établit pas la prise en charge de réponses privées/account-aware, files/PDF, collecte de leads, actions CRM, live-agent, réservations, achats, voice, omnichannel ou open web. Il ne revendique ni délai de setup, search volume, hausse de traffic, conversion, support deflection, compatibilité browser universelle ni accessibility compliance.
Lancez seulement après la réussite des deux parcours
Le parcours IA n’est prêt que pour une revue humaine lorsque le selector est stable, le fallback observable, les réponses connues soutenues, les questions non prises en charge honnêtement limitées, et les tests keyboard/mobile documentés. La recherche classique doit conserver submit, résultats, autocomplete/filters et rollback.
Si vous recherchez des réponses managées et sourcées sur du contenu public, évaluez la configuration Achla correspondante. C’est une prochaine étape contextuelle, pas la preuve d’un test de production réussi.
Questions fréquentes
Puis-je conserver autocomplete ?
Potentiellement, mais vérifiez sur le site. Enter, sélection de suggestion, focus et submit doivent rester corrects ; toute régression est un échec.
Que se passe-t-il si le CSS selector change ?
L’implémentation peut passer à bubble. Testez navigation et client-rendered routes, surveillez l’élément après un changement de thème et gardez la recherche normale.
L’IA doit-elle remplacer la page de résultats ?
Pas par défaut. Les réponses aident pour l’explication ; les résultats restent adaptés aux titres, produits, filters et navigation exhaustive.
Que faire sans réponse étayée ?
Montrez un état no-answer/error honnête, gardez les sources visibles et offrez un chemin clair vers les résultats. N’inventez pas une réponse confiante.
Bubble est-il plus sûr qu’attach ?
Il est plus indépendant et peut servir de fallback, mais exige encore des tests keyboard, obstruction, découverte, mobile et thème. « Séparé » ne signifie pas accessible automatiquement.
