Construire un RAG de production : ingestion, embeddings, recherche, reclassement et évaluation

Si vous avez déployé un système RAG simple, vous connaissez le principe : segmenter les documents, calculer leurs embeddings, les stocker dans une base de données vectorielle, rechercher les top-k pour une requête et les insérer dans le prompt. Cette approche fonctionne pour les démonstrations, mais déçoit souvent en production.

L’écart entre un RAG de démonstration et un RAG de production est considérable. Les documents réels sont désordonnés, les requêtes ambiguës et la qualité varie fortement selon leur type. Les coûts et la latence imposent de véritables contraintes. Les mises à jour et la gestion des versions sont également importantes.

Cet article décrit un pipeline RAG de production : ses six étapes, les principes propres à chacune et la discipline d’évaluation qui distingue les systèmes efficaces des systèmes décevants.

Le pipeline

Un système RAG de production comporte six étapes logiques :

[Documents] 
    ↓ 
1. Ingestion (parsing, cleaning, metadata extraction)
    ↓
2. Chunking (splitting into retrieval units)
    ↓
3. Embedding (vectors + storage)
    ↓
[Query]
    ↓
4. Retrieval (semantic + lexical + filters)
    ↓
5. Reranking (top-k → top-N)
    ↓
6. Generation (LLM + context)
    ↓
[Response]

Chaque étape comporte ses propres enjeux de qualité. Améliorer l’une d’elles bénéficie à l’ensemble du système.

Examinons-les successivement.

Étape 1 : ingestion

Des données médiocres produisent des résultats médiocres. La qualité de l’ingestion fixe le plafond de toutes les étapes suivantes.

Types de sources que vous rencontrerez :

• PDF (souvent les pires).
• Documents Word.
• Pages HTML.
• Markdown.
• Feuilles de calcul.
• Diapositives (PowerPoint, Google Slides).
• E-mails.
• Code.
• Données structurées (CSV, JSON).

Chaque format présente ses propres difficultés d’analyse.

Analyse des PDF. Un PDF est un format de présentation, et non un format de données. Son analyse est notoirement difficile. Plusieurs stratégies sont possibles :

• PDF textuels : pdfplumber, pymupdf, unstructured. Ces outils fonctionnent avec du texte propre.
• PDF scannés : OCR avec Tesseract, Google Cloud Vision ou AWS Textract.
• Analyse tenant compte de la mise en page : LayoutLM, Mathpix ou analyse par LLM (GPT-4 vision) pour les mises en page complexes, notamment les tableaux et les colonnes multiples.

Pour les PDF difficiles, une approche moderne consiste à employer un LLM doté de capacités visuelles afin d’effectuer l’OCR et de structurer le contenu. Le coût est supérieur, mais la qualité dépasse nettement celle de l’OCR traditionnel.

Gestion des tableaux. Les tableaux intégrés à du texte non structuré sont difficiles à traiter. Vous pouvez :

• Convertir en tableaux Markdown (préserve la structure).
• Linéariser en prose (“Ligne 1 : client A a eu 50 commandes…”).
• Les traiter comme des unités de recherche distinctes dotées d’un schéma structuré.

Le choix approprié dépend des requêtes attendues.

Extraction des métadonnées. Chaque document a des métadonnées importantes :

• Titre, auteur, date, version.
• Thème, catégorie, balises.
• URL ou emplacement de la source.
• Permissions / visibilité.

Collectez-les lors de l’ingestion. Elles serviront ensuite de paramètres de filtrage pendant la recherche.

Nettoyage. Supprimez les éléments inutiles :

• En-têtes/pieds de page répétés sur chaque page.
• Navigation, publicités, bannières de cookies.
• Pages “Table des matières”.
• Paragraphes vides ou dupliqués.

Un corpus propre améliore la recherche. Les éléments répétitifs génèrent de faux résultats.

Vérifications de qualité.

• Le parseur a-t-il vraiment extrait du texte ? (Certains PDF renvoient des chaînes vides.)
• Y a-t-il des problèmes d’encodage ?
• Les tableaux sont-ils préservés ?
• Les figures sont-elles légendées ou ignorées ?

Intégrez des contrôles de cohérence au pipeline d’ingestion. Détectez les analyses défectueuses avant qu’elles ne polluent l’index.

