Comment on transforme des notices, des vidéos et des schémas techniques épars en un diagnostic fiable, traçable et compréhensible — pour quelqu’un qui n’est pas expert.

Votre appareil électronique tombe en panne. Un voyant clignote, un écran reste noir, un bouton ne répond plus. L’information pour le réparer existe : quelque part dans une notice de 120 pages, dans une vidéo de tutoriel de vingt minutes, ou sur un schéma technique que vous ne sauriez pas lire. Le problème n’est presque jamais l’absence d’information. C’est qu’elle est fragmentée, dispersée entre des formats hétérogènes, et inaccessible pour qui n’est pas du métier.

Chez Tagwiser, c’est ce problème que nous avons attaqué avec TagnIot, notre assistant de dépannage IA destiné à l’utilisateur final, pour tout type d’appareil électronique. La brique centrale de la réponse, c’est le RAG — Retrieval-Augmented Generation — combinée à une idée simple pour ancrer chaque réponse au bon appareil : une vignette NFC apposée dessus. Voici un retour d’expérience technique sur ce qui fonctionne, ce qui casse, et pourquoi le dépannage grand public est un terrain particulièrement exigeant pour le RAG.

Pourquoi pas simplement un gros LLM ?

La tentation est réelle : brancher un modèle généraliste et lui poser la question. Trois raisons rendent cette approche inadaptée.

D’abord, le coût de l’erreur est asymétrique. Quand la personne en face n’est pas un professionnel, une instruction fausse mais plausible peut endommager l’appareil — ou blesser l’utilisateur (batterie lithium, tension secteur, condensateurs chargés). Un modèle qui « invente » avec assurance est ici plus dangereux qu’utile.

Ensuite, la connaissance est propriétaire, fragmentée et vivante. Les notices, vidéos et schémas se comptent par milliers, changent à chaque nouveau modèle, et ne vivent pas dans les poids d’un modèle public. Un fine-tuning serait périmé dès sa mise en production, et incapable de citer sa source.

Enfin, la confiance repose sur la traçabilité. Un utilisateur doit pouvoir vérifier d’où vient un conseil — retrouver le passage exact de la notice ou le bon moment dans une vidéo. Une réponse sans source est, dans ce contexte, inexploitable.

Le RAG répond aux trois : il ancre la génération dans des sources contrôlées, se met à jour par réindexation plutôt que par réentraînement, et permet de citer chaque affirmation.

L’architecture de TagnIot, étape par étape

Ingestion : trois modalités, trois pipelines

TagnIot s’appuie sur trois types de sources, chacune avec ses défis propres.

Les notices sont du texte structuré : procédures numérotées, tableaux, avertissements de sécurité. L’extraction naïve détruit cette structure ; nous préservons donc la hiérarchie procédure → étape et traitons les blocs d’avertissement comme des unités à part entière.

Les vidéos sont notre source la plus riche — et la plus difficile. Le pipeline transcrit l’audio (ASR), puis segmente la vidéo par sens plutôt qu’en tranches de durée fixe, en s’appuyant sur la transcription horodatée. Nous extrayons aussi des images-clés pour capter ce qui est montré mais pas dit à voix haute (un geste, une vis, un connecteur). Résultat : on ne renvoie pas « une vidéo », on renvoie le bon segment, au bon horodatage — « regardez à partir de 4:32 ».

Les schémas techniques passent par une compréhension visuelle (OCR et vision) pour rendre leurs composants, repères et connexions exploitables et référençables, au lieu de les traiter comme des images opaques.

Chunking : découper en respectant le sens

Le découpage à taille fixe est l’erreur classique, et elle est ici franchement risquée : couper une consigne de sécurité au milieu d’une étape produit une réponse tronquée et dangereuse. Nous utilisons un découpage structuré — une procédure reste une unité, un segment vidéo reste cohérent autour d’un geste — et chaque chunk est enrichi de métadonnées : type d’appareil, marque, modèle, nature de la source (notice / vidéo / schéma), horodatage pour la vidéo. Ces métadonnées ne sont pas cosmétiques : elles sont au cœur de la précision du retrieval.

Recherche hybride : le langage flou de l’utilisateur

C’est le point le plus spécifique au grand public. L’utilisateur ne décrit pas une panne en jargon : il dit « ça fait un bruit bizarre », « l’écran vacille », « ça sent le chaud ». La recherche dense (par embeddings) est donc essentielle pour relier ces descriptions imprécises à la bonne section documentée.

Mais l’utilisateur lit aussi parfois un code d’erreur exact ou une référence sur l’appareil (E24, un numéro de modèle). Là, la recherche sémantique échoue : ce sont des tokens lexicaux où la proximité de sens n’a aucun intérêt. Il faut une recherche sparse (type BM25) pour l’appariement exact.

La réponse est une recherche hybride qui combine les deux, puis fusionne les scores. Ni l’une ni l’autre seule ne suffit.

Identifier l’appareil : notre solution, la vignette NFC

