Comment laisser GPT-5.5 corriger un CV sans jamais lui montrer un seul donnée personnelle

A developer created piighost-proofreader, a tool that anonymizes CVs locally before sending them to an LLM for proofreading, ensuring no personal data like names, addresses, or employer details are exposed to the third-party service. The system uses an AI-powered detector to replace sensitive information with placeholders, then streams corrections back to the original PDF in real-time using instructor's `create_iterable` method for granular, object-by-object output.

Pour relire votre CV avant un envoi important, vous pouvez le confier à un LLM. Quelques secondes, et vous avez une liste de fautes. Sauf que vous venez aussi de donner votre nom, votre adresse, vos employeurs et vos dates à un service tiers. piighost-proofreader résout ça. Le CV est anonymisé localement avant l'appel au LLM, et les corrections retrouvent leur place sur le PDF d'origine : Le LLM ne voit jamais un nom, une date, une adresse. L'anonymisation, c'est la partie facile. Le morceau pénible, c'est de retrouver dans le PDF un mot que le LLM n'a vu qu'en Markdown. Et le LLM et PyMuPDF ne tokenisent pas pareil. Première idée : avant d'envoyer le CV au LLM, on remplace les données sensibles par une bonne grosse regex. Ça marche pour les emails et les numéros de téléphone, qui ont un format reconnaissable. Pour le reste, c'est mort. Paul Martin ressemble à n'importe quels deux mots capitalisés ; rien dans le texte ne dit à une regex que c'est un nom. Orange est une entreprise. C'est aussi un fruit. Mars , Apple , Carrefour , pareil.Il faut un détecteur entraîné, pas un pattern. piighost en fournit un, et l'appel ressemble à ça : python src/proofreader/anonymize.py async def anonymize self, text: str, , thread id: str - str: return await self. call "/v1/anonymize", text, thread id, response key="anonymized text" Le thread id est une UUID par CV. Le mapping entité→placeholder reste côté serveur, isolé par cet ID : un même nom devient le même placeholder à chaque occurrence. instructor Un CV de deux pages contient une bonne quinzaine de fautes, et le LLM prend plusieurs secondes pour les sortir. Sans streaming, l'utilisateur fixe un loader pendant tout ce temps. Avec, les fautes apparaissent une par une au fur et à mesure que le modèle les émet. Le piège : la plupart des libs de structured output LangChain with structured output , OpenAI Functions, Pydantic AI renvoient le résultat complet . Vous demandez un list Mistake , vous recevez la liste entière une fois l'inférence terminée. Pas de granularité objet par objet. instructor règle exactement ce cas. Sa méthode create iterable parse le JSON streamé par le LLM au fil de l'eau et renvoie chaque objet pydantic dès qu'il est complet : src/proofreader/llm.py client = instructor.from litellm litellm.acompletion response = client.chat.completions.create iterable model=model, response model=Mistake, un seul objet, pas list Mistake messages= {"role": "system", "content": SYSTEM PROMPT STREAM.format language=language }, {"role": "user", "content": markdown}, , async for mistake in response: yield mistake Deux complications qui ne sautent pas aux yeux : Le prompt change selon le mode. Pour un with structured output LangChain, on demande au LLM de renvoyer un objet wrapper avec une liste de Mistakes dedans. Pour create iterable , on lui demande d'émettre un seul Mistake JSON par tour de génération. Les deux prompts ne sont pas tout à fait les mêmes. Le projet maintient les deux côte à côte : LangChain pour le chemin Streamlit one-shot, instructor pour le streaming FastAPI. Le streaming SSE en aval. Chaque Mistake émis est immédiatement repackagé en event Server-Sent Events côté FastAPI, puis envoyé au frontend. Le locator de la section suivante tourne par-Mistake , donc l'utilisateur voit chaque rectangle rouge apparaître au fur et à mesure, pas en bloc à la fin. Pour chaque Mistake qu' instructor renvoie, j'ai un error text , un correction , un context before , et une description . Le LLM, lui, n'a jamais vu un seul pixel du PDF : il travaillait sur le Markdown extrait. Aucun champ ne contient des coordonnées. Or l'utilisateur veut voir les corrections sur le PDF d'origine, pas un texte plat dans une page de résultats. Donc il faut, pour chaque erreur, retrouver le mot dans le PDF. Du côté PDF, j'utilise PyMuPDF, qui me donne un word stream : la liste de tous les mots de la page avec leurs bbox rectangles en points . Le problème devient : trouver la fenêtre mot1, mot2, … dans cette liste. Sauf que le LLM et PyMuPDF ne tokenisent pas pareil, que les apostrophes typographiques ne sont pas alignées, et que sur un CV en deux colonnes le LLM hallucine parfois son context before . D'où quatre stratégies essayées dans l'ordre. Chacune rattrape un cas que la précédente ne sait pas gérer : python src/proofreader/locator.py def locate mistake mistake: Mistake, , words: list Word - LocatedMistake | None: err tokens = mistake.error text.split if not err tokens: return None ctx tokens = mistake.context before.split Strategy 1: strict whole-word match. matched = match window ctx tokens, err tokens, words, normalize=False if matched is not None: return build located mistake, matched Strategy 2: punctuation-tolerant casefold + ASCII quotes + strip punct . matched = match window ctx tokens, err tokens, words, normalize=True if matched is not None: return build located mistake, matched Strategy 3: error text alone if it appears exactly once on the page. Catches LLM context drift in multi-column layouts. matched = find error alone if unique err tokens, words if matched is not None: return build located mistake, matched Strategy 4: substring of the concatenated normalised stream. Handles LLM tokenisation drift like d'une → d' + une , where the standalone word has no PyMuPDF token equivalent. matched = find error as substring if unique err tokens, words if matched is not None: return build located mistake, matched return None Pourquoi cet ordre exact : Strict. La fenêtre context before + error text correspond au mot près, sans normalisation. Le cas heureux : le LLM cite le PDF parfaitement, correspondance exacte, zéro ambiguïté. Tolérant. Le LLM capitalise le premier mot d'une phrase, ou remplace ' par ' apostrophe typographique . normalize casefold le tout, remplace les guillemets et apostrophes typographiques par leur version ASCII, et retire la ponctuation que PyMuPDF colle aux tokens. Error-only unique. Sur les CVs en deux colonnes, le context before que le LLM produit est parfois pioché dans la mauvaise colonne les modèles linéarisent maladroitement le multi-colonne . Si l' error text n'apparaît qu'une fois sur la page, on prend, peu importe le contexte. Ça suffit dans la quasi-totalité des cas. Substring du stream concaténé. Cas tordu : d'une est un mot pour le LLM, mais PyMuPDF le tokenise en d' + une . Le LLM peut renvoyer error text="une" comme mot isolé, sans token PyMuPDF correspondant. Solution : concaténer tous les tokens de la page en une seule chaîne et chercher en sous-chaîne. On filtre par MIN SUBSTRING CHARS = 5 , parce que sans ça un error text="une" se retrouve dans commune , lacune , tribune . Bonjour les faux positifs. Si aucune des quatre n'attrape rien, l'erreur passe dans une section « Non localisées » du résultat plutôt que d'être silencieusement perdue. Une erreur visible que l'utilisateur peut lire mais qui n'a pas son rectangle rouge, c'est moins grave qu'une erreur dont on prétend qu'elle est ailleurs. Si vous bricolez quelque chose de similaire, trois choses à retenir : instructor est conçu pour ça. piighost règle le premier point. instructor règle le deuxième. Le troisième m'a fait écrire ce projet, dont le code est ouvert. Issues et PR bienvenues. Si vous travaillez sur du texte privé avec un LLM, les trois points ci-dessus vont probablement vous parler.