Étape 2 : segmentation

Vos documents sont désormais propres. Vous devez maintenant les diviser en unités de recherche, ou segments.

Le compromis fondamental :

• Petits segments : recherche précise et ciblée sur la question, mais contexte insuffisant.
• Grands segments : davantage de contexte, mais moins de précision, car l’information pertinente peut être enfouie.

Les deux extrêmes perdent en qualité. Le point optimal varie selon le type de contenu.

Stratégies courantes :

Segmentation en taille fixe avec chevauchement. Divisez le contenu en segments de N tokens (300 à 800) avec un chevauchement de 50 à 100 tokens. Cette méthode simple constitue une bonne référence initiale.

Segmentation tenant compte des phrases. Découpez le contenu aux limites des phrases avec nltk, spaCy ou un outil similaire. Vous éviterez ainsi les coupures en milieu de phrase.

Segmentation par paragraphe. Chaque paragraphe constitue un segment. Cette méthode convient aux documents dont les paragraphes sont bien structurés.

Segmentation hiérarchique (petits et grands segments). Utilisez deux index :

• Petits segments (300 tokens) pour une recherche précise.
• Grands segments (1 500 tokens) ou sections entières pour fournir le contexte.

Lors de la recherche, identifiez les petits segments, puis transmettez au LLM leurs grands segments parents.

Segmentation tenant compte de la structure du document. Appuyez-vous sur les titres et sections pour définir les segments. Chaque section devient un segment et la hiérarchie est préservée.

Segmentation sémantique. Utilisez les embeddings pour détecter les ruptures naturelles, lorsque le sujet change. Plus coûteuse, cette méthode produit de meilleurs segments pour certains contenus.

Segmentation par synthèse au moyen d’un LLM. Les documents longs sont synthétisés en segments hiérarchiques à plusieurs niveaux : paragraphe, section et document. Le LLM génère ces résumés une seule fois, lors de l’ingestion.

La stratégie appropriée dépend du contenu. Pour les articles et les wikis, utilisez une segmentation par paragraphe ou hiérarchique ; pour le code, segmentez par fonction ; pour les conversations, par tour de parole ; pour la documentation technique, respectez la structure du document.

Métadonnées des segments. Chaque segment doit contenir :

• ID et URL du document source.
• Chemin de section (chapitre > section > sous-section).
• Numéro de page (pour la citation).
• Titres qui précèdent ce segment dans la hiérarchie, afin de fournir du contexte.
• Métadonnées du document (date, auteur, type).

Ces métadonnées permettent le filtrage et la citation dans la réponse finale.

Étape 3 : embeddings

Convertissez les segments en vecteurs.

Choix du modèle d’embedding.

En 2026 :

• OpenAI text-embedding-3-large : modèle polyvalent et performant, mais coûteux.
• Voyage Voyage-3 : compétitif, souvent meilleur sur le contenu technique.
• Cohere embed-v4 : solide multilingue.
• BAAI bge-large : modèle open source performant.
• Nomic embed-text : bon modèle open source, auto-hébergeable gratuitement.
• Modèles spécialisés par domaine : pour le code (Voyage Code, OpenAI text-embedding-3-large fonctionne également pour le code), juridique, médical, etc.

Pour choisir un modèle, testez-le dans votre domaine. Ne supposez pas que le mieux classé convient nécessairement le mieux à vos données.

Dimension des embeddings. Les modèles proposent entre 256 et 3 072 dimensions. Une dimension supérieure améliore la qualité, mais augmente les coûts et le stockage. Pour la plupart des cas d’usage, la plage de 768 à 1 536 constitue un bon compromis.

Gestion des versions. Les modèles d’embedding évoluent et vous souhaiterez peut-être en changer. Anticipez cette transition :

• Enregistrez la version du modèle qui a produit chaque vecteur.
• Recalculez tous les embeddings lors de la migration, ou utilisez temporairement deux index.
• Ne mélangez pas les vecteurs provenant de différents modèles dans la même recherche.

Coût. Le calcul des embeddings de millions de segments est payant : entre 0,10 € et 0,50 € par million de tokens selon le fournisseur. Pour les corpus volumineux, estimez le coût à l’avance.

