Lorsque les citations semblent parfaites mais que le nombre de personnes reste incorrect

Une question relative aux paies devrait être ennuyeuse. Si l’on demande combien de personnes figurent dans le registre des salaires d’avril 2025, on s’attend à obtenir un chiffre, une référence, et rien de particulièrement intéressant. Le système a renvoyé une phrase bien formulée : un employé, fichier PDF indiqué, page marquée. Or le registre en listait douze.

C’est ce type de défaillance qui rend la génération assistée par récupération dangereuse dans la pratique. Le processus n’a pas planté ; les journaux de logs sont restés silencieux. La réponse ressemblait à toutes les réponses correctes de la même semaine. Une défaillance discrète accompagnée d’une note en bas de page est pire qu’un plantage complet, car personne ne prend au sérieux un paragraphe poli.

Cet article reconstitue le processus qui a généré ce mensonge, les outils de diagnostic qui l’ont révélé, ainsi que les modifications concrètes qui ont permis de ramener le chiffre à douze. L’ensemble des outils utilisés est délibérément ordinaire : pdfplumber pour traiter le texte PDF en tenant compte de sa mise en page, un séparateur de texte LangChain uniquement à des fins de segmentation, des embeddings MiniLM, Qdrant pour gérer les vecteurs, un système de recherche hybride combinant méthode dense et BM25, un réordonneur basé sur un cross-encoder, ainsi qu’un compresseur censé réduire la taille du contexte avant que le générateur ne s’exécute. Aucun de ces choix n’était particulièrement exotique. Les problèmes résidaient plutôt dans la manière dont ces outils interagissaient avec les tableaux et les identifiants.

Une seule ingestion, des réponses en permanence

Les documents sont traités une seule fois. Les questions, en revanche, arrivent sans cesse. Il est important de maintenir ces flux séparés lors du débogage, car une réponse erronée peut provenir de vecteurs obsolètes, de filtres défectueux ou d’un générateur qui n’a jamais pris en compte les lignes appropriées.

L’ingestion parcourt chaque PDF, extrait le texte en tenant compte de sa mise en page, le divise en blocs chevauchants, l’incorpore et l’insère dans Qdrant avec des métadonnées que les filtres ultérieurs pourront utiliser :

PDF → extract text per page → cut into chunks
    → convert each chunk to 384 numbers → store in a vector database

La réponse relève d’un autre type de traitement. On incorpore la question, on récupère les candidats possibles, on peut combiner les résultats correspondant aux mots-clés, on réordonne les résultats, on les compresse, puis on soumet la requête au modèle en y ajoutant des citations :

question → search → rerank → compress → ask the LLM → cited answer
              ↓         ↓          ↓
          5 chunks  3 chunks   ~600 chars

En théorie, ce flux est celui décrit dans les manuels. En pratique, ces hypothèses théoriques échouent avec les registres des employés, les tableaux de factures et tout document dont la réponse est une structure plutôt qu’un slogan.

Pourquoi chaque élément a trouvé sa place

pdfplumber n’est pas la bibliothèque PDF la plus rapide. C’est l’une des rares à conserver suffisamment d’informations sur la mise en page pour éviter que les lignes relatives aux salaires ne se mélangent en un seul paragraphe. Les outils d’extraction plus rapides qui transforment les tableaux en phrases continues rendent presque impossibles les questions ultérieures comme « compter le nombre d’employés », car le modèle ne perçoit jamais les limites entre les lignes.

Pour ce projet, le découpage des données a utilisé le séparateur de caractères récursif de LangChain, et rien d’autre du framework. L’objectif était d’obtenir des tailles de fenêtre prévisibles avec chevauchement, et non une chaîne RAG imposant une approche particulière. Après un bref test, les embeddings all-MiniLM-L6-v2 ont été retenus : les modèles plus petits manquaient de tokens d’identification ; ceux plus gros entraînaient des retards sans résoudre le problème essentiel. Qdrant a été choisi pour sa continuité entre l’environnement local et le cloud, ainsi que pour ses filtres de charge utile qui correspondaient à la manière dont l’application gérait déjà les types de documents.

