JONAS SUHARD — Growth Engineer juniorParis, France ·
Jonas Suhard←

Projet

Preuve publique

Job Radar - transformer des offres dispersées en décisions explicables

Job Radar Community est un radar d'offres local et configurable. Il normalise les annonces, retire les doublons et explique séparément la pertinence, la confiance et la fraîcheur, sans publier le CV ni envoyer de candidature.

Repo GitHubConfigurer son radarArchitecture publiquePreuve v0.1.0-beta.1Version Markdown
Radar de démonstration : offres fictives classées avec score, confiance, fraîcheur, source et raison principale.
TypeRadar d'offres local et open source
PériodeAoût 2026 · v0.1.0-beta.1
RôleConception produit, architecture, développement full-stack, sécurité, QA open source
StatutBeta publique open source v0.1.0-beta.1
Niveau de preuveUn lien public permet de contrôler au moins l'élément principal.
StackPython, FastAPI, React, SQLite, Pydantic, Playwright
Ce que ça prouveLa preuve publique v0.1.0-beta.1 rapporte 336 tests backend, 36 tests frontend et 37 tests E2E sans échec, ainsi que 20 combinaisons route/viewport sans violation Axe ni débordement.
PreuvesLa preuve v0.1.0-beta.1 rapporte 336 tests backend, 36 tests frontend et 37 tests E2E sans échec ; 8 scénarios E2E sont ignorés intentionnellement. Axe et responsive ont été contrôlés sur 20 combinaisons route/viewport, sans violation ni débordement.

Besoin

Les offres utiles sont dispersées.

APIs, ATS publics, alertes et imports manuels produisent des formats différents. Relire les mêmes annonces et subir des filtres opaques fait perdre du temps avant même de candidater.

  • Comparer des offres hétérogènes sans perdre leur provenance ni les extraits qui justifient les faits.
  • Adapter les critères au parcours, aux contraintes et aux priorités de chaque utilisateur sans modifier le code.
  • Écarter les doublons et les offres trop anciennes sans confondre fraîcheur et pertinence métier.

Intention

Construire un classement utile et explicable.

Le radar transforme les annonces en faits comparables, applique une grille YAML contrôlable et rend chaque score lisible. Les données restent locales par défaut.

  • Séparer la pertinence professionnelle, la confiance d'extraction et l'âge de l'annonce.
  • Expliquer les axes, règles, bonus, malus et blocages avec les extraits source associés.
  • Permettre de configurer profil, recherche, scoring, sources et taxonomie sans toucher au code.
  • Garder les entrées et le classement locaux dans cette beta, puis conserver une validation humaine avant toute candidature.

Architecture

Des entrées locales au score expliqué.

Chaque étape conserve sa provenance. Le navigateur présente les résultats ; le noyau local reste la seule source du calcul.

Schéma de l'architecture livrée : corpus hors ligne local_demo ou import JSON local normalisé, sans accès distant dans cette beta.
Schéma de l'architecture livrée : corpus hors ligne local_demo ou import JSON local normalisé, sans accès distant dans cette beta.
  1. La beta publique reçoit uniquement le corpus hors ligne local_demo, fourni, ou un import JSON local normalisé ; elle ne livre aucun connecteur distant.
  2. Le noyau Python normalise, canonicalise, déduplique et extrait les faits avant d'appliquer la configuration YAML.
  3. Le score, la confiance et la fraîcheur sont persistés dans SQLite puis exposés par une API FastAPI locale.
  4. L'interface React affiche Radar, Insights, Sources et Configuration sans recalculer le score côté navigateur.

Aperçu

Ce qui est visible.

Détail d'une offre fictive : score par axe, règles appliquées et explications restent visibles.
Détail d'une offre fictive : score par axe, règles appliquées et explications restent visibles.
Insights calculés depuis la base locale : décisions, compétences demandées et santé du corpus.
Insights calculés depuis la base locale : décisions, compétences demandées et santé du corpus.
Le radar conserve filtres, score, confiance, fraîcheur et décision sur un écran mobile de 390 px.
Le radar conserve filtres, score, confiance, fraîcheur et décision sur un écran mobile de 390 px.

Contraintes

Ce qu'il fallait respecter.

  • Préserver la version personnelle et son historique tout en reconstruisant une édition publique par liste blanche.
  • Fonctionner hors ligne avec un corpus fictif et garder les données utilisateur sur la machine par défaut.
  • Refuser le crawl automatique des sources qui ne l'autorisent pas et rendre leur politique visible dans l'interface.
  • Rester configurable sans masquer les règles derrière un modèle opaque ou un service cloud obligatoire.

Décisions

Pourquoi ces choix.

DécisionPourquoiÉcarté
Noyau déterministe et configuration YAMLLes critères restent auditables, versionnables et modifiables sans toucher au code.Un classement LLM opaque impossible à reproduire précisément.
SQLite et API loopbackLa démonstration reste locale, légère et utilisable sans compte cloud.Une base distante obligatoire pour un outil personnel.
Entrées locales explicitesLe corpus local_demo fourni et l'import JSON local normalisé rendent la provenance contrôlable sans dépendre d'un service distant.Présenter des connecteurs distants comme livrés avant de valider leur accès, leurs conditions et leurs limites.
Score, confiance et fraîcheur séparésUne offre peut être pertinente mais ancienne, ou bien extraite avec peu de certitude ; le produit ne mélange pas ces signaux.Un score unique dont les causes seraient impossibles à lire.

Livraison

Ce que j'ai livré.

  • CLI Python pour initialiser, valider, diagnostiquer, rafraîchir, importer et recalculer les offres.
  • Pipeline de normalisation, déduplication, extraction de faits et scoring configurable avec provenance.
  • API FastAPI locale, stockage SQLite et interface React responsive en quatre vues.
  • Corpus local_demo hors ligne de 42 offres fictives, import JSON local normalisé et documentation de configuration.
  • Contrats de sécurité, audits publics et archive de release reproductible.

Résultats

Ce qui fonctionne aujourd'hui.

  • 336 tests backend, 36 tests frontend et 37 tests E2E réussis ; 8 scénarios E2E ignorés intentionnellement.
  • 20 combinaisons route/viewport contrôlées à 320, 390, 768, 1024 et 1440 px, sans violation Axe ni débordement.
  • Audits de l'arbre public, de l'historique propre, de l'archive, des distributions Python, des dépendances et des captures : zéro finding déclaré dans la preuve v0.1.0-beta.1.
  • Corpus de démonstration de 42 offres fictives utilisable hors ligne et sans clé API.

Pas encore mesuré

Ce qui n'est pas encore mesuré.

  • Adoption externe, candidatures obtenues et gain de temps réel : pas encore mesurés pour cette beta.
  • Qualité du classement sur un corpus professionnel réel : la démonstration publique utilise 42 offres fictives.

V2 / suite

La prochaine étape.

  • Recueillir des retours utilisateurs publics pour calibrer la grille et les presets sans imposer un profil universel.
  • Étudier France Travail, Adzuna, Jooble, Remotive et les ATS publics comme connecteurs futurs, uniquement lorsque leur accès, leur API, leurs conditions et leurs limites le permettent.