Stockage. Les vecteurs sont volumineux. Un million de segments × 1 536 dimensions × 4 octets représente 6 Go. Dimensionnez le stockage en conséquence.

Étape 4 : recherche

Lorsqu’une requête arrive, vous devez trouver les segments pertinents.

Recherche vectorielle (recherche dense). Calculez l’embedding de la requête, puis trouvez ses plus proches voisins. Cette méthode standard capture la similarité sémantique.

Recherche par mots-clés (BM25 ou lexicale). Cette recherche textuelle traditionnelle identifie les correspondances exactes, les termes rares et les noms précis. Elle complète souvent la recherche vectorielle.

Recherche hybride. Exécutez les deux, fusionnez les résultats. La fusion par rang inverse (RRF) est l’approche standard de fusion.

def reciprocal_rank_fusion(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: -x[1])

En pratique, la recherche hybride surpasse la recherche vectorielle seule ou la recherche par mots-clés seule dans la plupart des benchmarks. Utilisez-la par défaut.

Filtrage par métadonnées. Filtrez les résultats au moyen des métadonnées avant de calculer leur score : « uniquement les documents datant de 2025 ou plus récents », « uniquement les documents accessibles à l’utilisateur » ou « uniquement les documents de type politique ».

Dans les systèmes mutualisés, ce point est essentiel : chaque requête doit être limitée aux documents accessibles au locataire.

Compréhension de la requête. Prétraitez la requête :

• Correction orthographique. “engineerin” → “engineering.”
• Développement des acronymes. « MFA » → « Multi-Factor Authentication MFA ».
• Synonymes et expansion de requête. Générez des formulations alternatives et lancez une recherche pour chacune.
• Décomposition. Divisez les questions en plusieurs parties en sous-requêtes, puis exécutez une recherche séparée pour chacune.

Ces étapes de prétraitement améliorent sensiblement la recherche pour les requêtes réelles.

HyDE (Hypothetical Document Embeddings). Demandez à un LLM de produire un faux « passage idéal » répondant à la question, calculez son embedding et utilisez-le comme requête de recherche. Cette méthode fonctionne souvent mieux que l’embedding direct de la question, car le passage hypothétique ressemble davantage aux documents qui contiennent la réponse.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Write a passage answering: " + query)
    embedding = embed(hypothetical)
    return vector_search(embedding, k=k)

Compromis : chaque requête nécessite un appel supplémentaire au LLM, avec un coût et une latence accrus. Cette dépense se justifie pour les requêtes difficiles, mais reste excessive pour les requêtes simples.

Recherche multivectorielle. Utilisez plusieurs vecteurs par segment au lieu d’un seul, par exemple un pour le segment, un pour son résumé et un pour des questions hypothétiques. Cette méthode augmente le stockage et la complexité, mais améliore la recherche pour certains contenus.

Étape 5 : reclassement

Après la recherche initiale (top-k, k=20 à 50), utilisez un modèle de reclassement pour évaluer plus précisément les candidats.

Pourquoi reclasser ?

La recherche initiale est rapide, mais imprécise. La similarité vectorielle ne constitue qu’une approximation de la pertinence. Un modèle de reclassement, généralement un encodeur croisé, lit conjointement la requête et chaque candidat afin de produire un score plus précis.

Options de reclassement :

• Cohere Rerank. Référence du secteur, de bonne qualité et hébergée.
• Voyage Rerank. Fort concurrent.
• BGE Rerank-large. Open source et auto-hébergeable gratuitement.
• MiniLM cross-encoders. Plus petits, plus rapides, qualité inférieure.
• Reclassement basé sur LLM. Utilisez un petit LLM pour évaluer les paires requête-candidat. Qualité la plus élevée, coût le plus élevé.

L’impact.

L’ajout d’un reclassement améliore généralement la qualité finale de la plupart des systèmes RAG. Considérez la fourchette souvent citée de 10 à 20 % comme une estimation à vérifier au moyen de vos propres évaluations. Le gain justifie presque toujours la latence et le coût supplémentaires.

Configuration typique :

• Récupérez 30-50 candidats avec une recherche hybride.
• Reclassez-les pour conserver les 5 à 10 premiers.
• Transmettez les résultats les plus pertinents au LLM.

Reclassement adaptatif.