La recherche hybride combinait la similarité sémantique avec une évaluation des mots-clés de type BM25, dans un rapport d’environ 0,65 / 0,35. La recherche purement sémantique se montrait excellente pour la question « Quelle est la politique de congé parental ? » mais médiocre pour STL/2025-26/003. Un réclassement à l’aide d’un encodeur croisé a permis de nettoyer la liste des résultats. La compression visait à conserver uniquement les phrases à fort signal avant l’appel au LLM. C’est à cette dernière étape que l’histoire du passage de douze à un a véritablement commencé.

La réponse fausse mais convaincante

Pour la question relative au salaire, une page plausible a été retrouvée et citée, mais le nombre de résultats obtenus était insuffisant. En examinant les scores bruts de recherche, on a pu observer le premier problème : les voisins sémantiques semblaient « suffisamment proches », tandis que les entrées correspondant exactement au registre demandé se classaient mal par rapport aux textes narratifs liés aux ressources humaines présents ailleurs dans le corpus.

0.781  Invoice_INV2025001_Arvind.pdf     <- returned
0.779  Invoice_INV2025002_Trident.pdf
0.776  Invoice_INV2025003_Welspun.pdf    <- actually wanted

En effet, la similarité de sens ne peut pas effectuer un travail précis sur les tokens. L’ajout de BM25 ainsi que le mélange des scores ont modifié le classement, ce qui a fait monter en priorité les identifiants et les segments contenant des tableaux :

0.854  Invoice_INV2025003_Welspun.pdf    <- correct
0.549  Invoice_INV2025001_Arvind.pdf
0.545  Invoice_INV2025002_Trident.pdf

Cela seul n’a pas permis de restaurer le comptage. Il a simplement fait en sorte que le bon document soit pris en compte. Les prochains obstacles se trouvaient à l’intérieur même du document.

Les identifiants des employés comme expérience de survie

Au lieu de discuter des aspects subjectifs, les identifiants des employés ST001 à ST012 ont été suivis à chaque étape : extraction, segmentation en chunks, récupération, réclassement, compression et assemblage final du prompt.

retrieved chunk    ST001 ST002 ST003 ST004 ST005 ... ST012   (12 present)
after rerank       ST001 ST002 ST003 ST004 ST005 ... ST012   (12 present)
after compression  ST001 ST002                                (2 present)
prompt sent        ST001 ST002                                (2 present)

Plusieurs identifiants ont disparu entre la compression et le traitement par le modèle. Le compresseur respectait un budget fixe de « phrases principales ». Une ligne de tableau compte comme une phrase. Un tableau de salaires dense épuise ce budget dès les premières lignes, tandis que les lignes suivantes – ainsi que le texte qui les explique – ne sont jamais incluses dans la requête. Le modèle rapporte alors fidèlement le sous-ensemble qu’il a vu.

# before — keep the top N
best = scored[:40]

# after — keep the best until the character budget runs out
budget = MAX_CONTEXT_CHARS // TOP_K_AFTER_RERANK
for sentence, score in ranked:
    if best and len(sentence) + 2 > budget:
        continue
    best.append(sentence)
    budget -= len(sentence) + 2

Lorsque la compression a mélangé et tronqué les lignes, le tableau de salaires est apparu comme un jeu de cartes distribué dans le désordre. Chaque nombre pourrait exister quelque part dans la fenêtre de contexte, mais la structure nécessaire pour compter les employés distincts avait disparu. Compter les personnes dans un tableau que quelqu’un a divisé en extraits classés est une tâche différente de la lecture du tableau lui-même.

Les scores des réordonneurs qui semblaient bons mais causaient quand même des problèmes

Les scores des encodeurs croisés pour les lignes critiques semblaient « raisonnables ». « Raisonnables » ne signifie pas pour autant que la table reste complète.

0.446  keep   ST001 Rajesh Kumar M CFO 75,000 ...
0.323  keep   ST002 Priya Sundaram Finance Mgr 45,000 ...
0.420  keep   ST003 Murugan K Sr Accountant 28,000 ...
0.259  DROP   ST005 Selvam R Production Mgr 38,000 ...   ← below 0.30
0.422  keep   ST006 Karthik P Supervisor 18,000 ...

# pick the best by score…
chosen = set(id(p) for p in best)
# …then put them back in document order before joining
best = [p for p in scored if id(p) in chosen]