Un même symptôme, un même code, ne veut pas dire la même chose d’un modèle à l’autre. Et le point faible de la plupart des assistants de dépannage est là : ils demandent à l’utilisateur d’identifier lui-même son appareil — une référence qu’il ne connaît pas toujours, qu’il saisit avec des fautes, ou qu’il confond avec un modèle voisin. Toute erreur à ce stade contamine l’ensemble du retrieval : on récupère la bonne procédure, mais pour le mauvais appareil.

Chez Tagwiser, nous avons choisi de ne pas résoudre ce problème de façon probabiliste dans le logiciel, mais de l’éliminer sur la couche physique. Une vignette NFC est apposée sur l’appareil. L’utilisateur approche simplement son smartphone : l’assistant identifie automatiquement la marque et le modèle exacts, puis la personne pose sa question.

L’intérêt est double. Pour l’utilisateur, zéro friction et aucune ambiguïté : il est certain que les réponses correspondent à son appareil, pas à un modèle qui lui ressemble. Pour l’architecture, l’identification devient déterministe : le filtrage par marque/modèle sur les métadonnées s’appuie sur une donnée fiable et non sur une supposition, ce qui supprime d’un coup toute une classe d’erreurs de retrieval. On restreint l’espace de recherche au bon appareil avant même de chercher.

C’est un bon rappel : la meilleure solution à un problème d’IA n’est pas toujours dans le modèle.

Reranking

Après un rappel large, un reranker (cross-encoder) réordonne les passages selon leur pertinence réelle vis-à-vis de la demande complète. Cela réduit le bruit envoyé au modèle et améliore nettement la fidélité de la réponse.

Génération ancrée, citée et sécurisée

La génération n’est pas libre. Le modèle doit s’appuyer uniquement sur les passages récupérés, citer sa source (section de notice, horodatage de vidéo, schéma), et refuser de répondre quand l’ancrage est insuffisant plutôt que de combler le vide. S’y ajoutent des garde-fous adaptés à un public non formé : quand une opération présente un risque réel (ouverture d’un appareil sous tension, batterie, composants chargés), TagnIot alerte et oriente vers un professionnel au lieu de pousser l’utilisateur à agir. L’enjeu n’est pas un assistant qui sait tout, mais un assistant qui sait quand il ne faut pas se lancer soi-même.

Les problèmes durs, propres au dépannage grand public

• Comprendre une requête d’utilisateur non expert. Des symptômes vagues, un vocabulaire approximatif : le poids se déplace vers la compréhension et la reformulation de la demande.
• La multimodalité réelle. Texte, vidéo et schéma ne se traitent pas de la même façon, et la réponse la plus utile mélange souvent les trois (« voici l’étape, et la vidéo qui la montre »).
• La précision temporelle sur la vidéo. Renvoyer la bonne vidéo ne suffit pas ; il faut le bon moment.
• L’identification de l’appareil sans présumer que l’utilisateur connaît son modèle — que nous résolvons par la vignette NFC plutôt que par une devinette logicielle.
• La sécurité comme principe de conception, pas comme filtre ajouté après coup.

Évaluer la qualité, sans jouer avec les chiffres

Nous ne mettrons pas en avant de métriques marketing ici — nous préférons parler de la manière dont nous jugeons la qualité. Côté RAG, deux choses comptent : le rappel du retrieval (la bonne réponse est-elle bien remontée, tous formats confondus ?) et la fidélité de la génération (la réponse est-elle réellement ancrée dans les sources, sans dérive inventée ?). Côté utilisateur, la seule question qui vaille est simple : la personne a-t-elle pu résoudre son problème en confiance — ou a-t-elle été correctement orientée vers un pro quand il le fallait ?

Ce que ce projet nous a appris

Le RAG n’est pas un composant qu’on branche, c’est un système où chaque maillon peut faire échouer l’ensemble. Pour du dépannage grand public en particulier : la vidéo est une mine d’or à condition de la rendre horodatée et récupérable ; la recherche hybride n’est pas une option quand vos utilisateurs alternent entre symptômes flous et codes exacts ; l’identification de l’appareil pèse plus lourd qu’on ne le croit, et la déplacer sur une couche physique (notre vignette NFC) fiabilise tout le reste ; et la capacité à refuser ou orienter vers un professionnel est une fonctionnalité, pas un échec.

Notre conviction chez Tagwiser tient en une phrase : l’IA vraiment utile à la maison n’est pas celle qui parle le plus, c’est celle en qui un utilisateur peut avoir confiance — parce qu’elle est ancrée, traçable, et lucide sur ses limites.

ous travaillez sur du RAG multimodal, en particulier sur l’indexation et la récupération de vidéo horodatée ? Je serais curieux d’échanger sur vos choix d’architecture.

Et si vous voulez voir le résultat côté utilisateur, testez gratuitement notre assistant IA : 👉 https://ai.tagniot.com

#RAG #IA #GenAI #LLM #Électronique #Réparation #DIY #IAmultimodale #Tagwiser