Lorsque le premier résultat initial présente une forte similarité vectorielle, signe d’une correspondance claire, omettez le reclassement. Lorsque plusieurs candidats obtiennent des scores proches, appliquez-le de manière approfondie.

Étape 6 : génération

Le LLM produit la réponse à partir du contexte recherché.

Structure du prompt :

You are an assistant answering questions based on the provided context.

Context:
[Document 1 - title, URL]
[chunk 1 content]
[Document 2 - title, URL]
[chunk 2 content]
...

User question: {query}

Instructions:
- Answer based only on the provided context.
- If the context doesn't contain the answer, say so. Don't make up information.
- Cite sources using [Source N] notation.
- Be concise but complete.

Les principes importants pour le prompt sont les suivants :

• Balises de source. Chaque segment de contexte est associé à sa source pour permettre les citations.
• Instructions d’ancrage. Indiquez explicitement au modèle d’utiliser uniquement le contexte.
• Exigence de citation. Forcez la citation. Détecte les hallucinations.
• Instruction de repli. « Si le contexte ne contient pas la réponse, dites-le. » Cette consigne empêche les informations inventées.

Gestion des citations.

Une pratique courante consiste à inclure les liens des sources dans la réponse. L’interface utilisateur les affiche sous forme de liens cliquables.

"The company's remote work policy allows up to 4 days/week from home [1].
[1]: https://wiki.company.com/policies/remote-work"

La réponse devient ainsi vérifiable. Les utilisateurs accordent davantage de confiance aux réponses fondées sur des sources.

Gestion de la taille du contexte.

Les contextes longs dégradent la qualité. La plupart des modèles fonctionnent mieux avec un contexte ciblé composé de 5 à 10 segments très pertinents qu’avec l’intégralité des résultats. La surcharge du contexte réduit la qualité.

Si vous devez inclure beaucoup de contexte, résumez les éléments moins pertinents plutôt que de les inclure en totalité.

Évaluation à chaque étape

Vous ne pouvez pas optimiser ce que vous ne mesurez pas. Chaque étape nécessite ses propres évaluations.

Évaluation d’ingestion. Les documents se sont-ils analysés correctement ? Échantillonnez des documents ; vérifiez que le contenu clé est préservé.

Évaluation de la segmentation. Les segments ont-ils la bonne taille ? Préservent-ils le contexte ? Les coupures interviennent-elles à des limites cohérentes ?

Évaluation des embeddings. Les concepts similaires possèdent-ils des embeddings proches ? Sur un jeu de test composé de paires similaires et différentes connues, la similarité cosinus correspond-elle aux attentes ?

Évaluation de la recherche. Pour une requête donnée, les segments pertinents figurent-ils dans le top-K ? Une métrique courante est le recall@K, soit la proportion de requêtes dont le top K contient au moins un segment pertinent.

Évaluation du reclassement. Pour un ensemble de candidats trouvés, le modèle de reclassement place-t-il le plus pertinent en premier ? Utilisez la NDCG (gain cumulé actualisé normalisé) ou le MRR (rang réciproque moyen).

Évaluation de génération. Étant donné le contexte et la requête, l’LLM produit-il une réponse correcte ? Métriques : fidélité (la réponse utilise-t-elle le contexte ?), exactitude (la réponse est-elle correcte ?), utilité (répond-elle à l’intention de l’utilisateur ?).

Évaluation de bout en bout. Pour une requête réelle, le système produit-il la bonne réponse ? Cette évaluation, la plus importante, dépend de toutes les étapes.

Chaque étape nécessite un jeu de test. Une méthode d’amorçage courante consiste à :

• Construisez 50-100 requêtes avec des réponses connues.
• Pour chaque requête, identifiez quel document(s) contient la réponse.
• Utiliser ces données pour évaluer la recherche des bons documents et l’exactitude de la réponse générée.

Outils : Ragas, TruLens, ensembles de tests personnalisés. L’outil exact importe moins que le fait de faire les évaluations.

Préoccupations opérationnelles

Quelques réalités de production :

Pipelines d’indexation. De nouveaux documents arrivent : calculez leurs embeddings, mettez à jour les index et gérez les suppressions comme les modifications. Ce pipeline fonctionne en continu, et non uniquement lors de l’installation. Concevez-le comme un système, pas comme un script ponctuel.

Latence.

Décomposition typique :