La correction consistait pas à « augmenter le seuil partout », mais plutôt à détecter les lignes ressemblant à des tables et à les exempter d’une compression agressive. Une heuristique pratique : si une ligne contient quatre chiffres ou plus et se trouve parmi au moins trois lignes similaires dans le même groupe, elle doit être traitée comme une ligne de table et conservée quel que soit son score de phrase.

ROW_MIN_NUMBERS = 4
TABULAR_MIN_ROWS = 3

def is_row(sentence):
    return len(NUMBER_RE.findall(sentence)) >= ROW_MIN_NUMBERSif looks_tabular(sentences):
    survivors = [p for p in scored if is_row(p[0]) or p[1] >= threshold]
else:
    survivors = [p for p in scored if p[1] >= threshold]

Avec ces lignes de table exemptées, les douze identifiants ont tous survécu jusqu’à l’instruction lors du prochain exécution. Le générateur disposait enfin d’une structure qu’il pouvait compter.

Petites corrections qui ont éliminé d’autres problèmes

Pendant que le chemin vers la table était ouvert, plusieurs problèmes connexes ont reçu le même traitement : des variables d’environnement vides qui remplaçaient silencieusement les valeurs par défaut prévues, des filtres de type de document qui se comportaient différemment entre Qdrant local et Qdrant Cloud, ainsi que des en-têtes de réponse qui ne renvoyaient que du texte narratif alors que les opérateurs avaient besoin du suivi du pipeline.

# the context cap must be at least CHUNK_SIZE × TOP_K_AFTER_RERANK
MAX_CONTEXT_CHARS = 5000   # was 2000 while 1200 × 3 = 3600

Désormais, chaque réponse renvoie l’intégralité du pipeline, et non seulement la phrase finale — les IDs récupérés, les scores, les décisions de compression et les filtres — afin que le prochain problème puisse être analysé sans devinette :

{
  "answer": "12 employees are listed...",
  "citations": [{"doc": "Salary_Register_April_2025.pdf", "page": 1}],
  "pipeline": {
    "retrieved": 5,
    "after_rerank": 3,
    "chars_before_compression": 3847,
    "chars_after_compression": 2103
  }
}

Le filtrage par type de document fonctionnait avec une instance locale de Qdrant mais échouait de la même manière dans Qdrant Cloud, tant que les index des en-têtes et les formes des filtres ne correspondaient pas à ce que la version cloud indexait réellement :

500 — Index required but not found for "doc_type"

Équivalent en Python : os.getenv("KEY", "default") renvoie une chaîne vide lorsque la variable existe mais est vide. Ce n’est pas là la valeur par défaut. Préférez or lorsque la valeur vide doit être utilisée :

QDRANT_URL = os.getenv("QDRANT_URL") or "http://localhost:6333"

Où s’est arrêté le processus

Après une récupération hybride, une compression tenant compte du tableau et des données de suivi explicites du pipeline, la question relative au registre d’avril a donné douze résultats, avec des références indiquant les lignes justifiant ce chiffre.

Retrieval:    hybrid, 0.65 semantic + 0.35 BM25
Reranking:    cross-encoder, 5 in → 3 out
Compression:  sentence-level, table-aware, ~35% reduction
Grounding:    prompt + threshold + temperature 0.0
Evaluation:   13/15 on the golden set, refusals tested
Latency:      ~4s end to end
Cost:         ~$0.003 per fifteen-question run

Rien de tout cela n’a nécessité un nouveau modèle de base. Il suffisait de considérer RAG comme un pipeline de données ayant des taux de survie mesurables pour les tokens importants. Les tutoriels promettent « intégrer, récupérer, générer ». En production, il s’agit de « prouver que les lignes ont bien atteint le prompt ».

Habitudes opérationnelles pour garantir une comptabilité fiable

Gardez un ensemble de questions clés comprenant au moins une comptage pur sur une table, une recherche par identifiant exact, et une question liée à la politique sémantique. Si seules les questions sémantiques réussissent, la démonstration ment quant à sa prête-à-l’emploi.

Enregistrez les IDs des blocs via la compression. Si un ID présent après récupération est absent après compression, il s’agit d’une erreur, même si la réponse finale se révèle être correcte ce jour-là.

Préférez les hybrides explicites pour des corpus mélangeant prose et registres différents. La seule recherche dense continuera de fonctionner bien pour les essais mais mal pour les codes.

Considérez les citations comme nécessaires mais pas suffisantes. Un numéro de page accompagnant un comptage erroné reste un comptage erroné.

