Le problème produit.
Les informations professionnelles se dispersent souvent entre d’anciens CV, des plateformes d’emploi, des notes et des portails de candidature. Les outils AI génériques ajoutent un risque : une réponse soignée peut perdre le lien avec le fait qui la justifie.
CareerOS Local a d’abord été conçu comme un registre de travail. Expériences, formations, compétences et réalisations conservent leur provenance, leur état de vérification et leur historique. Le LLM analyse ensuite ce registre maîtrisé pour le matching et le coaching, au lieu d’inventer un second profil déconnecté.
Ce que le système doit protéger.
L’architecture suit quatre contraintes produit :
- Les données professionnelles privées, les documents générés et les analyses restent sur l’appareil.
- Le matching et le coaching assistés par LLM exigent un runtime local approuvé ; aucun modèle cloud ne sert de solution de repli.
- Les suggestions générées ne peuvent pas remplacer silencieusement les faits sources ni leur historique.
- Sauvegardes, exports et effacement doivent couvrir ensemble les données structurées et les artefacts locaux.
La décision de conception.
La difficulté n’était pas d’ajouter une fenêtre de chat. Il fallait séparer les preuves, l’état déterministe des workflows et l’interprétation du modèle. Ces trois domaines ne présentent pas les mêmes défaillances et ne doivent pas partager une structure de données vague.
Je les ai répartis entre un coffre de carrière, des registres reproductibles de préparation et de candidature, et des pipelines d’analyse locale validés par schéma. L’interface peut montrer l’origine d’une conclusion et la correction qui appartient au fait source.
Un runtime local supervisé.
Tauri gère l’application de bureau et supervise un sidecar FastAPI sur loopback. React fournit l’espace de travail, SQLite et les artefacts locaux conservent le registre durable, tandis qu’un runtime géré compatible avec llama.cpp exécute l’analyse LLM obligatoire sans devenir une couche de stockage.
Les choix qui en font un véritable utilitaire.
Le produit utile est le workflow complet construit autour du modèle.
Conserver la provenance dans le registre
Les faits professionnels gardent leur source, leur état de vérification et leurs révisions. Le CV et les preuves de candidature peuvent remonter à ce registre.
Cette structure est plus exigeante qu’un profil libre, mais elle rend possibles les corrections et les audits.
Exiger l’analyse locale
Le matching et le coaching restent bloqués jusqu’à ce que le runtime local approuvé soit prêt. L’application n’envoie jamais la tâche à un modèle distant par commodité.
La première configuration est plus lourde et dépend du matériel, mais la limite de confidentialité reste honnête.
Regrouper les candidatures comme preuves
CV versionnés, réponses, correspondances d’exigences et fichiers vérifiés s’exportent avec un manifeste SHA-256 canonique.
Un dossier demande plus de rigueur qu’un répertoire de fichiers épars ; il est aussi reproductible et vérifiable.
Comment le produit est vérifié.
Le dépôt teste les services Python, le comportement React et l’intégration de bureau Rust. Les migrations suivent des cycles upgrade, downgrade puis upgrade. Les tests inspectent les sauvegardes v1 à v4 sans mutation, puis vérifient remplacement, détection de corruption et rollback contrôlé sur des données locales temporaires.
L’automatisation contrôle aussi les licences, les SBOM, les conteneurs et la politique de vulnérabilités critiques. Les captures du parcours produit proviennent de l’application réelle avec des données fictives ; l’enregistreur refuse les erreurs du navigateur, les réponses API en échec et les alertes visibles.
Ce qui existe aujourd’hui.
CareerOS Local est un utilitaire de bureau fonctionnel avec coffre de carrière, studio de CV, pipeline privé d’opportunités, dossiers de candidature, sauvegardes, exports et runtime supervisé d’analyse locale.
Il ne prétend pas qu’un LLM puisse décider d’une carrière. Le modèle aide à interpréter un ensemble de preuves maîtrisé ; l’utilisateur conserve le registre, les sources et la décision finale.
Registre des preuves.
Le dépôt actuel consigne ces vérifications et limites reproductibles :
- Backend
- 1 369 tests réussis sur la candidate v1.6.0 ; une revue indépendante a rejoué 42 tests de portabilité et de stockage.
- Frontend + shell
- 334 tests frontend dans 64 fichiers et 17 tests de bibliothèque Rust réussis, dont le writer natif de sauvegarde.
- Assurance des sauvegardes
- Les archives des versions 1 à 4 subissent un preflight complet sans mutation ; la réponse contient des métadonnées bornées, pas le contenu de l’archive.
- Fixture à grande échelle
- Une fixture d’agenda de 10 000 candidatures mesure un p95 de 68,670 ms face au budget projet de 200 ms.
- Limite
- Les reçus locaux ne protègent pas contre un processus capable d’écrire directement dans la base ; les imports non signés sont mis en quarantaine.