• Plongement (requête) : 50-200 ms.
• Recherche vectorielle : 50-200 ms.
• Reclassement : 200-500 ms (selon K).
• Génération : 1-5 s (selon le contexte et le modèle).
• Total : 1,5-6 s.

Optimisation :

• Mettez en cache les embeddings des requêtes fréquentes.
• Cachez le reclassement pour les paires requête-candidat répétées.
• Génération en flux.
• Parallélisez là où possible.

Pour obtenir une latence inférieure à 2 secondes, il faut généralement un modèle d’embedding et une base vectorielle rapides, ainsi qu’un modèle de reclassement performant ou la possibilité d’omettre cette étape pour les requêtes simples ou mises en cache.

Coût.

Coûts par requête :

• Embedding : environ 0,0001 €.
• Recherche vectorielle : environ 0,0001 € selon l’infrastructure.
• Reclassement : de 0,001 € à 0,01 € selon le modèle.
• Génération : de 0,005 € à 0,05 € selon le modèle et le contexte.
• Total : environ 0,01 € à 0,05 € par requête.

À grande échelle, ces montants s’additionnent : un million de requêtes représente de 10 000 € à 50 000 €.

Optimisation du coût :

• Cache.
• Utilisez des modèles moins chers là où la qualité le permet.
• Compressez le contexte en privilégiant les résumés aux segments complets.

Mises à jour. Les documents changent. Schémas :

• Gestion des versions : chaque document possède une version ; les anciennes sont conservées ou supprimées conformément à la politique applicable.
• Traitement incrémentiel : les nouvelles versions sont à nouveau segmentées et vectorisées, puis les anciens segments sont supprimés.
• Traitement différentiel : seules les sections modifiées sont retraitées.

Pour les scénarios à forte fréquence de mise à jour, cela compte beaucoup.

Autorisations. Dans un RAG portant sur des données privées, les documents sont soumis à des contrôles d’accès que la recherche doit respecter.

• Filtrage fondé sur les métadonnées, chaque segment indiquant qui peut y accéder.
• Index isolés par locataire pour garantir une séparation stricte.
• Journalisation d’audit de qui a accédé à quoi.

Ne confiez pas l’application des autorisations au LLM. Faites-les respecter pendant la recherche.

Modes de défaillance courants

Quelques schémas que nous voyons dans les systèmes RAG défaillants :

Défaillance 1 : mauvaise segmentation. Les segments coupent une idée, séparent un tableau ou dissocient un titre de son contenu. Solution : améliorez la stratégie de segmentation.

Défaillance 2 : la recherche ne trouve pas la réponse. Le segment pertinent existe, mais n’est pas trouvé, souvent en raison d’un décalage entre la requête et le document. Solution : utilisez HyDE, l’expansion de requête ou de meilleurs embeddings.

Défaillance 3 : bons segments, mauvais ordre. Le segment pertinent est trouvé, mais mal classé. Le LLM exploite alors des segments non pertinents mieux classés. Solution : ajoutez un reclassement.

Défaillance 4 : bons segments, hallucination. Les segments sont pertinents, mais le LLM invente des informations supplémentaires. Solution : renforcez les instructions d’ancrage, exigez des citations et réduisez la température.

Défaillance 5 : bons segments, mauvaise réponse. Les segments contiennent la réponse, mais le LLM extrait la mauvaise information. Solution : améliorez le prompt de génération et envisagez un modèle plus puissant.

Défaillance 6 : Données obsolètes. L’index n’a pas été mis à jour. Solution : pipeline d’ingestion continu.

Défaillance 7 : fuite d’autorisations. Les utilisateurs voient des segments auxquels ils ne devraient pas accéder. Solution : appliquez le filtrage pendant la recherche et auditez les accès.

Défaillance 8 : Spirale de coût. La latence et le coût ont augmenté à mesure que le corpus et le trafic ont augmenté. Solution : mise en cache, routage des modèles, éventuellement des changements d’architecture.

Exemple concret : système RAG de base de connaissances d’entreprise

Pour rendre concret : un système RAG typique de base de connaissances d’entreprise.

Corpus : ~50 000 documents (pages wiki, politiques, runbooks, notes de réunion, fils de discussion Slack).

Pipeline :