Lors du passage de Qdrant local au cloud, vérifiez à nouveau les index des données et le comportement des filtres avec les mêmes outils de test. La compatibilité API ne signifie pas des paramètres d’indexation identiques.

Le contexte budgétaire concerne la structure dans son ensemble, et non seulement les « phrases importantes ». Les tableaux font partie de cette structure. Les compresser comme des paragraphes de blog revient à transformer douze éléments en un seul.

Pourquoi les échecs mineurs méritent des contrôles plus stricts

Les équipes décident souvent du lancement de RAG en se basant sur le critère selon lequel « les réponses ont l’air correctes dans un tableau de prompts correspondant aux scénarios idéaux ». Ce critère manque cependant les échecs réels dans les domaines de la paie, des stocks et du respect des réglementations : un sous-comptage involontaire. Il convient d’ajouter des vérifications automatiques pour s’assurer que les ensembles d’entités extraites sont bien conservés dans les prompts pour les éléments fixes connus. Interrompre la compilation si ST001–ST012 ne figurent pas tous après compression pour l’élément de paie correspondant.

Le même mécanisme de contrôle peut vérifier que les poids des combinaisons hybrides sont bien activés dans la configuration en cours d’exécution, et non seulement mentionnés dans un README. Une divergence entre les expériences menées dans les notebooks et la configuration du service est une cause fréquente pour laquelle BM25 « disparaît » après un refactoring.

Finalement, enseignez aux opérateurs à se méfier des citations attrayantes. L’interface utilisateur du produit doit afficher les traces de récupération et de compression à côté de la réponse pour les utilisateurs internes, tant que l’ensemble cible reste vert pendant un cycle de publication. Les utilisateurs externes peuvent conserver le paragraphe propre ; les utilisateurs internes ont besoin d’un outil d’analyse approfondie.

Conclusion

Le registre n’a jamais indiqué qu’il y avait un seul employé. Le pipeline, lui, l’a fait, après avoir discrètement éliminé les lignes qui auraient pu le corriger. Corriger cela a nécessité une recherche hybride pour les identifiants, une compression adaptée à la structure des tableaux, ainsi que des réponses accompagnées de leur propre trace d’éléments probants. Une fois ces éléments en place, douze sont restés douze — et la prochaine citation fiable avait alors des bases réelles sur lesquelles s’appuyer.

C’est là la norme à respecter : non pas savoir si le modèle peut paraître sûr, mais plutôt si le système peut prouver les faits qui justifient cette certitude.

Un regard plus approfondi sur l’évaluation hybride en pratique

La récupération dense encode la question ainsi que chaque fragment dans le même espace vectoriel et classe les résultats en utilisant le cosinus ou le produit scalaire. Cette méthode fonctionne lorsque la langue de l’utilisateur correspond à celle du document : congé parental, indemnité de licenciement, politique de travail à distance. Elle échoue cependant lorsque l’utilisateur colle un token opaque qui apparaît à peine dans les données d’entraînement et ne cooccupe que rarement avec des mots voisins dans l’espace d’incorporation. Les codes employés, les numéros de facture et les identifiants de contrat relèvent précisément de cette catégorie de tokens.

BM25 et les outils d’évaluation lexicale associés inversent le problème. Ils se soucient du fait que le token apparaît, de sa rareté dans le corpus et de la fréquence à laquelle il apparaît dans le fragment candidat. Ils ne se préoccupent pas du fait que « STL/2025-26/003 » soit sémantiquement proche de rien. Mélanger ces deux scores n’a rien de philosophique ; il s’agit simplement de reconnaître que les corpus de paie contiennent à la fois des politiques ressemblant à des essais et des tableaux similaires à des registres.

Le ratio 0,65 / 0,35 utilisé ici est un point de départ, et non une loi naturelle. Les corpus riches en codes peuvent nécessiter plus d’importance accordée à l’aspect lexical, tandis que ceux axés sur le récit en ont peut-être besoin moins. Ce qui importe, c’est d’évaluer les deux types de questions dans l’ensemble de référence et de s’abstenir d’utiliser un mélange qui ne fonctionne que pour les prompts narratifs.