1. Ingestion :

   • Notion : export API.
   • Slack : export d’archives, filtré aux canaux pertinents.
   • Google Drive : export API des dossiers approuvés.
   • Nettoyage : supprimer les messages contenant uniquement des emojis, les signatures inutiles.

2. Fragmentation :

   • Hiérarchique : petits segments au niveau du paragraphe, segments parents au niveau de la section.
   • Environ 250 000 petits segments au total.
   • Métadonnées : source, chemin de section, dernière mise à jour, accessible à.

3. Embeddings :

   • Embeddings Voyage-3, 1 024 dimensions.
   • Stockés dans Pinecone (géré).
   • Embeddings recalculés chaque semaine pour les documents modifiés.

4. Recherche :

   • Hybride : recherche vectorielle + BM25 (via Pinecone’s hybrid).
   • HyDE pour la requête.
   • Filtre de métadonnées pour l’accessibilité.
   • Les 30 premiers résultats sont conservés.

5. Reclassement :

   • Cohere Rerank.
   • Top 30 → top 8.

6. Génération :

   • Claude Sonnet 5.
   • Les 8 premiers segments parents, et non les petits segments, sont fournis comme contexte.
   • Citation requise dans la réponse.

Évaluation :

• 100 paires de requête/réponse manuellement conçues.
• Recall@30 de la recherche : environ 92 %.
• Exactitude de la réponse finale : ~85 %.
• Fidélité (pas de hallucinations) : ~95 %.

Opérations :

• Ingestion incrémentielle quotidienne.
• Recalcul hebdomadaire de tous les embeddings des documents modifiés.
• Observabilité par requête.
• Ré-évaluation mensuelle ; surveillance des tendances.
• Revue trimestrielle du journal des requêtes pour détecter de nouveaux schémas de défaillance.

Coûts :

• Embeddings : environ 500 € par mois en régime permanent.
• Hébergement de la base de données vectorielle : environ 800 € par mois avec Pinecone.
• Recherche et génération : environ 0,02 € par requête.
• Total : environ 2 500 € par mois + 0,02 € × volume de requêtes.

Pour la plupart des entreprises, cela est pleinement justifié par les gains de productivité.

Plan de déploiement RAG sur 90 jours

Si vous commencez à partir de zéro :

Jours 1-30 : MVP.

• Identifier le corpus et le cas d’utilisation principal.
• Construire une ingestion basique (une source).
• Fragmentation basique (taille fixe avec chevauchement).
• Modèle d’embedding standard.
• Recherche vectorielle uniquement (pas de reclassement).
• Prompt de génération simple.

Jours 31-60 : Qualité.

• Créer manuellement un ensemble d’évaluation (50-100 requêtes).
• Identifier les modes de défaillance.
• Ajouter le reclassement.
• Ajouter la recherche hybride.
• Améliorer la segmentation.

Jours 61-90 : Opérations.

• Pipeline d’ingestion continu.
• Observabilité.
• Automatisation de l’évaluation.
• Permissions/autorisation.
• Surveillance des coûts.

Après 90 jours, vous avez un système qui n’est pas seulement démontrable, mais effectivement utilisable. Les utilisateurs réels peuvent s’y fier.

La qualité réside à chaque étape

Un RAG de production est un pipeline en six étapes avec des préoccupations de qualité à chaque étape. Les schémas qui distinguent les systèmes qui fonctionnent des systèmes qui déçoivent :

• Ingestion : analyse approfondie, préservation de la structure, capture des métadonnées.
• Segmentation : stratégie adaptée au type de contenu, souvent hiérarchique.
• Embeddings : modèle de qualité, gestion des versions et planification de la migration.
• Recherche : approche hybride par défaut, compréhension des requêtes et filtrage par métadonnées.
• Reclassement : presque toujours rentable.
• Génération : ancrage, citations et instruction de repli lorsque la réponse est inconnue.
• Évaluation : à chaque étape, continuellement.

Aucun de ces éléments n’est facultatif. L’écart entre un RAG qui atteint 60 % de qualité des réponses et un autre qui atteint 90 % réside dans ces détails.

L’investissement est réel : construire un RAG de production prend des mois, et non quelques semaines. En contrepartie, vous obtenez un système auquel vos utilisateurs peuvent réellement faire confiance. C’est le seuil qui importe.