Lors de la mise en œuvre du mélange, normalisez les scores avant de les combiner. Les similarités brutes et les scores BM25 bruts évoluent sur des échelles différentes. Les équipes qui utilisent des valeurs non normalisées constatent souvent qu’un canal domine par hasard. La fusion min-max ou la fusion par rang (RRF) sont toutes deux acceptables à condition d’être testées avec des exemples contenant des IDs exacts.

La compression en tant que codec perteux pour les tableaux

La compression contextuelle existe parce que les modèles disposent de fenêtres finies et parce que des phrases irrelevantes diluent l’attention. L’approche par défaut consiste à évaluer les phrases en fonction de leur pertinence, à conserver les k meilleures et à jeter le reste. Cette approche part du principe que les phrases sont des unités de sens interchangeables. Or, les lignes d’un tableau ne le sont pas. La ligne 7 sans les lignes 1 à 6 n’est pas simplement un tableau légèrement moins bon ; c’est un tableau défectueux.

L’heuristique d’exemption — de nombreux nombres sur une même ligne, plusieurs lignes similaires à proximité — est délibérément simpliste. Elle permet de conserver certaines lignes non tabulaires qui ont l’air numériques, ce qui est acceptable. Les faux positifs entraînent une perte de tokens, tandis que les faux négatifs compromettent la précision. Pour les paies et les inventaires, c’est la précision qui prime.

Des détecteurs plus sophistiqués peuvent utiliser la structure PDF fournie par pdfplumber : boîtes délimitant les cellules, colonnes alignées, coordonnées x répétées. Ces signaux sont excellents lorsqu’ils sont disponibles. L’heuristique basée sur les phrases reste utile en tant que solution de secours lorsque le texte a déjà été transformé en markdown ou en texte brut avant l’exécution de la compression.

Un autre mode de défaillance est le mélange des éléments. Même si toutes les lignes survivent, un réordonnement selon leur score de pertinence peut altérer les totaux et les comptages. Préférez un ordre de document stable pour les lignes de table exemptées. Classez librement le texte narratif ; conservez les tables dans l’ordre de lecture.

Citations qui défendent la mauvaise réponse

La citation UX met souvent en évidence le PDF et la page qui ont fourni le plus grand fragment récupéré. Lorsque la compression réduit ensuite de moitié le tableau, la citation indique toujours le bon fichier. Les utilisateurs interprètent cela comme une confirmation. La conception du produit doit soit citer les lignes spécifiques utilisées dans la requête finale, soit afficher un historique de récupération. Sinon, l’interface devient complice.

Pour les domaines réglementés, stockez le hash exact du contexte de la requête avec la réponse. Si un auditeur demande pourquoi le système a indiqué « un employé », vous pouvez rejouer le tableau tronqué et montrer la erreur plutôt que de débattre du tempérament du modèle.

Bases de données vectorielles locales versus cloud

Le filtre de type de document qui fonctionnait localement mais échouait dans Qdrant Cloud rappelle que « la même API » ne signifie pas « la même configuration d’index ». Les index de charge utile, les filtres de mots-clés et la gestion des valeurs nulles diffèrent selon les modes de déploiement. Les tests de fixture doivent être exécutés sur le même type de déploiement que celui utilisé en production. Un ensemble de tests locaux réussis accompagné d’un échec dans le cloud est la manière dont les requêtes de récupération vide sont livrées.

Les variables d’environnement vides méritent la même prudence. Les systèmes de configuration qui exportent des chaînes vides pour les secrets non définis contourneront les valeurs par défaut dans les langages où une valeur vide est suffisamment considérée comme vraie. Normalisez la configuration au démarrage du processus : traitez les valeurs vides comme manquantes, appliquez ensuite les valeurs par défaut, puis échouez immédiatement si les clés nécessaires sont toujours absentes.

Mesurer la survie, pas les impressions

L’expérience de survie des identifiants employés sert de modèle. Sélectionnez les entités qui doivent être présentes pour obtenir une réponse correcte. Vérifiez qu’elles existent après extraction, après segmentation en blocs, après récupération, après réclassement et après compression. Tracez les baisses de qualité. Le premier obstacle est généralement une erreur logicielle.

Étendez cette idée aux agrégats numériques. Si la question concerne une somme, assurez-vous que chaque terme de la somme a bien été pris en compte. Si la question concerne un décompte distinct, vérifiez que l’ensemble des clés distinctes est complet. Ces contrôles sont peu coûteux par rapport aux incidents en production.

À ne pas blâmer en premier

Il est tentant de blâmer le LLM lorsque le comptage est incorrect. Parfois, le modèle ne peut vraiment pas compter. Plus souvent, il n’a jamais reçu de structure comptable. N’échangez de modèle qu’après que le graphique de survie soit vert. Sinon, vous « corrigez » un bug de comptage en passant à un modèle plus grand qui hallucinera le nombre que vous vouliez — jusqu’à l’arrivée du prochain enregistrement.

De même, résistez à l’idée d’éliminer tout le framework parce qu’un compresseur ne fonctionne pas correctement. Isolez l’étape concernée, ajoutez des exceptions, effectuez des tests, puis continuez. Les réécritures approfondies donnent l’impression d’être productives, mais introduisent souvent la même catégorie de bugs sous de nouveaux noms.

Une liste de contrôle minimale pour renforcer la robustesse

1. Questions clés : comptage des tables, identifiant exact, politique sémantique.
2. Récupération hybride avec mélange normalisé ou RRF.
3. Compression tenant compte des tables, avec un ordre des lignes stable.
4. Traces du pipeline pour chaque réponse interne.

Normalisation de la configuration qui considère les variables d’environnement vides comme inexistantes.

Fixtures d’index cloud reflétant les filtres en production.

Contrôles de construction basés sur la présence des entités pour les documents connus.

Citations liées au contenu de la demande, et non seulement aux fichiers récupérés.

Exécutez cette liste de vérification avant de qualifier un RAG de paie de « terminé ». Le registre d’avril ne sera pas le dernier document qui semble simple mais échoue discrètement.

Conséquences pour l’équipe

Lorsque la réponse générée par les douze employés s’est stabilisée, les mêmes outils de telemétrie ont détecté deux bugs moins évidents : un alias de collection obsolète après une nouvelle ingestion, et un délai d’expiration du réclassificateur qui faisait retomber sur des résultats hybrides non classés sans marquer la réponse comme dégradée. Ces problèmes auraient été invisibles si l’API n’avait renvoyé qu’une chaîne de caractères. Le fait que l’API renvoie des données structurées — scores, temps d’exécution, solutions de secours — a transformé l’assistant en outil dont les opérateurs pouvaient suffisamment se fier pour le déboguer à 2 heures du matin.

C’est là la véritable leçon liée au produit. Les systèmes RAG ne sont pas de simples interfaces de chat sur des PDF. Ce sont des pipelines de données qui s’expriment par paragraphes. Traitez-les comme tels : mesurez les pertes, conservez la structure, et ne permettez jamais à une citation de remplacer une preuve.

Un dernier examen de la réponse incorrecte initiale

Réexaminer la mauvaise réponse avec les traces associées rend l’histoire presque ennuyeuse. Le système de récupération avait presque trouvé le bon PDF. La méthode d’évaluation hybride a achevé le travail. Ensuite, la compression a utilisé son budget de calcul sur les premières lignes numériques avant d’ignorer le reste. Le modèle a compté ce qui restait et a cité le fichier. Chaque étape effectuait en isolation une action défendable. Ensemble, elles ont créé de la confiance.

C’est pourquoi les métriques locales à l’étape de traitement induisent en erreur. Retrieval@k peut sembler correct, alors que la compression détruit la réponse. La survie des entités de bout en bout est la métrique qui reflète réellement les dommages causés aux utilisateurs. Adoptez-la tôt, surtout lorsque les documents sont des tableaux présentés sous forme PDF.

Si vous ne retenez qu’une chose de cet incident impliquant douze employés, c’est bien ceci : les échecs polis du système RAG sont des bugs dans le processus tant que leur nature n’est pas prouvée autrement. Instrumentez le flux de travail, protégez la structure et faites en sorte que le système montre son fonctionnement avant de pouvoir faire confiance à ses résultats. Les échecs mineurs exigent des contrôles stricts, des vérifications répétées et des opérateurs capables de surveiller chaque détail avant que les utilisateurs puissent à nouveau faire confiance aux chiffres présentés.

La survie des entités malgré la compression reste le critère le plus simple et le plus fiable pour les corpus riches en tableaux.

Lorsque le prochain enregistrement arrive, exécutez à nouveau le même graphique de survie des identifiants avant de faire confiance à une nouvelle citation présentée comme fiable.